26 | 5W根因分析法:怎么找准问题源头才能治标又治本?

2021-01-29 李运华
大厂晋升指南
进入课程

讲述:安晓辉

时长12:04大小11.05M

你好,我是华仔。
上一讲我介绍了 PDCA 执行法,它把执行过程分为四个环节。其中在检查(Check)环节,最容易出现的问题就是,分析原因的时候,只看到表层的原因,而没有去深挖深层的根本原因
这就会导致我们给出的解决方案治标不治本,虽然短时间内做了应急处理,但是按下葫芦浮起瓢,相关的问题之后还会接连不断地冒出来。

5W 根因分析法

怎么解决呢?这就要靠 5W 根因分析法了。它又叫 5Why 分析法或者丰田五问法,最初是由丰田集团创始人丰田佐吉提出的,后来成为丰田汽车公司获得成功的重要方法。(老板提出来的,应用也是自然的 ^_^)
那么,5W 根因分析法到底是什么做的呢?根据丰田汽车公司前副社长大野耐一的描述,就是重复问五次“为什么”,问题的本质和解决办法就会变得显而易见。
大野耐一曾经举过这样一个例子:
问题 1:为什么机器停了?
答:因为机器超载,保险丝烧断了。
 
问题 2:为什么机器会超载?
答:因为轴承的润滑不足。
 
问题 3:为什么轴承会润滑不足?
答:因为润滑泵失灵了。
 
问题 4:为什么润滑泵会失灵?
答:因为它的轮轴耗损了。
 
问题 5:为什么润滑泵的轮轴会耗损?
答:因为杂质跑到里面去了。
如果到了问题 1 就停止追问,那么工人的措施就是更换保险丝,一段时间后保险丝肯定还会烧断。
如果到了问题 4 就停止追问,那么工人的措施就是更换轮轴,一段时间后轮轴又会很快坏了。
只有当追问到了问题 5,才能找出停机的根本原因,这时工人的措施就是给润滑泵加上防杂质的滤网,从而彻底解决问题。
现在,5W 根因分析法在其他很多企业已经得到了广泛应用,并且融入到了各种管理方法中,比如持续改善法(日本持续改善之父今井正明提出)、精益生产法(美国学者研究丰田后提出的管理哲学)和六西格玛法(摩托罗拉提出的管理策略,杰克·韦尔奇推广到通用公司)等。
虽然它起源于生产过程中问题分析,但是作为一种思维方式,可以应用到很多场景,比如业务分析、技术学习和管理改进等。
接下来,我就针对这三类应用场景分别举例说明,这些都是我亲身经历的例子。

业务分析

第一个场景是业务分析。
在某交易平台的业务规划目标讨论会上,我通过 3 个为什么,了解到了业务目标背后的深层考虑。
问题 1:为什么今年的业务目标是成交金额翻番?
答:因为只有成交金额翻番我们才能达到盈亏平衡点。
 
问题 2:为什么今年要求达到盈亏平衡点?
答:因为集团要求我们的业务能够自负盈亏。
 
问题 3:我们本质上还属于创新业务,为什么集团要求我们的业务能够自负盈亏?
答:因为疫情的影响,集团需要开源节流,减少非盈利业务的持续投入。
你可能觉得有些奇怪:怎么这个例子只问了 3 个为什么就结束了呢?
因为 5 个为什么只是一个形象的说法,实际操作中可以是 3 个,也可以是 7 个,关键在于通过追问找到根本原因。
虽然在这个例子中,我们还可以继续问下去,比如:“集团为什么要开源节流,创新业务难道不重要吗?”
但这样的问题,业务团队很难得到确切答案,因为集团的决策背景和讨论信息只有高层才知道,而且就算知道答案,也不会对业务规划目标的理解有更多的帮助。

技术学习

第二个场景是技术学习。
在某次 Netty 培训课上,我通过 5 个为什么,来验证大家是否真的深入理解了 Netty 网络高性能的核心原理。
问题 1:为什么 Netty 网络处理性能高?
答:因为 Netty 采用了 Reactor 模式
 
问题 2:为什么用了 Reactor 模式性能就高?
答:因为 Reactor 模式是基于 IO 多路复用的事件驱动模式。
 
问题 3:为什么 IO 多路复用性能高?
答:因为 IO 多路复用既不会像阻塞 IO 那样没有数据的时候挂起工作线程,也不需要像非阻塞 IO 那样轮询判断是否有数据。
 
问题 4:为什么 IO 多路复用既不需要挂起工作线程,也不需要轮询?
答:因为 IO 多路复用可以在一个监控线程里面监控很多的连接,没有 IO 操作的时候只要挂起监控线程;只要其中有连接可以进行 IO 操作的时候,操作系统就会唤起监控线程进行处理。
 
问题 5:那还是会挂起监控线程啊,为什么这样做就性能高呢?
答:首先,如果采取阻塞工作线程的方式,对于 Web 这样的系统,并发的连接可能几万十几万,如果每个连接开一个线程的话,系统性能支撑不了;而如果用线程池的话,因为线程被阻塞的时候是不能用来处理其他连接,会出现等待线程的问题。
其次,线上单个系统的工作线程数配置可以达到几百上千,这样数量的线程频繁切换会有性能问题,而单个监控线程切换的性能影响可以忽略不计。
第三,工作线程没有 IO 操作的时候可以做其他事情,能够大大提升系统的整体性能。
这种场景在晋升答辩的时候也会经常发生。评委在考察申请者能力的时候,很喜欢用“夺命连环问”,连续追问为什么。如果平时没有训练和积累,你很可能被问到哑口无言的地步。
对于方案选择相关的问题,你可以用第 24 讲介绍的 3C 方案设计法,让自己的思考更加全面,选择更加有理有据。
而对于技术深度相关的问题,你可以先按照第 19 讲介绍的链式学习法学习某项技术,然后再搭配 5W 根因分析法来训练自己,多问自己一些为什么,把深层逻辑吃透。
这样在晋升答辩的时候,你就能从容应对,不用再害怕评委针对技术深度展开“夺命连环问”了。

管理改进

在某次项目延迟问题的讨论会上,我通过 6 个为什么,把项目延迟的核心原因找了出来。
问题 1:为什么项目延迟了?
答:因为要等测试环境进行测试。
 
问题 2:为什么要等测试环境?
答:我们只有 2 套测试环境,2 套都已经用于另外两个项目了。
 
问题 3:为什么只有 2 套测试环境,不能搭建多套吗?
答:现在没有机器用来搭测试环境了,而且我们有将近 20 个子系统,搭建一套可用的测试环境耗时可能要一周。
 
问题 4:为什么会没有机器,直接申请机器不就可以了?
答:运维今年的预算用完了,不能购买新机器了。
 
问题 5:为什么一定要用新机器,测试环境对机器性能要求高吗?
答:测试环境对机器性能要求不高,基本能跑就行。
 
问题 6:那为什么不找运维申请过保机器(使用超过 3 年的机器,即使没坏也要换掉)用来搭建测试环境?
答:之前没想过这个方案。
所以解决方案很简单,直接找运维借几台过保的机器用来搭建测试环境。
不过这还只是短期的解决方案,实际上在问题 3 的回答中,我们还可以发现另外一个问题:搭建一套环境太耗时了。
于是测试开发部启动了一个基于 Docker 的快速搭建环境的项目,项目完成后,任何一个开发或者测试同学花 5 分钟就能生成一套全新可用的环境。

注意事项

通过这 3 个例子,我想你已经理解了 5W 根因分析法的使用技巧。在实际应用的时候,我们还需要注意以下 3 点:
1. 问题数量不是关键,找到根本原因才是关键
在介绍业务分析这个例子的时候,我已经提到,5W 或者说 5 个为什么只是一个形象的说法,3 个也可以,7 个也可以,关键在于找到根本原因。
所以一个最简单的提问方法就是:下一个问题是对上一个回答的进一步深入
虽然数量可多可少,但我建议不要少于 3 个,因为凭借 3 个以下的为什么,大概率找不出根本原因;但是也不要多于 7 个,因为如果问了 7 个以上的为什么还没找到根本原因,那就要审视一下问题本身是不是有问题了,比如关注的焦点偏移,前面问的是 A,后面变成了问 B 了。
2. 首先要明确问题本身
5W 根因分析法起源于生产过程,通常情况下问题都是比较明显的,比如机器停机了或者次品率升高了。但是,还有很多情况下问题本身其实是不明确的,每个人的理解可能都不太一样。
如果没有明确问题就开始问为什么,无论问题多么精彩都没有意义,甚至越精彩离题越远。
比如“成交量大幅下降”,这个问题就不明确,到底下降 10%、30% 还是 50% 才算“大幅”?是同比下降还是环比下降?是某一个子业务下降很多,还是所有子业务都在下降?
如果这些问题都不明确就开始进行根因分析,就很可能得出一大堆似是而非的原因和改进措施。
3. 避免变成大型“撕逼”现场
在连续追问“为什么”的时候,如果双方没有对这个方法充分达成认识,被问的人很可能觉得你在挑战和质疑他,讨论的现场就会变成大型“撕逼”现场,最后闹得不欢而散。
所以在一开始的时候,就要先解释清楚,待会儿将采用 5W 根因分析法来探讨根本原因,避免挑起情绪对立,引发“撕逼”。

小结

现在,我们回顾一下这一讲的重点内容。
5W 根因分析法就是通过追问 5 个为什么来分析问题的根本原因,从而得到彻底的解决方案。
5W 根因分析法起源于生产过程的问题原因分析,但也可以应用于业务分析、技术学习和管理改进等场景。
使用 5W 根因分析法时要注意:首先要明确问题本身;问题数量不是关键,找到根本原因才是关键;避免变成大型“撕逼”现场。

思考题

这就是今天的全部内容,留一道课后思考题给你吧。
你是否经历过让自己印象深刻的挫折?试试用 5W 根因分析法自我分析一下原因,也许这次得出的答案会超出你原有的认知。
欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。
unpreview
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
上一篇
25 | PDCA执行法:怎么推动落地才能“步步为赢”?
下一篇
27 | 5S问题处理法:怎么应对问题才能转危为机?
 写留言

精选留言(6)

  • 2021-01-29
    让我想起了,领导的灵魂拷问,一般是连续问3到5个问题,直到找到问题的本质。
    这个方法适合上下级,或者自我审查。平级之间还真有可能,成了撕逼现场。
    一定要对事不对人,否则真会不欢而散。
    展开

    作者回复: 是的,这个技能是管理者的基础技能,用来处理问题、挖掘根因、考察下属是比较好的

    8
  • 2021-01-29
    你好,华仔:

        1.明确问题需要量化,我认为这个确实是个坑。好比别人让你做一件事情,说的很模糊,问多了你又担心别人认为你不聪明,导致信息不对称 。所以对这种问题需要自己整理一个处理问题的框架 问题的分类及解决方案。

        2.问题的源头一般情况下都能看到,比如项目延期,需求完成进度等。这些都有一些指标或者结果,适用复盘或者总结。

        3.如何终止提问也学到了一点,你或者团队不能掌控的事情,就可以终止了。
       
        4.请教一个问题?当5w的原因偏离了实际,又应该怎么解决呢?比如拿项目延期来说,有可能原因是个人能力不行,那么下一个问题就是为什么个人能力不行,因为加班没时间学习。这个问题链就全然不同。

    展开

    作者回复: 第2点:恰恰相反,很多时候源头并不容易看出来,需要去挖。

    第4点:对于项目延期来说,问到个人能力不行已经够了;原因和你说的第3点收获是一样的,因为项目经理或者TL为了解决项目延期的问题,要做的要么就是加人,要么就是换人,不可能说培养这个能力不行的员工来避免项目延期,因为培养的时间和效果都是不确定的,对当前项目延期这个问题没有帮助。

    至于某个成员能力不行这个问题,可以使用5W继续深挖,但深挖的目的不是为了解决项目延期的问题,而是解决成员能力不行这个问题,可能是招聘有问题、也可能是培养有问题、也可能是工作态度有问题,不同原因的对应措施不同。

    3
  • 2021-01-29
    感觉面试也能用的着,可以针对一个技术点,一层一层的问,每一级都对应着一个技术深度

    作者回复: 完全可以,面试的时候考察技术深度和思考深度就是用这个方法。

    3
  • 2021-01-29
    想到今年刚做的一个项目,没有按计划时间发布,
    1.为什么没有按计划完成发布?
    因为时间计划安排太紧,产品一直没达到老板要求,一再修改调整导致延期。
    2.为什么时间计划安排不准确?
    这是个技术产品,需求由团队内部提出,做成什么样也是内部决定,项目开始时没有明确好产品需求范围,没有明确好产品要做成什么样,自己做为负责人,把产品想简单了,很多隐形需求没评估到,所以时间没估准。
    3.为什么把产品想简单了?
    因为没有做好产品方案的调研,对于产品做成什么样没想清楚。另外老板心里其实有产品的样子,但是没领会他的想法。
    展开

    作者回复: 非常赞的案例👍

    到了第3个问题后还可以继续问下去:为什么没有领会老板的想法?老板的想法为什么没有明确的表达出来?

    1
    2
  • 2021-01-30
    两个问题
    1.用5w在分析线上bug时,如果发现是其他部门基础支撑平台提供的下载服务有问题,是不是就算找到核心问题了?
    2.学习技术时,用5w确实可以深入理解某一项技术,但是理解到什么程度就可以终止?这个技术深度的度怎么去把握?
    展开

    作者回复: 1. 可以再多问1个w,但不需要继续深入了,这样做的目的是当其它人问起来的时候,如果你完全不知道基础平台的情况,可能会给人一种事不关己的感觉。
    2. 参考19讲的链式学习法,一般来说领域深度3~5层差不多了,这一讲的netty就是5层,其实你直接按照5W来问,只要是逐步深入的,5个问题基本就够了。

    1
  • 2021-02-15
    用5w根因法,很担心会被认为一直质问别人。
    展开

    作者回复: 是有这个风险,所以说话要委婉一些,例如把“为什么”三个字前面加上“我想了解一下”。

×
拖拽到此处
图片将完成下载