产品模式 vs 项目模式: 两种团队模式的比较

项目模式是很多传统企业对 IT 进行投资的方式，相对于产品模式，项目模式在团队建设、快速反应等方面存在很多弊端，本文从多个角度比较了产品和项目两种团队模式的利弊，并在最后回答了若干常见问题。原文: Products Over Projects

软件项目模式是投资、组织软件开发的流行方式，这种模式将工作分发给临时的、只负责构建的团队，并通过业务案例获得特定回报。相反，产品模式利用长期的、负责构思-构建-运行的团队来处理长期业务问题。产品模式允许团队快速重新定位，减少端到端时间，并允许通过利用短周期迭代来验证实际收益，同时维护软件的体系架构完整性以保持其长期有效性。

作者简介:

Sriram Narayan是 Thoughtworks 数字化 IT 管理顾问，通过改变数字化/产品/工程/IT 部门的工作方式(技术运营模式)，帮助客户提高效能。Sriram 写作的关于这个主题的书《敏捷组织设计(Agile IT Organization Design)》被 Enterprisers Project(哈佛商业评论、CIO 杂志和 RedHat 联合倡议的社区)推荐为 CIO 们的必读书籍。

软件项目模式是投资、组织软件开发的流行方式，项目是根据预期的商业利益，以个案的形式进行投资，组织起一个或多个临时团队，这些临时团队的成员在项目组织之外另有长期的汇报线，员工来自"人才库"，其成员在专业领域内被认为是可替代的。通常，软件项目团队的工作是构建或增强某些系统或应用程序，然后继续其他工作。

然而，项目并不是投资和组织软件开发的唯一方式。例如，许多将软件作为产品或服务出售的公司并不以项目的形式投资、组织其核心产品/平台的开发。相反，只要产品在市场上销售，就会通过近乎永久性的团队进行产品开发和支持。预算可能逐年变化，但一般来说，足以在产品生命周期内持续投资于一个持久的核心开发组织。团队在一段时期内为一个特定的商业问题或产品工作，工作性质由要解决的商业问题而不是一系列要交付的功能来定义。这种工作方式被称为"产品模式"，反过来说，没有必要为了投资和组织这样的软件开发而构建一个软件产品。

什么是产品模式(Produce-Mode)?

"产品模式"是一种投资和组织软件开发的方式，与项目模式有很大不同，通常适用于数字时代的企业 IT，但这种工作方式特别适合那些旨在通过数字平台推动业务的组织。下面总结了两者的区别，并在本文其余部分进行了详细说明。

产品模式不只局限于销售软件的公司，在由科技平台支持的所谓科技企业中也很常见，这些平台为用户提供流媒体内容、电子零售服务、分销基金、打车、住宿、航班等服务。在更为传统、保守的企业中，产品模式在数字/产品/工程/IT 部门也开始流行了起来。例如，澳大利亚保险集团(IAG)最近从项目模式转移到以产品模式运营的更持久的平台化组织，澳新银行(ANZ Bank)也在尝试类似的做法。

在产品模式下运作的团队有几种不太理想的变体。有些地方采用项目模式投资和产品模式组织的折中方法，即使是产品模式的组织也不总是统一负责构建+运行，也有可能跨职能团队由面向不同职能负责人汇报的人员组成。

理想的产品模式团队是一个被授权的、以结果导向的、与业务能力相一致的、长期存在的、跨职能的、构思-构建-运行一体化的团队，该团队能够并且被期望去解决问题、改善业务结果，而不是按计划交付特定范围的变更。这些团队接手的通常是长期存在的问题，例如，不断提高购买成功率(减少弃购率)。问题定义也需要足够聚焦，以便各个团队能够专注于问题。例如，尽管"净推荐值"(NPS, Net Promoter Score)是一个很好的整体指标，但通常过于宽泛，不适合指派给任何特定团队负责。

产品模式中，不仅团队长期存在，团队与问题域的联系也是长期存在的。产品模式团队通常以基于 pull 的开发模式(pull-based development mode)运作，专注于实现流程，较少强调基于故事的估算或者发布计划实现可预测性。

以产品模式运作的好处

在今天(2017 年)的商业环境中，以产品模式运作比以项目模式运作有几个优势。

快速调整方向的能力

过去，IT/工程部门在收到市场情报或反馈后的一年内作出反应就足够了。随着"数字化"成为主流，这种情况已不复存在。以在线零售为例，一般来说，基本的在线零售平台的功能可以分为商品目录、订单管理、支付和履行。

在项目模式下，可能在某个时间点上，由于优先级的原因，需要完成一个影响订单管理、支付和履行的项目，但没有影响到商品目录。现在，如果意外收到来自市场或商业利益相关者的与商品目录有关的反馈，不会有一个团队准备好对这些反馈采取行动。通常情况下，任何新的反馈都会被默认为要经过商业案例和项目审批流程，然后再根据优先级进行人员配置。即使可以暂停某个正在进行的项目，并将团队重新安排到商品目录中，该团队也可能对商品目录不熟悉，无法立即投入工作。

相比之下，在产品模式下，会有一个长期团队，专门负责商品目录、订单管理等，并随时准备根据新的反馈采取行动，只需要产品所有者和业务相关方决定释放一些团队能力来处理新问题。这种快速调整团队的能力是更好的响应能力的首要组成部分。

缩短端到端周期时间

周期时间是响应性的常用度量指标，完整的周期时间包括调整方向的时间和执行的时间。我们现在来研究执行部分。

大多数企业 DevOps 计划根本不会改变"变更"和"运行"团队之间的分离。通常，两个团队都会采用某些新工具、某些部署和基础设施自动化，可能还会基于某些"云"作为不错的补充设施，从而可以获得更频繁、自动化和可靠的部署等好处。

然而，由于长期存在从开发到集中化运维的切换，交付变更的端到端周期时间不会有太大变化。产品模式团队在部署和运行所构建的产品时不会面临这种切换，因此可以获得采用 DevOps 的全部潜力。应用级运维与开发人员的整合还可以促进更好的端到端迭代，以及帮助开发人员和站点可靠性工程师之间互相更好的理解。

请注意，产品模式团队通常还是需要依赖其他专业运维团队，这些团队提供自助构建和部署基础设施，管理数据中心和/或处理非应用程序级安全。即使没有与业务能力保持一致，这些团队也可以在产品模式下运行。

不要像管理城市一样管理

项目模式类似于城市的运行方式。城市的供水、卫生、交通、治安等各个部门都要保持正常运转，在这些部门工作的人相当于运营团队。另一方面，当建设新的用水或污水处理厂或引入新的地铁线路时，城市作为项目方提供资金，并由承包商执行，承包商相当于构建(变更)团队。

与现代软件团队的"谁构建，谁运维"的精神相比，城市的方法是"你构建，我运营"，这对城市来说是可行的，尽管市民可能更喜欢看到各个领域的快速改进。另一方面，与软件的情况不同，建设/改变城市的基础设施和服务所需的技能与运营它们的技能有很大不同。对一个城市来说，维持长期的变更团队可能并不划算。项目模式对城市来说具有成本效益，但如果在商业投资上输给其他城市时，也确实为差劲的表现付出了代价。

传统的企业 IT 遵循长期"运维"团队和按需"变更"团队双管齐下的城市模式，即项目方法，并在业务响应性方面付出了代价。数字时代的企业无法承受对业务利益相关者或市场反馈的迟缓反应。与业务能力保持一致的团队需要有资金、人员配置和随时切换重点/方法的权限级别。

真正迭代的能力

首席运营官经常抱怨技术团队的成本。然而，他们错过了最大的省钱机会，因为问题的根源不在技术领域。大型项目的构思和投资都是一蹴而就的，没有有效机制来验证实际效益，而这些项目在交付效益方面往往没有达到预期目标。如果组织有跟踪收益实现率(实际收益/预期收益)的习惯，大多数情况下他们会感到震惊。一个真正的迭代开发过程可以很容易的失败并节省资金。

尽管迭代开发的概念已经出现了一段时间，但在实践中，迭代在大多数情况下只能达到展示 sprint 的程度。大多数 Scrum 团队都受制于基于范围的 sprint 承诺，并希望按照计划范围进行交付，而不是解决问题。为了迭代的解决问题，团队需要能够响应解决方案早期版本的反馈(使用分析、用户调查、利益相关者意见)。稳定且长期存在的产品模式团队可以选择以真正迭代的方式解决问题。

项目团队不容易脱离交付范围有两个原因。首先，通常只用于"构建"解决方案，而不是运维。因此，通过一个或多个版本构建解决方案，将其移交给"运维"团队，然后继续进行下一个项目。其次，项目资金的运作方式是，资金用于维持团队的持续时间远远短于正在解决的潜在问题的生命周期。

案例: 退休计算器

例如，某个金融服务公司批准开发一个退休计算器项目，以鼓励潜在客户购买退休产品或提高现有计划的缴费额度。该项目组只得到了构建计算器所需时间的资金，但并没有解决根本问题，即提高退休产品的购买率。另一个团队在公司网站上嵌入计算器，第三个团队建立必要的数字活动，向计算器引流。至少有三个不同的经理(主管)密切跟踪工作的完成情况，直到商业利益相关者在获得了指定要构建的东西，或者在最好的情况下，参加了为期一天的启动活动。如果交付的解决方案在市场上失利，将不得不等待新一轮资金和人员配置，以找到改进的解决方案。

适应产品模式

产品模式的组织如何满足上述情况？首先，我们不会考虑成立新团队来开发这个计算器。相反，它将被一个已经存在的、稳定的、长期的、最接近问题域的团队(即产品模式团队)所承担。在这种情况下，可能有哪些产品模式的团队？鉴于这条业务线销售的是退休产品，能否为每个退休产品设立一个产品模式团队？不幸的是，由于业务流程和逻辑的共性，以及现有系统的构造，即使从客户角度来看，每个退休产品一个团队也是不现实的。另一方面，为所有退休产品建立一个产品模式团队会过于庞大和难以管理。

相反，会有几个业务能力一致的产品模式团队。以下是对退休产品的长期客户旅程的一种划分方式: 公司入职、员工注册、退休储蓄、提款等。请注意，每个部分都是以客户为中心的，并且是一个数据和业务逻辑分布在多个系统中的分片。整个客户旅程太大，不可能由一个团队维护。因此，每个分片(业务能力)都有一个产品模式的团队。这有点类似于先前的在线零售平台的例子，整个客户旅程被划分为产品目录、订单管理、支付和履行。

现在，由于退休计算器的工作和改善注册或储蓄有关，因此属于注册或储蓄团队的职责范围。这个团队，就其通常解决的问题的性质而言，通常会有数字营销技能，并能利用团队内的营销系统和资产。该团队现在有责任提供并证明可归因于计算器的转换率提升。作为长期团队，有足够时间来迭代开发和测试解决方案的有效性，同时在空闲时间处理其他路线图上的项目。

就成本和转换增加的百分比而言，产品模式很可能比项目模式更有利。对于任何给定的组织，可靠验证这一点的唯一方法是对几个问题尝试产品模式并评估其结果。

知识沉淀

关于软件的真相是，再多的文档、交接和知识转移也无法 100%弥补团队流失。然而，这正是项目模型所带来的问题。技术能力并不存在于成熟度模型、流程模板、文档、代码或基础架构中，而是存在于团队中，并在团队中成长。

在稳定、长期的团队中，知识会更好的增长和保存，团队在同一领域工作了多年，与项目团队每隔几个月就会变化形成了对比。不可维护的代码(至少部分是)来自不可维护的团队。

尽管文档有用且必要，但在更喜欢"可工作的软件而不是全面的文档"的组织中，不能替代产品模式团队中发生的那种知识沉淀。

产品模式团队允许成员专注于特定领域(与业务一致的能力)，时间比典型的项目持续时间长得多。这有助于建立知识，提高对问题和权衡的理解，并提高与业务相关团队和利益相关者的交互质量。

当团队成员离开时，产品模式团队会失去部分知识吗？如果他们的工作基于整体范围的集体所有权，就不会。当团队成员各自拥有不同的特性或子领域时，知识沉淀就面临风险。

架构完整性

项目模式下的激励机制给团队带来了压力，使他们忽视了中期架构的完整性，而倾向于(通常被认为)短期的功能交付。由于团队并不面临这种权衡的后果，也无法从反馈循环中获益，而这种反馈循环只有在有长期团队的情况下才会出现。众所周知，项目团队由于不了解企业架构指南，或者在狭隘追求及时交付项目的过程中简单的忽略了这些指南，从而(无意中)造成了架构债务。从中期来看，这种现象损害了系统稳定性，降低了交付速度。下面是几个例子:

• 他们可能最终完成了一个低质量的系统集成，而不是与下游系统进行更高质量的集成。这损害了路线图，并增加了使用多个执行类似任务的系统维护应用程序环境的成本。

• 他们最终可能会直接集成下游系统的数据库，而不是在通过 API 公开其功能后进行集成。反过来，这会损害下游系统需要对其数据库模式进行突破性更改的任何演进。

另一方面，产品模式团队不会让其他团队与他们拥有的系统进行不恰当的集成，因为他们能够更敏锐的意识到后果。这就是"构建+运维"团队拥有系统的优势，而在项目模式下，只由运维团队拥有系统。

代码和系统所有权

团队级别的代码和系统所有权能够极大帮助团队在构思-构建-运行模式下操作的能力。所有权允许团队以更可控的方式更快的发展系统，在团队中最好以集体所有为目标，因为个人所有有一定的问题。然而，在团队之间，所有权的明确划分可以实现负责任的自治。

一些最先进的科技公司使用内部开源模型，任何团队中的任何人都可以通过向托管人(类似于开源项目中的核心提交者团队)团队发送 pull request，对几乎任何代码提出更改。

虽然这种模式可以与团队所有权共存，但往往会产生某种默认期望，即依赖团队会自己处理/实现需要的变更。这在开源项目中比较常见("发现了一个 bug？很好，请提交一个修复。")，但在大多数主流企业的数字/工程/IT 部门是不现实的。首先，很少有具备足够领域知识水平的人可以有效的对不同系统进行修改。此外，这要求所有的代码在文档、构建(如简单的签出和构建)和测试准备方面保持在可自助完成的水平，这对大多数组织来说是很高的标准。这也是为什么内部开放源码计划在大多数尝试过的主流企业中未能发展起来的原因之一。对于这样的组织来说，以可协商的依赖性作为默认期望，而不是自助服务，是很务实的选择。任何改变都必须在默认情况下得到代码所有权团队的同意和优先考虑，并由他们交付。

团队动机和动力

团队需要时间来作为整体有效工作。Tuckman 的团队发展理论认为，一个团队会经历一系列次优阶段(形成、冲突和规范)，然后才能在执行阶段找到自己的最佳状态。项目模式的人员配置在团队进入规范或执行阶段时存在解体的风险，稳定且长期存在的产品模式团队可以受益于长期的执行阶段。

研究表明，自主、精通、目标和归属感是关键的内在激励因素。产品模式团队往往比典型的固定范围的项目交付团队拥有更大的自主权和目标。因此，引入产品模式的团队通常会受到团队成员欢迎，只是管理层需要时间来适应这一新常态。

流和迭代的经济性

产品开发中，最大的浪费不是低生产力的工程师，而是在处理队列中闲置的工件。

-- Donald G. Reinertsen

目前为止，这些争论听起来可能与传统 IT 智慧相悖。但自从智能手机上市以来，商业格局已经发生了巨大变化。尽管把 IT/工程作为成本中心从来就不明智，但现在更是站不住脚了，以成本效率为主要关注点的 IT 管理从未如此适得其反。在缓慢的后端 IT 基础上创建高效的"数字化"前端组织是不够的，双模/双速 IT(Bimodal/Two-speed IT)是基于错误的前提，其始作俑者已经开始承认这一点。

传统 IT 智慧在几个方面已经过时了。一是组织 IT 团队以实现规模经济，最大限度的利用 IT 专家。在某些方面，基于项目的操作模型通过以下方式反映了这一规范: 第一，利用临时变更团队; 第二，利用用于设计、测试、部署等的共享服务。另一方面，流和迭代的经济性对目标的响应性更重要。

当加工的单位成本随着加工规模的增加而降低时，规模经济就产生了。另一方面，当处理的单位时间(对于单件流程的批量大小的端到端周期时间)随着处理流程的改进而减少时，流的经济性就产生了。由大量共享服务支持的纯项目构建团队可能有助于实现规模经济，而整合构思-构建-运行的产品模式团队则有助于实现流经济。

类似的，迭代的经济性出现在实现业务利益所需的努力随着对小变更的迭代能力的改进而减少时。只负责构建的项目团队在迭代的有效性方面面临太多的交接。此外，团队寿命也不够长，无法进行一系列持续的基于反馈的迭代。而产品模式团队，从设计上讲，没有这些缺点。

以产品模式运作的挑战

人员利用率

一个常见的担忧是:"当产品模式团队没有工作时，会发生什么？"如果团队负责的领域够大，比如商品目录或履约，这种情况就不会发生。此外，团队规模会定期(例如一年一次)进行评估，以调整变更的相对优先级。有些地方采用核心+弹性模式，即由核心员工组成团队，并与通过外包商进行弹性补充。尽管如此，如果给定的业务能力领域没有健壮或足够重要的路线图，团队将被整合(与核心团队一起)到邻近的能力域，直到下一次审查。

有时，潜在问题是:"如果我们(PMO 或同等级别的人)在给定团队的工作领域中没有优先考虑任何事情，会怎样？"答案是，产品模式团队意味着是一个被授权的、半自主的单位，因此，不完全依赖外部优先级。只有跨领域的计划才会从外部得到优先级考虑。对于路线图上的工作，团队级产品所有者被授权与业务相关者协调确定优先级。经验法则是，把三分之二的路线图工作和不超过三分之一的主动性工作作为目标。因此，投资组合管理在产品模式中经历了根本性的变化。

跨职能团队中不同角色的利用情况如何？如果没有足够工作让所有不同的角色都忙起来，会发生什么？人们会从事与其技能相关的工作，例如，业务分析师可能会执行探索性测试，QA 可能会帮助改进文档等等。一开始，他们可能需要跟随其他人来获得初始水平的技能，但很快他们就会从专家变成通才。

在谈到利用率时，必须注意优化利用率不利于减少端到端周期时间。你不能通过提高高速公路的利用率(即引入更多车辆)来改善公路上的交通流量。对利用率的主要关注是"IT 作为成本中心"思维模式的遗留物，这与数字业务格格不入。

僵化

稳定、长期的团队不是导致态度狭隘和普遍停滞的原因吗？这是有风险的，但通常情况下，技术团队总会有一些变动，从而注入了新思想。此外，许多组织投资于实践社区，即非正式的、与特定能力(如客户体验、A/B 测试等)相一致的内部网络，从而将不同团队的人聚集在一起。

新的竖井

在项目模式中，我们会遇到产品管理、架构、设计、开发、测试、运营和支持等竖井。在产品模式下，我们最终会得到新的、与业务能力一致的竖井吗？比如商品目录、订单管理、支付和履行？也许吧，但远没有面向活动的竖井那么糟糕。产品模式团队以结果为导向，最坏的结果可能是仍然朝着业务结果工作的竖井。与业务能力相一致的竖井并不像与产品开发价值流阶段相一致的竖井那样糟糕。

也就是说，我们可以通过沿着服务经验(如"从问题到解决")或业务价值流(如"从订单到现金")定义的业务一致的能力边界设置产品模式团队，在一定程度上减轻新竖井的风险。如果这对一个团队来说太大了，那么就分成多个团队(部落中的小组，就像 Spotify 流行的命名模式)，但试着让他们在同一地点工作，并指定一个服务体验专家或业务价值流所有者与细分产品所有者合作。

作为对策，对于跨越多个产品模式团队的计划，建议任命与产品所有者和业务相关者一起工作的竖井穿透、优先级谈判、依赖关系管理解决方案专家。另一个好的做法是，让员工在工作了较长时间(比如 18 到 24 个月)后可以选择更换团队。

最终，在产品模式中打破竖井可以确保一致性和自主性。老派的方法通过牺牲自主权来实现一致性。相反，我们使用对齐映射等技术来获得两方的最佳效果。

其他考虑

目前为止，我们已经从正反两方面角度来看待产品模式，最后一节将讨论其他一些常见的注意事项。

分层的团队

前面介绍的在线零售案例建议设立如商品目录、订单管理、结账和履约等产品模式团队，退休产品示例建议设立如入职、注册、保存和提取等产品模式团队。这就提出了一个问题，这些团队是否对企业应用程序栈负有端到端的责任，即从面向市场的前端系统一直到支持后台功能的后端系统(下图中的第 3 和第 4 层)，答案是"不总是"，原因如下:

图 1: 在线零售中分层的产品模式团队简化示例。

尽管端到端职责有助于实现结果导向，但考虑到系统架构，通常并不现实。例如，在线零售平台通常至少有网络应用和移动应用作为客户前端，有呼叫中心应用作为支持前端，有商店管理应用作为商店经理的前端。通常，这每个前端系统都有自己对底层功能(如商品目录、订单管理、结帐和履约)的依赖关系，端到端的商品目录(或任何其他功能)团队没有明确的前端系统边界。例如，如果某个功能只依赖单一的层 3 功能(如商品目录)，就有可能不用依赖层 4 的商店管理应用程序团队。上图中的商店管理功能不仅依赖商品目录，还依赖其他功能。因此，我们在层 3 和层 4 采用独立的产品模式团队，如图所示，较高级别的层是较低级别层的消费者。

一个新趋势是将前端系统分解为与层 3 功能相匹配的微前端，使得跨层 3 和层 4 的端到端团队更加容易，但大多数已经/正在转移到微服务的团队还没有计划转移到微前端。

有时存在支持多个层 2B 功能的遗留系统，可能会导致层 3 团队也依赖具有相应功能的层 2B 团队的情况。理论上，可以将层 2B 的人员嵌入相应的层 3 团队。然而在实践中，这可能会受到层 2B 容量不足或共享配置管理、测试环境等实际挑战的限制。

层 1 和层 2A 是持续交付、DevOps 和精益产品开发的推动者，更适用于跨业务领域。例如，流水线基础设施团队负责维护 Jenkins/GoCD/TeamCity 等基础设施，他们不负责处理高级团队的构建问题。因此，较高的层可能对较低的层有一个或多个依赖。无论层级如何，从某种意义上说，每个团队都是产品模式，是稳定、长期、跨职能、以结果为导向、构思-构建-运行一体的团队。较低层的团队以解决问题(而不是固定范围的交付)的方式将较高层的团队视为(内部)客户。

小组(Squad)和部落(Tribe)

通常，像商品目录这样的单一领域对单个团队来说可能太大了，可以将其分成多个产品模式团队。在这种情况下，商品目录部落有多个小组，每个小组都有自己的结果、路线图和系统。对于很难嵌入到每个小组中的角色，这种架构还允许本地共享(部落内部)角色。要注意，尽管团队成员可能会被故意要求在部落内轮换，例如，18 到 24 个月的间隔，以获得知识的广度，并避免成为单点故障，但团队寿命要比典型的项目团队长得多。

但产品在哪里?

重申一开始提出的观点，构建以产品模式运行的产品是没有必要的。也就是说，如果我们超越传统的产品定义，即在市场上销售的东西，那么就有可能将商品目录之类的东西视为产品。一旦像商品目录这样的功能包含在团队负责的系统中，并通过内部应用或有良好文档的 API 公开，就变成了可重用、可自服务、迎合内部客户的类似产品的功能。这同样适用于较低级的产品模式团队。

结论

综上所述，为了取得更快的响应能力和更高的收益率，"产品模式"是一种比项目更有效的工作方式。

面向主流企业数字化/产品/工程/IT 部门来说，可能感觉像是彻底的变革，在某种程度上确实如此。然而，因为我们太沉迷于以"项目"的方式做事，只是让人感觉激进。亚马逊首席技术官沃纳·沃格尔斯(Werner Vogels)在 2006 年采用了类似的方法:

在 Amazon 使用的细粒度服务方法中，服务不仅表示软件架构，还表示组织架构。服务拥有强大的所有权模式，再加上团队规模较小，使得创新变得非常容易。在某种意义上，可以把这些服务看作是大公司内部的小创业公司。这些服务需要高度关注他们的客户是谁，无论是外部的还是内部的。

-- Werner Vogels

要迁移到产品模式，最好采用迭代和低失败成本的方法。从一两个试水项目开始，学习并适应。尽管对那些习惯于批准带有详细路线图的大变革项目的人来说，可能感觉不可靠，但在验证实际(而不是预计)收益之前避免过度投资是精益敏捷思维的精髓。

FAQ

如何解决产品模式中的安全性和法规遵从性问题?

就其本身而言，与项目相比，产品模式并不需要非常不同的方法来解决这些问题。也就是说，产品模式不鼓励将这些关注点完全分离为专门的共享服务。通过内部咨询方法，安全和合规专家使小组和部落能够在这些领域获得一定能力，同时继续提供全面的审查/审计/控制功能。虽然不是产品模式直接要求的，但响应性的要求鼓励转向自动化审计。详情请参阅这篇文章。

为了保持双模/双速 IT，不能以产品模式运行数字组织而以项目模式运行 IT 组织吗?

双模/双速(Bimodal/Two-speed)方式基于一个错误的前提，即可以以敏捷的方式或以可靠的方式构建软件，而不能两者兼而有之，它忽略了敏捷工程技术通过可靠性来实现速度这一点。

在这个平台时代，为什么要谈论"产品优于项目"?

同样，本文不是关于构建产品的，而是关于组织和团队以产品模式而不是项目模式工作。通过这种工作方式，通常会在内部或外部创建对业务有意义的平台。例如，分层团队的示例让层 3 为层 4 的跨渠道消费开发内部业务 API 平台。

难道不应该以客户为中心而不是以产品/项目为中心来组织吗?

通过建立团队来解决问题，而不仅仅是交付固定范围的内容，产品模式比项目更能以客户/市场/业务为中心。

产品模式如何与外包团队一起工作?

在产品模式中，没有项目要外包给供应商。相反，供应商可能会被要求提供一个稳定、长期、构思-构建-运行一体的团队，其中某些关键角色由内部人才组成。

与特性团队相比如何?

特性团队通常不是构思-构建-运行一体的团队，而只负责构建。他们构建一个又一个特性，没有太多构建时的交接或与其他团队的依赖关系。这些特性可能不在业务领域的同一子区域中。知识沉淀可能有风险，因为尽管团队本身可能是长期存在的，但与业务领域的关联却不是。

产品模式如何符合康威定律?

就组织的沟通架构影响系统设计的程度而言，我们可能会看到架构边界沿着分层团队插图中描述的路线发展/强化，即使这样的边界还不存在。因此，在产品模式下操作可能有助于摆脱单一的企业架构。

产品模式团队在开发了产品/应用程序后要做什么?之后主要是维护?

"构建一次，然后维护"是老派的做法，会导致产品不达标，即浪费投资。产品模式最适合于不断发展的产品/应用/功能/平台，在这种情况下，开发和维护是齐头并进的，直到生命终止。也就是说，如果我们在"功能"粒度上问同样的问题，那么答案是他们会解决其他问题(通过新的/增强的功能/体验来解决)。

当系统所有权受到大型单体系统的限制时，产品模式是否可行?

单体可能必须由许多小组甚至部落共同拥有(为了构建和运维)。有时，如果整个工作流程表明某个特定的小组或部落将不得不比其他团队更频繁的对整体进行更改，那么有可能分配临时所有权(例如一年)。在此期间，所属团队将为传入的依赖项提供服务。在某些情况下，共享"运维"所有权可能会有问题，我们可能不得不将一些"运维"功能分配给单独的、专用的运维团队，直到整个系统被分解成更小的系统。

如何在产品模式中解决技术债问题?如果被授权的产品所有者总是选择优先考虑功能呢?

产品负责人应该听取技术负责人和企业架构师的建议，优先考虑技术债方面的工作。他们可能会选择暂时推迟技术债工作，以支持新功能，但最终，他们(和团队)负责以稳定的方式解决问题。如果技术债得不到解决，问题必然会以某种形式重新出现。在权衡两者优先级方面有困难历史的组织可以使用决策记录为过程带来某些严谨性。

产品模式是否需要不同风格的治理?

从项目模式到产品模式的过渡也意味着从固定范围交付团队到问题解决团队的过渡。相应的，我们更看重价值而非可预测性。在产品模式下，增加价值的人与追踪价值的人的比例上升了。强调流而非利用率的基于 pull 的交付技术更适用于产品模式。

对统一汇报层次结构的需求是否意味着产品模式团队最终要向业务汇报?

不一定。将部落级别的产品负责人看作是与一个或多个业务产品负责人/经理(负责损益表或汇报给负责损益表的人)一起工作的软件产品负责人。软件产品负责人最终向 CTO、CPO、CDO 或 CIO 报告。

将软件开发成本资本化的能力是否会因为转向产品模式并且不断演进的软件开发而减弱?

这是一个常见的误解，答案恰恰相反。与传统的线性方法相比，早期和持续地关注业务价值可以使更多的精力资本化。

团队仍然需要时间表吗?

尽管产品模式是为稳定、长期存在的团队而不是项目提供资金，但我们仍然希望跟踪为解决给定问题所花费的精力。因此，时间跟踪可能仍然是必要的，但时间表并不是唯一的方法。例如，可以使用敏捷项目管理工具来报告用户故事的进展时间。

做出改变的具体步骤是什么?

这超出了本文和 FAQ 的范围，但简单来说，首先要让高管们接受技术和业务。这也有助于理解，为什么尽管最初有一些计划和专家指导，但真正的变化是在执行过程中慢慢学习、实现的。

构思-构建-运行团队是否偏离了谷歌的专职 SRE 团队模式?

是也不是。构思-构建-运行团队可以与层 2A 的 SRE 基础设施团队共存，后者也可按需提供 SRE 咨询。Björn Rabenstein 和 Matthias Rampke 在《Seeking SRE》一书中介绍了他们在 SoundCloud 的经历。结论是，在团队规模小于谷歌/Netflix 的情况下，对于能够有效处理来自应用领域的各种特定领域警报的专职 SRE 团队来说，成本可能是令人望而却步的。

在采用产品模式之前，不需要关注 IT 效率以避免对齐陷阱吗?

IT 效率是必须的，但它也是一个变化的目标。如果到 2018 年，你仍然有机会按部就班的做，那就这么做。另一种方法是在 IT 效率方面全力以赴，采用产品模式进行深度优先(垂直切片)。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。

微信公众号：DeepNoMind