聪明就是知道自己想要什么。
明智就是知道自己不想要什么。
为了变得聪明，你需要在你的头脑中有模型。模型是用数学和图表表示的形式结构，它帮助我们理解这个世界。掌握模型可以提高我们推理、解释、设计、沟通、行动、预测和探索的能力。当我们的思维被不同的、逻辑一致的、经验验证的框架所支配时，我们更有可能做出明智的选择。
我们将用三个博客来探索由 DevOps Dojo 区开发的以产品为中心的模型和精益产品模型。这个博客是第一部分。
介绍
在 Dojo 的愿景和策略的最初构想中，一个关键组件是定义一个完整的端到端 DevOps 分类法，用于 DevOps 功能的分类，以及分类的基本原则。我们都明白，文化，包括人和心态，是一个重要的支柱。我们都同意科技是支柱。我们还有意将架构作为一个支柱，因为它是 DevOps 中一个经常被低估但又非常关键的组件。最后，我们把进程作为一个支柱，尽管我们的大多数辩论都是关于这个支柱的。
Value Stream Mapping
我们建议作为 Dojo 流程的第一个选项是 Value stream mapping 的，因为它在我们的支持组织中得到了广泛的使用。虽然它是一个评估价值流和识别浪费的伟大过程，但它没有描述 DevOps 中理想的目标过程应该是什么。此外，它通常用于评估 IT 流程，该流程从业务涉众提出的业务需求开始。
(SAFe)可伸缩的敏捷框架(SAFe)
当提出 SAFe 方法时，反对派开始蜂拥而至。事实上，微软的产品组从来没有使用过 SAFe，我们的服务组织也没有 SAFe 方面的专业知识，所以使用 SAFe 作为我们的流程是没有意义的，因为我们不能言行一致。
其他程序架构
还有其他的选择，比如 IT4IT 和 ITIL，但是它们不符合我们的战略ーー我们在 DevOps 中使用的是业务、 IT 和以人为中心的设计的联合空间。
说到战略，重要的是要理解战略的核心有三个要素: 问题分析、指导原则和连贯的行动。那么，我们试图解决的问题是什么？正如我们的博客 # 1所提到的，我们的 DevOps 观点不仅仅是 Dev + Ops 的 IT 功能。我们的 DevOps 人员 MECE (相互排斥，集体穷尽)原则包括业务，IT，客户和合作伙伴。因此，这个过程必须涵盖的不仅仅是 IT 组织。
以产品为中心的模式
根据研究文章，Gartner 预测2020年: 敏捷和 DevOps 是数字化转型的关键,
“在未来，我们将不再有敏捷、 DevOps 和项目团队之间的分歧对话。这将是一场以产品为中心、以客户价值为唯一焦点的价值流对话。”
这项研究表明，该行业正在从项目为中心的模式转向产品为中心的模式。
当我们设计 DevOps Dojo 时，我们并不认为 Dojo 只是一个短期程序。我们相信 Dojo 对于微软内部服务和我们的客户来说都是一个变革性的程序，因此我们的目标远远超过了短期目标。以产品为中心的模式对于大多数仍然以项目为中心的行业客户来说可能是新的，但是以产品为中心的模式对于像微软这样已经制造软件产品几十年的产品公司来说并不新鲜。正如您所看到的，我们的愿景超越了以产品为中心的模式。
在收集了来自行业分析师的大量研究，回顾了来自以产品为中心的模型中的思想领袖的研究，并在 Dojo 区中进行了许多激烈的辩论之后，我们在2019年初夏着手于名为“精益产品”的过程支柱。
为这个过程命名仅仅是这个过程的开始，因为我们精益产品的道路一直是崎岖不平的。让我们回顾一下我们的历史，了解一下我们到目前为止所学到的东西。
我们中的一些人对精益产品充满热情，我们按时完成了我们的白带视角和练习。我们决定在从 区收集更多的评论和反馈之前发布它。带着来自核心团队的极大兴奋和高度期望，我们同意在我们最大的内部面对面 Dojo 准备活动之一中向四个主类提供白带精益产品内容。那是在大流行之前。
唉，我们跌跌撞撞的，但是为什么呢？
在我们的回顾中，我们学到了一些很好的经验教训，关于我们在设计过程中没有考虑到的东西:
- 参与者不明白为什么我们在服务组织中采用以产品为中心的模型，因为我们在交付中一直使用以项目为中心的模型。
- 参与者不理解以产品为中心的模型，更不用说理解以产品为中心的精益模型了。
- 我们没有提供一个观点来描述如何从以项目为中心的模型过渡到以产品为中心的模型。
- 我们没有提供一个观点来描述两个模型之间的角色差异以及如何从人的角度转换。
- 我们没有提供与服务交付的以产品为中心的模型相关的契约选项的观点。
尽管遇到了挫折，但我们并不认为这是一次失败，而是在这个重要问题上的一次很好的学习经历。我们决定重新设计白带、橙带、绿带和黑带的整个精益产品内容，并采取以下指导原则和一致行动:
- 白带涵盖了以产品为中心的模型的基础知识
- 橙色腰带覆盖精益产品模型的所有元素
- 绿带覆盖精益产品模型的透镜视图
- 黑带覆盖精益产品模型的 C 级视图
值得一提的是，我们学到了一个很好的领导力教训:
“一个好的领导者不能超前于他的追随者太多”
富兰克林·德拉诺·罗斯福
白带产品中心模式介绍
基于我们从以前的错误中学到的东西，我们在 Dojo White Belt 中使用以下内容重新讨论了我们的设计。在新的设计中，我们有两个假设。首先，我们假设大多数人都熟悉以项目为中心的模型，因此在以项目为中心的模型和以产品为中心的模型之间进行清晰的比较应该会导致对以产品为中心的模型的更好和更广泛的接受。其次，我们假设服务组织中的大多数人愿意讨论这个模型将如何影响服务组织，包括合同选项、资源规划、技能准备等。
我们将讨论以下主题:
- 以项目为中心的模型与以产品为中心的模型的可视化示例。
- 课堂练习讨论他们对项目和产品的观察。
- 项目中心模型与产品中心模型中角色的比较。
- 如何从以项目为中心的模式过渡到以产品为中心的模式。
- 与服务组织中的以产品为中心的模型相关的各种主题。
为什么要使用以产品为中心的模型
帮助参与者快速认识到以产品为中心的模式的好处的最好方法是创建一个对比。因为一张图片胜过千言万语，我们决定把两个模型并排比较，然后我们要求参与者分享他们自己的观察得出自己的结论。参与者立即意识到以产品为中心的模式能够带来什么。理解和接受该模型是向以产品为中心的模型过渡的一大步。
下面是我们在课堂上使用的一个案例研究。
在这里，我们有一个时尚公司，提供现场和在线服务的客户购买时尚产品从该公司的商店或在线 站。随着时尚界对个性化服装的需求与日俱增，为了支持可持续发展，该公司决定增加一项名为“ New Look”的新服务。这项服务允许顾客从名人照片、 交媒体或他们自己的创作中上传他们最喜欢的外表，然后公司根据顾客的独特需求为他们制作个性化的外表。
以下是构建新服务时以项目为中心的模型的工作方式
步骤1: 业务和 IT 之间的关系是，IT 主要从业务中获取详细的项目需求，根据预算执行项目，然后在接受后将它们移交给业务和操作。
步骤2: 使用“ New Look”业务用例，业务将基于业务涉众的各种输入创建和批准业务用例。一旦获得批准，业务就会创建业务需求，并要求 IT 部门提供一个估算。然后，该项目的资金将用于完成“新面貌”所需的时间。
步骤3: 一个项目团队由一个新的项目经理和一个新的架构师组成，他们都需要把项目计划和人员配置计划放在一起。与此同时，履行团队需要找到一个合作伙伴来处理履行，因为它目前还没有得到公司的支持。一个新的项目经理被指派与 站团队和市场营销团队协调各种合作，以确保每个人都与紧凑的时间表保持一致。
步骤4: 项目团队已经配备了人员，但是有很多挑战，因为对于新团队来说有一个重要的学习曲线，而且团队建立信任也需要时间。团队还需要构建 DevOps 平台和搭载新的团队成员，因此在最初的几个 sprint 中速度较低。
步骤5: 由于所有四个团队以前都没有一起工作过，所以这四个团队之间有大量的协调、协商和协调。履行团队是一个外部合作伙伴，由时间和材料(T & M)支付，但是他们很大程度上依赖于项目团队提供一个接口，这样他们就可以并行开发他们的组件。不幸的是，项目团队需要很长时间来组建一个团队和整理各种物流，所以项目团队直到几个月后才能向合作伙伴提供功能界面。
步骤6: 经过九个多月的开发，项目最终投入生产。
步骤7: 此时，项目已经关闭，因此项目团队将被释放。所有资源都被重新分配给其他新项目。
步骤8: 几个月后，新的发行没有达到目标。这种失败发生的部分原因是人工智能模型根据推荐的外观本身计算错误。更复杂的推荐模型应该被使用，例如，利用洞察力，如时尚影响者的联系和影响者的季节性更新。
步骤9: 在这一点上，原来的团队已经发布，因此需要另一轮的资金和人员配置来改善这个产品。
步骤10: 再次启动相同的进程。正如您所看到的，在这个以项目为中心的模型中浪费了太多的人力资本。
以下是构建新服务时以产品为中心的模型的工作方式
步骤1: 在这个模型中，业务和 IT 是由以产品为中心的模型组织的。
第二步: 公司是一个以客户为中心的产品公司，因为产品组织是基于客户对时尚产品的体验。有四个产品团队来支持客户之旅。
第三步: “提供时尚产品”团队专注于建立一个基于市场调研的时尚产品目录。他们是行业趋势、地区需求、竞争分析、定价和新市场方面的专家。
步骤4: “吸引客户”团队关注客户数据，包括他们的偏好、生活事件、 交 络、购买习惯、影响者等等。
第五步: “订购时尚产品”团队专注于他们的现场和 上购物经验，订购历史，购物车放弃，愿望清单，礼品卡，促销等。
第六步: “实现时尚产品”团队的重点是实现，回 ，信用等。
步骤7: 创建新外观的新服务将涉及客户团队、订购团队和履行团队。如果新外观很流行，也可以将其添加到产品目录中。通过客户上传的新外观，“吸引客户”团队需要捕捉关于客户的品味、喜好、厌恶、生活方式、影响者、生活事件和未来建议的洞察力。“订购时尚产品”团队需要添加新的功能，包括上传和处理媒体，客户大小的身体扫描，一个新的基于材料的价格计算器，附加要求的备注字段。“实现时装产品”团队将接受从订单输入创建定制设计，退货政策将最有可能不同于普通产品。
步骤8: 一个长期存在的产品团队负责这个新产品和史诗/特性，这大大减少了启动时间。他们把这个新产品看作是产品的任何新史诗和新特性。这些团队已经相互信任地合作了很长时间。有了这些新特性，他们可以专注于构建新功能，而不会浪费任何时间。
步骤9: 产品团队一起工作来交付这个新产品。一旦产品投入生产，产品团队就会继续开发待办事项列表中的其他新特性。
步骤10: 几个月后，如果新产品没有达到标准，同一个团队可以检查洞察力并根据学习情况决定根本原因，同一个团队可以开发新版本的功能，然后同一个团队可以测量、学习和改进。从长远来看，与以项目为中心的组织相比，以产品为中心的组织在客户体验、成本、敏捷性和业务结果方面要有效得多。
总结与体验式学习
我们在 Dojo 中的经验学习的一部分是，首先不向类提供新概念的答案或定义，而是为类提供要解决的问题。通过详细地分析问题状态，然后发现模式，班级可以作为一个团队更好地一起学习。当我们在练习之后提供了以产品为中心的模型的定义时，它确实对所有参与者都有意义。我们在下面包括了以产品为中心的模型的两个定义。
Martinfowler.com 定义: “产品模式”是一种工作方式。它是一种资助和组织软件开发的方式，与项目的开发方式有很大的不同。虽然通常适用于数字时代的企业 IT，但这种工作方式特别适合那些旨在通过数字平台推动业务的人。
Gartner 的定义: 一种以业务为中心的战略，用于交付软件和数字体验，其中开发的产品可以交付正在进行的业务能力(相对于基于项目的有限时间项目)。一般来说，产品经理拥有该产品，并对其正在进行的开发和预算负责。该产品可能存在于一个平台上，该平台本质上是构建其他产品的产品。
Model项目中心模式与产品中心模式
良好的分析通过确定局势的某些方面至关重要，从而简化了现实往往极其复杂的情况。以下是与会者在观察和讨论后得出的结论。这些类在寻找以产品为中心的模型的核心概念方面做得很好。我们在下面只列出了四个在课堂讨论中得出的比较图。
以项目为中心的模型与以产品为中心的模型的成功标准
以项目为中心的模型与以产品为中心的模型的属性
以项目为中心的模式与以产品为中心的模式
以项目为中心的模式与以产品为中心的模式的 InsideOut 或 OutsideIn
项目经理 VS 产品经理
在我们理解了这两种模型之间的差异之后，让我们来看一下项目经理、产品所有者和产品经理角色的定义。
项目经理
项目经理是项目管理领域的专业人士。项目经理有责任计划，采购和执行一个项目，在任何企业，有一个明确的范围，明确的开始和明确的完成，无论行业。项目经理作为项目代表，在问题升级到更高权力机构之前，是组织中各利益相关者提出的任何问题或差异的第一联系人。项目管理是项目的责任
产品负责人
产品所有者是一个人，而不是一个委员会。必须具备重要的相关业务背景。产品所有者是唯一负责管理产品待办事项列表的人。产品所有者负责从开发团队的工作中最大化产品的价值。
产品经理
产品经理是产品的首席执行官，因为他们推动产品的愿景、策略、(高级)设计和执行。当一个产品成功的时候，它就是每个人的成功。不幸的是，当一个产品失败时，那就是产品经理的失败。让我们来看一些产品构建中的愿景、策略、设计和执行的好例子。
许多公司误解和滥用这一角色，所以让我们给出一个更多的背景知识，成为一个好的产品经理需要什么。产品经理需要有组织知识、产品知识和行业知识。鉴于需要知识的广泛领域，在我们的行业中找到优秀的产品经理似乎非常困难，在我们的行业中，优秀的产品经理严重短缺。
正如您所看到的，项目经理、产品所有者和产品经理之间存在显著的差异。让我们看看以产品为中心的模型中的其他角色。
向以产品为中心的模式过渡
Dojo Master Class 的参与者现在理解了这两种模型之间的差异，并理解了业界转向以产品为中心的模型的原因。现在最重要的问题是我们如何从以项目为中心的模式过渡到以产品为中心的模式？
我们在课堂上花了很多时间讨论挑战。从项目转移到产品需要对企业的核心流程进行实质性的改变，包括以产品为中心的筹资模式、业务和 IT 联盟模式、团队模式、所需的技能和人才等。最后，我们都同意，领导力将在向这一新模式的转变中发挥关键作用。我们将在本博客的第3部分中更多地讨论精益产品中的领导角色。
尽管面临种种挑战，但我们一致认为，以产品为中心的模式的影响和好处，不仅可以让企业在这个不断变化的世界中生存下来，而且可以让它们在这个世界中脱颖而出。
以产品为中心的服务模式
在所有这些对话和学习经验之后，我们必须让它们都与我们的服务组织相关。问题是，在这种新模式下，服务提供商将如何改变？这包括采购模式、采购/供应商管理和合同模式的变更。我们只列出了课堂上提出的三个问题。
问题 # 1: 公司正在转向内包模式，但是在以产品为中心的模式中缺乏所需的技能，服务提供商如何提供帮助？
在课堂上，我们一致认为，对 Dojo 类型的沉浸式学习的需求越来越大，这种学习要求培训整个产品团队提高产品交付的技能。
问题 # 2: 公司已经开始从服务提供商那里雇佣多学科团队，那么这些公司是如何寻找服务提供商的呢？
据 Gartner 称，IT 服务正在发生变化。Gartner 将持续的以产品为中心的服务定义为具有长期合同的外部服务提供者，提供使用敏捷和 DevOps 方法构建、部署和支持软件的多学科团队。
一个主要的挑战是，采购团队缺乏评估和选择以产品为中心的供应商的经验。几乎所有的外包服务提供商和系统集成商都提供了一定程度的敏捷能力，但是很少有人能够提供以产品为中心的多学科团队。选择过程应该确定哪些供应商带来了真正深度的以产品为中心的体验，而不仅仅是“口惠而实不至”，例如通过认证的 Scrum Master 的数量。有些公司更有创造性，例如，他们可能会将编程马拉松或 Dojo 作为供应商选择过程的一部分。
问题 # 3: 契约模型在这个转变过程中发生了变化。在这个以产品为中心的外包模型中，最好的契约选择是什么？
在我们的课堂上，我们讨论了以下六种可能的选择。
时间及物料(测试及测试)/管理能力
这是一种非常常用的方法，因为它简单，快速到位，而且非常灵活。在供应商提供整个团队的情况下，有时会使用固定的每月“每个团队的价格”，提供混合资源作为管理能力。然而，在 T & M 和管理能力方面，客户承担了承诺的风险，而服务提供者则没有承担任何风险。
以单位为基础
许多采购组织理想的做法是按交付的工作单位支付 酬，但挑战在于找到一种有效的单位度量方法。故事点没有行业标准的定义。每个团队、项目和供应商定义故事点的方式不同。因此，不可能以每个故事点的价格为基准来验证资金的价值。
每冲刺固定价格
在每个 sprint 的开始，将要交付的一组故事或特性以通常的敏捷方式达成一致。供应商的部分收入可以作为实现里程碑(如部署最低可行产品)的保留。
基于业务结果的定价
实现这个模型很困难，因为定义一个结果并不像它听起来那么容易，而且一个业务结果可能只是部分地依赖于服务提供者。服务提供商可能不愿意基于自己无法控制的因素，将部分付款置于风险之中。此外，业务成果可能无法实现，直到数月后的项目完成，从而造成服务提供商的成本和收入之间的延迟。
基于产品结果的定价
业务结果度量业务的进展情况。产品结果衡量产品推动业务向前发展的程度。产品团队将在产品结果上取得进展，而不是在业务结果上取得进展。产品结果在产品团队的控制范围之内，但是业务结果通常需要产品团队之外的许多业务功能(如市场营销和客户支持)之间的协调。产品结果可以通过滞后指标或领先指标来衡量。滞后的度量标准在事情发生之后进行衡量。领先指标预测滞后指标的发展方向。在任何产品组织中，定义领先指标都是至关重要的，但并不容易。
使用哪种合同模式？
正如你所看到的，T & M 很容易，但客户承担了所有的风险。其它模式更为公平，但难以实施。从根本上说，需要客户和服务提供商之间的信任才能使其他模式发挥作用，而信任需要时间。
修订后的白带成果
“结果是人类行为的改变，这种改变推动了业务结果。”
– Josh Seiden，输出的结果
通过修订课程，我们在各种跨职能团队中测试了“白带”，范围从更多的技术团队到全世界所有地区更加注重过程的团队。我们收到的反馈是积极和鼓舞人心的。我们收到了调查后的结果，全球范围内的总体满意率为4.52分(满分5分)。
在更多的技术团队中，这些类有许多关于全栈特性团队将如何支持这个模型的问题。在更加注重过程的团队中，我们在实现想法和执行模型方面取得了最大的成功。同样有趣的是，我们在不同地区之间存在一些差异。最吸引人的团体来自欧洲，例如，我们在那里有一个小时的会议，在星期五下午延长到两个半小时。
通过使用假设发展的方法，我们在新的设计中验证并否定了我们的假设。此外，我们已经看到大多数类在最终的挑战竞赛中利用了以产品为中心的概念，这表明这些概念得到了很好的应用。值得一提的是，课堂上的大多数人都不明白为什么我们三年前需要转向以产品为中心的模式，但现在每个人都接受了这个概念，并积极地向我们的客户推广它。
有了以产品为中心的模型的基础知识，我们将深入研究以精益产品为中心的模型，更重要的是，我们将在下一篇博客(第2部分)中讨论如何应用精益产品模型在 Dojo 中创建我们自己的精益产品。
特别献辞
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！