当您需要多个团队来推进产品开发时，可以有以下的选择：围绕产品功能组建团队或围绕产品组件组建团队。本文解释了为什么这是个对产品人员非常重要的决策，并分享了关于何时应选择组建功能团队（Feature Teams）及何时应组建组件团队（Component Teams）更适合产品开发的一些建议。 

什么是功能团队和组件团队？ 
       功能团队是端到端实现最终用户功能的开发团队。与组件团队相比，如图 1 所示，功能团队拥有一个体系性的结构基块，例如，拥有一个层、一个子系统、一些组件或服务的集合。 
 

 图 1：功能与组件团队
 

       图 1 描述了一个简单的软件体系结构，它由三个层组成：用户界面、业务逻辑和数据。假如说我想开发一个可以帮助人们更健康的饮食的应用程序，那么功能团队可能会去开发一个允许用户查看其饮食趋势的功能，团队将从用户界面到数据层把功能进行垂直切片。但是，如果是组件团队则可能会开发计算推荐卡路里摄入量的业务逻辑，该团队不会接触任何其他层，而仅只是关注业务逻辑。 

为什么这对产品人员很重要？ 
       当产品开始吸引更多用户时，通常需要更多的开发团队来维持产品增长、增强产品功能或添加新功能。此时您可以有以下选择：主要围绕功能或围绕体系结构模块来组织团队。这个选择很重要，因为这将影响推进产品及实现其战略目标的能力。我将在下文中更详细的进行解释。 
       功能团队和组件团队都有各自的优缺点。前者强力聚焦于最终用户：他们开发基于为最终用户创造价值的功能，也直接从产品待开发列表中寻找项目，并将其加入到软件中去。此外，功能团队间松散耦合，工作并不依赖于其他功能团队。这有两个好处：首先，它允许快速去测试一个新的想法、开发一个伪功能或早期版本的功能来收集用户的反馈并及时进行调整；其次，即便一个功能团队无法及时完成交付，通常其他团队的工作仍然可正常进行。但是，使用功能团队会导致引入的用户体验和架构不一致，并可能导致大量的重复代码。在最坏的情况下，每个团队创建自己的用户体验和用户界面设计、使用独有的业务逻辑和数据层。体系结构如图 1中所示例一样。 
       组件团队可避免这些缺点。由于它们围绕体系结构基块进行组织，因此可以强制实现体系结构的一致性。此外，与功能团队相比，为组件团队配备人员可能更会容易一些。例如，在图 1 中，每个功能团队都需要有具有相应用户界面设计能力的人（这样相对组建团队来说人员组成要求更高）。缺点是，组件团队通常不直接从产品待开发列表中寻找项目。在图 1 中拥有业务逻辑和数据层的团队需要描述应创建或增强的接口的技术要求。将最终用户的需求转换为技术要求会产生额外的开销并减慢开发速度。此外，当组件团队倾向于为其他开发团队开发软件时，他们可能会忽视最终用户并对构建基块进行次优化。我见过很多更关心其组件性能而非最终用户体验的组件团队。 

       接下来我们继续讨论如何在不同的场景中选择合适的产品团队组建方式。 

何时应选择功能团队及何时组件团队会工作更好？
       我建议当您的产品发生重大变化时，就应该选择功能团队而不是组件团队。这对于全新的产品、处于引入阶段的产品、快速增长的产品或生命周期正在延长的产品来说都是标准的选择，例如那些需要打入新市场或增加新功能的产品。但是，一旦您的产品稳定并进入成熟阶段（也就是不打算延长其生命周期时），那么组件团队往往是一个更好的选择，正如图2所示。 
 

图 2：功能和组件团队以及产品生命周期

       功能团队允许您快速移除、添加新功能、响应用户反馈以及调整产品。这使得它们更适合去应对创新、不确定性和变化等存在于产品早期生命阶段及生命延长阶段的挑战。
       组件团队通过最大化重用和确保架构完整性来帮助降低成本并提高盈利能力。这对于成熟或处于下降期的产品来说是可取的。在这些产品阶段中，您通常关注的是增强功能和错误修复，以及降低成本。 
       因此，当产品进入成熟阶段以后变更团队设置是合适的。但是，变更应该始终征得开发团队的同意：告诉团队他们将被解散和重组，即便变更与对敏捷开发团队充分授权的想法会发生冲突。 

如果将两种团队混合和匹配呢？ 
       当然，可以将功能团队和组件团队协同使用，但上述建议仍然是正确的：明确团队设置使产品受益最大化。例如，在管理一个处于青年期的产品时，您可能会发现有一个负责数据层的组件团队是更有益的。但是，如果您决定要这样安排，请确保有充分的理由去使用组件团队，并在此阶段将组件团队数量控制在最低水平。同样，当您需要对成熟产品进行较大的更改（如实质性功能增强）时，可以使用功能团队来完成工作。 
       不过不要忘记，凝聚一个团队需要时间。团队成员间必须学会相互信任并建立联系来有效地协同工作。因此，经常更改团队设置是不可取的。 

       这是一篇对功能团队和组件团队讲解很清晰的文章，很多时候我们会被“敏捷”二字所吸引，让我们忽视了最重要的团队组成方式。毕竟，无论是瀑布，敏捷、迭代抑或原型，都需要组建合适的团队才能真正达到某一种研发模式的效果和期望。
       我准备在个人的专栏中写一些我咨询辅导过的产品从初始阶段一直到成熟期该如何组建不同形态团队的案例。敬请期待……

       文章分别详细介绍了功能团队和组件团队的优缺点以及什么场景下该选择什么团队来应对。发布后很多感兴趣的小伙伴也积极留言展开讨论，摘录一部分分享给大家。
 

 
Q1： 
       你好，这是篇非常好的文章，读后使我的概念清晰了不少，谢谢！不过我还是有一个问题：正如你所说，如果一个产品不断经历重大变化，那么首选应当组建功能团队。但是，如果有重大更改，不就更有可能会导致不一致？因此组建组件团队不是更合适些吗？顺便来说，我个人更喜欢功能团队，请您建议我们如何处理这些潜在的不一致或可能的代码冗余问题？或者如何将两种模式进行组合？ 

A1： 
       你好，首先感谢您的反馈和问题。您提出的是一个很重要的问题。为了降低因组建功能团队而引入的不一致的风险，团队应定期反思其工作实践，创建、审查和调整共同的标准，这些标准包括软件架构、UX（用户体验）或编码标准。这可作为跨团队或整体回顾的一部分来完成。 
希望这对您有帮助！ 
---------

Q2： 
       你好， 好文章，感谢您分享你的想法！ 
       关于组建组件团队，我有一个问题：假设无论成熟度级别如何，每个阶段性的改变都应带来（最终用户）价值，当（组件）团队设置更偏向于"技术驱动"时，您如何衡量此价值？ 
       在我看来，组件团队的方法与精益开发的方法有点小冲突，一个最小单元的可行的产品是基于垂直切片而不是一次一个层的方式来开发的。 
       特别是对于 SaaS （Software as a Service，软件即服务）解决方案，成熟阶段总是受时间限制的，那么团队不是总会工作在"功能团队"模式下吗？ 
      感谢您对这些问题的考虑，并感谢您写了如此优秀的产品管理相关书籍！ 

A2： 
       您好， 感谢您分享您的反馈。我完全同意一个最简可行产品（MVP）最好由一个或多个功能团队开发。这就是为什么我在文章中建议，功能团队"更适合应对创新、不确定和变革——早期生命周期阶段面临的挑战"。后者包括开发阶段，从而开发出MVP。 
       如果你的产品持续经历更大的变化，从来没有完全成熟，那么我建议你坚持使用功能团队。 
希望这对您有帮助！ 

-----------
Q3： 
       我喜欢你提到的关于组件团队更适合长寿命产品的观点。我也同意您关于组建团队没有一体适用的解决方案，团队本身应该参与到这一组建过程中来的观点。我有使用“事件风暴”和 DDD（Domain Driven Design）方法，围绕产品架构，吸纳足够多的集体智慧，来更好的做出团队拆分决定的经验。“事件风暴”是一种可以应对大量与会者（20 人左右）参与协作的设计活动。以下是您可能感兴趣的主题的其他参考文献（不幸的是，我还没有来得及阅读这些参考文献）： 
       * 动态重新组队："如果更改团队配置会造成损害，那么我们需要更频繁地这样做。“ 
       * 团队拓扑 
       感谢您的文章！

A3： 
        您好，感谢您分享您的反馈和经验。我更倾向于将团队的寿命和人员配置方法与团队类型分开讨论。例如，一个功能团队很可能在项目中会长期存在，并且可能自行选择配备人员。 
       也感谢您分享参考文献。我相信，更复杂的团队拓扑结构对项目更有帮助。但是，基于本文的目的（帮助产品人员反思如何更有效的组建开发团队），我想简单点可能更好。 
       虽然我认同团队组成上会发生变化，但以我的经验表明，频繁的团队变化通常会导致较低的工作效率和较差的团队合作精神。Richard Hackman在他的著作《协作智能》中支持我这一观点："拥有稳定成员关系的团队具备更健康团队活力，并且比那些经常不得不去应付新老交替的团队表现更好。"
       希望这对您有帮助！

       从大家的思考和问题中可以感受到，需要根据业务特点来选择合适的团队组建类型，更关键的是如何让团队成员具备与产品持续发展的技能和应对人员更迭带来的产品生长冲击，尤其是中小企业的产品和研发负责人在这件事上需要更大的投入。但这种投入往往具有较大的不确定性和较长的回报周期，boss们是否愿意投入才是真正的挑战。

惟特翻译团队版权声明----------------