思维模型

五问法

一种有步骤的问题分析方法,通过反复追问“为什么”,从表面症状找到深层根本原因。

探索一下

车子发动不了时,你可以直接叫拖车。但修车师傅会接连问几个问题,找出真正的故障。用五问法时,第一个问题是什么?

给这些步骤排个顺序

弄清步骤的顺序,你就能看到每一步如何帮助你找到持久有效的解决办法。

理解概念

理解概念

五问法很简单:先确定一个问题,再反复问“为什么会这样?”,通常问五次左右,找出根本原因。你可以先把问题说清楚,比如“网站总是崩溃”,然后针对每个答案继续追问,直到找到真正能解决的原因。例如,一个软件团队可能发现,网站崩溃不是代码写得不好,而是服务器负载过高。这时需要考虑升级硬件,而不是继续排查代码。试试这样:找一个生活中反复出现的问题,连续问五次“为什么”,看看你会发现什么。

详细讲解

详细讲解

这个方法怎么用

先问第一个“为什么”,记下所有合理的答案;再针对每个答案继续追问,形成几条可能的原因分支。五次只是参考,不是硬性规定:有些问题问三次就够了,有些则要问七次。当继续追问已得不到有用信息时,你可以停下来,找出各条分支背后的系统性原因,再制定有针对性的行动。

关键原则

这个方法能否奏效,取决于三点:准确描述问题、诚实回答,以及坚持找到真正的根本原因。你可以探索多条分支,因为不同团队成员可能看到系统的不同部分。每次继续追问前,最好用数据核实答案,而不是只靠推测。

实际例子

一家医院的团队调查用药错误时发现,原因不是护士粗心,而是病人缺少腕带;继续追查,又发现打印机坏了,最后发现采购“非临床”设备的流程存在缺陷。一个总在截止日期前赶工的软件团队,可能发现问题源于产品团队给出的需求不清楚,于是开展需求说明写作培训。一位小企业主收到客户关于配送延迟的投诉后发现,根本原因不是司机开得慢,而是路线规划软件更新后取消了手动调整路线的选项。

什么时候适合用

五问法最适合因果关系清楚、相对直接的问题,也适合你能直接接触流程参与者,或问题在表面修补后仍反复出现的情况。对于多种原因相互作用的复杂系统,或需要专业技术分析的问题,它的效果较差。这一方法起源于丰田,由丰田佐吉提出,至今仍是精益方法的一部分。不过,专家建议搭配其他工具,才能更全面地分析问题。

研究依据

研究依据

五问法起源于丰田生产方式,并成为丰田科学地解决问题的重要方法 [1]。尽管医疗质量改进领域广泛采用这一方法,医疗改进研究所等机构也在推广它,研究人员仍严厉批评它把复杂问题过度简化 [2]。Card(2017)指出,受单一路径的限制,五问法通常只能找出全面因果树分析所揭示的潜在改进机会中不到 3% 的部分 [2]。

  • Serrat(2017):这一方法要奏效,需要三个关键条件:准确描述问题;根据观察而非推测诚实作答;坚持找到真正的根本原因,而不是停在表面症状 [1]。
  • Card(2017):受单一路径的限制,五问法通常只能找出全面因果树分析所揭示的潜在改进机会中不到 3% 的部分 [2]。
  • 医疗改进研究所:该机构承认,看到系统不同部分的人可能会给出不同答案;一个问题也可能有多个根本原因,而非只有一个 [3]。

适用局限

适用局限

将五问法用于复杂系统时,它有明显局限。不同团队分析同一个问题,往往会得出不同的根本原因,因为选择追问哪条路径、在哪里停下,都带有主观性。这种方法容易让人停在表面症状,而不再深挖;使用者也常凭一时推测作答,而没有实际观察或收集数据。只沿一条路径寻找单一“根本原因”,会忽略大多数事故和故障都有多个促成因素这一事实。此外,没有逻辑依据表明第五次追问得到的原因一定是最佳干预点。有时处理更直接的原因,比如增加一道安全检查,比改变更上游的系统更有效。对于复杂问题,专家建议使用更全面的工具,例如鱼骨图、因果因素树或基于系统理论的分析。

参考来源

参考来源

试一试

检验你的理解

一家咖啡店的老板发现,顾客抱怨早高峰时服务太慢。要正确使用五问法,首先必须做哪一步?

查看文章解释

答案: 明确具体问题

五问法总是从清楚说明问题开始。如果大家没有就要解决的问题达成一致,例如明确说出“早上 8 点到 9 点,等待时间超过 10 分钟”,而只是笼统地说“服务太慢”,后续追问就会失去焦点,团队成员也可能各自调查完全不同的问题。

你的团队用五问法调查配送延误,找到了两个不同的根本原因:一个软件漏洞,以及仓库员工培训不足。按照五问法,应如何看待这个结果?

查看文章解释

答案: 不同分支可能指向多个根本原因

虽然“五问法”这个名称容易让人想到单一路径,有效的做法仍鼓励你探索不同的答案分支。一个问题往往有多个起作用的根本原因。这个方法的局限在于容易只关注一条路径,因此全面分析时应考虑所有合理的分支,而不是随意选一条。

你的软件团队用五问法分析一次生产环境服务中断,追问得到的原因链是:服务器崩溃 → 内存泄漏 → 代码缺陷 → 开发赶工 → 需求不清楚。为什么把“代码缺陷”当作根本原因就停下来,可能还不够?

查看文章解释

答案: 需求不清楚等更上游的原因会让问题反复出现

修复眼前的代码缺陷可以防止这次服务中断再次发生,但没有解决需求不清楚导致开发赶工这一上游流程问题。有效的根本原因分析会考虑:改进需求流程等更上游的环节,是否能预防今后一整类问题;同时,代码补丁等直接修复措施也能处理眼前的症状。

继续探索

为眼前的选择,再找一个有用的想法。

Reframo 的全部已发布文章均可免费阅读。准备好后,随时继续探索。