用途
Pre-Mortem Analysis（事前验尸分析）用于在承诺执行计划或发布之前，通过“假设已经失败”的方式暴露隐含风险。其核心规则是：前瞻性后见之明（prospective hindsight）优于直接问“可能会出什么问题？”。具体做法是假设计划已经失败（用过去时表述），生成具体失败路径，将其反向转化为预防要求，并把每条关键路径绑定到可验证的计划变更上。
何时使用
- 在启动、重大技术承诺、高风险冲刺工作、发布或上线之前。
- 在计划看起来扎实但尚未执行时，尤其是乐观或过度自信可能出现时。
- 当决策逆转成本高，且风险仍是隐含的而非已被强制执行时。
何时不使用
- 工作规模小、局部、可低成本逆转——跳过此仪式。
- 正处于事故处理中且有时间压力——立即行动（OODA / 科学方法）；事前验尸是执行前的活动。
- 只能产出泛泛风险（如“范围蔓延”“需求不清晰”）且无法绑定到本计划时。
- 风险已由实时门禁（CI、金丝雀、回滚、告警）强制执行，且没有残留的未列出路径。
- 已有成熟风险登记册覆盖相同的具体失败路径，并配有负责人和检查。
流程
- 用过去时设定失败框架：“现在是[截止日期之后]。计划失败了：[回滚 / 数据丢失 / 无人采用 / SLA 违约]。”必须解释已发生的失败，仅预测不够。
- 在筛选前生成失败原因：扫过技术、流程、假设、依赖/外部、人员。强制进行第二轮：“计划最需要成真但并未成真的事情是什么？”先收集广度（目标为许多不同原因）；不要在扫掠中途排序。
- 优先级排序：按主题分组；按可能性 × 影响评分；保留前 3–5 项具体风险（丢弃无法绑定的泛泛项）。
- 失败优先反向分析（吸收反向路径）：对每项顶级风险，(a) 用过去时重述失败结果，(b) 列出该失败必须为真的必要/使能条件，(c) 将每个条件反转为可验证的预防要求（避免/要求规则 + 检查），(d) 绑定负责人、验证检查点和发布/阶段门禁。
- 缓解并更新计划：对每项顶级风险，附加缓解步骤、必要时 spike/应急方案，以及反向分析得出的预防要求作为明确的计划门禁。没有计划变更的事前验尸是不完整的。
- 当每项顶级风险都有绑定的缓解或预防门禁，或进一步原因只是泛泛重述时停止——然后发布更新后的计划，不要继续头脑风暴。
输出
- 失败场景——带日期和失败结果的过去时灾难框架。
- 失败原因——未过滤列表，然后按可能性 × 影响排序的前 3–5 项。
- 反向路径——对每项顶级风险：必要条件 → 反转后的预防要求。
- 缓解措施——每项顶级风险的负责人、验证检查点、发布/阶段门禁。
- 计划增量——添加到计划中的具体任务、spike、应急方案和门禁。
验证
- 证伪/停止：如果无法用过去时陈述计划特定的失败路径及其必要条件，停止——你正在生成表演，而非风险。如果“缓解措施”没有验证检查点，就不算完成。
- 过度应用防护：不要对可逆杂务、事故中救火或已强制执行相同路径的系统做事前验尸。不要把抽象风险留作“稍后缓解”；要么将其反转为门禁，要么作为不可操作项丢弃。