布鲁克斯定律：人月神话
"给一个已经延期的项目加人——只会让它更慢。"这不是说加人不干活——而是说新人的上手成本、沟通成本、协调成本，在已经延期的项目上会超过他们带来的额外产出。
**预计时间：**25 分钟读完 + 25 分钟做练习 = 50 分钟。
一、为什么加人会让项目更慢
1.1 三种”减速”机制
| 机制 | 说明 | 量化 |
|---|---|---|
| 培训成本 | 现有团队成员需要花时间带新人——这些时间本应花在实际开发上 | 新人上手期（2-12 周），老成员的效率会下降 20-50% |
| 沟通成本 | N 个人的沟通路径 = N(N-1)/2——加人后路径数平方增长 | 5 人团队：10 条路径；10 人团队：45 条路径 |
| 任务不可分割 | 有些任务不能并行——你必须等 A 做完，B 才能开始 | ”9 个女人不能在一个月内生出一个孩子”——Brooks 的经典比喻 |
1.2 布鲁克斯定律的数学直觉
假设一个项目需要 100 人月，已经花了 20 人月完成了 20%。还剩 80 人月的工作量。你觉得再加 5 个人 → 剩下 80 人月由原来的 5 人 + 新 5 人 = 10 人，8 个月做完？
实际上：新 5 人需要 2 个月上手（前 2 个月产出很少→老 5 人还需要花时间教他们）。2 个月后，10 人一起做剩下的 80 人月——但沟通成本增加了。原本的进度可能变成：前 2 个月几乎没有额外产出（老成员在带人），第 3-6 个月 10 人做了一部分——总时间可能 >12 个月。
二、布鲁克斯定律的例外
2.1 什么时候加人有效
- 项目早期：还在架构设计和任务分解阶段——新人可以在”独立的任务块”上工作，不干扰核心
- 任务高度可分解：比如测试、文档、数据迁移——这些任务可以独立进行，不需要太多上下文
- 已经有明确的设计和接口规范：新人不需要理解全系统——只需要按照接口规范做一部分
- 不是延期项目：正常进度的项目加人可以提前——但延期的项目加人大概率会更慢
2.2 什么时候加人特别无效（甚至有害）
- 项目已经延期了（最经典的违反）
- 架构还在变动中（新人学到的知识很快就过时了）
- 没有完善的文档和环境搭建指南（新人上手慢）
- 需要”全栈”理解才能做贡献的任务
三、布鲁克斯定律的应对策略
3.1 不加人——而是缩小范围
如果项目延期了，最好的选择不是加人——而是和业务方商量”哪些功能可以推迟到 V2”？减少范围比增加人手更有效。
3.2 做”可逆”的架构设计
将系统设计成”可并行开发”的模块——这样在需要加速时，可以分配多个团队并行工作而不增加沟通成本。但这需要在早期就做好——不是延期时能做的工作。
3.3 用更好的工具和自动化
与其加人——不如投资在 CI/CD、自动化测试、代码生成、脚手架工具上。这些工具的回报在下一个项目也会持续体现。
3.4 新人入职有”缓冲区”
不要指望新人一进来就全速产出。给他们 2-4 周的”缓冲区”——这段时间他们学习系统、熟悉流程、做小任务。团队的 Sprint 容量在这段时间不应该把新人算进去。
四、实战案例
4.1 案例 1：经典的反面教材
某金融系统项目延期了——管理层决定从其他项目组调 5 个人来”支援”。
- 5 个人来了——但他们不熟悉交易业务
- 原有的 3 个核心开发需要花时间给他们讲解架构、业务逻辑、代码规范
- 前 4 周：原团队的产出下降了 60%（因为 3 个人都在带新人）
- 第 5 周：新人开始能做一些独立任务——但沟通会议从每周 3 小时变成了每周 8 小时
- 第 8 周：项目进度比”不加人”还慢了 20%
管理层很困惑：“我们加了人啊！“——这就是布鲁克斯定律的经典场景。
4.2 案例 2：正确的做法
另一个项目也延期了——团队做了不同的事：
- 不是加人——而是和业务方重新讨论优先级：把 V1 范围缩小 40%
- 砍掉的功能：次要报表、管理后台的一些页面、非核心流程的优化
- 保留了核心交易流程、风控、核心报表
- 结果是：V1 在延期 2 周后上线——而不是延期 3 个月等”加人的效果显现”
4.3 案例 3：架构”可分解”的例子
一个项目在设计时已经考虑到了可并行性：
- 清晰界定了 API 契约（服务间接口）
- 每个模块的数据库有独立的 Schema
- 文档完整（包括本地开发环境搭建指南）
- 结果：加入 2 个新人后，第 1 周就有独立的模块可做——因为接口定义清楚了，不需要理解全系统
这是布鲁克斯定律的反面——当系统可分解时，加人是有效的。
五、测验（11 题）
布鲁克斯定律的核心是？
"9 个女人不能在一个月内生出一个孩子"——Brooks 的比喻说明了？
新人加入团队时，老成员的效率通常会？
5 人团队的沟通路径数是？
布鲁克斯定律什么时候成立？
项目延期后，比加人更有效的第一步是？
下面哪种情况适合在项目中加人？
"新人入职的前 4 周不算 Sprint 容量"——为什么要这样做？
Berkshirie 核心投资团队不到 10 人——体现了芒格对什么的理解？
布鲁克斯定律给 PM 最重要的启示是？
场景题
R1. 场景：你的交易结算模块项目已经延期 1 个月了。VP 说"我再给你调 3 个人过来"。你应该？
R2. 场景：你正在启动一个新项目——你有机会在团队组建时就做好"可扩展"的架构。你该做什么？
六、答题提示
展开提示
- Q1-3 核心：培训成本 + 沟通成本 + 任务不可分解 = 加人更慢。
- Q4-5 沟通路径 = N(N-1)/2——平方增长。
- Q6-7 缩范围 > 加人；但架构清晰时加人有效。
- Q8-10 新人缓冲期不可忽视；芒格的”小团队”本质上是对布鲁克斯定律的直觉理解。
- R1-R2 延期时不要本能扩张——先缩范围；新项目先打好架构基础。
七、本课行动清单
- 回顾你经历过的延期项目——是不是有过”加人反而更慢”的经历？如果有，把那次经历写下来作为团队的学习材料。
- 在项目启动时，做一次”可分解性评估”：这个项目能否拆成可并行开发的任务块？如果不能——提前警告利益相关方”加人不会加快”。
- 在新人入职时，确保有文档、有 Mentor、有缓冲区——不要让新人第一周就全速投入。
- 下次项目延期时，先试着谈范围缩减——在没有尝试过范围缩减之前，不要谈加人。
八、参考来源
- ② 经典：Frederick P. Brooks Jr.，《The Mythical Man-Month》（1975）——布鲁克斯定律的原始出处，软件项目管理经典中的经典
- ③ 严肃著作：Frederick P. Brooks Jr.，《The Design of Design》——关于设计过程和可分解性的延伸思考
- ③ 严肃著作：Tom DeMarco & Timothy Lister，《Peopleware: Productive Projects and Teams》——从”人”的角度看项目管理，与布鲁克斯定律互相印证
- ④ 实用读物：Steve McConnell，《Rapid Development》——快速开发的最佳实践，包括如何避免布鲁克斯陷阱
**下一步：**看 Lesson 0019 · 侯世达定律。