编程进阶网编程进阶网
  • 基础组成体系
  • 程序编程原理
  • 异常和IO系统
  • 六大设计原则
  • 设计模式导读
  • 创建型设计模式
  • 结构型设计模式
  • 行为型设计模式
  • 设计模式案例
  • 面向对象思想
  • 基础入门
  • 高级进阶
  • JVM虚拟机
  • 数据集合
  • Java面试题
  • C语言入门
  • C综合案例
  • C标准库
  • C语言专栏
  • C++入门
  • C++综合案例
  • C++专栏
  • HTML
  • CSS
  • JavaScript
  • 前端专栏
  • Swift
  • iOS入门
  • 基础入门
  • 开源库解读
  • 性能优化
  • Framework
  • 方案设计
  • 媒体音视频
  • 硬件开发
  • Groovy
  • 常用工具
  • 大厂面试题
  • 综合案例
  • 网络底层
  • Https
  • 网络请求
  • 故障排查
  • 专栏
  • 数组
  • 链表
  • 栈
  • 队列
  • 树
  • 递归
  • 哈希
  • 排序
  • 查找
  • 字符串
  • 其他
  • Bash脚本
  • Linux入门
  • 嵌入式开发
  • 代码规范
  • Markdown
  • 开发理论
  • 开发工具
  • Git管理
  • 百宝箱
  • 开源协议
  • 技术招聘
  • 测试经验
  • 职场提升
  • 技术模版
  • 关于我
  • 目标清单
  • 学习框架
  • 育儿经验
  • 我的专栏
  • 底层能力
  • 读书心得
  • 随笔笔记
  • 职场思考
  • 中华历史
  • 经济学故事
  • 基础组成体系
  • 程序编程原理
  • 异常和IO系统
  • 六大设计原则
  • 设计模式导读
  • 创建型设计模式
  • 结构型设计模式
  • 行为型设计模式
  • 设计模式案例
  • 面向对象思想
  • 基础入门
  • 高级进阶
  • JVM虚拟机
  • 数据集合
  • Java面试题
  • C语言入门
  • C综合案例
  • C标准库
  • C语言专栏
  • C++入门
  • C++综合案例
  • C++专栏
  • HTML
  • CSS
  • JavaScript
  • 前端专栏
  • Swift
  • iOS入门
  • 基础入门
  • 开源库解读
  • 性能优化
  • Framework
  • 方案设计
  • 媒体音视频
  • 硬件开发
  • Groovy
  • 常用工具
  • 大厂面试题
  • 综合案例
  • 网络底层
  • Https
  • 网络请求
  • 故障排查
  • 专栏
  • 数组
  • 链表
  • 栈
  • 队列
  • 树
  • 递归
  • 哈希
  • 排序
  • 查找
  • 字符串
  • 其他
  • Bash脚本
  • Linux入门
  • 嵌入式开发
  • 代码规范
  • Markdown
  • 开发理论
  • 开发工具
  • Git管理
  • 百宝箱
  • 开源协议
  • 技术招聘
  • 测试经验
  • 职场提升
  • 技术模版
  • 关于我
  • 目标清单
  • 学习框架
  • 育儿经验
  • 我的专栏
  • 底层能力
  • 读书心得
  • 随笔笔记
  • 职场思考
  • 中华历史
  • 经济学故事
  • 1.1专栏序言和介绍
  • 1.2需求层次的模型
  • 1.3一起来做个练习
  • 1.4要带上技能地图
  • 1.5经营好自我工作
  • 2.1信息过载怎么办
  • 2.2体系思维很重要
  • 2.3构建知识的体系
  • 2.4结构化思维思考
  • 2.5闭环思维的逻辑
  • 3.1宏观学习的方法
  • 3.2用海绵法找时间
  • 3.3三段分解学什么
  • 3.4学习方法论实践
  • 3.5链式和环式思考
  • 3.6玩和教保证效果
  • 4.1以结果导向计划
  • 4.2目标设立和管理
  • 4.3分解目标要明确
  • 4.4计划的落地策略
  • 4.5结果的检查改进
  • 5.1掌握些做事方法
  • 5.2三种方案设计法
  • 5.3Pdca执行方法
  • 5.4五问根因分析法
  • 5.5五步问题处理法
  • 5.6四维度总结分析
  • 5.7金字塔汇报方法
  • 5.8STAR摸底分析法
  • 5.9阶段复盘方法论
  • 5.10生命线分享游戏
  • 6.1语言底蕴的提升
  • 6.2阅读的持续提升
  • 6.3理解能力的锻炼
  • 6.4沟通能力的演进
  • 6.5演示幻灯片提升
  • 6.6学会高效的提问
  • 6.7公众演讲的提升
  • 6.8做好技术的演讲
  • 7.1职场晋升的规则
  • 7.2提高工作的效率
  • 7.3打工人如何提升

5.4五问根因分析法

目录介绍

  • 01.5W分析法的背景
  • 02.丰田的5W分析法
  • 03.为何要去学习5W
  • 04.实际场景的分析
  • 05.5W分析管理场景
  • 06.实际使用注意点
  • 07.总结重点的内容

01.5W分析法的背景

在实践过程中,遇到了卡点或者问题,该如何排查。其中在检查环节,最容易出现的问题就是,分析原因的时候,只看到表层的原因,而没有去深挖深层的根本原因。

这就会导致我们给出的解决方案治标不治本,虽然短时间内做了应急处理,但是按下葫芦浮起瓢,相关的问题之后还会接连不断地冒出来。

怎么解决前面的问题呢?这就要靠5W根因分析法。它又叫5Why分析法或者丰田五问法,最初是由丰田集团创始人丰田佐吉提出的,后来成为丰田汽车公司获得成功的重要方法。

02.丰田的5W分析法

5W 根因分析法到底是什么做的呢?根据丰田汽车公司前副社长大野耐一的描述,就是重复问五次“为什么”,问题的本质和解决办法就会变得显而易见。 5why法的关键所在:鼓励解决问题的人要努力避开主观或自负的假设和逻辑陷阱,从结果着手,沿着因果关系链条,顺藤摸瓜,直至找出原有问题的根本原因。 沿着“为什么——为什么”的因果路径逐一提问,先问第一个“为什么”,获得答案后,再问为何会发生,以此类推,问5次“为什么”,或者更多,以此来挖掘出问题的真正原因。 image

2.1 看一个例子

大野耐一曾经举过这样一个例子: 问题 1:为什么机器停了?答:因为机器超载,保险丝烧断了。 问题 2:为什么机器会超载?答:因为轴承的润滑不足。 问题 3:为什么轴承会润滑不足?答:因为润滑泵失灵了。 问题 4:为什么润滑泵会失灵?答:因为它的轮轴耗损了。 问题 5:为什么润滑泵的轮轴会耗损?答:因为杂质跑到里面去了。

2.2 问题思考的层次

反思一下。针对问题的思考,我们处于哪个层级,那么对应的解决方案也是不一样的。问题的本质会随着你追问的层次而不相同。 如果到了问题1就停止追问,那么工人的措施就是更换保险丝,一段时间后保险丝肯定还会烧断。 如果到了问题2就停止追问,那么工人措施就是添加润滑油,过一段时间后机器又会超载。 如果到了问题4就停止追问,那么工人的措施就是更换轮轴,一段时间后轮轴又会很快坏了。 只有当追问到了问题5,才能找出停机的根本原因,这时工人的措施就是给润滑泵加上防杂质的滤网,从而彻底解决问题。

03.为何要去学习5W

3.1 学习5W的目的

系统的方法并不急于立即解决问题,而是立足于揭示问题根源,找出长期的对策! image 为什么要学习和使用5W根因分析法,例如冰山问题,找到根本原因! image

3.2 5W分析法步骤

第一步:把握现状。搞清楚问题然后针对性查找原因,注意首先要搞清楚问题本身,和针对性查找原因。 第二步:不断原因调查深入。

04.实际场景的分析

4.1 5W是形象的说法

在某交易平台的业务规划目标讨论会上,我通过 3 个为什么,了解到了业务目标背后的深层考虑。 问题 1:为什么今年的业务目标是成交金额翻番?答:因为只有成交金额翻番我们才能达到盈亏平衡点。 问题 2:为什么今年要求达到盈亏平衡点?答:因为集团要求我们的业务能够自负盈亏。 问题 3:我们本质上还属于创新业务,为什么集团要求我们的业务能够自负盈亏?答:因为疫情的影响,集团需要开源节流,减少非盈利业务的持续投入。 你可能觉得有些奇怪:怎么这个例子只问了3个为什么就结束了呢?因为5个为什么只是一个形象的说法,不管几个为什么,关键在于通过追问找到根本原因。

4.2 不断的去追问

在某次 Netty 培训课上,通过 5 个为什么,来验证大家是否真的深入理解了 Netty 网络高性能的核心原理。 问题 1:为什么 Netty 网络处理性能高?答:因为 Netty 采用了 Reactor 模式 问题 2:为什么用了 Reactor 模式性能就高?答:因为 Reactor 模式是基于 IO 多路复用的事件驱动模式。 问题 3:为什么 IO 多路复用性能高?答:因为 IO 多路复用既不会像阻塞 IO 那样没有数据的时候挂起工作线程,也不需要像非阻塞 IO 那样轮询判断是否有数据。 问题 4:为什么 IO 多路复用既不需要挂起工作线程,也不需要轮询?答:因为 IO 多路复用可以在一个监控线程里面监控很多的连接,没有 IO 操作的时候只要挂起监控线程;只要其中有连接可以进行 IO 操作的时候,操作系统就会唤起监控线程进行处理。 问题 5:那还是会挂起监控线程啊,为什么这样做就性能高呢?

4.3 5W指导准则

原则1:问问题要尽可能多方考虑。尽量找出所有可能原因。 原则2:问题要绝对的客观。找的是原因,不是借口和理由。 原则3:根据数据、事实问问题,而非猜测和假设。做到三现,在现场通过现物掌握现实。 原则4:不要认为答案是显而易见的。只有锲而不舍,追根究底,才能找到真正的答案。

05.5W分析管理改进

5.1 分析项目延期原因

在某次项目延迟问题的讨论会上,下面通过 6 个为什么,把项目延迟的核心原因找了出来。 问题 1:为什么项目延迟了?答:因为要等测试环境进行测试。 问题 2:为什么要等测试环境?答:我们只有 2 套测试环境,2 套都已经用于另外两个项目了。 问题 3:为什么只有 2 套测试环境,不能搭建多套吗?答:现在没有机器用来搭测试环境了,而且我们有将近 20 个子系统,搭建一套可用的测试环境耗时可能要一周。 问题 4:为什么会没有机器,直接申请机器不就可以了?答:运维今年的预算用完了,不能购买新机器了。 问题 5:为什么一定要用新机器,测试环境对机器性能要求高吗?答:测试环境对机器性能要求不高,基本能跑就行。 问题 6:那为什么不找运维申请过保机器(使用超过 3 年的机器,即使没坏也要换掉)用来搭建测试环境?答:之前没想过这个方案。

5.2 延期治理解决方案

解决方案很简单。直接找运维借几台过保的机器用来搭建测试环境。不过这还只是短期的解决方案,实际上在问题 3 的回答中,我们还可以发现另外一个问题:搭建一套环境太耗时了。 于是测试开发部启动了一个基于 Docker 的快速搭建环境的项目,项目完成后,任何一个开发或者测试同学花 5 分钟就能生成一套全新可用的环境。

06.实际使用注意点

6.1 找到根本原因是关键

问题数量不是关键,找到根本原因才是关键。在介绍业务分析这个例子的时候,已经提到,5W或者说5个为什么只是一个形象的说法,3 个也可以,7 个也可以,关键在于找到根本原因。 所以一个最简单的提问方法就是:下一个问题是对上一个回答的进一步深入。 虽然数量可多可少,但建议不要少于 3 个,因为少于3个大概率找不出根本原因;但是也不要多于 7 个,因为多于7个还没有找到根本原因,那就要审视一下问题本身是不是有问题。

6.2 首先要明确问题本身

5W 根因分析法起源于生产过程,通常情况下问题都是比较明显的,比如机器停机了或者次品率升高了。但是,还有很多情况下问题本身其实是不明确的,每个人的理解可能都不太一样。 如果没有明确问题就开始问为什么,无论问题多么精彩都没有意义,甚至越精彩离题越远。 比如“成交量大幅下降”,这个问题就不明确,到底下降10%、30%还是50%才算“大幅”?是同比下降还是环比下降?是某一个子业务下降很多,还是所有子业务都在下降?如果这些问题都不明确就开始进行根因分析,就很可能得出一大堆似是而非的原因和改进措施。

6.3 避免变成“撕逼”现场

在连续追问“为什么”的时候,如果双方没有对这个方法充分达成认识,被问的人很可能觉得你在挑战和质疑他,讨论的现场就会变成大型“撕逼”现场,最后闹得不欢而散。

所以在一开始的时候,就要先解释清楚,待会儿将采用5W根因分析法来探讨根本原因,避免挑起情绪对立,引发“撕逼”。

07.总结重点的内容

5W 根因分析法就是通过追问 5 个为什么来分析问题的根本原因,从而得到彻底的解决方案。

5W 根因分析法起源于生产过程的问题原因分析,但也可以应用于业务分析、技术学习和管理改进等场景。

使用 5W 根因分析法时要注意:首先要明确问题本身;问题数量不是关键,找到根本原因才是关键;避免变成大型“撕逼”现场。

贡献者: yangchong211
上一篇
5.3Pdca执行方法
下一篇
5.5五步问题处理法