产品模式优于项目模式：为什么产品型团队更适合软件研发

软件项目，是当前软件开发中最常见的资金投入和组织方式之一。它通常根据商业论证中预估的收益获得资金支持，并以临时团队的形式组织工作。这些团队往往只负责开发，项目结束后便随之解散。

与之不同，产品模式采用长期稳定的产品型团队。这类团队负责从构思、开发到运行的完整过程，并持续围绕某一业务问题或业务能力开展工作。相比传统项目模式，产品模式让研发团队能够更快调整方向，缩短端到端交付周期，通过短周期迭代验证真实收益，同时保持软件架构的完整性，确保系统长期可演进。

软件开发为什么不能只依赖项目模式

软件项目是软件开发资金投入和组织方式的一种常见形式。项目资金通常根据商业案例中预测的收益逐项审批。项目也往往由一个或多个临时团队承担，团队成员在项目组织之外拥有各自稳定的汇报关系。他们来自不同的“人才池”，可以根据专业领域被灵活调配。

通常，软件项目团队的任务是构建或改进某个系统或应用，然后项目结束，团队解散。

然而，项目并不是软件开发资金投入和组织方式的唯一选择。许多以软件产品或服务为核心的企业，并不会以项目形式来支持核心产品或平台的开发。相反，它们会建立相对稳定的长期团队，在产品的整个生命周期内持续开展开发、支持和演进工作。

预算可能逐年变化，但通常足以在产品生命周期内持续支持一个稳定的核心开发团队。团队获得资金，是为了在一段时间内持续解决特定业务问题，或持续提供某项产品或服务；团队工作的性质由待解决的业务问题决定，而不是由一组预先定义好的功能清单决定。

我们将这种工作方式称为“产品模式”。需要强调的是，并不是只有开发对外销售的软件产品，才可以采用产品模式来组织软件开发。

什么是产品模式？

“产品模式”是一种工作方式，也是一种不同于传统项目模式的软件开发资金投入和组织方式。它普遍适用于数字化时代的企业 IT，尤其适合那些希望通过数字化平台推动业务发展的企业。

下表概述了产品模式与项目模式的主要区别，后文将进一步展开说明。

对比维度	项目模式	产品模式
资助对象	预先定义的解决方案，或待交付的项目范围	长期稳定的团队
资金如何投入	按项目逐项审批，资金用于完成既定交付范围	按滚动周期投入，例如一年一评估，团队持续围绕同一问题领域工作
资金覆盖生命周期	主要覆盖解决方案的构建阶段	覆盖构建、运行、迭代，甚至在必要时转向不同解决方案，直到根本问题被验证性解决
构思、构建、运行如何组织	通常分属不同部门	通常由同一团队承担，并具有统一的责任归属
团队持续多久	直到项目资金用完，理想情况下即预设解决方案交付完成，通常持续数周或数月	只要其路线图仍与业务相关，团队就持续存在，通常以年为单位
成员是否长期深耕同一领域	通常不是。个人下一个项目可能属于完全不同的业务领域	是。团队和成员通常长期围绕同一问题领域工作
优先级如何确定	由业务部门与项目组合管理团队共同确定	产品路线图由产品负责人及业务伙伴确定优先级；跨领域计划由业务或技术领导层确定优先级，并分配给现有产品团队，而不是临时组建新团队
收益如何验证	项目审批前重点评估预期收益；项目交付后通常缺乏验证实际收益的机制	产品负责人需要通过 A/B 测试、数据分析、用户调研或业务反馈证明产品实际效果
如何定义成功	按时、按预算交付约定范围	业务指标得到改善，且指标应直接或间接指向业务成果
团队组织是否有限制	基本没有	最有效的产品模式团队，通常同时契合业务能力边界和企业架构边界

产品模式团队的资金通常按滚动周期投入，例如一次投入一年，并定期评估。团队会持续解决大致相同领域的问题，并围绕与产品或业务战略一致、不断演进的路线图开展工作。

在产品模式下，预先评估预期收益的重要性会相对降低。尤其对于那些执行周期短、能够低成本尝试新想法的优秀团队而言，更重要的是通过小规模、端到端的迭代快速验证效果。产品负责人有权根据判断批准路线图项目的开发，并通过短周期迭代及时发现效果不佳的方案，从而低成本地快速失败。

理想情况下，每个产品模式团队都应该是一个以业务 KPI 为导向的团队。例如，一些海外互联网公司会让不同团队分别负责流量、用户互动、转化率等指标。这样的指标最好能够直接对应业务成果，或者至多与业务成果相隔一到两层。

产品模式不再局限于软件公司。它在所谓的科技企业中非常常见，这些企业依靠技术平台提供流媒体内容、电商、基金分销、出行、住宿、机票预订等服务。类似模式也正在传统企业的数字化、产品、工程和 IT 部门中兴起。例如，一些海外保险集团和银行近年也开始从项目制转向更持久的平台型组织结构，并尝试以产品模式运作。

当然，团队以产品模式运作的方式多种多样，也并非都十分理想。有些组织采用折中方案：资金投入仍是项目制，但团队组织上部分借鉴产品模式。也有一些组织虽然采用了产品式团队结构，却没有真正做到“构建+运行”一体化。还有一些跨职能团队的成员，仍分别向不同职能负责人汇报。

理想的产品模式团队，应当是一个充分授权、以结果为导向、与业务能力相契合、长期稳定、跨职能，并集构思、构建和运行为一体的团队。它不仅被要求按时交付项目范围，更被期望解决问题、改善业务结果。

这类团队承担的问题通常具有长期性。例如，持续提升购物车到结账的转化率，降低购物车放弃率。与此同时，问题定义也需要足够具体，以便单个团队能够真正负责。比如，“净推荐值”（NPS）是一个很好的整体指标，但它通常过于宽泛，难以由某个具体团队直接承担。

在产品模式下，不仅团队生命周期更长，团队与问题领域之间的关联也更长久。产品模式团队通常更倾向于采用拉动式开发，关注工作流动是否顺畅，而不是过度依赖故事点估算和发布计划来制造可预测性。

产品模式的优势：更快响应、更短周期、更高收益

在当下的商业环境中，以产品模式运营相比项目模式具有几个明显优势。

一、快速调整方向

过去，IT 或工程部门在收到市场情报或业务反馈后，只要能在一年内做出响应，通常就已经足够。但随着数字化成为主流，这种节奏已经不再适用。

以在线零售为例，一个基本的在线零售平台通常可以分为目录、订单管理、支付和物流履约等能力。

在项目模式下，某个时期可能会有一些正在进行的项目影响订单管理、支付和履约，但并没有团队正在处理产品目录相关工作。此时，如果市场或业务利益相关者突然反馈了一个与产品目录相关的重要问题，组织往往没有一个现成团队可以立即处理。

通常，这类新反馈需要经过商业案例、项目审批和优先级排序流程，然后再配置人员。即便可以暂停某个正在进行的项目，并将团队重新部署到产品目录相关工作上，该团队也可能并不熟悉该领域，因此无法迅速上手。

相比之下，在产品模式下，组织会建立一个或多个长期稳定的团队，分别负责产品目录、订单管理等业务能力，并能够随时根据新反馈采取行动。只要团队的产品负责人及其业务伙伴共同决定，就可以调整部分团队资源来处理新信息。

这种快速调整现有团队方向的能力，是提高组织响应速度的首要因素。

二、缩短端到端交付周期

周期时间是衡量响应速度的常用指标。总周期时间包括两部分：重新调整方向所需的时间，以及执行所需的时间。前文已经讨论了方向调整，接下来分析执行时间。

许多企业的 DevOps 计划，其实并没有真正改变“变更”部门与“运行”部门之间的边界。通常，这两个部门会采用一些新工具，引入部署和基础设施自动化，也许还会使用一些云技术。它们确实可能获得一定收益，例如部署更频繁、更自动化、更可靠。

但由于开发到集中式运维之间的交接依然存在，交付变更的端到端周期时间并不会发生根本性变化。

产品模式团队在部署和运行自己构建的产品时，不需要经历这种交接，因此更能发挥 DevOps 的真正潜力。应用级运维与开发人员共同工作，也有助于形成更好的端到端迭代，并增强开发人员与站点可靠性工程师之间的相互理解。

需要注意的是，产品模式团队通常仍然依赖其他专业运维团队。这些团队可能负责提供自助式构建与部署基础设施、管理数据中心，或负责非应用层面的安全工作。即使这些团队并不直接对应某个业务能力，它们本身也可以按照产品模式运作。

三、真正具备迭代能力

许多首席运营官经常抱怨技术部门成本高昂。然而，他们往往错过了一个最大的省钱机会，因为真正的问题根源并不总是在技术部门内部。

大型项目通常一次性构思、一次性投入资金，却缺乏有效机制来验证实际收益。这些项目经常无法达到预期效果。如果企业养成追踪收益实现率的习惯，也就是比较实际收益与预期收益之间的差距，结果往往会令人震惊。

真正的迭代式开发，可以用更低成本试错，从而节省资金。

虽然迭代开发的概念已经存在很久，但在实践中，很多组织所谓的迭代只是冲刺演示。大多数 Scrum 团队仍受限于基于范围的冲刺承诺，被期望按计划交付范围，而不是持续解决问题。

如果团队想以迭代方式解决问题，就必须能够响应早期版本解决方案带来的反馈，例如使用情况分析、用户调查和利益相关者反馈。产品模式团队由于稳定且长期存在，更有条件以真正迭代的方式解决问题。

项目团队很难摆脱交付范围的束缚，主要有两个原因。

首先，它们通常只负责“构建”解决方案，而不负责运行解决方案。因此，它们会通过一个或多个版本构建系统，然后移交给负责“运行”的团队，之后便转向下一个项目。

其次，项目资金的运作方式决定了团队存在的时间，往往远短于所解决问题的生命周期。

例如：退休计算器

以一家金融服务公司为例。某个项目获得批准，目标是开发一个退休计算器，引导潜在客户购买退休产品，或促使现有客户增加缴费。

这个项目团队的经费只覆盖开发计算器所需的时间，而不是覆盖解决根本问题所需的时间——根本问题是提高退休产品的购买率或参与率。

另一个团队负责将计算器嵌入公司网站，第三个团队负责开展必要的数字营销活动，以吸引用户访问计算器。至少有三位不同的管理者会密切跟踪项目进度，而业务利益相关者则通常只在开发目标确定后保持有限参与，最多参与一天左右的早期构思或孵化活动。

如果最终交付的解决方案未达到市场预期，组织就必须等待新一轮资金和人员投入，才能探索改进方案。

将其调整为产品模式

产品模式组织会如何处理上述情况？

首先，组织不会考虑为了开发这个计算器而新建一个团队。相反，这项工作会交给一个已经存在、稳定、长期运作，并且与问题领域最接近的产品模式团队。

在这种情况下，可以有哪些产品模式团队？如果该业务线销售多种退休产品，是否可以为每种退休产品设立一个团队？从客户角度看，这样似乎有一定道理。但考虑到业务流程、业务逻辑以及现有系统架构之间存在大量共性，为每种退休产品设立一个独立团队通常并不现实。

另一方面，如果为所有退休产品只设立一个产品模式团队，这个团队又可能过于庞大，难以管理。

更合理的方式，是设立多个与业务能力相匹配的产品模式团队。比如，可以按照退休产品长期客户旅程划分为：企业入驻、员工注册、退休储蓄、资金提取等阶段。

请注意，每个阶段都以客户为中心，并包含大量数据和业务逻辑，而这些数据和逻辑又分布在多个系统中。完整客户旅程过于庞大，无法由单个团队负责。因此，每个阶段，也就是每项业务能力，都可以对应一个产品模式团队。

这与前面在线零售平台的例子类似。在那个例子中，完整客户旅程被划分为目录、订单管理、支付和交付等阶段。

现在，任何旨在提高退休金参与率或储蓄率的退休计算器开发工作，都应归入注册或储蓄团队的职责范围。由于该团队长期处理类似问题，通常具备数字营销相关技能，并能使用团队内部的营销系统和资源。

该团队不仅要交付计算器，还要证明转化率提升确实来自这个计算器。作为一个长期运作的团队，它有足够时间迭代开发、测试解决方案有效性，并在此过程中处理其他路线图工作。

就提升转化率所需的成本和时间而言，产品模式很可能比项目模式更具优势。要可靠验证这一点，唯一的方法是在特定组织内选择几个问题，以产品模式尝试解决，并评估实际结果。

四、知识保留

软件开发中的一个事实是，再多文档、交接和知识转移，也无法弥补团队成员 100% 流失带来的损失。然而，项目模式恰恰很容易造成这种结果。

技术能力并不真正存在于成熟度模型、流程模板、文档、代码或基础设施中。它存在于团队之中，并随着团队长期协作而不断发展。

知识更容易在稳定且长期存在的团队中积累和保存。这些团队往往在同一领域工作多年，与每隔几个月就频繁更换成员的项目团队形成鲜明对比。

难以维护的代码，至少部分源于缺乏长期维护它的团队。

文档当然有用，也很必要。但对于那些相信“可运行的软件胜过面面俱到的文档”的组织来说，文档无法替代产品模式团队内部长期积累的知识。

产品模式团队允许团队成员在远超典型项目周期的时间里专注于特定领域，也就是与业务相关的能力。这有助于积累知识，加深对问题和权衡取舍的理解，并提升团队与业务专家及利益相关者互动的质量。

产品型团队是否会在成员离职时丢失知识？如果团队基于整体范围的集体所有权开展工作，知识流失会相对可控。但如果团队成员各自只负责不同功能或子领域，知识保留就会面临风险。

五、架构完整性

项目模式下的激励机制，往往会迫使团队为了短期功能交付而牺牲中期架构完整性。由于团队通常不需要承担这种取舍带来的长期后果，因此也无法从长期所有权模式产生的反馈循环中获益。

众所周知，项目团队经常因为不了解企业架构指南，或者为了按时交付项目，而忽略这些指南，进而无意中造成架构债务。从中长期来看，这种现象会损害系统稳定性，并降低交付速度。

例如：

他们最终可能会选择与一个即将淘汰的系统进行低成本集成，而不是投入更多精力与即将上线的替代系统集成。这会影响淘汰计划的执行，并增加维护多个功能相似系统的成本。

他们最终可能会直接与下游系统进行数据库集成，而不是先通过 API 暴露功能再完成集成。这样一来，下游系统如果需要对数据库模式进行重大调整，就会受到阻碍。

另一方面，产品模式团队不会轻易允许其他团队不恰当地集成他们负责的系统，因为他们更清楚这样做的后果。这正是“构建+运行”团队拥有系统所有权的优势所在。相比之下，在项目模式中，系统往往只由运行团队拥有，而构建团队并不长期承担后果。

六、代码和系统所有权

团队层面的代码和系统所有权，能够极大提升团队在“构思—构建—运行”模式下的运作能力。所有权让团队可以以更快、更可控的方式演进系统。

那么，集体所有权的理想状态又该如何理解？

在团队内部，追求集体所有权是好的，因为个人所有权会带来许多问题。然而，在团队之间，清晰的所有权划分能够确保责任明确，并使团队拥有真正的自主性。

一些先进的海外科技企业采用内部开源模式。任何团队中的任何成员，都可以向代码维护者提交拉取请求，对几乎任何代码区域提出修改建议。这些代码维护者类似于开源项目中的核心提交者团队。

尽管这种模式可以与团队级所有权共存，但它往往默认依赖“团队自行完成所需变更”。这在开源项目中很常见：如果发现了 bug，很好，请你提交修复。但对大多数主流企业的数字化、工程或 IT 部门来说，这并不现实。

首先，这些组织中的团队很少具备有效修改其他系统所需的领域知识。其次，这要求所有代码都保持在可自助维护的状态：文档足够完善，构建过程足够简单，测试也足够完备。对大多数组织来说，这是很高的要求。

这也是许多主流企业尝试内部开源计划却未能成功的原因之一。对这类组织而言，更务实的做法，是将默认预期设定为“协商依赖关系”，而不是完全自助服务。任何变更默认都应由拥有该变更的团队同意、排序并交付。

七、团队激励与动力

团队需要时间才能形成高效协作。团队发展理论指出，团队在进入高效执行阶段之前，会经历形成期、冲突期和规范期等阶段。

项目型团队配置模式存在一个风险：团队刚刚进入规范期或高效执行阶段，就要被解散。而产品型团队由于更稳定、更长期，能够从更长的高效执行阶段中获益。

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

八、流程经济与迭代经济

在产品开发中，最大的浪费不是效率低下的工程师，而是闲置在流程队列中的工作成果。

——一位精益产品开发研究者

以上论点或许与传统 IT 理念相悖。但自智能手机普及以来，商业格局已经发生了巨大变化。把 IT 或工程部门视为成本中心，从来都不是明智选择，如今更是难以成立。以成本效率作为主要目标来管理 IT，其弊端也前所未有地明显。

即便在缓慢的后端 IT 之上构建一个高速的“数字化”前端组织，也无法真正解决问题。双模或双速 IT 模式建立在一个错误假设之上，而这种模式的倡导者也已经开始意识到其中的问题。

传统 IT 理念在许多方面都已过时。其中之一，是为了追求规模经济并最大限度利用 IT 专家资源，而将 IT 团队按专业职能组织起来。

在某种程度上，项目型运营模式也体现了这种思路：一是使用临时变更团队，二是通过共享服务完成设计、测试、部署等工作。

然而，如果目标是提高响应速度，那么流程经济和迭代经济往往更加重要。

规模经济指的是，随着处理规模扩大，单位处理成本下降。流程经济则是指，随着流程得到优化，单位处理时间缩短，也就是从开始到完成的端到端周期时间缩短。

由大量共享服务支持的纯构建型项目团队，有助于实现规模经济；而集构思、构建和运行为一体的产品模式团队，则更有助于实现流程经济。

同样，当团队具备更强的迭代能力，能够通过小幅迭代减少实现业务收益所需的工作量时，迭代经济就会显现出来。

纯构建型项目团队由于交接环节过多，难以有效迭代。此外，它们生命周期较短，也无法持续基于真实反馈进行迭代。产品型团队的设计初衷，正是为了避免这些弊端。

产品模式下运营的挑战

产品模式具有明显优势，但也会带来一些新的挑战。

一、人员利用率

一个常见担忧是：“如果产品团队没有工作可做怎么办？”

如果团队负责的领域足够大，例如产品目录或订单履约，这种情况通常不会发生。此外，团队规模会定期审查，例如每年一次，以便根据不断变化的相对优先级进行调整。

有些公司会采用“核心团队+灵活人员”的模式：由正式员工组成核心团队，再辅以合同工等灵活人员。但如果某个业务能力领域没有足够成熟或重要的路线图，就可以将其连同核心团队并入相邻能力领域，直到下一次评审。

有时，真正的问题其实是：“如果我们，比如项目管理办公室或类似部门，不再对某个团队的工作领域做优先级排序，那该怎么办？”

答案是，产品模式团队本应是一个被赋权、半自治的单元，因此不应完全依赖外部优先级排序。只有跨领域项目才需要外部排序。对于路线图工作，团队层面的产品负责人有权与业务利益相关者共同确定优先级。

一个经验法则是：路线图工作应占三分之二，项目型工作不超过三分之一。因此，在产品模式下，项目组合管理本身会发生根本变化。

那么，在跨职能团队中，如何合理利用不同角色？如果工作量不足以让所有角色都忙起来怎么办？

现实中，人们会承担一些与自身技能相邻的工作。例如，业务分析师可以参与探索性测试，质量保证人员可以协助改进文档。起初，他们可能需要跟随其他人学习，以掌握基础技能；但很快，他们就会从单一领域专家成长为能够胜任多个领域的通才。

谈到利用率，还需要注意一点：优化资源利用率，并不利于缩短端到端周期时间。你不会通过提高高速公路利用率，也就是增加更多车辆，来改善交通流量。

过度关注利用率，是“IT 即成本中心”思维的遗留产物，与数字化业务并不匹配。

二、封闭性

稳定且长期存在的团队，是否会导致封闭心态和整体停滞？

这确实是一个风险。但通常来说，技术团队总会有一定人员流动，这能够带来新的思路。此外，许多组织会支持实践社区。这些非正式内部网络围绕特定能力展开，例如客户体验、A/B 测试等，从而将不同团队中的成员连接起来。

三、新的信息孤岛

在项目模式下，组织经常面临产品管理、架构、设计、开发、测试、运维和支持等职能部门之间的信息孤岛。

那么，在产品模式下，是否会形成新的、围绕业务能力划分的信息孤岛，例如目录、订单管理、支付和交付？

或许会。但这类孤岛远没有按活动阶段划分的职能孤岛那么糟糕。产品模式团队以结果为导向，即便形成某种孤岛，最坏情况下也仍然有助于实现业务目标。与产品开发价值流阶段相关的孤岛，远比与业务能力相关的孤岛危害更大。

也就是说，我们仍然可以通过合理设计产品模式团队，降低出现新孤岛的风险。团队可以沿着与业务相关的能力边界划分，这些边界可以由服务体验定义，例如“问题解决”；也可以由业务价值流定义，例如“订单到收款”。

如果单个团队无法覆盖完整范围，就可以将其拆分为多个团队，类似一些海外科技企业推广过的“小队和部落”命名方式。但组织应尽量让这些团队保持紧密协作，并指定一位服务体验负责人或业务价值流负责人，与各细分领域的产品负责人协作。

对于涉及多个产品团队的项目，一个有效做法是任命解决方案负责人。这个角色负责打破团队边界、协调优先级、管理依赖关系，并与产品负责人和业务利益相关者合作。

另一个好做法是，允许员工在任职较长时间后，例如 18 到 24 个月，选择更换团队。

归根结底，产品模式下“打破信息孤岛”的关键，是同时确保协同一致和自主性。传统方法往往通过牺牲自主性来换取协同一致，而更好的方式是借助协同图等技术，力求兼顾二者。

产品模式的其他组织设计问题

到目前为止，我们已经从优势和挑战两个角度探讨了产品模式。最后，还需要讨论一些常见的组织设计问题。

一、分层团队

前文提到的在线零售案例表明，产品模式团队可以包括目录管理、订单管理、结账和发货等。退休产品案例则表明，产品模式团队可以包括注册、登记、储蓄和取款等。

这会引出一个问题：这些团队是否应对企业应用栈承担端到端责任，即从面向市场的前端系统，一直到支持后台功能的后端系统？

答案是：并不总是如此。原因如下：

尽管端到端责任有助于实现结果导向，但受制于系统实际情况，它往往并不容易实现。

例如，在线零售平台通常至少包含一个网页应用和一个移动应用作为客户入口，一个呼叫中心应用作为支持前端，以及一个门店管理应用作为门店经理的前端。通常，每个前端系统都依赖底层能力，例如目录、订单管理、结账和履约。

对于一个端到端的目录团队而言，前端系统边界往往并不清晰。例如，如果门店管理应用只依赖目录这一项底层能力，也许就不需要设立单独的门店管理应用团队。但如果门店管理还依赖目录之外的其他能力，就需要采用独立的上层和下层产品模式团队。

较高层级团队依赖较低层级团队。较低层级团队同样可以以产品模式运行，并将较高层级团队视为内部客户。

一种新趋势，是将前端系统分解成与底层支持能力相匹配的微前端。这使得跨前端和后端支持能力建立端到端团队变得更容易。但目前，大多数已经或正在迁移到微服务架构的公司，并没有同步计划迁移到微前端。

有时，由于遗留系统支持多个业务能力，底层团队也会依赖具备特定技能的更基础平台团队。理论上，可以将这些基础平台人员嵌入到相应产品团队中。但在实践中，这可能受到资源稀缺、配置管理共享、测试环境复杂等因素限制。

基础设施和平台团队是持续交付、DevOps 和精益产品开发的重要推动者，它们通常服务于多个业务领域。例如，流水线基础设施团队负责维护常见持续集成工具及相关基础设施，但它们并不负责修复上层团队的构建失败。

因此，上层团队可能依赖一个或多个下层团队。无论处于哪个层级，每个团队都可以以产品模式运作：稳定、长期、跨职能、以结果为导向，并负责构思、构建和运行。下层团队也应以解决问题而非交付范围的方式服务上层团队，把上层团队视为自己的内部客户。

二、小队和部落

通常，像产品目录这样的单一领域可能规模过大，单个团队难以承担，因此可以将其拆分为多个产品模式团队。

在这种情况下，产品目录领域下可以设置多个小队。每个小队都有自己的目标、路线图和负责的系统。这种结构也允许团队在更大领域内部共享一些难以在每个小队中单独配置的角色。

需要注意的是，小队的生命周期通常比典型项目团队长得多。但为了拓展知识面，并避免形成单点故障，可以要求小队成员在较大团队内部轮换，例如每 18 到 24 个月轮换一次。

三、可是产品在哪里？

需要再次强调开头提到的一点：并不是一定要开发对外销售的产品，才能以产品模式运作。

如果我们超越“产品必须在市场上销售”这个传统定义，那么像目录这样的业务能力，也可以被视为一种产品。一旦目录之类的能力被纳入某个团队拥有的一组系统中，并通过内部应用或文档完善的 API 对外开放，它就变成了一种可复用、可自助服务、类似产品的能力，服务于内部客户。

这同样适用于更底层的产品模式团队。

结论：产品模式为什么优于项目模式

总之，如果组织希望获得更高的响应速度、更短的端到端交付周期和更高的收益实现率，产品模式通常比项目模式更有效。

对于主流企业的数字化、产品、工程和 IT 部门而言，这可能看起来像是一场彻底变革。某种程度上，它确实如此。然而，之所以感觉变革如此彻底，很大程度上只是因为我们太习惯于项目式工作方式。

某大型海外电商公司的技术负责人曾描述过一种类似方法：

在该公司采用的细粒度服务架构中，服务不仅代表软件结构，也代表组织结构。这些服务拥有明确的所有权模式，并与精简团队规模相结合，旨在极大促进创新。从某种意义上说，可以把这些服务视为大型公司内部的小型创业公司。无论客户是外部客户还是内部客户，每项服务都需要高度关注自己的客户群体。

要过渡到产品模式，最好的方式是采用迭代式、低成本试错的方法。可以先选择一两个试点，不断学习和调整。

对于那些习惯用详细路线图审批大型变革项目的人来说，这种做法可能显得不合常理。但精益敏捷思维的精髓，正是在验证实际收益之前，避免对尚未证实的方案过度投资。