root-causelisted

# 根因分析（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（人）** | 用户行为 / 团队