项目已经延期时，加人可能先让它更晚
新人不是可立即并联的工时：现成员需要培训和协调，许多任务又有先后依赖；临近截止日期加人可能暂时降低净产出。
谁在何时、何处提出
弗雷德里克·布鲁克斯在1975年发表的《人月神话》（The Mythical Man-Month）中明确讨论了这一思想。定位：第二章“The Mythical Man-Month”，尤其关于顺序任务、培训与沟通成本的讨论。
初版由Addison-Wesley于1975年出版；链接为密歇根大学课程保存的周年版扫描，包含初版章节及后增内容。本篇引用第二章，不把1995年新增章节倒算为1975年。
原文、核心意思与误读
“Adding manpower to a late software project makes it later.”自然译为：给一个已经延期的软件项目增加人手，会让它更晚。
布鲁克斯反对把“人月”当成可以任意兑换的单位。挖沟的一部分工作或许可并行，理解架构、协调接口和调试系统却有顺序与沟通关系。新成员要熟悉背景，老成员要抽时间讲解；团队扩大后，需要同步的关系也增加。因此，某些阶段加人会先产生负产能。
这不是“项目永远不能加人”。若工作可以清楚切分、培训成本低、时间尚早，新增成员可能有益。法则针对已经延期且相互依赖的软件项目，是警告而非物理定律。另一个误读是把问题全归给新人；真正需要检查的是任务结构、文档、接口和剩余时间。
例如三天后要交报告，临时加入四个人共同改同一稿件，原成员可能一直解释背景和处理冲突。若先把资料核验、图表复核等低耦合任务单独交出，增加的人才更可能贡献净进度。
为什么落实起来仍有阻力
本篇归入B类：观点已有传播，但日常落实仍需要条件。没有找到可靠的总体采用率数据，以下是对执行阻力的分析。
第一，项目延误时“再加资源”是可见动作，重排范围或承认日期不现实更难解释。第二，管理报表容易统计人数，却难显示培训与协调占用了谁的时间。第三，团队可能缺少模块化边界，新增人员没有安全的独立工作面。这些是执行分析；没有依据声称所有现代团队都忽略了这条法则。
今天做一个小实验
这是据上述思想设计的个人练习，不是原作者的标准实验，也不预先保证一定有效。
用40分钟做一次“净增产能”估算。选一个正在赶工的任务，前10分钟列出剩余事项并标注可并行或必须顺序；用10分钟估算新人前两天需要谁培训、多久，以及新增同步会议；用10分钟找出一个低耦合工作包，写清输入、输出和验收标准；最后10分钟比较“直接加人”和“先切工作包”在截止日前的净可用小时。练习据书中机制设计，不把估算当精确预测。
什么时候不宜照搬
人员不足确实可能是根因，不能用布鲁克斯法则为长期缺编辩护。支持、测试、资料整理等工作常能并行，经验匹配的新成员也可能迅速解除瓶颈。安全事故或值班覆盖需要立即增援时，风险控制优先于一般生产率判断。