事前验尸（Pre-mortem）
事前验尸的做法是假定方案已经失败，让模型倒推失败原因。相比开放式地问「可能有什么风险」，「它已经坏了，因为……」这个设定绕开了乐观偏差，更容易挖出具体隐患。输出按「失败机制 + 早期信号 + 预防动作」三件套整理，可以直接进风险台账。
基本信息
| 设定 | 假定方案上线后已被证明失败 |
|---|---|
| 输出 | 失败机制 + 早期信号 + 预防动作 |
| 来源 | 事前验尸方法（Gary Klein, HBR 2007） |
| 排序 | 按可能性排序，避免罗列常识级风险 |
典型使用场景
- 上线前风险盘点：在方案评审会上作为固定环节
- 迁移与割接方案：倒推最容易出问题的步骤
- 预算与排期评估：找出导致超期超支的具体机制
- 组织变更：识别执行层面的阻力与断点
- 项目复盘模板复用：把上一轮的失败机制作为本轮的检查项
模板
模板
假设该方案上线 3 个月后被证明失败。
请倒推 6 条可能的原因，按可能性由高到低排序，
每条包含：
1. 失败机制：一句话说清是怎么坏的
2. 早期信号：上线后多久、通过什么指标能提前发现
3. 预防动作：现在就能做的一件具体事
约束：
- 不要写「可能人手不足」这类放之四海皆准的原因
- 每条必须能对应到本方案的具体环节
- 输出用表格：机制 / 信号 / 预防动作 / 可能性输出逐列读法
| 列 | 含义 | 质量判断 |
|---|---|---|
| 失败机制 | 失败是如何发生的 | 能说出具体环节与因果链才合格 |
| 早期信号 | 上线后可观测的预警指标 | 写不出可观测指标说明机制太笼统 |
| 预防动作 | 当前可执行的干预 | 动作要能在评审后一周内启动 |
| 可能性 | 相对排序 | 全部标「高」等于没有排序 |
| 覆盖面 | 是否覆盖技术、流程、协作三类 | 只列技术风险说明视野偏窄 |
不限定数量与排序时，模型会罗列放之四海皆准的风险。要求按可能性排序并给出可观测信号，输出质量会明显提升。
倒推出来的结果需要人工筛选，不要把整张表原样当成风险清单发布。模型的产出适合作为讨论的引子，最终结论仍要由了解项目细节的人确认。