时间: 2021-07-30 09:43:52 人气: 6 评论: 0
无论你在小型创业公司工作还是在大公司的新产品线工作，当团队人数越来越多时总**达到一个临界点。尽早识别这个临界点可以让您的团队避免进入低效阶段。
每个产品都是不同的，团队合作也是如此。因此，拆分团队也需要做一些反映团队情况的决定。
在做决定时有以下几点需要考虑：
开始考虑团队拆分或增加新团队最明显的迹象就是团队的预算增加，这可能发生在创业公司的新一轮投资或企业产品的新目标中。
如果预算增加较多你的团队规模**增长3倍甚至更多，这个时候你就不得不拆分现有的团队以延续原有的技术知识。
然而，当预算增加呈递增式时，你的决定就变得没有那么明确，最终的结果就是在名册上增加一些新人。
如果说，你计划将自己的团队由7个人增加到11个人，需要做拆分吗？敏捷提倡小团队，但也同样提倡个体和互动高于流程和工具，拥有两个或以上的团队必可避免的要创建更多流程以便能够同步工作。
亚马逊创始人贝索斯曾将两个披萨原则用在**议和团队中，那就意味着无论是**议还是团队应该只有两个披萨可以喂饱午餐的人数。
Scrum指南建议有3到9名成员实际执行sprint backlog，这就意味着总数中不可能包含PO或者Scrum Master，除非他们他们当中有人在执行sprint backlog项。
这些数字看起来更有直观意义，但他们背后也有数学原理。如果将团队中的每个人都看做一个节点，并将他们链接到其他节点。这就是队友之间的人际关系。
他们之间可以是友好的、竞争的、恶意的或者关怀的，无论两人之间的关系是什么，都需要每个人有一定的心理承受能力。
随着团队人数的增长，这些链接之间的数字不**呈线性增长。节点之间的链接公式，如下图的链接增长图所示：
图表从数学角度清楚的说明了为什么当团队规模不是特别大的时候能实现运营效率的最大化。
如果我们遵从Scrum指南的建议采用3到9人的团队规模人数，最终的链接值为3到36。如果把团队人数增加到15人，链接值将**过100。
这种规模的团队只有在团队中每个人的责任定义都非常明确且很少重叠或者一些非官方的小组才能有效运营。基于敏捷原则工作时既非案例也非期望。
每日Scrum是整个团队的聚**，用于阐述sprint进展和遇到的困难，有时候也被称为每日站**。
Scrum指南建议每日站**要在15分钟内完成，这个时间限制对团队规模来说是很好的试金石。如果你注意到自己的团队开始**过15分钟线，那么可以表明两件事：
你还应该注意到团队中的一些人，正在逐渐失去兴趣因为一个人可以接收的信息量是有限制的。如果太多人提供更新，那么跟踪每个人的进度并了解团队的状态就**变得很难。
这使得人们只**向内看，只看到自己的进步而不是寻找机**去帮助他人。
梳理和迭代规划都是与分解用户故事和预估交付时间或规模大小有关的活动。
虽然有更多的人可以帮团队做出更好的决策，同样的拥有太多人也容易让团队陷入僵局。
同一任务可以由不同的方法来完成，并且每一边的论点数量都**随着人员数量的增加而增加。与站**一样，不要把低效的计划谈话与团队规模过大混淆。
最终，让scrum仪式变得更高效且有效是scrum master的工作。
在回顾**议期间，团队成员可以解决任何争论或冲突并提出改善其工作流程的方法。回顾**议教**我们妥协的艺术，因为它让我们在不同团体直接寻求共同点。团队也因为它的成员愿意在他们的分歧上适当妥协而变得强大。
然而，和sprint规划一样，团队成员过多那么链接点也**很多，所有这些链接点都是潜在冲突。
如果你在回顾**议时发现大家的共同点越来越少的时候你就应该开始注意，这很有可能是由于团队规模过大，团队拆分是最佳选择。
表明上看，拆分团队是一个相对简单的任务。将团队成员分成两组，确保每组中都有相似经历的成员，明确新团队的目标。
然而，在拆分团队时还有很多因素需要考虑进去，以免影响团队以后的成功。
需要时刻牢记的最重要的事情之一就是团队士气。一天结束时，团队中的成员将不得不在新的组织架构中工作。
如果团队在敏捷原则方面是成熟的，那么他们应该能够自己分裂。这是最理想的结果，因为团队成员最了解他们的内部关系——谁与谁关系最好以及谁能从分离的组织中收益。
Scrum推动跨职能团队“拥有创建产品增量所需的所有技能”，扩展到两个甚至更多团队时也是如此。
对于很多开发者尤其是一些敏捷新手来说，自然趋势是与技术线路一起思考的。
例如，团队经常想将拆分成前端和后端。这在某些罕见的情况下可能**有意义，但作为产品经理，你应该在大多数时间提出反对意见。
一个全是前端开发者的团队无法自行提供产品增量，并且自然地就开始思考技术能力也就是将他们团结起来的原因。相反，他们更应该关注的是客户以及如何满足他们的需求。
另一个有趣的考虑因素是团队中的非开发角色。在各种情况下，一个团队可能包括一个设计师、业务分析师和QA专家。一旦你拆分了一个团队，尤其是如果你没有雇更多的新人，那么在处理这些角色的问题上就**陷入两难的境地。
他们应该分配自己的时间到不同的团队吗？你应该雇佣只服务于一个团队的新人吗？他们应该跟开发团队一起工作呢还是成为产品团队的一员？
对此并没有绝对的好建议因为每个产品都是不同的。这些决定最好与团队一起做出，同时记得需要一直不断修正。
如果一个团队被拆分，那么接下来的问题自然就是他们应该用同一个backlog工作还是再独立一个backlog出来？
Scrum@Scale是由Scrum指南的创建者开发的一种方法，Scrum@Scale不是很规范，但它确实指出了两点：
所以，本质上来讲，Scrum@Scale描绘了新团队与他们各自的PO和backlog紧密配合的场景，只是添加了一些额外的结构来协调团队之间的工作。
Scrum@Scale适合数个、数十个或数百个团队，但即使你们只有两个团队一起工作它也能提供一些有价值的见解。
大规模scrum（LeSS）：
LeSS提供了一种有趣的产品backlog方法。在LeSS中，一个PO与2到8个团队一起工作。一个PO能跟那么多团队一起工作看起来有点不太可能。
LeSS的理念是PO在抽象层面上工作，并将产品backlog项细化的职责委托给团队。这种情况下，跨职能开发团队还应该包括业务领域知识以便交付产品增量。
在LeSS中，只有一个backlog。
对于一个产品经理来说，多团队意味着更多的工作追踪和响应查询。
如果你曾参加单个团队的每日站**，那么现在你可能**发现继续这个习惯很可能是徒劳的。
将每日站**作为一个让他们了解团队动力并提醒他们可以进行讨论的机**，你参加sprint规划**议与否取决于你团队的成熟度。
如果团队中有很多新面孔或者他们已经很长时间没有用敏捷的方式工作了，那么你的指导就非常必要。
即使你有信心让团队在没有你参与的情况下进行规划，如果出现问题请务必要在规划期间与团队进行交流或语音聊天。Sprint review必须始终是你的首要任务，所有人都应该参加。
Sprint review是一个能让你从所有在场的利益相关者和团队本身获得第一手反馈的机**。这是一个验证假设的时间，不应该错过。
你可能**减少某些scrum仪式的参与，但应该增加与scrum master间的合作。
团队拆分后，肯定不止一个scrum master，这种情况下，你需要与他们所有人密切合作。确保你可以信任他们，以便真实了解团队的进展及sprint期间出现的任何问题。
这种关系可以帮助你了解最新进展并且无需参加所有的scrum仪式。
scrum of scrums 介绍：
时候也称为元scrum，scrum of scrums是一个新的仪式，通常作为scrum流程规模引入。
它是更高级别的站**的复制品，每个团队都指派一名大使，所有大使每天都在S0S**议上碰面沟通进展和阻碍。
这个**议还用于突出可能需要解决的任何跨团队技术问题。
如果你的团队设置要求产品经理积极参与到团队中，那么请考虑在产品方面再添加一些人员。有几种方法可以解决这个问题：
随着团队的发展，你可能**开始注意到一些它变得太大的迹象，尤其是在：
所有这些迹象都表明你可能需要拆分团队，拆分团队看起来是一项简单的任务但也**带来持续的后果。如果真的要这么做，每个产品经理都要考虑以下几个问题：
如果需要跟踪两个或以上团队则需要确定优先级顺序。高效率的产品经理应该计划如何与新团队保持同步：
希望通过以上几点建议，你能有一个相对比较清晰的团队拆分思路。
原文作者：Stephanie Ockerman
翻译/校对：吴倩倩
本文由 @吴倩倩 翻译发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
