事故根因分析：上集

北京某软件开发公司，专门为电信供应商做定制软件开发，比如发短信做些推广活动等。公司希望做过程改进，我首次与公司老板访谈：
我：过程改进主要帮助管理层更好达到公司业务目标。你们自己是最清楚有那些不足，请问你觉得哪里最有改进空间？
总经理：我不太熟识技术细节，只能从客户视角看。例如，去年因为某一次软件错误引起供应商损失了几十万元，我就立马内部开会找根因，最后发现是因为某开发人员粗心大意，没注意，编码时把两行数字搞错了，后面测试人员测试时针对这功能，测试操作有收到短信，没有细看短信内容，没发现这缺陷，便通过了。这事故不仅招致公司金钱损失，更影响了客户的信任度，和我们公司在这行业的口碑。
我：针对你说这些主要原因你采取了什么纠正措施？
总经理：我们后面就加强了代码的评审，要求这些代码都需要主管看过，也增加了惩罚措施，如果有同类问题再发生，项目经理和部门负责人都要承担责任。
我：采取这个措施之后，效果如何？
总经理：很好，大家都注意了，到现在都还没有再发生同类的问题。

= = =

你估计以上的根因分析能避免同类问题再发生吗？
如果你赞同以上事故的主因是人员疏忽，请看看以下故事。

香港南丫海难

2012年10月1日晚上8时，任职港九小轮的黎细明驾驶海泰号（注）由中环出发前往南丫岛榕树湾。15分钟后,任职港灯的周志伟驾驶南丫四号从榕树湾出发,接载港灯员工及亲友到维港观赏国庆烟花。两船于8时20分相撞，南丫四号船尾迅速沉没，造成39人遇难。

（注：海泰号是大型喷射双体船，速度与载客量都远比南丫四号高。）

南丫四号船尾沉没，消防处安排潜水员紧急救援:

黎细明（左，56岁），小二程度学历，82年任职小轮公司，2008年成为船长。

周志伟（58岁），小六程度，已婚，育有两女，1974成为海员，1993年开始担任船长。

2015年，开庭审判两船长：

周：南丫四号案发前曾3度转右避撞，但海泰号不依规则3度转左，由于海泰号船速较快及操控性较高，故南丫四号的避撞措施均被海泰号的相反举动抵消。

黎：造成大量乘客死亡的原因是南丫四号船身有问题，包括部分船舱并非水密舱等，而且海上的雾灯及其他背景灯光影响我难以观察到南丫四号。

专家：海泰号没有根据"国际海上避碰规则"右转，反而左转3度，属"极度危险",南丫四号虽曾按规则向右转,但"幅度太小、转得太迟"。

陪审团以7比2 裁定黎细明误杀罪成立，法官判入狱8年
陪审团以8比1 裁定周志伟误杀罪不成立，但危害他人在海上安全罪以7比2 裁定罪成，法官判入狱6个月

你赞同两船长失职是海难的根因吗？

政府经过3年多的事件调查，最终做出调查报告。报告显示，海难中沉没的南丫四号，从设计到验收，每个环节都存在纰漏，每个环节都有出错，例如包括：

没有安装水密门（导致南丫四号在碰撞另一艘船之后，迅速沉没）
座位的螺丝松动（导致撞船后，因船尾沉没水中，所有座位都松脱，跌到船尾，影响乘客逃生）
没有儿童救生衣等

因此导致南丫四号在碰撞海泰号之后，迅速沉没，并且导致罹难人数众多，政府展开内部调查，怀疑海事处有十七名职员应负责任。

除了南丫四号的问题，你是否觉得小轮公司也有责任，例如：

是否有足够对船长的培训/监督
是否有定期检查船上救生设备

你可能反驳，南丫四号这类小型船，预算少，所以关注度，监控度都低，如果大型项目应不会出现这类纰漏事故。请看看美国NASA太空穿梭机(Space Shuttle)计划因发生了两次严重致命事故，最终被叫停。

太空穿梭机灾难（Space Shuttle disasters）

1986: 挑战者号（Challenger），挑战者号航天飞机升空后，于发射后的第73秒爆炸,机上7名宇航员全部罹难。( 视频可以网上看到)
2003：哥伦比亚号（Columbia）, 航天飞机返回地球时,因为左翼的隔热保护胶在十六天前升空时被固体火箭助推器外层脱落的乳胶击破损坏，航天飞机回航进入大气层后第1000秒钟，在35,000米高空因过热解体，7名宇航员全部罹难。

Sally RIDE 在2003哥伦比亚号灾难事故调查回顾说：我很诧异这两次事故的原因非常相似（她也是挑战者号事故调查组员），86 年引起挑战者灾难的陋习又再出现 : 因要赶上计划升空日期，忽略之前性能报告的发现，没有注意前线技术工程人员提出的安全隐患，也缺乏安全保障措施。从哥伦比亚号1981年首次升空开始，其实每次都有出现升空时燃料缸外的保护乳胶掉落事故，但管理层一直都没有关注，工程师因为赶进度，每次升空前，都没有时间预先处理好。

图3： 7名哥伦比亚号宇航员

反过来，管理层、工程师只关注项目成本进度，忽略了质量与安全，便会导致灾难。

以上两例子，与其它很多航空或海上灾难类似，虽然当事人（如船长、工程师）失误引起事故，但并非根因，背后系统的不足才是主因。

你估计上面总经理的纠正措施能避免同类问题再出现？

不一定。因为高管关注，而且已引起公司极大的损失，开始的时候大家还是会注意，但不能长久，因为都依赖个人习惯，很可能几个月后会再发生。

根因分析的主要元素

如果想挖掘系统的不足，便必须找出根因（而不是仅仅处理浮出来的问题），根因分析主要包含那些元素？可参考CMMI模型的根因分析(Causal Analysis & Resolution CAR)：

利用二八原则识别引起大部分问题的最主要因素
分析背后的主要原因
对应改进措施
判断改进效果
总结成根因分析报告

如想了解对应实例，可参考附录里的Esquire俱乐部过程改进例子。如果你觉得只要使用各种根因分析方法，如帕累托图，鱼骨图等，便能做好根因分析，请看看下面案例：

现场辅导团队如何做好根因分析

某公司过程改进组（共4人）分析以往一年项目，做根因分析，希望改进交付的质量，减少交付验收时的缺陷数。。。

我：请问你这个帕累托图是依据什么画出来的？
组长：针对客户缺陷密度较高，我们希望降低。我们就做了敏感度分析，发现需求引入的缺陷数跟它相关性最高，我们接下来就用鱼骨图分析，四个人一起头脑风暴，识别出以下十几项主要的原因种类，然后我们就按每人三票，各自单独投票得出这个排序，然后我们就依据二八原则选择了头三项原因是主要的对象，然后我们按这三项发现这些项目的导致需求出现的原因包括流程图画不好等。

我听完以上根因分析故事，便在投影仪投出以下某机场某年导致航班延误的原因统计表，问项目经理：“假如你是顾问团队，要为机场管理层高层分析导致航班延误的主因并提出改进方案你会怎么利用二八原则画帕里托图？”

香港启德国际机场1996年航班延误统计:

然后我解释：
“我们不应直接按几十条原因，按每条问题的影响度，从最高排到最低做帕里托图，而应先把原因分类。用上面机场延误为例，比如，哪些是不可抗力的天然原因（如天气原因），哪些是跟闸口管理相关的问题，那些是跟机场打印登机牌相关等，例如，如果识别出是跟闸口管理类的问题最多，后面便针对这进一步分析根因。分组才有针对性、有意义。 ”

我：你们的分类，帕累托图依据的“数据”，都只是用数字形式表达你们头脑风暴的主观判断，所以你用这种帕累托图其实跟直接用头脑风暴做出做出的结论没什么差异，只是你们用了投票数使结果看起来量化，其实是没有实际客观数据支撑。

你们也难以利用你们的分类分析你们的项目数据，例如，你怎么从过去历史项目数据判断哪些项目是归属于‘功能描述不明确’？每个项目肯定都有几十条、几百条需求，其中可能有些是描述不清，但有些可能是其他问题，你们难以判断有多少项目归属于‘功能描述不明确’。
你们上图的分类不完整：例如，只有‘功能描述不明确’，非功能需求描述，如性能，安全性就不需要考虑？
你们现在那分类有很多重复性，同样一个问题也可能是归属于两类、三类。如果你确实想做好，应先预先要按你们要解决问题的方向，识别相关度量项，然后针对这些度量项，例如，缺陷，并定义如何分类（详见附件“二八原则与数据分类”），收集数据后，做分析。有客观数据分析才可以是你们根因分析的第一步。

= = =

我：你们现在的找出的其实并非根因，只是浮在水面上的现象，你们有听过5W吗？
组长：有， What When ..
我：不，你说的是5W+1H ，5W是五个为什么(why)，所以你们应一直追问，才能更好识别出背后主因，并针对主因采取纠正措施，才能避免同类问题重复发生。

我继续用5分钟与他们讲述丰田汽车大野耐一先生的5W故事。（详见附件“大野耐一先生5Why例子”）

除了依赖问“为什么”外，模型（例如CMMI， XP极限编程等）也可以帮你们更全面找根因。很多原因会导致项目延误。“未能出正确的干系人”可能只是其中一个原因，例如：

跟踪干系人的协调问题（甲方会在那天前提供什么信息）
监控活动（里程碑）的延误（实际与计划对比）

如能做好这些可帮助你们团队减少项目延误,以上两例子都是CMMI里的最佳实践，所以模型可以帮团队更全面看问题。

分析流程

某家电力服务公司的内部软件开发团队，公司规定每两周固定日期发新版，因客户对软件质量要求很高，每次都必须通过一系列的评审和测试才可以发版。
如果不能按发版时间完成项目交付，经理和团队都会回复整个流程，识别在整个过程里那些地方出现了失效点，然后针对失效点分析根因。所以除了模型，也可以分析过程找出根因。画了流程图后，便可以利用FMEA方法针对每个失效点，找根因，和对应纠正措施。（详见附件“FMEA 实例”）

怎样才能做好根因分析

从前面各例子看到，有些团队没有根因分析的意识：不理解核心思路，只是表面“做”了根因分析的步骤，其实未找到根因。所以，要做好便必须利用培训，提高大家的根因意识。大家从以下日本回国技术总监的故事可以更好理解什么是“根因意识”。

技术总监经验之谈

总监之前一直在日本带领开发团队，十年前回大陆。最近为他们做过程差距分析，我汇报他们根因分析的不足后，总监开车送我去机场时分享他的日本经历：

你说我们团队没有找出真正根因，我非常赞同。日本在根因分析做得特别好。我之前在日本工作，带领小组做开发，当时我们团队共5人，有2位来自大陆，其他是本地人，有一次，因为我们开发计算公积金出错，QA一直追问问题的原因。当时我还没有找出根因的概念，不明白QA的意图，以为只是问责，希望找个人背锅。其实他们确实是希望找出问题的源头，避免同类问题再发生。当主管追问原因，要求我发问题报告。我的报告只说了一些开发问题，人员经验不足等。主管一直追问为什么。“如果你说培训经验不足，你有什么培训相关的安排来避免？”我回答不上来。最后发现，原来是日本计算方法和大陆不同，他们不四舍五入，导致我们两位大陆开发人员的计算便和本地的不同。很多大陆工程师没有根因分析概念，认为质量依靠个人保证 - “我负责，有问题我承担”。日本人不是这个思路，他们希望挖掘到问题的根本原因，并避免。后面我回国发展，开始时兼职做咨询工作，帮一位老朋友看看某软件开发公司团队的问题，发现很多大陆团队对质量方面的要求远远不如日本，很不习惯。

日本产品质量

98年,我在香港富士通工作，试图在香港市场推富士通的服务器，富士通服务器跟美国太阳（SUN）匹配(compatible)，但它的价位反比美国太阳服务器贵，一直想不出什么原因。后来我去东京出差，发现原来日本公司，例如，富士通，对质量特别有要求，测试设计等都要通过很多关卡，才可以出厂。有些日本国外的富士通工程师就不明白为什么日本要这么苛刻？不断测试，好像浪费资源。原来日本市场对质量要求特别高，无论是消费品或者电脑，所以如果达不到日本的高水平质量要求，基本上卖不出去。富士通公司电子产品大部分主要满足本土市场，所以公司必须有很高的质量要求。所以日本电子产品质量比美国高。所以客户（甲方）对质量是否有高要求也是促进这个行业质量的一个重要因素。

（因要使用一些应用软件，我现在还有用一部东芝(Toshiba)笔记本电脑，也不贵。已经用了它超过十年。虽然因它使用传统内置硬盘，RAM也不多，跑Win10比较慢，但一直很稳定，没有出过问题。）

结束语

根因分析包括下图各主要元素：

从上面案例，大家看到有些团队虽然用了根因分析的各种方法，但不了解里面的原理。所以要弄懂根因分析不能单靠学理论与方法，必须利用实际数据让学员动脑筋和讨论。所以我每次培训根因分析，会：

先介绍了日本绅士俱乐部例子（30分钟）
然后请学员分组分析机场延误数据，请组员在大白纸上画帕里托图与根因分析（45分钟）
模拟向机场管理层汇报结果（我与其他组扮演机场管理层，听汇报，提问）（30分钟）

回到开头北京总经理案例：
原以为因为某些人员粗心大意（编码和测试），未做好，导致严重问题，我们就应该问这些问题能否预先避免。例如：

是否测试用例没写好，测试本身不够充分
代码写完以后有没有同行评审
有没有做单元测试

我们也可以利用根因分析的步骤：

按可能引起缺陷的原因，定义收集哪些项目数据（例如验收测试；缺陷分类；代码同行评审；缺陷数和分类，单元测试，缺陷数）
从项目数据利用二八原则，找出引起验收测试缺陷的主要因素
利用头脑风暴和五个‘为什么’找出背后的根因
针对根因制定纠正措施
选取一些项目试点，看有没有显著改善

从而识别出背后系统的不足，而不仅仅‘解决’当前遇到的问题（好比，发烧只吃退烧药，不去医院看病）。

下一章，我们看看如何利用根因分析做好迭代回顾。

附件

二八原则与数据分类

帕里托(Pareto) ，16世纪意大利威尼斯人，他发现虽然威尼斯很富有，但财富并非平均分布，80%财富在20%手里，他也发现很多其他分布都非平均。

因为过程改进要花费公司额外的资源投入，必须有针对最容易得到改进效果的原因，才能最大机会成功，所以应利用二八原则识别哪几个主要因素的影响最大。以上图为例，原本A类问题出现最多，针对这类问题做过程改进，之后A类问题少了很多，下一轮便应针对最多的B类做改进。

有些人以为只需要对某个维度做分析，没有从多个维度分析。

例如，某纸制产品工厂会计数据显示八成的产品问题相关成本都归属于5类，例如：质量不合格，赔偿，售后现场服务等（共有20类）针对5类中最大的一类：质量不合格，发现里面八成的成本都由于六个产品引起（共有50个产品）针对这六个产品把成本按缺陷种类细分，发现B产品断裂缺陷的成本最高，我们就应该针对这一问题研究如何改善。

大野耐一先生 5 Why 例子

有一次，大野耐一先生见到生产线上的机器总是停转，虽然修过多次但仍不见好转，便上前询问现场的工作人员。
(1-Why)问：“为什么机器停了？” 答：“因为超过了负荷，保险丝就断了。”
(2-Why)问：“为什么超负荷呢？” 答：“因为轴承的润滑不够。”
(3-Why)问：“为什么润滑不够？” 答: “因为润滑泵吸不上油来。”
(4-Why)问：“为什么吸不上油来?”答: “因为油泵轴磨损、松动了。”
(5-Why)问: “为什么磨损了呢?” 答: “因为没有安装过滤器,混进了铁屑等杂质。”
经过连续五次不停地问“为什么”，找到问题的真正原因（润滑油里面混进了杂质）和真正的解决方案（在油泵轴上安装过滤器）。由现象推其本质，因此找到永久性解决问题的方案，这就是5-Why。

FMEA 实例

(FMEA: Failure Mode Effects Analysis)

大家都可能试过未管理好时间，导致迟到。以坐飞机为例，从离开酒店到登上飞机过程中很可能有不少风险导致最后没搭上。

你出发的时候，可能用不同的交通方式：出租车、机场大巴等。如果你不能在起飞前45分钟到达机场办理登机牌，你便搭不上。但是你拿了登机牌也有可能最后搭不上，因为飞机都严格执行起飞前15分钟关舱门，所以你拿了登机牌也要在起飞前15分钟到达，才能顺利乘机。

Fig 1 登机过程

要赶上飞机其实是个过程，中间有很多环节会导致最后失败，所以我们可以用 FMEA 过程分析，来看如何控制减少失败的概率。

Fig 2 FMEA 例子

Fig 3 打分参考

以第一个失效为例：如发生便坐不上飞机，所以严重性是最高10。发生的概率还是比较高6。是否容易预防，预警，因不熟悉当地情况，加上我主要靠问酒店前台，有时候她也不清楚，所以我定6。RPN = 10x6x6=360。

从以上登机的例子，可以看出FMEA是以整个过程来管理风险，比如在出发前，就要查询一下各个交通工具要花费的时间，比如你发现在南京，从酒店坐地铁要转车，要花1个小时以上，如果时间太紧就来不及，宁可多花钱打车，才能控制风险。当你拿了登机牌，还是要经过安检，还要从安检走过登机口。有时候机场很大，到达登机口也要花很长时间，就要先问好路径，提前计算好时间，才不会误点。

过了安检到登机口要10分钟以上，就要在起飞前的35分钟完成通过安检，才来得及。这些都可以通过FMEA的形式把整个坐飞机的过程识别出来，找各个阶段会出现的问题，就知道如何控制。

以这坐飞机的风险为例，我自己是不仅一次有赶不上飞机，很多原因，但回顾一下都是习惯没改过来问题。我应依据以往差点赶不上的经验，回顾一下，确保每一个过程都控制住，就不会后面再次出问题，这个和企业做风险管理概念一样。
有度量才有管理。人和公司一样，很多做的事情好像是自己主动去想，其实很多都是潜意识习惯，如果你没有定一些量化的控制手段，就不会提高这方面风险意识，还是会搭不上飞机。我先回顾以往几次搭飞机的情况，并把每次到达机场的时间和到达闸口的时间写下（详见下面 Fig 4 ）

Fig 4 上面是机场柜台关闭（45分钟）前到达时间，下面是关闸口前到达时间（分钟）（ X 代表赶不上飞机）