思维模型
五问法
一种有步骤的问题分析方法,通过反复追问“为什么”,从表面症状找到深层根本原因。
探索一下
车子发动不了时,你可以直接叫拖车。但修车师傅会接连问几个问题,找出真正的故障。用五问法时,第一个问题是什么?
给这些步骤排个顺序
弄清步骤的顺序,你就能看到每一步如何帮助你找到持久有效的解决办法。
理解概念
理解概念
五问法很简单:先确定一个问题,再反复问“为什么会这样?”,通常问五次左右,找出根本原因。你可以先把问题说清楚,比如“网站总是崩溃”,然后针对每个答案继续追问,直到找到真正能解决的原因。例如,一个软件团队可能发现,网站崩溃不是代码写得不好,而是服务器负载过高。这时需要考虑升级硬件,而不是继续排查代码。试试这样:找一个生活中反复出现的问题,连续问五次“为什么”,看看你会发现什么。
详细讲解
详细讲解
这个方法怎么用
先问第一个“为什么”,记下所有合理的答案;再针对每个答案继续追问,形成几条可能的原因分支。五次只是参考,不是硬性规定:有些问题问三次就够了,有些则要问七次。当继续追问已得不到有用信息时,你可以停下来,找出各条分支背后的系统性原因,再制定有针对性的行动。
关键原则
这个方法能否奏效,取决于三点:准确描述问题、诚实回答,以及坚持找到真正的根本原因。你可以探索多条分支,因为不同团队成员可能看到系统的不同部分。每次继续追问前,最好用数据核实答案,而不是只靠推测。
实际例子
一家医院的团队调查用药错误时发现,原因不是护士粗心,而是病人缺少腕带;继续追查,又发现打印机坏了,最后发现采购“非临床”设备的流程存在缺陷。一个总在截止日期前赶工的软件团队,可能发现问题源于产品团队给出的需求不清楚,于是开展需求说明写作培训。一位小企业主收到客户关于配送延迟的投诉后发现,根本原因不是司机开得慢,而是路线规划软件更新后取消了手动调整路线的选项。
什么时候适合用
五问法最适合因果关系清楚、相对直接的问题,也适合你能直接接触流程参与者,或问题在表面修补后仍反复出现的情况。对于多种原因相互作用的复杂系统,或需要专业技术分析的问题,它的效果较差。这一方法起源于丰田,由丰田佐吉提出,至今仍是精益方法的一部分。不过,专家建议搭配其他工具,才能更全面地分析问题。
研究依据
研究依据
适用局限
适用局限
将五问法用于复杂系统时,它有明显局限。不同团队分析同一个问题,往往会得出不同的根本原因,因为选择追问哪条路径、在哪里停下,都带有主观性。这种方法容易让人停在表面症状,而不再深挖;使用者也常凭一时推测作答,而没有实际观察或收集数据。只沿一条路径寻找单一“根本原因”,会忽略大多数事故和故障都有多个促成因素这一事实。此外,没有逻辑依据表明第五次追问得到的原因一定是最佳干预点。有时处理更直接的原因,比如增加一道安全检查,比改变更上游的系统更有效。对于复杂问题,专家建议使用更全面的工具,例如鱼骨图、因果因素树或基于系统理论的分析。
参考来源
参考来源
- [1] 五问法Olivier Serrat - 2017
- [2] “五问法”的问题Alan J. Card - 2017
- [3] 五问法:寻找根本原因Institute for Healthcare Improvement
试一试
检验你的理解
一家咖啡店的老板发现,顾客抱怨早高峰时服务太慢。要正确使用五问法,首先必须做哪一步?
查看文章解释
答案: 明确具体问题
五问法总是从清楚说明问题开始。如果大家没有就要解决的问题达成一致,例如明确说出“早上 8 点到 9 点,等待时间超过 10 分钟”,而只是笼统地说“服务太慢”,后续追问就会失去焦点,团队成员也可能各自调查完全不同的问题。
你的团队用五问法调查配送延误,找到了两个不同的根本原因:一个软件漏洞,以及仓库员工培训不足。按照五问法,应如何看待这个结果?
查看文章解释
答案: 不同分支可能指向多个根本原因
虽然“五问法”这个名称容易让人想到单一路径,有效的做法仍鼓励你探索不同的答案分支。一个问题往往有多个起作用的根本原因。这个方法的局限在于容易只关注一条路径,因此全面分析时应考虑所有合理的分支,而不是随意选一条。
你的软件团队用五问法分析一次生产环境服务中断,追问得到的原因链是:服务器崩溃 → 内存泄漏 → 代码缺陷 → 开发赶工 → 需求不清楚。为什么把“代码缺陷”当作根本原因就停下来,可能还不够?
查看文章解释
答案: 需求不清楚等更上游的原因会让问题反复出现
修复眼前的代码缺陷可以防止这次服务中断再次发生,但没有解决需求不清楚导致开发赶工这一上游流程问题。有效的根本原因分析会考虑:改进需求流程等更上游的环节,是否能预防今后一整类问题;同时,代码补丁等直接修复措施也能处理眼前的症状。
继续探索
为眼前的选择,再找一个有用的想法。
Reframo 的全部已发布文章均可免费阅读。准备好后,随时继续探索。