marsloting Pre-mortem 失败推演 + Risk Register
何时触发
- 任何方案 / 上线 / campaign / 战略决策定稿前
- "上线前最后过一遍"
- "这有什么风险"
- "万一 X 怎么办"
- 五维碰撞测试发现某维度有问题但不严重时（追加 pre-mortem 量化）
- 用户 表达"我感觉哪里不对但说不上来"
- 团队过度乐观信号（"肯定能做完" / "一定会成功"）
何时不触发
- 已经上线后的事故复盘 → 用
root-cause - 单一选项是否做的二元决策 → 用
decision-matrix - 创意发散阶段（pre-mortem 是收敛阶段工具）
核心方法：Klein Pre-mortem
Gary Klein 1989 经典方法——把 post-mortem 提前。
视角切换（关键）
不要问："这个方案会有什么风险？"（人会下意识防守）
要问："假设 6 个月后这个方案彻底失败了。现在写一份 autopsy——失败的原因都有哪些？"（视角切换 → 大脑进入归因模式 → 风险被主动挖出）
5 步流程
Step 1：场景设定
现在是 <T+6 个月> / <上线后 X 周> / <campaign 结束后>
方案 / 项目 / 决策已经彻底失败
你正在写失败 autopsy
明确"失败"的具体形态：用户没用 / 业务指标没达 / 团队解散 / 老板砍项目 / 技术债不可维护 / 法务被告 / 公关危机。
Step 2：穷举失败原因（每人独立写）
每个参与者独立列出至少 5 条失败原因。不要先讨论——独立列完后再合并。
理由：群体讨论会触发从众效应，独立列才能拿到 diverse 输入。
类型清单（每类至少 1 条）：
| 类别 | 检查点 |
|---|---|
| 用户层 | 用户根本不需要 / 用户用法和我们想的不一样 / 用户切换成本太高 |
| 市场层 | 竞品先发 / 时机错 / 用户教育成本太高 |
| 技术层 | 实现复杂度被低估 / 性能不满足 / 第三方依赖崩 / 数据迁移踩坑 |
| 团队层 | 关键人离职 / 技能不匹配 / 沟通断 / 优先级被抢 |
| 流程层 | 评审流程没走完 / 法务卡住 / 安全 review 不过 |
| 外部层 | 政策变 / 合作方违约 / 黑天鹅事件 |
Step 3：合并 + 概率 / 影响 评分（FMEA 量化）
合并所有人列的原因，去重。每条按 FMEA 三维评分：
| 维度 | 含义 | 范围 |
|---|---|---|
| Severity (S) | 失败影响多大 | 1 (轻微) - 10 (灾难) |
| Probability (P) | 多大可能发生 | 1 (几乎不) - 10 (高度可能) |
| Detectability (D) | 多容易事先发现 | 1 (容易) - 10 (难) |
RPN (Risk Priority Number) = S × P × D，最高 1000，最低 1。
Step 4：Risk Register（按 RPN 降序）
| ID | 失败原因 | S | P | D | RPN | Mitigation 动作 | Owner | 截止 |
|---|---|---|---|---|---|---|---|---|
| R1 | <原因 1> | 8 | 6 | 7 | 336 | <具体动作> | 用户 | 5-15 |
| R2 | <原因 2> | 9 | 4 | 3 | 108 | <具体动作> | F | 5-12 |
| ... |
红线：
- RPN > 200 → 必须有 mitigation，mitigation 不到位前不上线
- 100 < RPN ≤ 200 → 必须有 mitigation 计划，可上线但盯紧
- RPN ≤ 100 → 标记观察，无 mitigation 也可上线
Step 5：Mitigation 类型（按降序选）
- Eliminate：消除根因（最优）—— 改方案让风险不存在
- Reduce probability：降低发生概率
- Reduce severity：降低发生时影响（feature flag / staged rollout）
- Improve detectability：提早发现（监控 / alert / canary）
- Transfer：转移风险（保险 / 合同条款）
- Accept：接受风险（写进 decisions-log，不再 mitigation）
模板（完整 pre-mortem 输出）
# <方案名> Pre-mortem
## 场景设定
- 失败时点：<T+X 月>
- 失败定义：<用户没用 / 业务指标没达 / ...>
## 独立列出的失败原因（合并去重前）
### 用户 列的：
1. ...
2. ...
### F 列的：
1. ...
2. ...
## Risk Register
| ID | 原因 | S | P | D | RPN | Mitigation | Owner | 截止 |
|---|---|---|---|---|---|---|---|---|
| R1 | ... | 8 | 6 | 7 | 336 | ... | 用户 | 5-15 |
## 红线决策
- 不上线条件：RPN > 200 的项 mitigation 不到位
- 当前 ≥ 200 项：R1, R3, R7
- 当前 mitigation 状态：R1 done / R3 in progress / R7 owner 未定
- **结论**：暂不上线，等 R3 + R7 mitigation 完成
## Accept 类风险（不再 mitigation）
- R12: ... 接受理由：成本过高 / 概率过低 / 已有补偿机制
Anti-Rationalization
| 逃逸路径 | 为什么不行 |
|---|---|
| "感觉风险都列得差不多了" | 每人独立列 5 条最低线。少于 5 条 = 没认真挖。"差不多了"是乐观偏差信号 |
| "我们没踩过这种坑应该不会发生" | 没踩过 = 你的样本不全，不等于不会发生。pre-mortem 是借助"假设它发生了"绕过经验偏差 |
| "RPN 200 红线太严了，业务等不及" | 红线是默认值。要降低必须 decisions-log 留痕 + 用户 拍板 + 接受 R-X 后果 |
| "Mitigation 写'盯紧点'就行" | "盯紧点"不是 mitigation。必须有具体动作 + owner + 截止时间。"盯紧"= 没人负责 = 没人做 |
| "S/P/D 评分主观不准" | 主观不等于无用。三人独立评分取平均 → 差异 > 3 时讨论 → 收敛。比"凭感觉判断风险"准一个数量级 |
| "FMEA 太工业化不适合 SaaS" | FMEA 是质量工程通用方法，跨行业有效。SaaS 风险天然契合 S/P/D 三维 |
| "项目小不需要 pre-mortem" | 项目小 = 5 步走 30 分钟。不做的成本 = 上线踩坑后 5-10 倍返工成本。不存在"小到不用 pre-mortem"的方案 |
| "悲观假设打击士气" | Klein 原始研究：pre-mortem 反而提升团队信心，因为风险被显式管理而不是悬空。"打击士气"是回避真正问题的借口 |
与五维碰撞测试的关系
- 五维碰撞（collision-test）：从机制 / 协议设计角度做静态推演（计算时序 / 同类竞争 / 跨层 / 修饰叠加 / 人类认知）
- Pre-mortem：从场景失败角度做动态推演（用户 / 市场 / 技术 / 团队 / 流程 / 外部）
- 两者不替代：方案设计前过五维碰撞，方案上线前过 pre-mortem
关联
- 上线后真出事 →
root-cause5 Whys / Fishbone 找根因 - Risk Register 中的 mitigation 动作进 sprint →
product-management:sprint-planning - 高 RPN 项需要 A/B 验证 →
gtm-ops:growth-engine - 写 risk register 时套五维碰撞 →
collision-test
Status
v1.0 — 2026-05-08 product-thinking plugin v0.1.0 首发。