侯世达定律：估算恒久远
侯世达定律说："任何事——即使你考虑了侯世达定律——所花的时间总是比你预期的要长。"它是软件工程中最令人沮丧又最准确的定律。
**预计时间：**20 分钟读完 + 25 分钟做练习 = 45 分钟。
一、为什么估算总是不准
1.1 根本原因
| 原因 | 说明 |
|---|---|
| 未知的未知 | 你不可能知道那些你不知道的东西——而它们一定会出现。一个新框架的坑、一个之前没发现的兼容问题、用户的一个意外需求 |
| 乐观偏差 | 人天然倾向于假设”一切顺利”——而现实是”大部分时候不会一切顺利” |
| 计划谬误 | 即使是知道历史数据的团队，在做新估算时也会忽略历史数据——因为”这次不一样” |
| 预估 = 承诺 | 当估算被当作承诺时，人们倾向于报一个”乐观时间”来取悦上级——然后这个时间就成了deadline |
| 忽略了协调成本 | 估算时只算了”纯开发时间”——忘记了会议、代码审查、沟通、环境问题、等待审批的时间 |
1.2 “自指”特质
侯世达定律的巧妙之处在于它是”自指”（self-referential）的——你即使知道这个定律，试图在估算时加上侯世达定律的”buffer”，这个 buffer 本身也可能不够。因为你在加 buffer 时也会乐观——“2 周变 3 周应该够了吧”——但可能实际上要 4 周。
二、侯世达定律的应对策略
2.1 不要做”点估算”——做”区间估算”
不要估”2 周”——估”2-4 周”或者”中位数 3 周，P80 5 周”（80% 的概率在 5 周内完成）。区间估算诚实地表达了不确定性。
2.2 用历史数据做解药
收集”估算 vs 实际”的数据。不要凭感觉——用数据告诉你”通常偏差多少”。如果一个团队的历史偏差是 2x——那他们的新估算乘以 2 才是合理预期。虽然听起来沮丧，但至少数据比你乐观偏差诚实。
2.3 分解到”小任务”
小任务的估算比大任务更准。一个 2 天的任务，大概率就是 2 天左右。一个 2 个月的功能——可能偏差 2-4 周。越小越准。所以好的做法是：在估算时把大任务分解成 2-3 天的小任务。
2.4 不要混淆”估算”和”截止日期”
估算 = 基于当前信息的最好推测。截止日期 = 业务需要的交付时间。它们是两回事。好的流程是：团队给出估算（包含不确定性范围）→ 业务方根据估算决定截止日期（或调整范围）。
2.5 定期重新估算
不要”估一次用一年”。随着项目进行，你对系统的理解在变化——每个月重新审视估算，更新范围和时间预期。
三、侯世达定律 vs 其他项目管理定律
| 定律 | 核心 | 侯世达定律的关系 |
|---|---|---|
| 帕金森定律 | 工作膨胀填满可用时间 | 互补——即使给了合理时间，帕金森让你用满；即使算上了帕金森，侯世达还是让时间不够 |
| 布鲁克斯定律 | 延期项目加人更慢 | 互补——延期了想加人（布）→ 加人后协调成本增加（侯世达）→ 更延期 |
| 侯世达定律 | 总是比你预期的长——即使你考虑了这个定律 | —— |
四、实战案例
4.1 案例 1：“集成只要 1 天”
A 系统要和 B 系统做一个新的数据对接。开发估算”集成只要 1 天”。实际上：
- B 系统的 API 文档不全——花了 1 天读代码
- B 系统的认证方式和我们假设的不同——花了半天改认证
- A 系统的数据格式需要转换——比想象中复杂，花了 1 天
- 联调时发现 B 系统有一个 Bug——等 B 团队修复等了 2 天
- 总时间：5 天——“1 天”的 5 倍
侯世达定律在作用：你不可能提前知道那些”你不知道你不知你道”的细节。
4.2 案例 2：侯世达定律 + 管理层
团队说”2 个月能上线 V1”。管理层在汇报时承诺了”2 个月”。结果：
- 第 1 个月末发现：第 3 方 SDK 兼容性问题花了 2 周——进度落后
- 管理层追问：“为什么？你们当时不是估了 2 个月吗？”
- 团队陷入”解释延期”的循环——而不是真正去解决问题
- 最终上线时间：4 个月
问题：把”估算”当成了”承诺”。管理层如果能接受”2-4 个月的区间估算”，整个沟通过程会顺畅很多。
4.3 案例 3：反侯世达实践——渐进式交付
某团队的做法是：不做一个巨大的 V1 版本——而是把项目分成多个 2 周的小迭代——每个迭代交付一个可用的、但功能有限的小版本。
- 不用一次性估算 6 个月后的交付日期
- 只估算接下来 2 周的工作
- 每 2 周重新调整后续计划
- 结果：没有一次”大延期”——每次都是小范围调整
这是对抗侯世达定律最有效的方式——不依赖长期估算，而是靠短期交付的反馈来校准方向。
五、测验（10 题）
侯世达定律的核心是？
侯世达定律的"自指"特质意味着？
"计划谬误"指的是？
下面哪种做法能最有效对抗侯世达定律？
"估算"和"截止日期"应该是什么关系？
为什么小任务的估算比大任务更准？
管理层把"2 个月"的估算当成承诺向公司宣布——问题在哪？
对抗侯世达定律最有效的项目管理方式是？
芒格的"反转"方法在侯世达定律上的应用是？
收集"估算 vs 实际"的历史数据——价值在于？
场景题
R1. 场景：你的团队估计一个数据迁移项目需要 2 周。你检查了历史数据——发现过去类似的"2 周估算"项目，实际平均花了 3.5 周。你的侯世达应对？
R2. 场景：某功能开发了 2 周后发现比想象中复杂很多——需要额外 2 周。管理层很不满意因为"你们当时说 2 周"。你该怎么做？
六、答题提示
展开提示
- Q1-3 核心：你不知道你不知道的东西 + 乐观偏差 = 总延期。
- Q4-5 区间估算 + 区分估算/截止日期 = 诚实沟通的基础。
- Q6-7 小任务更准 + 不要把估算当承诺。
- Q8-10 短迭代不依赖长期估算；历史数据是乐观偏差的解药。
- R1-R2 用历史数据说话 + 诚实沟通未知复杂性。
七、本课行动清单
- 收集你最近 10 个任务的”估算 vs 实际”数据——计算你的团队的平均偏差。
- 下次做估算时，给区间（“2-4 周”）而不是点（“3 周”）。
- 如果管理层要求”一个数字”——给出”最有可能是 X 周，但 P80 是 Y 周”。
- 在项目启动时用”反转法”：列 5 个”这个项目最可能延期的原因”——提前做应对计划。
八、参考来源
- ③ 严肃著作：Douglas R. Hofstadter，《Gödel, Escher, Bach: An Eternal Golden Braid》（1979）——侯世达定律的原始出处（一本关于自指、递归和意识的经典）
- ③ 严肃著作：Daniel Kahneman & Amos Tversky——关于”计划谬误”（Planning Fallacy）的前景理论
- ③ 严肃著作：Bent Flyvbjerg & Dan Gardner，《How Big Things Get Done》——大型项目的延期规律和应对策略
- ④ 实用读物：Steve McConnell，《Software Estimation: Demystifying the Black Art》——实用的软件估算方法
**下一步：**看 Lesson 0020 · 事前验尸与预检。