布鲁克斯法则

BROOKS'S LAW // 人月是个神话

> 项目落后三个月，经理的本能是加人——而布鲁克斯用 IBM System/360 与 OS/360 的血泪写下：向进度落后的项目增加人手，只会使进度更加落后。因为"人月"是个神话：人和月不能互换。新人要老手带教（净产出为负）、沟通链路按 n(n−1)/2 爆炸、可并行的工作总量有限——加的是人手，买的是延迟。

SUBJECT: 软件工程 · 项目管理 FILE: cards/brooks-law SINCE: 1975 BUILD v1.0

Principle — 原理与来源

布鲁克斯法则 BROOKS'S LAW // 《人月神话》第 2 章

向进度落后的项目增加人手，只会使进度更加落后

Adding manpower to a late software project makes it later.

人物：弗雷德里克·布鲁克斯（Frederick P. Brooks Jr., 1931–2022）——"IBM 大型机之父"：主持 IBM System/360 系列架构（其 embrace 的 8 位字节、32 位字等决策影响至今），又历任 OS/360 操作系统项目经理。1975 年他把这段"人类历史上最大软件项目"的教训写成《人月神话》（The Mythical Man-Month）——被誉为"软件开发者的圣经"，2020 年再版 40 周年纪念版。

三台引擎（为什么加人更慢）：① 沟通开销爆炸——n 个人的沟通链路是 n(n−1)/2：5 人 10 条、10 人 45 条、20 人 190 条，加人先加会议；② 带教抽血——新人要老手培训引导，老手产出被抽走，且新人可犯错会污染生产代码，其净贡献在相当长时间内为负；③ 任务不可分——"九个女人一个月生不出一个孩子"：梗图式比喻的严肃版本是，可并行分解的任务有限（Brooks 补充：串行部分正是 Amdahl 定律的软件版）。三者叠加，"人月"作为成本单位就此破产。

一体两面的姊妹概念：同书还提出第二系统效应（second-system effect：设计师成功后的第二个系统倾向于过度设计）与"外科手术队伍"（组织模式）。1986 年论文《没有银弹》（No Silver Bullet，收于 1995 十周年版）进一步断言：软件的本质复杂性（essence）没有单一突破解——复杂度、一致性、可变性与不可见性四大属性使生产力不可能数量级跃升。

① 法则有适用边界，Brooks 自己说的：适用于"已经落后"且可并行度低的项目——如果工作高度可分（如纯手工测试、内容填充），或人员早已预分配、加的只是执行者，加人仍可能提速；十周年版里他补充了适用条件而非推翻结论。 ② "九个女人"不是《人月神话》原文——这句谚语流传已久，只是后人爱用它阐释该法则；原著用的是生孩子比喻（"The bearing of a child takes nine months, no matter how many women are assigned"），方向相同、引用别张冠李戴。 ③ "没有银弹"是 1986 年论文、1987 年正式刊出（IFIP 会议 / IEEE Computer），常被误当《人月神话》章节；其"十年内没有单一技术能带来数量级提升"的赌约到 1996 年仍无完全兑现者（虽有争议）。 ④ 《人月神话》全书大部分文章写于 1974–75，但素材源于 1964–68 年 OS/360 项目与布鲁克斯此前在 IBM 的管理实践；"1975 年凭空写出"是压缩叙事。 ⑤ 布鲁克斯不是只写过一本"悲观之书"——他 1999 年获图灵奖，授奖词表彰"对计算机体系结构、操作系统与软件工程的里程碑式贡献"；《设计原本》（2010）是他晚年的设计哲学总结。 ⑥ 现代反驳的边界：开源与敏捷实践（如 Brooks 自己也惊叹的 Linux 现象）表明高度模块化 + 异步沟通可部分缓解沟通爆炸——但那是"降低 n(n−1)/2 的系数"，不是废除它；把"Linus 维护着大内核"当成法则失效，恰恰忽略了分布式协作对耦合结构的苛刻前提。

Apply — 用在哪里

进度管理落后时的正确动作清单：砍范围 > 调顺序 > 换关键路径的人；加人排最后，且加的必须能独立接走一整块（见视角 A 的分区实验）。

估算纪律看到"人月"单位先追问：这些任务真的可并行吗？——沟通成本与带教成本在不在估算里？没有两者的估算都是虚构的进度。

团队设计沟通链路 n(n−1)/2 是组织税：小团队 + 清晰接口（康威定律）比大团队堆人头便宜——两个人的沟通只有一条线，二十个人有一百九十条。

新人融入承认带教是投资而非产能：配对编程、文档化、把新人先放到低耦合模块——缩短"净贡献为负"的窗口期，而不是假装它不存在。

向上沟通领导说"再加五个人"时的标准答复姿势：拿视角 A 的曲线说话——显示加人后完成时间的拐点，把争论从勇气变成算术。

Simulate — 加人模拟器 × 分区推演

双视角实验室 // 加人那一下到底发生了什么；哪种落后还能救

视角 A：亲手加人，看完成时间先变长再变短；视角 B：同样加人，高/低可并行项目命运迥异

当前团队规模 n：5 人

一次性加入人数 m：5 人

带教抽血率 τ：0.5（每新人消耗 τ 名老手产出，累计 2.5 人月/月）

净有效人力（老手产出 − 带教抽血）被抽走/损耗的产出

—

Personal Takeaways — 个人启示 · 03

人月不是货币，是陷阱

一切"再要十个人月"的说法都值得警惕：人月假设人和月可互换，而真实世界里沟通成本按平方增长、带教成本先吃掉产能。估算时把这两项显式列进成本，是管理者诚实的第一步。

落后的项目，先减法后加法

落后时最便宜的三步永远是：砍范围、调顺序、换掉关键路径上的人——加人是最后手段，且加的人必须能独立扛走一块完整工作。用视角 B 的结论说话：可并行度不够时，加人是花钱买延期。

组织结构是最好的优化器

n(n−1)/2 不是宿命而是设计参数：小团队、清晰接口、异步文档化沟通，都在压低那条平方曲线的系数。把系统拆成低耦合模块，等于把大团队的沟通税分摊给接口——布鲁克斯与康威在此汇合。