0009 · 根因分析
真正的原因在哪一层——不要把症状当原因
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 · 简化启发式