职场工具箱之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 实战经验，或者你踩过的坑。

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