1. 一个具体问题
一个六人软件团队已经比交付计划落后两周，负责人决定立即加入六名开发者。任务看起来很多，人多似乎就能把剩余工期减半。但新人要理解业务、配置环境和学习隐含约束，负责关键模块的老成员反而要停下编码。真正需要判断的是：新人的净贡献何时会超过引入他们造成的延误？
2. 一句话解释
在已延期且高度耦合的软件项目中，临时增员可能因为培训、协调与拆分成本而进一步拖慢交付。
3. 出处与原意
Fred Brooks 在《人月神话》（1975）中提出这一经验判断，背景是大型软件工程的组织管理。他有意采用尖锐表述来纠正“人数乘时间就是固定工作量”的直觉。它不是统计上证明的普遍定律，也不意味着所有项目都不该招聘。
4. 原理与机制
任务先要能够分割，新人才能并行开展工作；分割后还要统一接口、审查和集成。如果每个人都与其他人直接协调，潜在沟通关系有 n(n−1)/2 条，但真实团队通常通过负责人和模块边界降低联系数量，不能把这个公式直接当作工期模型。另一项成本是知识转移：新人学习的同时，占用的往往正是关键路径人员的时间。剩余工期越短，收回这些投入的机会越小。
还可以把增员视为一项有回收期的投资：最初几天，新增产能可能为负，之后才逐渐转正。估算时应比较从今天到交付日的累计净贡献，而不是只比较稳定状态的人均产出。如果新人承担的是关键人员必须审查的工作，审查队列可能成为新瓶颈。此时把原有维护、答疑或测试工作转交出去，通常比直接把核心实现切成更多块更值得评估。
5. 一个完整案例
假设案例：支付改版还剩十个工作日，关键路径是两名熟悉结算规则的工程师完成对账与迁移。新增四人若各需这两人辅导半天，就先消耗两个人日；如果新工作还要重新拆接口，会继续挤占关键路径。团队于是只让两位新人接管已有说明书的回归测试和数据核验，由一位非关键路径成员答疑。五天后测试积压减少，而迁移负责人保持连续工作。这个选择有效的原因是新人承接了可独立的阻塞因素，而非人数本身产生魔法。
6. 适用条件与反例
适合用来检查临近截止日的扩编方案，尤其是业务知识集中、集成频繁的项目。若剩余工作是大量独立的素材整理，或新人本来就熟悉系统，增员完全可能缩短时间。长期缺编也不能用它来合理化；早招聘、持续培养与临时救火是不同决策。
7. 今天可以尝试的行动
把剩余工作按“可以独立交付”“必须共同设计”“关键路径”分成三类。为每个拟加入的人估计三项时间：上手时间、占用谁的指导时间、第一次独立成果的时间。若净收益晚于截止日，优先减少范围或移走关键成员的杂务，并用实际交付量复核估计。