无论你在小型创业公司工作还是在大公司的新产品线工作，当团队人数越来越多时总会达到一个临界点。尽早识别这个临界点可以让您的团队避免进入低效阶段。

每个产品都是不同的，团队合作也是如此。因此，拆分团队也需要做一些反映团队情况的决定。

在做决定时有以下几点需要考虑：

1. 团队不在一起工作时如何确保专业知识的完整性？
2. 是否应该按职能划分？（如：前端团队和后端团队）
3. 新的团队应该有单独的backlog吗？
4. 产品管理团队是否应该相应增长？

什么时候开始创建第二个团队？

开始考虑团队拆分或增加新团队最明显的迹象就是团队的预算增加，这可能发生在创业公司的新一轮投资或企业产品的新目标中。

如果预算增加较多你的团队规模会增长3倍甚至更多，这个时候你就不得不拆分现有的团队以延续原有的技术知识。

然而，当预算增加呈递增式时，你的决定就变得没有那么明确，最终的结果就是在名册上增加一些新人。

如果说，你计划将自己的团队由7个人增加到11个人，需要做拆分吗？敏捷提倡小团队，但也同样提倡个体和互动高于流程和工具，拥有两个或以上的团队必可避免的要创建更多流程以便能够同步工作。

专家怎么说？

亚马逊创始人贝索斯曾将两个披萨原则用在会议和团队中，那就意味着无论是会议还是团队应该只有两个披萨可以喂饱午餐的人数。

Scrum指南建议有3到9名成员实际执行sprint backlog，这就意味着总数中不可能包含PO或者Scrum Master，除非他们他们当中有人在执行sprint backlog项。

这些数字看起来更有直观意义，但他们背后也有数学原理。如果将团队中的每个人都看做一个节点，并将他们链接到其他节点。这就是队友之间的人际关系。

他们之间可以是友好的、竞争的、恶意的或者关怀的，无论两人之间的关系是什么，都需要每个人有一定的心理承受能力。

随着团队人数的增长，这些链接之间的数字不会呈线性增长。节点之间的链接公式，如下图的链接增长图所示：

图表从数学角度清楚的说明了为什么当团队规模不是特别大的时候能实现运营效率的最大化。

如果我们遵从Scrum指南的建议采用3到9人的团队规模人数，最终的链接值为3到36。如果把团队人数增加到15人，链接值将超过100。

这种规模的团队只有在团队中每个人的责任定义都非常明确且很少重叠或者一些非官方的小组才能有效运营。基于敏捷原则工作时既非案例也非期望。

团队变大的信号

1. 每日Scrum

每日Scrum是整个团队的聚会，用于阐述sprint进展和遇到的困难，有时候也被称为每日站会。

Scrum指南建议每日站会要在15分钟内完成，这个时间限制对团队规模来说是很好的试金石。如果你注意到自己的团队开始超过15分钟线，那么可以表明两件事：

1. 站会效率较低。大家陷入太多细节当中。或者没有明确的发言顺序需要团队成员轮流点名。也有可能PO或Scrum Mater利用站会时间提出与sprint无关的各种更新。
2. 团队规模过大。如果站会效率很高，但是你的团队开会时间仍然超过15分钟，那就很有可能是你的团队人数过多导致的。

你还应该注意到团队中的一些人，正在逐渐失去兴趣因为一个人可以接收的信息量是有限制的。如果太多人提供更新，那么跟踪每个人的进度并了解团队的状态就会变得很难。

这使得人们只会向内看，只看到自己的进步而不是寻找机会去帮助他人。

2. 梳理和Sprint规划

梳理和迭代规划都是与分解用户故事和预估交付时间或规模大小有关的活动。

虽然有更多的人可以帮团队做出更好的决策，同样的拥有太多人也容易让团队陷入僵局。

同一任务可以由不同的方法来完成，并且每一边的论点数量都会随着人员数量的增加而增加。与站会一样，不要把低效的计划谈话与团队规模过大混淆。

最终，让scrum仪式变得更高效且有效是scrum master的工作。

3. 回顾

在回顾会议期间，团队成员可以解决任何争论或冲突并提出改善其工作流程的方法。回顾会议教会我们妥协的艺术，因为它让我们在不同团体直接寻求共同点。团队也因为它的成员愿意在他们的分歧上适当妥协而变得强大。

然而，和sprint规划一样，团队成员过多那么链接点也会很多，所有这些链接点都是潜在冲突。

如果你在回顾会议时发现大家的共同点越来越少的时候你就应该开始注意，这很有可能是由于团队规模过大，团队拆分是最佳选择。

如何拆分团队？

表明上看，拆分团队是一个相对简单的任务。将团队成员分成两组，确保每组中都有相似经历的成员，明确新团队的目标。

然而，在拆分团队时还有很多因素需要考虑进去，以免影响团队以后的成功。

1. 团队士气

需要时刻牢记的最重要的事情之一就是团队士气。一天结束时，团队中的成员将不得不在新的组织架构中工作。

如果团队在敏捷原则方面是成熟的，那么他们应该能够自己分裂。这是最理想的结果，因为团队成员最了解他们的内部关系——谁与谁关系最好以及谁能从分离的组织中收益。

2. 跨职能团队

Scrum推动跨职能团队“拥有创建产品增量所需的所有技能”，扩展到两个甚至更多团队时也是如此。

对于很多开发者尤其是一些敏捷新手来说，自然趋势是与技术线路一起思考的。

例如，团队经常想将拆分成前端和后端。这在某些罕见的情况下可能会有意义，但作为产品经理，你应该在大多数时间提出反对意见。

一个全是前端开发者的团队无法自行提供产品增量，并且自然地就开始思考技术能力也就是将他们团结起来的原因。相反，他们更应该关注的是客户以及如何满足他们的需求。

另一个有趣的考虑因素是团队中的非开发角色。在各种情况下，一个团队可能包括一个设计师、业务分析师和QA专家。一旦你拆分了一个团队，尤其是如果你没有雇更多的新人，那么在处理这些角色的问题上就会陷入两难的境地。

他们应该分配自己的时间到不同的团队吗？你应该雇佣只服务于一个团队的新人吗？他们应该跟开发团队一起工作呢还是成为产品团队的一员？

对此并没有绝对的好建议因为每个产品都是不同的。这些决定最好与团队一起做出，同时记得需要一直不断修正。

3. 团队之间应该有独立的Backlog吗？

如果一个团队被拆分，那么接下来的问题自然就是他们应该用同一个backlog工作还是再独立一个backlog出来？

Scrum@Scale是由Scrum指南的创建者开发的一种方法，Scrum@Scale不是很规范，但它确实指出了两点：

1. 团队级别的流程跟Scrum指南中的流程相同；
2. 产品负责人组成专门的产品负责人团队，在他们那里创建单一的backlog。这样做是为了避免重复工作，在公司范围内增强可见性。与此同时，团队从统一的backlog中提取各自的backlog。

所以，本质上来讲，Scrum@Scale描绘了新团队与他们各自的PO和backlog紧密配合的场景，只是添加了一些额外的结构来协调团队之间的工作。

Scrum@Scale适合数个、数十个或数百个团队，但即使你们只有两个团队一起工作它也能提供一些有价值的见解。

大规模scrum（LeSS）：

LeSS提供了一种有趣的产品backlog方法。在LeSS中，一个PO与2到8个团队一起工作。一个PO能跟那么多团队一起工作看起来有点不太可能。

LeSS的理念是PO在抽象层面上工作，并将产品backlog项细化的职责委托给团队。这种情况下，跨职能开发团队还应该包括业务领域知识以便交付产品增量。

在LeSS中，只有一个backlog。

如何保持更新？

对于一个产品经理来说，多团队意味着更多的工作追踪和响应查询。

1. 优先级会议

如果你曾参加单个团队的每日站会，那么现在你可能会发现继续这个习惯很可能是徒劳的。

将每日站会作为一个让他们了解团队动力并提醒他们可以进行讨论的机会，你参加sprint规划会议与否取决于你团队的成熟度。

如果团队中有很多新面孔或者他们已经很长时间没有用敏捷的方式工作了，那么你的指导就非常必要。

即使你有信心让团队在没有你参与的情况下进行规划，如果出现问题请务必要在规划期间与团队进行交流或语音聊天。Sprint review必须始终是你的首要任务，所有人都应该参加。

Sprint review是一个能让你从所有在场的利益相关者和团队本身获得第一手反馈的机会。这是一个验证假设的时间，不应该错过。

2. 与Scrum Master多互动

你可能会减少某些scrum仪式的参与，但应该增加与scrum master间的合作。

团队拆分后，肯定不止一个scrum master，这种情况下，你需要与他们所有人密切合作。确保你可以信任他们，以便真实了解团队的进展及sprint期间出现的任何问题。

这种关系可以帮助你了解最新进展并且无需参加所有的scrum仪式。

scrum of scrums 介绍：

时候也称为元scrum，scrum of scrums是一个新的仪式，通常作为scrum流程规模引入。

它是更高级别的站会的复制品，每个团队都指派一名大使，所有大使每天都在S0S会议上碰面沟通进展和阻碍。

这个会议还用于突出可能需要解决的任何跨团队技术问题。

3. 考虑扩充产品团队

如果你的团队设置要求产品经理积极参与到团队中，那么请考虑在产品方面再添加一些人员。有几种方法可以解决这个问题：

1. 初级产品经理。 一条途径是让自己承担更具挑战性的工作，同时增加初级产品经理来处理一些日常琐事。他们可以承担一些如质量保证（QA）、编写用户故事或为新功能创建高级模型的任务；
2. 业务分析。 另一种方法是让一个或多个业务分析师在团队中或者与团队一起工作。产品经理可以与业务分析师一起确定产品假设，然后让业务分析师通过研究或新功能找到验证假设的方法。

结论

随着团队的发展，你可能会开始注意到一些它变得太大的迹象，尤其是在：

• 站会。 如果你们的每日站会超过15分钟的时间界限并且注意到人们开始逐渐失去兴趣；
• sprint规划 。如果你们在Sprint规划期间越来越频繁的陷入僵局；
• 回顾 。如果你开始注意到在回顾期间大家的意见越来越难达成一致。

所有这些迹象都表明你可能需要拆分团队，拆分团队看起来是一项简单的任务但也会带来持续的后果。如果真的要这么做，每个产品经理都要考虑以下几个问题：

1. 团队士气 。理想情况下，应该让团队自己决定如何拆分，最大限度的减少对良好的工作关系的影响；
2. 跨职能团队 。团队应该具备创建产品增量的所有必要技能；
3. 产品backlog 。决定你的团队是有独立的还是一个统一的backlog。

如果需要跟踪两个或以上团队则需要确定优先级顺序。高效率的产品经理应该计划如何与新团队保持同步：

• 优先级会议 。思考哪些敏捷仪式是值得你花费时间参与的而哪些是可以被忽略的；
• 与scrum master互动 。让scrum master作为你的团队代理人，通过他们获取团队信息；
• 扩充产品团队 。在产品团队中添加一些成员和你一起工作，让他们帮你完成一些日常重复性任务或进行用户调研和市场分析。

希望通过以上几点建议，你能有一个相对比较清晰的团队拆分思路。

原文作者：Stephanie Ockerman

翻译/校对：吴倩倩

本文由 @吴倩倩 翻译发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议