0009 · 根因分析
· · ·
真正的原因在哪一层——不要把症状当原因
题目进度 0 / 0 ✓ 0
0009 · 根因分析
预计时间：20 分钟读完 + 25 分钟做练习 = 45 分钟。
本课核心论点 根因分析是区分症状（表面现象）和根因（最深层的本质原因）的能力。解决症状只能暂时缓解，解决根因才能真正防止问题再次发生。这是 PM/BA 做决策时最容易被忽视的维度。
一、什么是根因？
症状 vs 根因：
症状：你能直接观察到的现象
→ “Bug 报告突然增加”
→ “用户投诉变多”
→ “上线后流量下降”
根因：导致症状出现的最深层的原因
→ “新上线的功能有内存泄漏导致服务不稳定”
→ “最近一次 UI 改动让用户找不到搜索入口”
→ “竞品做了我们还没做的新功能”
关键原则：症状 = 你看到的结果；根因 = 导致结果的最深层原因
→ 只处理症状 = 临时止痛
→ 处理根因 = 彻底解决
症状：你能直接观察到的现象
→ “Bug 报告突然增加”
→ “用户投诉变多”
→ “上线后流量下降”
根因：导致症状出现的最深层的原因
→ “新上线的功能有内存泄漏导致服务不稳定”
→ “最近一次 UI 改动让用户找不到搜索入口”
→ “竞品做了我们还没做的新功能”
关键原则：症状 = 你看到的结果；根因 = 导致结果的最深层原因
→ 只处理症状 = 临时止痛
→ 处理根因 = 彻底解决
二、5 Whys 根因分析法
连续问 5 次”为什么”，直到找到根因：
例子：
Q1: “为什么用户投诉增加？”
→ “因为加载速度变慢了”
Q2: “为什么加载速度变慢了？”
→ “因为最近上了新图片库”
Q3: “为什么新图片库导致加载变慢？”
→ “因为图片没有做压缩优化”
Q4: “为什么图片没做压缩？”
→ “因为发布流程里没有自动压缩的步骤”
Q5: “为什么发布流程没有压缩步骤？”
→ “因为当初搭建流程时没有考虑图片优化”
根因：流程搭建时缺少图片优化的设计思考
→ 解决方案：不是”压缩图片”（这是处理症状），而是”建立发布流程时加入自动压缩环节”（处理根因）
Q1: “为什么用户投诉增加？”
→ “因为加载速度变慢了”
Q2: “为什么加载速度变慢了？”
→ “因为最近上了新图片库”
Q3: “为什么新图片库导致加载变慢？”
→ “因为图片没有做压缩优化”
Q4: “为什么图片没做压缩？”
→ “因为发布流程里没有自动压缩的步骤”
Q5: “为什么发布流程没有压缩步骤？”
→ “因为当初搭建流程时没有考虑图片优化”
根因：流程搭建时缺少图片优化的设计思考
→ 解决方案：不是”压缩图片”（这是处理症状），而是”建立发布流程时加入自动压缩环节”（处理根因）
三、根因分析的三个层次
| 层次 | 问题 | 方法 |
|---|---|---|
| 第一层：表面 | ”发生了什么？“ | 描述症状——数据、日志、用户反馈 |
| 第二层：过程 | ”流程哪里出了问题？“ | 5 Whys、流程图分析——找到流程中具体的薄弱点 |
| 第三层：系统 | ”为什么系统允许这个问题发生？“ | 系统思考——制度、工具、文化层面的根本原因 |
四、PM/BA 日常中的根因分析
场景 1：用户满意度下降
- 症状：NPS 分数下降
- 5 Whys → 根因可能是”新上线的功能太复杂，用户学习成本高”
- 只处理症状：鼓励用户用 NPS 调查 → 短期数据好看，但不解决根本问题
场景 2：项目延期
- 症状：里程碑延期了两周
- 5 Whys → 根因可能是”需求变更没有经过正式的变更控制流程”
- 只处理症状：要求团队加班赶进度 → 下个里程碑依然延期
场景 3：竞品市场份额增长
- 症状：市场份额下降 5%
- 5 Whys → 根因可能是”我们对用户需求的理解有偏差，没有捕捉到用户真正想要的”
- 只处理症状：加大广告投放 → 花钱但不增长根本竞争力
五、常见错误
- 把相关性当因果：“我们的营销支出增加了 30%，同时收入增长了 20%，所以是营销带来的增长”——可能只是市场趋势
- 停止搜索过早：“找到原因了！”→ 但只是第一层表面的原因
- 混淆谁与什么：不是”谁的责任”，而是”什么导致了这个问题”
- 忽视系统因素：一个人的错误可能只是因为系统的缺陷让他容易犯错（瑞士奶酪模型）
对 PM/BA 的具体启示
- 每次事故/问题发生后，先用 5 Whys 找到根因再行动
- 根因通常不在”人”的层面，而在”流程/系统”层面
- 每次写方案文档后，自查”这个方案解决的是症状还是根因？”
- 产品复盘时，问”真正的根因是什么？不是表面原因”
六、练习题（10 题）
1
"Bug 报告突然增加"这是什么？
2
以下哪项最可能是"根因"而非"症状"？
3
5 Whys 分析中，最常见的错误是？
4
"用户满意度下降"是症状，根因分析应该找什么？
5
"项目延期两周"——如果是"需求变更没有经过正式的变更控制流程"导致的，这是第几层？
6
只处理症状的后果是什么？
7
在根因分析中，关于"责任"的正确态度是？
8
以下关于根因的描述哪个正确？
9
"市场趋势不好所以我们收入下降"——这是一个根因吗？
10
根因分析对 PM/BA 最重要的价值是什么？
读代码题
R1
R1. 分析以下场景的根因：
"我们产品上线后 3 个月，用户活跃度持续下降。"
用 5 Whys 分析：
1. 为什么活跃度下降？因为用户使用频率降低
2. 为什么使用频率降低？因为用户找不到新的使用场景
3. 为什么找不到新场景？因为功能设计过于单一
4. 为什么设计单一？因为需求阶段没有充分调研不同用户群体的使用偏好
5. 为什么没有充分调研？因为产品团队一直在"快速迭代"而没有停下来做深度调研
根因是什么？
R2
R2. 场景：一个 PM 说"用户留存率低是因为我们做得不够好"。用根因分析的思想帮他重新审视。
你的回应：
六、答题提示
展开提示
- Q1 — Bug 报告增加是症状
- Q2 — 流程缺少环节才是根因
- Q3 — 问到第一层就停止是常见错误
- Q4 — 根因在流程/产品层面
- Q5 — 需求变更流程问题是第二层（流程）
- Q6 — 只处理症状问题会反复出现
- Q7 — 关注是什么而非谁
- Q8 — 根因是最深层的原因
- Q9 — 市场趋势不一定是根因
- Q10 — 解决根因而非处理症状
七、本课行动清单
- 每次项目问题发生后，先写 5 个 Whys 找根因再行动
- 每次写方案文档时，自查：“这个方案是解决症状还是根因？”
- 建立团队复盘习惯——用 5 Whys 分析每个重要决策的结果
- 把”症状”和”根因”变成日常用语——“这是在处理症状，不是根因”
八、参考来源
- ③ 学术经典：Toyota Production System — 5 Whys 作为丰田生产系统的核心问题解决工具。
- ③ 学术：W. Edwards Deming, Out of the Crisis — 区分症状和根因的质量管理理念。
- ④ 芒格文集：Poor Charlie’s Almanack — “不要把表面现象当原因”。
下一步：看 Lesson 0010 · 简化启发式