根因分析（5 Whys + Fishbone + Pareto）

何时触发

• 已经发生的问题 / bug / incident / 数据异常
• "为什么 X" 类问题
• 重复出现的同类问题（"上次也踩过"）
• 用户流失 / 转化下降 / 留存崩盘
• 上线后事故复盘
• "这次修了，下次还会不会"

何时不触发

• 上线前的风险预测 → 用 pre-mortem
• 多个候选项排序 → 用 rice-prioritization
• 用户需求挖掘 → 用 jtbd-framework

默认起点：5 Whys（Toyota 经典）

最简单最有效。从症状开始连问 5 个 why，每个 why 的答案是下一个 why 的输入。

标准模板

症状：<具体观察到的问题>
↓ Why 1?
答案 1：<直接原因>
↓ Why 2?
答案 2：<更深一层>
↓ Why 3?
答案 3：<更深一层>
↓ Why 4?
答案 4：<更深一层>
↓ Why 5?
答案 5：<根因，通常是流程 / 文化 / 系统设计层>

经典案例（Toyota）

症状：机器停转
Why 1? 保险丝烧了
Why 2? 电流过载
Why 3? 轴承润滑不足
Why 4? 润滑泵工作不正常
Why 5? 润滑泵的轴磨损（根因 → 替换轴 + 增加维护流程）

如果只修到 Why 1（换保险丝），下次还会烧。修到 Why 5（替换轴 + 加流程），从根上解决。

5 Whys 红线

• 不允许在 Why 3 之前停：到 Why 3 大概率还在症状层
• 不允许全程指向同一个人："因为 X 没做好"5 次出现 = 你在找替罪羊不是找系统问题
• 不允许循环回路：Why 4 答案 = Why 1 答案 → 你在原地打转
• 每层 why 必须可证伪："因为大家不重视"不是答案，要继续问"什么导致大家不重视"

升级：Fishbone (Ishikawa) Diagram

5 Whys 假设单一因果链。当问题是多因素叠加时（症状有多个并行原因），用 Fishbone。

6M 分类（生产 / 工程标准）

                                    ┌─ Man (人)
                                    │
         Method (方法) ──┐         ┌─┘
                          ↓         ↓
症状 ←────────── 原因汇集 ─────────────
                          ↑         ↑
         Machine (机器) ─┘         └─ Material (材料)
                                    │
                                    └─ Environment (环境)
                                       Measurement (测量)

6M 在软件 / 产品场景的映射

每个类别下列至少 2 条可能原因 → 6 × 2 = 12 个起点 → 找出真正贡献度最高的 2-3 个。

收敛工具：Pareto 80/20

Fishbone 列出 12+ 原因后，80% 的影响通常来自 20% 的原因。

评估流程

1. 每条原因估算"贡献度百分比"（团队投票或数据估算）
2. 排序 → 累计百分比达到 80% 的项是关键少数
3. 优先 fix 关键少数，其余记录但不主动 fix

Pareto 红线

• 不允许把所有原因平均分配权重：12 条原因每条 8% = 没分析
• 关键少数通常 2-4 条：超过 6 条说明你没真正归因
• 数据估算 > 团队投票：能量化用量化（错误率 / 用户数 / 工时）

5 步标准流程

1. 症状陈述：写下"具体观察到什么"，不写解读。"用户流失" → 不行。"用户在 onboarding 第 3 步流失率从 20% 上升到 45%" → 行
2. 5 Whys 起步：从症状开始连问 5 个 why。卡在 Why 3 之前 = 没到根因
3. 多因素信号检测：5 Whys 答到 Why 3-4 时如果出现"原因有好几个"——切换到 Fishbone
4. Fishbone 6M 列原因：每个 M 类别至少 2 条
5. Pareto 收敛：排序 → 关键少数 → 优先 fix

模板（完整根因分析）

# <事故 / 问题> 根因分析

## 症状
- 具体观察：<可量化的描述>
- 时间范围：<开始 - 持续>
- 影响范围：<用户数 / 业务影响>

## 5 Whys（如单因素链）
- Why 1: ... → 答案
- Why 2: ... → 答案
- Why 3: ... → 答案
- Why 4: ... → 答案
- Why 5: ... → 根因

## Fishbone 6M（如多因素）

### Man
- 原因 A1 (贡献度 估 X%)
- 原因 A2 (贡献度 估 X%)

### Machine
- 原因 B1 ...
- 原因 B2 ...

### Method
...

### Material
...

### Measurement
...

### Environment
...

## Pareto 排序
| 原因 | 贡献度 | 累计 |
|---|---|---|
| C1 | 35% | 35% |
| C2 | 25% | 60% |
| C3 | 20% | 80% ← 关键少数线 |
| C4 | 8% | 88% |
| ... |

## 修复动作
- 关键少数 (top 3)：
  - C1 → <具体动作> / Owner / 截止
  - C2 → <具体动作> / Owner / 截止
  - C3 → <具体动作> / Owner / 截止
- 其余记录但不主动 fix（accept）

## 系统性预防（重要）
此根因导致下次 X 还会发生吗？如果会，加什么流程 / 监控 / 协议防止？

Anti-Rationalization

关联

• 找到根因后修复优先级排序：用 rice-prioritization
• 系统性预防方案要 review：用 pre-mortem
• 重大事故升级到全局复盘：写到 methodology/internal-retrospective-YYYY-MM-DD.md（参考 retrospective-hygiene 5 条偏差）
• 同根因第二次出现 → 触发 cross-domain-defense 第三层熔断

Status

v1.0 — 2026-05-08 product-thinking plugin v0.1.0 首发。