规划谬误
解释规划谬误如何让人系统性低估未来任务的时间、成本与风险，并用内部视角、外部基准和参考类预测改进软件项目估算。
[!info] related notes
- 所属 MOC: cognitive-biases-moc
- 前置概念:
- 并列概念:
- 易混淆概念:
- 关系笔记:
规划谬误
一句话定义
规划谬误（planning fallacy）是：即使过去类似任务反复延期，人们仍倾向根据当前计划的理想执行路径，系统性低估未来任务所需时间、成本和风险。
它不是普通的“一次估错”，而是一种有方向的偏差：经常偏向过度乐观。
内部视角 Inside View
做计划时最自然的方式是：
需求分析 2h
编码 6h
测试 3h
部署 1h
≈ 12h这叫内部视角：从当前任务的具体故事出发，模拟“如果一切按计划进行”。
问题是现实还包括：
- 需求变化；
- 环境差异；
- review；
- CI；
- 集成冲突；
- 等待外部依赖；
- 失败重试；
- 隐藏工作。
这些往往不会出现在最初的心理模拟里。
外部视角 Outside View
外部视角先问：
过去真正类似的任务通常花多久？
例如：
过去 20 个类似重构：
P50 = 4 天
P80 = 7 天
P90 = 10 天即使当前团队觉得：
“这次比较简单，3 天应该够。”
也应该先以历史分布为基准，再根据真正不同之处调整。
这叫 reference class forecasting（参考类预测）。
软件项目特别容易出现
软件任务通常具有：
- 高不确定性；
- 隐藏依赖；
- 首次实现；
- 集成成本；
- 测试与 review 后才暴露的新工作。
因此只估“写代码时间”会极度乐观。
真正的 Done 往往是：
理解需求
+ 设计
+ 实现
+ 测试
+ 集成
+ review
+ repair
+ 文档
+ 发布
+ 验证Agent 自动开发同样会中招
计划可能写：
1. 修改 API
2. 更新 UI
3. 跑测试
4. 合并看起来只需四步。
真实执行却可能出现：
测试暴露旧契约
→ 修复
→ review 发现架构偏移
→ replan
→ CI 环境差异
→ repair因此 Agent planner 不能把“计划步数”直接当作工作量。
更好的系统应该记录：
- 每类 ticket 的历史 cycle time；
- review retry 分布；
- blocked 比率；
- CI failure rate；
- 返工比例。
与过度自信的关系
过度自信偏差表现为：
我对这个时间估计过于确定。
规划谬误更具体：
我的计划系统性遗漏现实摩擦，因此整体偏乐观。
它们经常共同出现：
乐观计划
+
极窄时间区间
=
高风险承诺与锚定的关系
如果第一个人说：
“两天差不多。”
整个团队后续可能围绕 2 天调整，形成 锚定效应。
所以流程上最好：
先独立拆任务 / 看历史基准
→ 再共享估计为什么“加 20% buffer”不总能解决
如果真正的问题是遗漏了整类工作：
迁移 3 天
review repair 4 天
外部依赖等待 5 天而你原估计只有 2 天编码，那么机械加 20% 仍然远远不够。
先要识别工作分布，再谈 buffer。
参考类预测
步骤：
- 找到一组真正类似的过去项目；
- 看实际结果分布，而不是原计划；
- 选择需要的置信水平，例如 P80；
- 再根据当前任务的明确差异调整。
例如：
类似任务 P80 = 8 天
当前任务少一个迁移步骤，历史该步骤通常 2 天
→ 初始参考估计约 6 天这比从空白开始想象“我觉得四天”更稳健。
什么情况乐观估计不是谬误
如果当前任务确实发生结构性变化：
- 有新的自动化；
- 模板化程度显著提高；
- 团队已重复完成很多次；
- 依赖被移除；
那么过去基准可以合理向下调整。
关键是有可说明的差异证据，而不是“这次感觉会顺”。
去偏方法
1. 先看历史完成时间
不要只看历史计划时间。
2. 给概率区间
P50：4 天
P80：7 天
P95：11 天比“6 天完成”更真实。
3. 做 premortem
假设项目已经延期两周，问：
最可能是什么导致的？
主动把隐藏风险写出来。
4. 区分编码完成和交付完成
明确 Definition of Done。
5. 记录估计误差
长期看：
estimated / actual按任务类别校准。
快速自测
一个团队过去 10 次类似发布平均要 6 天，当前负责人说：
“这次我把步骤都想清楚了，应该 2 天。”
正确动作不是直接否定 2 天，而是要求解释：这一次相较历史样本到底改变了哪些结构性因素，足以把 6 天降到 2 天？
一句记忆
计划描述的是事情怎样顺利发生；历史分布提醒你，现实还会决定事情怎样不顺利。
Digital Biome