在软件工程中，扩大项目规模并不像扩大生产线。招聘更多开发者可以提升总体容量，却不会按比例加快单一功能或项目的交付。

Fred Brooks 在 The Mythical Man-Month 中准确描述了这一点：向一个已经延期的软件项目增加人力，往往会让它延期得更久。著名的比喻是，一位女性可以用九个月孕育一个孩子，但九位女性无法在一个月内完成。这一定律谈的不是生物学，而是复杂工作的内在约束。

为什么增加人员经常适得其反

布鲁克斯定律指出了三个根本原因：

  1. 上手时间。 新成员必须学习代码、领域和上下文。资深成员需要暂停工作来帮助他们，短期生产力因此下降，缺陷与返工风险也随之上升。
  2. 沟通开销。 团队越大，协调路径增长得越快。三个人有三条连接，六个人则有十五条。更多会议、同步和上下文传递会吞噬本应用于交付的时间。
  3. 工作不可无限拆分。 并非所有任务都能分成独立部分。设计、架构决策和集成经常要求连贯的顺序。把复杂问题切成很多小工单，并不能保证最终自然形成一致的方案。

因此，单纯增加开发者带来的收益存在上限。到达某个点后，协调与集成成本会超过更多人手的收益。

小而专注的团队为何有效

敏捷实践长期倡导小型跨职能团队。Jeff Bezos 在 Amazon 推广过两张披萨团队规则：如果两张披萨喂不饱一个团队，它可能已经太大了。

小团队减少沟通，更快做出决策，也更容易维持清晰责任。软件项目分析经常把四到五人视为高效区间。准确数字取决于领域，但方向一致：人数增加不会带来线性收益，反而可能提高缺陷与成本。

我的实践数字：三位开发者

担任 EITS CTO 期间，我尝试过不同团队构成，最终形成了一个务实判断：三位开发者能在两周迭代中交付出色结果。

三人之间只有三条沟通路径。团队不需要过度协调就能自组织，每个人也更容易保持明确的责任感。共享上下文、代码评审和共同做设计决策都会更简单。

这不仅关乎效率，也关乎创造力。复杂问题需要深度专注。参与者过多时，工作会被切碎，方案的整体视角容易丢失。三人团队可以共同处理架构、实现和测试，同时保持整体一致。

团队之外的约束

增加开发者的前提，是有足够多可并行的工作。现实中，业务需求、产品设计和利益相关方的决策经常才是吞吐量的限制。

如果任务还不清晰，额外的工程师要么等待，要么基于脆弱假设开始工作，之后产生更多返工。创造力与方案设计也不会随参与人数线性增长。

如何克制扩充团队的冲动

  • 尽早投入。 项目后期增员伤害最大。若确实需要扩充，应在上手成本仍可吸收时完成。
  • 关注能力，而不是人数。 一位与上下文匹配的资深工程师，可能比多位缺少必要经验的新成员更有价值。
  • 先澄清架构与需求。 很多延期来自模糊需求或不合理的架构边界。
  • 保持自治。 多个小团队并行时，应定义清晰接口，并尽量减少跨团队依赖。

结论

这个比喻经久不衰，是因为它直指软件项目的核心：不是所有工作都能靠增加人员来压缩。并行化存在自然上限；超过上限后，沟通、上手和认知负担会拖慢项目。

在为了赶期限而扩充团队之前，先问新增的人是否真的能推动交付，还是只会增加复杂性。有时最有效的策略，是给一个小而专注的团队明确目标、充分自治，以及交付所需的信任。