marsloting 根因分析（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 在软件 / 产品场景的映射
| 类别 | 软件 / 产品场景含义 |
|---|---|
| Man（人） | 用户行为 / 团队技能 / 沟通 / 培训缺失 |
| Machine（机器） | 基础设施 / 服务器 / 第三方依赖 / 工具链 |
| Method（方法） | 流程 / SOP / 协议 / 评审机制 |
| Material（材料） | 数据 / 文档 / 内容 / 素材 |
| Measurement（测量） | 监控 / 日志 / 指标定义 / 告警阈值 |
| Environment（环境） | 部署环境 / 时间窗口 / 业务背景 / 合规约束 |
每个类别下列至少 2 条可能原因 → 6 × 2 = 12 个起点 → 找出真正贡献度最高的 2-3 个。
收敛工具：Pareto 80/20
Fishbone 列出 12+ 原因后，80% 的影响通常来自 20% 的原因。
评估流程
- 每条原因估算"贡献度百分比"（团队投票或数据估算）
- 排序 → 累计百分比达到 80% 的项是关键少数
- 优先 fix 关键少数，其余记录但不主动 fix
Pareto 红线
- 不允许把所有原因平均分配权重：12 条原因每条 8% = 没分析
- 关键少数通常 2-4 条：超过 6 条说明你没真正归因
- 数据估算 > 团队投票：能量化用量化（错误率 / 用户数 / 工时）
5 步标准流程
- 症状陈述：写下"具体观察到什么"，不写解读。"用户流失" → 不行。"用户在 onboarding 第 3 步流失率从 20% 上升到 45%" → 行
- 5 Whys 起步：从症状开始连问 5 个 why。卡在 Why 3 之前 = 没到根因
- 多因素信号检测：5 Whys 答到 Why 3-4 时如果出现"原因有好几个"——切换到 Fishbone
- Fishbone 6M 列原因：每个 M 类别至少 2 条
- 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
| 逃逸路径 | 为什么不行 |
|---|---|
| "Why 2 已经找到原因了" | Why 2 几乎都是症状层。强制问到 Why 5，到流程 / 系统 / 文化层才是根因 |
| "因为 X 没做好" 重复 5 次 | 你在找人背锅不是找系统问题。换问题：是什么让 X 没做好的环境 / 流程 / 工具？ |
| "5 Whys 太呆板" | 呆板是 feature 不是 bug。强制深挖防止思维断在第一层 |
| "Fishbone 太正式不适合 startup" | 6M 是分类工具不是仪式。startup 团队 30 分钟跑完 Fishbone 比"凭感觉找原因"准 5 倍 |
| "Pareto 估贡献度不准" | 不准也比不估好。team 三人独立估 → 取中位数 → 偏差 ±10% 内已经足够指导决策 |
| "只修关键少数其他不管" | Pareto 是 80/20 不是 100/0。关键少数优先 fix，其他记录 + 监控，发现升级时再处理 |
| "找到根因就行了不用管系统预防" | 只 fix 实例 = 同根因第二次还会发生 = 重复劳动。系统性预防（加流程 / 加监控 / 加协议）是根因分析的必要产出，不是 nice-to-have |
| "incident postmortem 模板我们公司有" | 公司模板 ≠ 5 Whys。多数公司 postmortem 停在 Why 2-3 层（"修了 bug 加了监控"）。本 skill 强制 Why 5 + 系统预防 |
关联
- 找到根因后修复优先级排序：用
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 首发。