thinking-pre-mortem

事前验尸分析

核心原则： 前瞻性后见之明胜过“可能出什么问题？”。假设计划已经失败（用过去时），生成具体的失败路径，将其反向转化为预防要求，并为每个主要路径绑定一项可验证的计划变更。

适用场景

• 启动前、做出重大技术承诺前、开展高风险冲刺工作前、发布或上线前。
• 计划看似完善但尚未执行时，尤其是在容易过度乐观或过度自信的情况下。
• 决策一旦做出就难以撤回，而风险仍未明确落实为强制措施时。

不适用场景

• 工作规模小、范围局部且容易低成本撤回——跳过这套流程。
• 时间紧迫，正处于事故处理中——立即行动（OODA / 科学方法）；事前验尸用于执行前。
• 你只能列出“范围蔓延”“需求不明确”等通用风险，且这些风险与当前计划无关。
• 风险已经由实时关卡（CI、金丝雀发布、回滚、告警）强制管控，且没有未列出的剩余路径。
• 成熟的风险登记表已经涵盖相同的具体失败路径，并明确了负责人和检查项。

流程

1. 用过去时设定失败情境：“现在是 [截止日期之后的日期]。计划失败了：[回滚 / 数据丢失 / 无人采用 / SLA 违约]。”必须解释已经发生的失败；仅仅预测失败还不够。
2. **筛选前先生成失败原因：**逐一检查技术、流程、假设、依赖项/外部因素和人员。强制进行第二轮：“计划最依赖哪件必须为真的事情，结果却并非如此？”先广泛收集（尽量列出许多不同原因）；扫描过程中不要排序。
3. **确定优先级：**按主题分组；评估可能性 × 影响；保留排名前 3–5 的具体风险（剔除与计划无关的泛泛之谈）。
4. 以失败为先进行反向分析（吸收式逆向路径）：针对每项主要风险，(a) 用过去时重述失败结果，(b) 列出导致该失败所必需的条件/促成条件，(c) 将每个条件反转为可验证的预防要求（避免/强制规则 + 检查），(d) 绑定负责人、验证检查点和发布/阶段关卡。
5. **采取缓解措施并更新计划：**为每项主要风险附上缓解步骤；必要时增加探索性验证或应急方案，并将反向分析得出的预防要求作为明确的计划关卡。没有计划变更的事前验尸并不完整。
6. **在以下情况下停止：**每项主要风险都有明确绑定的缓解措施或预防关卡，或者进一步列出的原因都只是泛泛重述——然后发布更新后的计划，不要继续集思广益。

输出

1. 失败情境——包含日期和失败结果的过去时灾难情境。
2. 失败原因——未经筛选的列表，然后列出按优先级排序的前 3–5 项及其可能性 × 影响。
3. 反向路径——针对每项主要风险：必要条件 → 反向得出的预防要求。
4. 缓解措施——针对每项主要风险，列出负责人、验证检查点和发布/阶段关卡。
5. 计划变更——新增的具体任务、探索性验证、应急方案和关卡。

验证

• **证伪/停止：**如果无法用过去时陈述与计划具体相关、且包含必要条件的失败路径，就停止——你是在作秀，而不是评估风险。如果某项“缓解措施”没有验证检查点，就说明尚未完成。
• **避免过度应用：**不要对可撤回的杂务、事故中的紧急处置，或已通过强制措施管控相同路径的系统进行事前验尸。不要把抽象风险留作“之后再缓解”；要么将其反向转化为关卡，要么将其剔除为不可采取行动的风险。