谁说“大团队”和“敏捷开发”不能兼得？

当一个小团队的产出不能满足业务需求时，团队将面临规模问题。从一个团队到三个团队，您仍然可以通过简单的团队沟通来保持高效的协作。当产品足够复杂，需要五个以上的团队同时开发时，我们需要一定的组织设计来确保团队之间的顺利合作，这样多个团队在一起开发产品时仍然可以保持灵活性。此时该如何设计组织？今天，让我们分析一些方法。

1、保持一个小团队

当创业公司或产品刚刚起步时，团队通常很小。随着业务的发展，需求越来越多，产品也越来越复杂。许多团队的第一反应是增加人员。事实上，加人不是唯一的选择，也不一定是最好的选择。很多时候，小团队可以带来惊人的业务成果。一方面，通过专注：做好一件事，小团队可以专注于核心业务，消除不必要的干扰。

另一方面，随着开源运动、中平台技术和云技术的发展，许多非核心业务逻辑可以在外力的帮助下快速构建，在业务高速发展的同时，继续保持一支精干的团队。

2、业务单元功能团队

即使我们试图保持专注并耗尽技术红利，有时业务开发也远远超出预期。此时，组建多个团队势在必行。理想的选择是根据业务单元构建功能团队。一个业务单位类似于一家小型初创公司，有着自己的长期使命和愿景，相对明确的业务界限和盈利模式。在人员方面，每个业务单元都有独立的业务、产品和研发团队。在技术上，每个业务单元可以独立完成产品开发的全过程，包括业务决策、产品设计、开发、测试和发布，并尽量避免业务单元之间的依赖。

3、无限制功能团队

有时团队在业务开发中成长，但经过一段时间的快速发展，原有的业务方向遇到了瓶颈，新的业务方向仍在探索中。此时，业务方向不明确，很难根据明确的业务单元组建团队。团队需要快速适应业务方向的变化。此时，我们应该鼓励团队广泛学习，避免局部优化。与围绕业务单元构建的功能团队不同，不受限制的功能团队没有相对独立的业务领域。多个功能团队共享一个产品待办事项列表（Product Backlog），并根据统一的优先级交付产品功能。不受限制的功能团队，并非所有团队都是相同的无差别功能团队。每个团队仍然可以有自己的特点和专业知识，只要根据 Product Backlog 的优先级组合多个团队来交付功能。

总之，无限制的功能团队解决方案解决了业务需求等待资源瓶颈的痛点。它不是让业务发展与人员的技能相匹配，而是扩展人员的技能以满足业务发展的需要。与此同时，团队成员的个人能力得到了锻炼，团队的自组织能力得到了发展，职能管理者得到了解放。无论是业务单元功能团队还是无限功能团队，每个团队都应该能够独立交付产品功能。一个复杂的产品功能通常需要修改多个模块才能实现。当多个团队修改同一个模块时，如何确保模块设计的一致性，并及时清理代码以偿还技术债务？

引入模块监护人通常是一种有用的做法：最好让两个模块监护人为每个模块相互备份。要修改模块代码，您需要要求模块监护人进行代码审查。对于一些复杂的修改，最好提前进行设计审查。模块守护者可以是兼职的，只要每周分配一定比例的时间来维护模块代码。

随着业务方向变得更加明确和稳定，无限制的功能团队将逐渐找到一种相对固定的分工与合作模式，每个功能团队将逐渐找到他们最擅长和最感兴趣的产品方向。明确的产品方向为团队提供了长期培养的条件，团队逐渐成为某个领域的专家。此时，无限制功能团队已经完成了到业务单元功能团队的转换。

4、总结

当业务方向明确时，根据业务单元组建功能团队是最佳选择。当业务方向不确定时，您可以首先建立一个无限制的功能团队，然后逐渐过渡到业务单元功能团队。无论采用何种组织设计，其目的都是快速通过业务闭环：不断交付业务价值，在真实的市场环境中测试假设，并通过快速试错，找到一种可行的方式，以一定的利润水平向企业或最终用户提供产品和服务。

来源：阿里技术