Back to Details

thinking-pre-mortem

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Pre-Mortem Analysis

Pre-Mortem 事前失败分析

Core rule: Prospective hindsight beats "what could go wrong?" Assume the plan has already failed (past tense), generate concrete failure paths, reverse them into prevention requirements, and bind each top path to a verifiable plan change.
核心原则： 前瞻性事后复盘优于“可能会出什么问题？”的思考方式。假设计划已经失败（用过去时态表述），梳理出具体的失败路径，将其转化为预防要求，并将每条关键路径与可验证的计划变更绑定。

When to Use

适用场景

  • Before kickoff, major technical commitment, high-risk sprint work, launch, or release.
  • After a plan looks solid but before execution, especially when optimism or overconfidence is likely.
  • When a decision is costly to reverse and risks are still implicit rather than enforced.
  • 在项目启动、重大技术投入、高风险迭代工作、上线或发布之前。
  • 在计划看似成熟但尚未执行时，尤其是可能存在乐观情绪或过度自信的情况下。
  • 当决策的反转成本很高，且风险仍未明确而是隐含存在时。

When NOT to Use

不适用场景

  • Work is small, local, and cheaply reversible — skip the ceremony.
  • You are mid-incident under time pressure — act now (OODA / scientific method); pre-mortem is pre-execution.
  • You would only emit generic risks ("scope creep", "requirements unclear") that do not bind to this plan.
  • Risks are already enforced by live gates (CI, canary, rollback, alerts) with no residual unlisted path.
  • A mature risk register already covers the same specific failure paths with owners and checks.
  • 工作规模小、影响范围有限且反转成本低——无需进行该流程。
  • 处于事件处理中且时间紧迫——立即采取行动（OODA循环/科学方法）；事前失败分析是执行前的工作。
  • 只能提出通用风险（如“范围蔓延”、“需求不明确”），且这些风险与当前计划无关。
  • 风险已由现有管控节点（CI、金丝雀发布、回滚机制、告警）覆盖，无剩余未列明的风险路径。
  • 成熟的风险登记册已涵盖相同的具体失败路径，并明确了负责人和检查机制。

Procedure

执行步骤

  1. Set the failure frame in past tense: "It is [post-deadline date]. The plan failed: [rollback / data loss / no adoption / SLA breach]." Explaining a happened failure is required; predicting one is not enough.
  2. Generate failure reasons before filtering: sweep technical, process, assumptions, dependencies/external, and people. Force a second pass: "What did the plan most need to be true that was not?" Collect breadth first (aim for many distinct reasons); do not rank mid-sweep.
  3. Prioritize: group by theme; score likelihood × impact; keep the top 3–5 concrete risks (drop generics that do not bind).
  4. Failure-first reverse analysis (absorbed reverse path): for each top risk, (a) restate the failed outcome in past tense, (b) list necessary/enabling conditions that had to be true for that failure, (c) invert each condition into a verifiable prevention requirement (avoid/require rule + check), (d) bind owner, verification checkpoint, and ship/stage gate.
  5. Mitigate and update the plan: for each top risk, attach mitigation steps, spike/contingency if needed, and the reverse-analysis prevention requirements as explicit plan gates. A pre-mortem with no plan change is incomplete.
  6. Stop when top risks each have a bound mitigation or prevention gate, or when further reasons are only generic restatements — then ship the updated plan, do not keep brainstorming.
  1. 设定过去时态的失败场景：“现在是[截止日期之后的日期]。计划失败了：[回滚/数据丢失/无人采用/SLA违约]。”必须解释已发生的失败，仅预测失败是不够的。
  2. **先梳理失败原因再筛选：**涵盖技术、流程、假设、依赖/外部因素以及人员方面。进行二次梳理：“计划最需要成立的前提是什么，但实际并不成立？”先广泛收集（目标是多种不同的原因）；梳理过程中不要排序。
  3. **优先级排序：**按主题分组；按可能性×影响评分；保留前3–5个具体风险（剔除与当前计划无关的通用风险）。
  4. 以失败为导向的反向分析（反向路径整合）：针对每个关键风险，(a) 用过去时态重述失败结果，(b) 列出导致该失败必须满足的必要/促成条件，(c) 将每个条件转化为可验证的预防要求（包含规避/强制规则+检查机制），(d) 绑定负责人、验证检查点和交付/阶段管控节点。
  5. **缓解风险并更新计划：**针对每个关键风险，附加缓解步骤、必要的探索性任务/应急预案，并将反向分析得出的预防要求作为明确的计划管控节点。如果事前失败分析没有带来计划变更，那么该分析是不完整的。
  6. 停止时机：当每个关键风险都有绑定的缓解措施或预防管控节点，或者后续提出的原因只是通用表述的重复时——此时即可发布更新后的计划，无需继续头脑风暴。

Output

产出物

  1. Failure scenario — past-tense disaster frame with date and failed outcome.
  2. Failure reasons — unfiltered list, then prioritized top 3–5 with likelihood × impact.
  3. Reverse paths — for each top risk: necessary conditions → inverted prevention requirements.
  4. Mitigations — owner, verification checkpoint, ship/stage gate per top risk.
  5. Plan deltas — concrete tasks, spikes, contingencies, and gates added to the plan.
  1. 失败场景——包含日期和失败结果的过去时态灾难场景描述。
  2. 失败原因——未筛选的完整列表，以及经优先级排序的前3–5个风险（带可能性×影响评分）。
  3. 反向路径——针对每个关键风险：必要条件→转化后的预防要求。
  4. 缓解措施——每个关键风险对应的负责人、验证检查点和交付/阶段管控节点。
  5. 计划变更——添加到计划中的具体任务、探索性任务、应急预案和管控节点。

Verification

验证机制

  • Falsify/stop: if no plan-specific failure path can be stated in past tense with necessary conditions, stop — you are generating theater, not risk. If a "mitigation" has no verification checkpoint, it is not done.
  • Over-application guard: do not pre-mortem reversible chores, mid-incident firefighting, or systems that already enforce the same paths. Do not leave abstract risks as "mitigate later"; either invert them into gates or drop them as non-actionable.
  • **证伪/停止：**如果无法用过去时态表述带有必要条件的特定于计划的失败路径，那么停止——你只是在走形式，而非识别风险。如果某个“缓解措施”没有验证检查点，则视为未完成。
  • **过度应用防范：**不要对可反转的日常事务、事件处理中的应急工作或已覆盖相同风险路径的系统进行事前失败分析。不要将抽象风险留作“稍后缓解”；要么将其转化为管控节点，要么将其视为无法落地而剔除。