产品胜过项目

快速调整的能力

过去，IT/工程只需在收到市场情报或反馈后一年内做出反应就足够了。随着“数字”成为主流，这种情况不再适用。让我们以在线零售为例。从广义上讲，基本在线零售平台的功能可以分为目录、订单管理、支付和履行。

在项目模式中，可能在某个时间点，由于优先级的原因，我们有影响订单管理、支付和履行的活动项目，但没有影响目录。现在，如果我们从市场或业务利益相关者那里收到意外的、与目录相关的反馈，我们将没有一个团队到位，可以随时对反馈采取行动。通常，任何新的反馈都会默认地受到商业案例和项目批准流程的约束，然后进行优先级排序以进行人员配备。即使我们可以暂停其中一个活动项目并将团队重新部署到目录，该团队也可能不熟悉目录，因此无法立即投入工作。

相比之下，在产品模式中，我们将有一个或多个长期团队专门负责目录、订单管理等，并随时准备对新的反馈采取行动。它只需要团队的产品负责人及其业务对应方做出决定，将部分团队容量转移到新的信息上。这种快速调整就绪团队的能力是提高响应能力的第一个组成部分。

减少端到端周期时间

周期时间是衡量响应能力的常用指标。整体周期时间包括重新定向时间和执行时间。现在让我们来考察后一个组成部分。

大多数企业 DevOps 倡议根本没有改变“变更”和“运行”组织之间的分离。通常，这两个组织都会采用一些新的工具，一些部署和基础设施自动化，也许还会加入一些“云”来锦上添花。他们甚至可能实现一些好处，例如更频繁、自动化和可靠的部署。

然而，由于开发到集中式运维的交接仍然存在，交付变更的端到端周期时间并没有太大变化。产品模式团队在部署和运行他们构建的内容时，不会遇到这种交接。因此，他们可以充分发挥 DevOps 采用的潜力。将应用程序级运维与开发人员合署办公，也有助于促进更好的端到端迭代，以及开发人员和站点可靠性工程师之间更好的理解。

请注意，产品模式团队通常会继续依赖其他专门的运维团队，这些团队提供自助式构建和部署基础设施，管理数据中心，或负责非应用程序级别的安全。即使这些团队不与业务能力保持一致，它们也可能以产品模式运行。

真正迭代的能力

首席运营官经常抱怨技术组织的成本。然而，他们错过了节省资金的最大机会之一，因为其根本原因不在技术领域。大型项目是一次性构思和资助的，没有有效的机制来验证实际效益。这些项目经常在交付效益方面达不到预期。如果组织习惯于跟踪其效益实现率（实际效益/预期效益），他们会在大多数情况下感到震惊。真正迭代的开发过程能够以低成本失败并节省资金。

虽然迭代开发的概念已经存在了一段时间，但在实践中，迭代在大多数情况下只进行到冲刺展示。大多数 Scrum 团队都受限于基于范围的冲刺承诺，并且预期能够按计划交付范围，而不是解决问题。为了迭代地解决问题，团队需要能够对早期版本解决方案的反馈（使用分析、用户调查、利益相关者证词）做出响应。产品模式团队由于稳定且寿命长，可以选择以真正迭代的方式解决问题。

项目团队难以轻易摆脱范围交付，原因有两个。首先，他们通常只负责“构建”解决方案，而不是运行它。因此，他们会在一两个版本中构建一个解决方案版本，将其交付给“运行”组织中的团队，然后继续下一个项目。其次，项目资金的运作方式是，资金的可用时间远短于所解决的根本问题的寿命。

示例：退休计算器

例如，在一家金融服务公司，一个项目获得了批准，用于开发一个退休计算器，该计算器可以促使潜在客户购买退休产品或改善现有计划中的缴款。该项目团队只获得构建计算器的资金，而不是解决根本问题，即提高退休产品的采用率。另一个团队会将计算器嵌入公司网站，第三个团队会建立必要的数字营销活动，以将流量引导到计算器。至少有三个不同的经理（主管）会密切跟踪工作的完成情况，而业务利益相关者则在指定构建内容后或最多参与一天的启动/头脑风暴后，保持距离。如果交付的解决方案在市场上没有达到预期，它将不得不等待另一轮资金和人员配备，才能找到改进解决方案的方法。

就每增加百分比的转化率的成本和时间而言，产品模式设置很可能与项目模式设置相比更有利。验证任何给定组织的可靠方法是尝试使用产品模式解决几个问题，并评估结果。

知识保留

软件的真相是，无论多少文档、交接和知识转移，都无法弥补团队 100% 的人员流动。然而，这正是项目模式带来的结果。技术能力并不存在于成熟度模型、流程模板、文档、代码或基础设施中。它存在于团队中，并在团队中不断发展。

知识在稳定、寿命长的团队中积累和保留得更好，这些团队在同一个领域工作多年。这与每隔几个月就组建和解散的项目团队形成对比。难以维护的代码至少部分是由于团队没有得到维护造成的。

虽然文档很有用且必要，但在更喜欢“可工作的软件胜过全面文档”的组织中，它无法替代产品模式团队中发生的知识保留。

产品模式团队允许团队成员比典型的项目持续时间更长时间地专注于某个领域（与业务保持一致的能力）。这有助于积累知识，提高对问题和权衡的理解，并提高与业务 SME 和利益相关者互动质量。

当团队成员离开时，产品模式团队会失去知识吗？如果他们基于对整体范围的集体所有权进行工作，则不会。当团队成员分别拥有不同的功能或子领域时，知识保留就会有风险。

架构完整性

项目模式中涉及的激励措施会给团队带来压力，迫使他们为了（通常被认为是）短期功能交付而忽视中期架构完整性。由于团队不会承担这种权衡的后果，因此他们不会从长期所有权出现时出现的反馈循环中获益。众所周知，项目团队会通过不了解企业架构指南或在狭隘地追求及时交付项目时无视这些指南，而无意中导致架构债务。从中期来看，这种现象会影响系统的稳定性，并降低交付速度。以下是一些例子

• 他们最终可能会对一个即将被淘汰的系统进行低成本集成，而不是对即将推出的后继系统进行高成本集成。这会影响淘汰路线图，并增加维护具有多个执行类似功能的系统的应用程序环境的成本。
• 他们最终可能会对下游系统执行直接数据库集成，而不是在公开其功能后通过 API 集成。反过来，这会影响任何需要对下游系统进行数据库模式更改的演变。

另一方面，产品模式团队不会让其他团队不适当地与他们拥有的系统集成，因为他们更清楚地了解后果。这就是拥有“构建+运行”团队拥有系统而不是项目模式下运行团队拥有系统的优势。

代码和系统的所有权

团队级别的代码和系统所有权极大地提高了团队以构思-构建-运行模式运作的能力。所有权允许团队更快、更可控地演化系统。但是集体所有权的理想状态呢？在团队内部追求集体所有权是件好事，因为个人所有权的替代方案是有问题的。然而，在团队之间，明确的拥有权划分可以实现负责任的自主权。

一些最先进的技术公司使用内部开源模型。任何团队中的任何人都可以通过向保管人（类似于开源项目中的核心提交者团队）团队发送拉取请求，来提议对几乎任何代码区域进行更改。

虽然这种模型可以与团队级别的所有权共存，但它往往会产生一种默认预期，即依赖团队会自行服务他们需要的更改。这是开源项目中的常见预期（“发现了一个错误？太好了。请提交一个修复程序。”），但在大多数主流企业数字/工程/IT 部门中是不现实的。一方面，很少有人拥有有效更改不同系统的领域知识。此外，它要求所有代码都以可自助服务级别的文档、构建（即简单签出和构建）和测试准备状态进行维护，这对大多数组织来说是一个很高的门槛。这是内部开源计划在大多数尝试过它的主流企业中未能起飞的原因之一。对于这些组织来说，务实的做法是将默认预期不是自助服务，而是协商依赖。任何更改都必须默认由拥有团队同意、优先排序和交付。

团队动力和动态

团队需要时间才能有效地作为一个单元协同工作。塔克曼的团队发展理论断言，团队在进入执行阶段之前，会经历一系列次优阶段（形成、冲突、规范）。项目模式的人员配备存在解散团队的风险，而这些团队恰好进入规范或执行阶段。产品模式团队由于稳定且寿命长，可以从长期的执行阶段中获益。

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

流动和迭代的经济效益

在产品开发中，我们最大的浪费不是非生产力的工程师，而是闲置在流程队列中的工作产品。

-- 唐纳德·G·莱纳森

到目前为止的论点可能听起来与传统的 IT 智慧相悖。但自智能手机进入市场以来，商业环境发生了巨大变化。虽然将 IT/工程视为成本中心从来都不是明智之举，但现在是不可辩护的。将 IT 管理的主要重点放在成本效益上，从来都没有比现在更不利。仅仅在缓慢的后端 IT 之上创建一个高速的“数字”前端组织是不够的——双模/双速 IT 是基于一个错误的前提，其实施者已经开始承认这一点。

传统的 IT 智慧在几个方面已经过时。其中一个方面是将 IT 团队组织起来以实现规模经济，从而最大限度地利用 IT 专家。在某种程度上，基于项目的运营模式反映了这种规范，一方面是使用临时变更团队，另一方面是使用共享服务进行设计、测试、部署等。另一方面，流程和迭代的经济效益对于响应能力的目标来说更为重要。

规模经济是指随着处理规模的扩大，单位处理成本降低。另一方面，流程经济是指随着处理流程的改进，单位处理时间（一批次大小为一的端到端循环时间 - 单件流）降低。由大量共享服务支持的仅构建项目团队有助于实现规模经济，而构思-构建-运行产品模式团队有助于实现流程经济。

类似地，迭代经济是指随着迭代能力的提高，实现商业效益所需的努力减少。仅构建项目团队由于存在太多交接，难以有效迭代。此外，它们的寿命太短，无法进行持续的基于真实反馈的迭代。产品模式团队在设计上不会遇到这些缺点。

人员利用率

一个常见的担忧是：“当产品模式团队没有工作时会发生什么？” 如果团队负责一个足够大的领域，例如目录或履行，这种情况永远不会发生。此外，团队规模会定期（例如每年一次）进行审查，以适应不断变化的相对优先级。一些地方采用核心加灵活的模式，即由核心员工团队和灵活的承包商补充。但是，如果某个业务能力领域没有一个健壮或足够重要的路线图，它将（连同核心团队）被合并到相邻的能力中，直到下次审查。

有时，潜在的问题是：“如果我们（PMO 或等效组织）没有优先考虑某个团队工作领域中的任何事情会怎样？” 答案是，产品模式团队应该是一个赋能的、半自治的单元，因此不完全依赖于外部的优先级。只有跨领域项目才会在外部优先考虑。对于路线图工作，团队级别的产品负责人有权与业务利益相关者协商优先级。一个经验法则是，路线图工作应占三分之二，项目工作不超过三分之一。因此，在产品模式下，投资组合管理发生了根本性变化。

跨职能团队中不同角色的利用率如何？当没有足够的工作让所有不同角色都忙碌时会发生什么？ 嗯，人们会承担与他们技能相关的额外工作，例如，业务分析师可能会进行探索性测试，质量保证人员可能会帮助改进文档等等。在开始时，他们可能需要向其他人学习以获得最初的技能水平，但很快他们就会从专家转变为通用专家。

在谈到利用率时，重要的是要注意，优化利用率不利于缩短端到端循环时间。你不会通过提高高速公路的利用率（即增加车辆数量）来改善交通流量。过度关注利用率是“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... 基础设施。他们不负责处理更高层级团队的构建中断。因此，更高层级可能对较低层级存在一个或多个依赖关系。无论层级如何，每个团队都是产品模式的，因为它们是稳定的、长寿的、跨职能的、结果导向的、构思-构建-运行团队。较低层级团队将更高层级团队视为其（内部）客户，以解决问题（而不是交付范围）的方式进行合作。

小队和部落

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

但产品在哪里？

重申一下开头提到的观点，不必构建产品才能以产品模式运作。也就是说，如果我们超越了产品的传统定义，即在市场上销售的东西，那么就可以将目录之类的东西视为产品。一旦像目录这样的能力被包含在一个由团队拥有的系统集中，并通过内部应用程序或文档齐全的 API 公开，它就会成为一个可重用且自助式的、类似产品的功能，为内部客户提供服务。同样适用于较低层级产品模式团队。