侯世达定律：估算恒久远
预计时间：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 · 事前验尸与预检。