pre-mortem — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited pre-mortem (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
root-causedecision-matrixGary Klein 1989 经典方法——把 post-mortem 提前。
不要问:"这个方案会有什么风险?"(人会下意识防守)
要问:"假设 6 个月后这个方案彻底失败了。现在写一份 autopsy——失败的原因都有哪些?"(视角切换 → 大脑进入归因模式 → 风险被主动挖出)
#### 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 |
| ... |红线:
#### Step 5:Mitigation 类型(按降序选)
# <方案名> 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: ... 接受理由:成本过高 / 概率过低 / 已有补偿机制| 逃逸路径 | 为什么不行 |
|---|---|
| "感觉风险都列得差不多了" | 每人独立列 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 反而提升团队信心,因为风险被显式管理而不是悬空。"打击士气"是回避真正问题的借口 |
root-cause 5 Whys / Fishbone 找根因product-management:sprint-planninggtm-ops:growth-enginecollision-testv1.0 — 2026-05-08 product-thinking plugin v0.1.0 首发。
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.