短大纲（给忙人）

职场工具箱之5个Why：别再"查查看"了，学会追问才能找到真相

"再查查"是职场最大的时间黑洞

你有没有经历过这样的场景？

线上出了问题，老板问："什么原因？"

你说："我再查查。"

一小时后，老板又问："查到了吗？"

你说："有点眉目了，我再深入看看。"

又过了两小时，老板第三次问。你说："情况比较复杂，我再理一理。"

"再查查"——这三个字，可能是职场最大的时间黑洞。

问题不在于你不努力。问题在于你没有方向地"查"，就像在大海里捞针——看起来很忙，但其实在原地打转。

今天要聊的这个方法，简单到你可能会觉得"就这？"——5 Why，连续问五个"为什么"。

但别小看它。这个方法帮丰田从一个小作坊变成全球最大的汽车制造商；它是亚马逊事故复盘的标准流程；它也是我在 20 多年职业生涯中用得最多的根因分析工具。

读完这篇文章，你会获得： - 一套可以立即上手的追问框架 - 三个不同场景的实战演示 - 一份避坑指南，帮你绕过 5 Why 最常见的误区

5 Why 是什么？一个简单到令人发指的方法

来自丰田的"追问神器"

5 Why 最早由丰田汽车创始人丰田佐吉发明，后来被丰田生产系统（TPS）发扬光大。

核心思想极其简单：当一个问题出现时，不要停留在表面症状，而是连续追问"为什么"，直到找到真正的根因。

为什么是 5 次？

丰田发现，大多数问题追问 5 次左右就能触及根因。当然，实际操作中可能是 3 次，也可能是 7 次——重点不是数字，而是追问的态度。

一个经典案例：杰斐逊纪念堂的墙

这是一个被讲烂了但依然经典的案例：

问题：杰斐逊纪念堂的墙面比其他建筑腐蚀得更快。

• Why 1：为什么墙面腐蚀快？→ 因为清洁工用了腐蚀性清洁剂。
• Why 2：为什么要用腐蚀性清洁剂？→ 因为墙上有太多鸟粪。
• Why 3：为什么鸟粪这么多？→ 因为这里有很多蜘蛛，鸟来吃蜘蛛。
• Why 4：为什么蜘蛛多？→ 因为这里有很多小飞虫，蜘蛛来吃虫子。
• Why 5：为什么飞虫多？→ 因为纪念堂的灯在黄昏时最先开，吸引了大量趋光昆虫。

根因：灯开得太早。 解决方案：延迟开灯时间。

如果停在 Why 1，你会得到一个"症状级"的解决方案：换一种清洁剂。

但如果追问到 Why 5，你会得到一个"根因级"的解决方案：调整开灯时间——成本更低、效果更持久。

这就是 5 Why 的威力：它帮你从"治标"走向"治本"。

苏格拉底式追问：从"是什么"到"为什么"

大多数人卡在"是什么"

当问题出现时，大多数人的本能反应是：

• 这是什么问题？（定义症状）
• 有什么解决方案？（跳到行动）

这种"是什么→怎么办"的思路有一个致命缺陷：你可能在解决错误的问题。

就像头痛吃止痛药——药到病除，但如果头痛的根因是颈椎问题，你吃再多止痛药也没用。

苏格拉底的追问法

2400 年前，苏格拉底就发现了这个问题。他发明了一种叫"苏格拉底式追问"（Socratic Questioning）的方法，核心就是不断追问"为什么"。

苏格拉底认为：真正的智慧不是知道答案，而是知道如何提问。

5 Why 可以看作是苏格拉底式追问在工程领域的实践版：

追问的心法：保持"新手心态"

追问最难的不是技巧，而是心态。

很多人问到第 2 个 Why 就停了，因为觉得"差不多知道了"。这就像挖井挖到一半就停下——你看到了湿润的土，但还没挖到水。

好的追问者要像侦探一样，保持"新手心态"：

• 不预设答案
• 对"常识"保持怀疑
• 不怕显得"无知"

丰田有一句名言："问五次为什么，你就能找到真相；问三次为什么，你只会找到借口。"

实战案例：三个场景演示

场景 1：线上接口超时（技术问题）

症状：用户反馈搜索功能经常超时。

Why 1: 为什么接口超时？
       → 因为数据库查询耗时太长（3秒+）。

Why 2: 为什么数据库查询慢？
       → 因为有一个查询没有走索引，全表扫描。

Why 3: 为什么没有走索引？
       → 因为新加的过滤字段没有建索引。

Why 4: 为什么没有建索引？
       → 因为上线前没有做慢查询检查。

Why 5: 为什么没有做慢查询检查？
       → 因为发布流程没有这个环节。

根因：发布流程缺少慢查询检查环节。

对策： - 止血：加索引（5分钟） - 治本：发布流程增加"数据库变更 checklist" - 防复发：CI 流水线加入慢查询自动检测

场景 2：项目延期（管理问题）

症状：Sprint 5 延期了一周。

Why 1: 为什么 Sprint 延期？
       → 因为 3 个用户故事没有按时完成。

Why 2: 为什么这 3 个故事没完成？
       → 因为实际工作量比估算的多了 2 倍。

Why 3: 为什么估算差这么多？
       → 因为估算时没有拆解到足够细的粒度。

Why 4: 为什么没有拆细？
       → 因为需求评审时产品和开发对"完成标准"理解不一致。

Why 5: 为什么理解不一致？
       → 因为需求文档没有明确的"验收标准"和"不做什么"。

根因：需求文档模板缺少"验收标准"和"不做什么"字段。

对策： - 止血：补齐剩余故事的验收标准，重新估算 - 治本：更新需求模板，增加必填字段 - 防复发：Sprint Planning 增加"验收标准对齐"环节

场景 3：客户投诉（业务问题）

症状：本月客户投诉"跟进不及时"增加了 50%。

Why 1: 为什么投诉增加？
       → 因为很多客户咨询后超过 48 小时才收到回复。

Why 2: 为什么回复这么慢？
       → 因为销售同时跟进 80+ 个客户，顾不过来。

Why 3: 为什么一个销售要跟这么多客户？
       → 因为最近市场活动带来大量线索，但销售人数没有增加。

Why 4: 为什么不增加销售？
       → 因为招聘周期要 2 个月，短期没法补人。

Why 5: 为什么不能用其他方式分流？
       → 因为没有客户分级机制，所有客户同等优先级。

根因：缺少客户分级和优先级机制。

对策： - 止血：按成交概率给现有客户分级，高优先级客户 24 小时内响应 - 治本：建立客户分级 SOP，CRM 系统增加优先级标签 - 防复发：设置 SLA 告警，超时自动升级

避坑指南：5 Why 最容易翻车的 5 个地方

坑 1：把人当根因

错误示范：

Why 5: 为什么没有做代码审查？
       → 因为小王太粗心了。

问题：把人当根因，等于把问题归结为"运气不好，摊上一个粗心的人"。这不仅不解决问题，还会让团队氛围变差。

正确姿势：根因要落在流程、机制、工具上，而不是人身上。

Why 5: 为什么没有做代码审查？
       → 因为发布流程没有强制要求 Code Review。

坑 2：问得太发散

错误示范：

Why 3: 为什么数据库慢？
       → 因为服务器配置低 / 数据量太大 / 查询没优化 / 网络延迟...

问题：同时追问多个分支，最后哪个都没追到底。

正确姿势：一次追一条线。如果有多个可能原因，先用数据或排除法确定最可能的一个，然后顺着它深挖。

坑 3：问得太浅就停

错误示范：

Why 1: 为什么线上出 bug？→ 因为代码有问题。
Why 2: 为什么代码有问题？→ 因为测试没覆盖到。
（停了）

问题：问到"测试没覆盖"就停，得出的对策是"加测试"。但这只是表面原因，真正的问题可能是"没有测试用例设计规范"或"测试资源不足"。

正确姿势：至少追问到"流程/机制"层面。如果你的答案还是"某个事情没做"，继续问"为什么没做"。

坑 4：变成甩锅大会

错误示范：

Why 3: 为什么需求变更？→ 因为产品没想清楚。
Why 4: 为什么产品没想清楚？→ 因为产品经理不专业。

问题：追问变成指责，团队开始互相甩锅，根因分析变成"批斗会"。

正确姿势：对事不对人。可以引入第三方主持，或者用"系统视角"重新表述问题：

Why 3: 为什么需求变更？→ 因为前期需求调研不够充分。
Why 4: 为什么调研不充分？→ 因为项目时间紧，跳过了用户访谈环节。

坑 5：问完就完，没有闭环

错误示范：

（问了 5 个 Why，找到根因）
"好的，我们下次注意。"
（然后就没有然后了）

问题：找到根因却不落实对策，下次还会再犯。

正确姿势：每次 5 Why 都要产出至少一个可行动的改进项，并且有 owner、deadline、验收标准。

5 Why 实战检查清单

在开始追问之前，用这个清单确保你走在正确的路上：

准备阶段

• [ ] 我已经用"一句话"定义了问题（现象 + 影响 + 范围）
• [ ] 我有基本的数据/证据支持（不是纯靠猜）
• [ ] 参与追问的人包括"知情者"（了解细节的人）

追问阶段

• [ ] 每个 Why 都基于上一个 Why 的答案（逻辑链不断）
• [ ] 我没有把"人"当作根因
• [ ] 我没有同时追问多个分支（一次一条线）
• [ ] 我追问到了"流程/机制/工具"层面

闭环阶段

• [ ] 我产出了至少一个可行动的改进项
• [ ] 改进项有 owner、deadline、验收标准
• [ ] 我把这次追问过程记录下来了（方便复盘和分享）

思维导图

@startmindmap
<style>
mindmapDiagram {
  .root { BackgroundColor #2C3E50; FontColor white; FontSize 16 }
  .what { BackgroundColor #3498DB; FontColor white }
  .how { BackgroundColor #27AE60; FontColor white }
  .example { BackgroundColor #9B59B6; FontColor white }
  .pitfall { BackgroundColor #E74C3C; FontColor white }
  .action { BackgroundColor #F39C12; FontColor white }
}
</style>

*[#2C3E50] 5 Whys\n追问到根因 <<root>>

left side
**[#3498DB] 是什么 <<what>>
*** 丰田生产系统的追问法
***_ 连续追问"为什么"
***_ 从症状穿透到根因
*** 苏格拉底式追问
***_ 真正的智慧是提问
***_ 保持新手心态

**[#27AE60] 怎么问 <<how>>
*** 准备阶段
****_ 一句话定义问题
****_ 准备数据/证据
****_ 找到知情者
*** 追问阶段
****_ 逻辑链不断
****_ 一次一条线
****_ 追到流程/机制层
*** 闭环阶段
****_ 产出改进项
****_ 明确 owner/deadline
****_ 记录存档

right side
**[#9B59B6] 场景案例 <<example>>
*** 技术问题
****_ 接口超时 → 发布流程缺检查
*** 管理问题
****_ 项目延期 → 需求模板缺字段
*** 业务问题
****_ 客户投诉 → 缺客户分级机制

**[#E74C3C] 常见坑 <<pitfall>>
*** 把人当根因
*** 问得太发散
*** 问得太浅就停
*** 变成甩锅大会
*** 问完没闭环

**[#F39C12] 核心心法 <<action>>
***_ 对事不对人
***_ 根因落在流程/机制/工具
***_ 每次产出可行动改进项
@endmindmap

小结

5 Why 解决了什么问题？

大多数人遇到问题时，要么在症状里打转（"再查查"），要么直接跳到解决方案（"加个补丁"）。5 Why 帮你穿透表面，找到真正值得解决的根因。

核心心法：

1. 对事不对人：根因落在流程/机制/工具，不是"某人不行"
2. 一次一条线：不要同时追问多个分支
3. 追到底：至少追到"流程/机制"层面才停
4. 必须闭环：每次产出至少一个可行动的改进项

一句话总结：

问 3 次 Why，你找到的是借口；问 5 次 Why，你找到的是真相。

延伸阅读

• The 5 Whys - Atlassian — 5 Why 的入门介绍
• Toyota Production System — 丰田生产系统官方介绍
• Root Cause Analysis - Wikipedia — 根因分析方法综述
• 苏格拉底式追问法 — 追问法的哲学源头

互动时间

你最近一次"再查查"查了多久？如果用 5 Why 重来一遍，你觉得能快多少？

欢迎在评论区分享你的 5 Why 实战经验，或者你踩过的坑。

系列回顾

1. 4D 总结法
2. 黄金圈法则
3. TNB 表达模型
4. FAB 提案法
5. STAR 面试法
6. 同理心三方法
7. 5W1H + 8C1D
8. 艾森豪威尔矩阵
9. PDCA 循环
10. SMART 原则
11. 领导力
12. 逻辑树
13. 解决问题五步法
14. 5 个 Why（本篇）
15. 沟通四要素 CARE
16. 金字塔原理
17. 三点法
18. DACI
19. 四线复盘法
20. RAPID
21. 5S 问题处理法
22. SWOT 自我定位
23. AARRR 漏斗
24. 第一性原理
25. RACI
26. 非暴力沟通
27. SCAMPER
28. MVP 思维
29. ABC 情绪理论
30. AI Agent 学职场英语
31. 向上管理
32. OODA 循环

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。