5W法则： 打造高效技术团队必备利器

不幸的是我被派去推动整个项目改进计划，请允许我摘一段和项目经理的谈话来引入今天要讨论的正题：

PM一头雾水：“这次Milestone指定保不住，客户批了好几次，我们的效率太低了。”

我不解：“为什么不快点呢？”

PM有点生气：“Demo总是过不了，怎么快？”

我更不解：“Demo为什么不过呢，功能实现完没？”

PM真生气了：“都是脑残的客户，说不是他想要的，我们都实现了他的要求……”

我不想重复上面那种你来我往的问题，这已经说明了这个项目存在诸如效率低下的问题，被客户责备，在这种情况下，我们需要问自己“为什么效率低下？是什么导致效率低下？”，而不能因为客户老说我们的Demo不是他们想要的，我们就重复Demo的改进，我们更需要去思考，什么阻止了我们的Demo不能满足客户的需要。在我做咨询的日子里，见到影响团队效率提高的原因不外乎以下三个。

制度问题：常见的如产品公司，比如Adobe的Photoshop，用户告诉HelpDesk说，你的画刷不好用，Adobe拿到这个问题，可能需要不下十个部门的审核，最终给出解决方案。

技术问题：某类技术问题太难或者某类问题重复出现。常见如大型软件产品中疑难问题导致了某个迭代里程碑不能顺利发布。

能力问题：整个组织或者团队Competence不行。

解决此类问题，我们必须先知道哪块石头绊倒了自己，在欧美软件公司流行两个词语：RCA和EDA。一个是倾向过程分析，一个是角色分析。

找到问题的本质原因（Root Cause）是一个高效技术团队必须具备的能力，但常常效果并不理想，主要表现在以下几方面。

问题的原因盘根错节：比如通信产品的一个Bug可能是很多Team共同导致的，也可能是因为历史遗留或者技术升级造成的。

问题肇事方横跨国际：在技术国际化的今天，经常出现在中国开发，在印度维护，在韩国修复这种类似的情况。

调查方认知狭窄经验不足：人员流动是技术类公司的普遍特点，我们经常出现刚组建不久的团队需要去修复很久以前的Bug，由于团队新、员工能力薄弱，很难看到问题的本质。

为交差而非探究：这种情况在外包类公司很普遍，外包分为Capacity外包或者Content外包。团队成果交付的界限是完成任务，所以在分析问题时，很多目的为了完成里程碑，为了交付。殊不知这个问题一次不能彻底解决，可能在后续会不断重现，其叠加效应造成的成本流失更大。

在问题的重复中迷失：开篇的一席对话，其实就是这个原因的佐证，我们没能一次解决问题，而是修修补补，发现同质不同样的问题不断重现，交付的时间越近，大脑越是没有片刻的清净去思考问题的本质。

除以上几点原因外，在我们的外包实践中，遇到过很多其他的问题，比如团队管理松散、流程执行不严格、风险管理滞后等，都直接削弱了技术团队的高效性。那么我们是如何解决如上问题的呢，我们遵循的是“5W法则”。

在我向公司引入6Sigma质量管理方法论时，曾经深入地研究过这个法则，同6Sigma一样，5W法则来自日本丰田公司，由丰田佐吉先生发明，以此来改进丰田生产线上的诸多问题。其最基本的原则就是：任何生产型问题都可以连续问5个为什么找到答案。

“打破砂锅问到底”：5W法则和我们民间常说的“打破砂锅问到底”如出一辙，但又有不同，5W法则需要有技巧地去问，需要有规则地单向地去问，具有单点目的性，但后者则没有这些特点。

 5W法则要旨在问，原则在中立：我们做问题分析时通过问的方式进行，但要采用问题中立的原则，不能有问题方的心理障碍在里面，这是最基本的原则。

 5W法则在欧美企业中的典型应用：RCA和EDA。RCA意为Root Cause Analysis（本质问题原因分析），EDA意为Espcae Defect Analysis（控制遗漏分析）。

我们可以跨域地借鉴这个在制造业中的方法到我们的技术型团队中，接下来我们对开篇的那个让项目经理头疼的问题采用5W法则找一下问题的原因，来看看在实际的团队运作中如何使用。

第一步：成立分析组

对于典型问题或者核心问题，要成立问题分析组，为了分析开篇实例中的问题，我们成立了分析组，取名为：P7延期分析组。

该分析组需要以下特点。

分析组的Leader：必须是Scrum Master或者Team Leader，或是问题整个参与者。因为Leader需对问题有比较全面的了解。

分析组组员需要包含问题相关方：比如我们P7的Milestone延期，可能因为Demo没有通过，那么就需要Demo的相关方（比如开发者Eric、资深Tester Tom、Product Owner Susan还有产品专家Sean）一起参与。只有问题的相关方都参与，我们才可以全面分析问题的原因。

第二步：准备5W分析表

有些公司习惯将5W分析称为RCA表。图1是我们公司喜欢用的5W表，当然别的公司可能有自己的形式，这不是重点。重点是内容需要体现5W的思想。简单说一下每个元素。

 Root Cause Analysis列：这里列出将被分析的问题，比如“37号基站扇区配置失败”，比如“Excel中的格式刷在大文本下无效”或者也可以是“每天早上总有20%的员工迟到”等。这里需要用简明的语言列出被分析的问题。

 Why1至Wh5：这五个列，则是对第一列的问题引申出的原因。

 Root Cause：该列就是我们针对该行的Why分析出的最本质的原因。

 Actions：最后一个列则是针对前面的Root Cause提出的改进计划。

表中的粗线左向箭头：其代表着问题的层次性，比如Why1下的第一个原因，可能会引出Why2下的另外几个原因，以此类推呈树状散射分布。

表中的文字：每一个Why的内容，都需要以“因为（Because或 As）”开头。

第三步：进行分析

在前两步准备好后，我们进入非常重要也是非常有意思的第三步。我们的Leader Warren会找一个宽敞的会议室，带领大家进入主题，我以影视场景的方式描述整个过程。

剧情1：Warren会说：“今天我们分析P7延期的问题，大家畅所欲言，为什么会延期？直接原因是什么？”

剧情分析：这是第一个“为什么”（Why），组员需要去想导致这个问题的最直接的原因是什么？而不是比如：C++没学好、物价飞涨等间接原因。也许C++没有学好可能导致Developer代码的质量不好、物价飞涨或许会让员工无心工作，但切记这都不是最直接的原因。

剧情2：Warren说完后Susan迫不及待地说：“因为Demo两次没有过。”Tom失落地说：“我们的工作检查表中有三项没完成。”后面大家一起抱怨说：“时间太紧迫。”突然角落一个声音传来，资深开发Eric无奈地说：“客户的需求一直在变。”这个话题引起了大家的共鸣，开始你一句我一句进入了发泄和辩论的环节。这时Warren优雅地拍了拍手，提醒大家暂停，并且引导说现在是分析最直接的原因，已经有四个原因，大家同意吗？经过大家投票Eric的原因不是直接原因，其他三个是。于是Warren淡定地把这三个原因写到Why1的列。

剧情分析：这就是分析现场，很多经验尚浅的分析小组，最后陷入一团糟，甚至引起关系紧张的论战。所以Leader很重要，需要引导大家，按照“直接原因——依次深入”的方式进行。

经过第一个Why的询问，我们发现导致P7延期的有三个直接原因：Demo审查不过、工作表有三项没完成、时间紧迫。

那么还有第四个原因吗？这个需要团队决定，当时大家一致通过没有。同时Warren需要出来引导组员：既然大家同意只有三个直接原因，那如果顺利解决了这三个问题，是否P7就不会Delay？

注意这里就是5W法则在执行过程中的一个很重要的原则——闭环性。即一旦次级的原因解决，那么本级的问题必然被解决。Warren带领大家完成了Why1的分析，很漂亮地找到了三个原因，接下来进入Why2的分析。

剧情3：Warren指着“Demo审查不过”这一条，问组员：“为什么审查不过？”这时组员列出各种原因，比如“代码没有写完”，“实现需求和客户期望有差距”等。也有组员说“时间太紧了”。

剧情分析：注意对于最后一个关于时间太紧的问题，需要在这个Why2分析域中移除，因为它属于Why1的第三个原因。想必大家明白此举的目的，即防止重复分析、提高分析效率。

我们不断重复着Why1和Why2的节奏，无限地延伸到WhyN，但终点在哪里呢？如果我们不停止，我们可以从一辆飞奔的汽车一直分析到每一个金属原子的夸克结构。如图2中的深红色圆圈就是我们末态原因。判断是否需要停止进一步分析时，需要满足几个条件。

这个原因大家明确且可修复：比如我们沿着“任务中三项没完成”脉络分析到“因为Master请假没有及时检查任务完成情况”时，这个原因大家都明确，且只要Master不请假或者请假也能及时检查就可以修复。

这个原因不在自己的控制范围：比如我们沿着“Demo审查不过”分析到“客户的需求文档开发人员离职”，到此我们就无须深入，因为员工离职我们可能分析出各种原因，但他不是我们所能掌握的，所以他是我们的职责之外。如果需要继续则需要客户方参与。

这个原因原子不可分：比如我们沿着“时间太紧”分析到“因为端午节放假”，这个就已经不能再分，因为你无法再继续去分析为什么端午节放假的问题了。

有没有超过5个Why呢？

在我带领我的团队作分析时，开始时经常出现类似情况，一个问题，按照5W法则我们希望在5个Why之前就可以找到问题的本质原因，可是总有组员尝试刷新纪录搞出很多个Why出来。切记如果某一个Why的次级Why的个数太多则说明如下几个问题：

上一级Why粒度太大；

被分析对象粒度太大；

分析者没有全局掌握；

分析者没有有效合并。

比如我们如果分析一下PM2.5为什么超过300，那么我们无论如何都不能用5Why搞定，因为被分析的对象太宽泛，我们需要把这个大问题划分成很多个子问题再分析。

通过前面的分析，我们总结一下5W法则的实施原则，如图3所示。

 Host是分析过程的引导者：分析问题过程中，不同的角色很容易执迷于自己的方向，而让整个分析过程一团糟。所以Host需要引导组员并在一些比较迷茫的问题上或大家都沉默时，利用发散思维、合理引导，比如可以说：是否存在这样的可能，是否存在那样的可能等。

一次只分析一个问题：我们都喜欢大而化之一个问题，但我们会在众多的问题中迷茫，所以在分析时选择一个问题分析，在每一个Why的阶段，只分析一个阶段的Why，不要涉及其他Why。

最后一个Why结果就是Root Cause：在每个Why分析到末态时，如图2中我们用深红色标注的部分，那就是末态原因，是我们寻找的Root Cause。

费了这么多功夫，我们都是在找Root Cause，那么Root Cause有什么特点呢？

正交性：意指最终Root Cause列中所列出的原因，彼此不能包含，原因间彼此独立。如果出现包含或者重叠的问题，那就说明我们在前面的Why分析中做了重复分析。比如出现以下Root Cause：P7延期因为文档不全和P7延期因为需求说明文档缺失。明显后者被前者包含。如果出现这个问题，我们需要把这个两个原因合并。

原子性：意指末态Root Cause不能再分或者不属于我们的掌控范畴，我在前面的篇幅中已经讲解。

可度性：这个概念引申于SMART原则，指我们的Root Cause是可以度量的。也就是可以切实去理解、规划和实施。不能出现如：P7 Milestone延期是因为“客户希望我们成为一名伟大的人”，这种原因是不能度量的。

闭环性：闭环就是每一级的Why可以覆盖上一级Why，简而言之，如果我们可以把这一级Why中的所有问题都解决，那么上一级的所有问题都不会出现。闭环性是检验我们分析问题的是否完整的主要手段。比如P7的Why1里面的三个问题都被组员认可，但我们采取了很多Action解决了之后，发现问题依然存在，就说明我们的5W分析违背了闭环性的原则。

经过上面分析，用了一个小时的时间，最终我们的P7延期问题分析小组终于完成了所有的5W分析。最后找到7个Root Cause：

因为Sprint开始估计项目Task时间不准确；

因为客户的需求提供者要求不稳定，没有文档化；

因为结对检查规定没有执行；

因为Demo时准备的资料不具体；

因为演讲者口语不好；

因为新加功能处Case没有覆盖；

因为新工具没有培训就使用。

这就是我们想要的结果，根据闭环性的原则，我们如果解决了这最终的7个问题，P7延期的问题就可以解决。于是我们制定Action，也就是改进措施，加入到5W表的Action列：

一个高效技术团队或者生产团队，需要有面对问题的勇气，同时也需要解决问题的方法和能力，小的技术团队可以坐在办公室里用10分钟的时间想清楚所有问题的脉络，但对于人数较多的大型技术团队，就需要一套好的方法论支撑。效率来源于工作流的流畅性，不应该让困难的问题成为节点，不能让不清楚的问题重复出现。所以需要5W方法论来自省和分析。

高效的团队来自每个节点的高效，如果没做好些细节，5W法则可以帮你找到。

每级的原因都需要半数以上的人首肯：因为分析小组成员都是问题的参与方，都会直接或间接为分析结果负责，这个也避免了敏感问题上组员人为规避的可能。比如有个案例就是：P7延期是因为项目经理没有严格推进流程监控。这个原因可能会使在场人员考虑到项目经理的情绪，不敢提。所以Leader需要在这里提出来，引导大家，并且征得大家半数以上人同意。

本文为ImapBox原创文章，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)