分析事故根因：上集
北京某软件开发公司，专门为电信供应商做定制软件开发与运营，比如用短信做些推广活动等。公司希望做过程改进。
我: 过程改进的主要目的是帮助企业更好地达成业务目标。你们应该是最清楚自己有哪些不足的，请问你觉得哪些方面有改进空间?
总经理: 我不太熟悉技术细节，只能从客户视角来看。例如，去年因为软件的一个错误导致客户损失了几十万元，我立即在公司内部开会，希望找出根因，最后发现是因为某开发人员粗心大意，在编码时把两行数字搞错了，在测试人员针对这项功能进行测试时，虽然收到短信了，但并没有仔细看短信的内容，没有发现缺陷，测试便通过了。这事故不仅招致了公司的经济损失，更影响了客户对我司的信任度，也影响公司在行业内的口碑。
我: 公司采取了哪些纠正措施?
总经理: 之后我们加强了对代码的评审工作，要求这类代码都需要经过主管审查，还增加了相应的惩罚措施， 如果再次发生同类事件，项目经理和部门负责人都要承担责任。
我：采取这个措施之后，效果如何？
总经理：很好，大家都注意了，到现在都还没有再发生同类的问题。
= = =
你认为以上的纠正措施能避免同类问题的再次发生吗?
你可能赞同以上事故的主因是人员疏忽，但很多事故的主因其实不仅仅是人员疏忽。
香港南丫海难
| 2012年10月1日晚上8时，任职港九小轮的黎细明驾驶海泰号（注）由中环出发前往南丫岛榕树湾。15分钟后,任职港灯的周志伟驾驶南丫四号从榕树湾出发,接载港灯员工及亲友到维港观赏国庆烟花。两船于8时20分相撞，南丫四号船尾迅速沉没，造成39人遇难。 （注：海泰号是大型喷射双体船，速度与载客量都远比南丫四号高。） |
南丫四号船尾沉没，消防处安排潜水员紧急救援:
黎细明(左，56岁)，小二文化程度，1982年任职小轮公司，2008年成为船长。
周志伟(58岁)，小六文化程度，已婚，育有两女，1974成为海员，1993年开始担任船长。
| 2015年，开庭审判两船长： 周：碰撞发生前，南丫四号曾右转3度避撞，但海泰号违规左转3度，且海泰号船速较快及操控性较高，故南丫四号的避撞措施均被海泰号的相反举动抵消。
|
你赞同两位船长的失职是本次海难的根因吗?
政府经过3年多的事件调查，最终做出调查报告。报告显示，在海难中沉没的南丫四号，从设计到验收，每个环节都存在纰漏和出错，例如包括：
没有安装水密门（导致南丫四号在碰撞另一艘船之后，迅速沉没）。
座位的螺丝松动（导致撞船后，因船尾沉没水中，所有座位都松脱，跌到船尾，影响乘客逃生）。
没有儿童救生衣等。
因此导致南丫四号在碰撞海泰号之后，迅速沉没，并且导致罹难人数众多，政府展开内部调查，怀疑海事处有十七名职员应负责任。
除了南丫四号的问题，你是否觉得小轮公司也应负责任，例如：
对船长的培训/监督是否足够。
是否有定期检查船上救生设备。
在上一章说明了改正(Correction)和 纠正措施(Corrective Action)的区别。如果发生了重大事故，分析根本原因，找出系统背后的不足，举一反三，采取纠正措施，才可以避免同类问题重复发生；但只是处理了某事故，不能算是纠正措施，只是改正。例如发生海难事故，不能仅仅归咎到是船长失误。因难以避免同类事故再发生，不算是纠正措施。
其它不少类似的海空灾难或事故，虽然当事人(如船长)的失误引发了事故，但这并非根因，背后系统的不足才是根因。
你可能反驳，像“南丫四号”这类小型船预算少，所以关注度、监控度都低，如果是大型项目应该不会出现这类纰漏事故。请看看美国航空航天局(NASA)的太空穿梭机(航天飞机 Space Shuttle)计划因发生了两次致命的事故，最终被叫停的案例。
| 太空穿梭机（航天飞机）灾难 （Space Shuttle disasters） 1986: 挑战者号（Challenger）航天飞机升空后，于发射后的第73秒爆炸，机上7名宇航员全部罹难。( 相关视频可以在网上搜到) 2003：哥伦比亚号 (Columbia) 航天飞机在返回地球时，因为左翼的隔热保护胶在16天前升空时被固体火箭助推器外层脱落的乳胶击破损坏，导致航天飞机返航时进入大气层的第1000秒钟，在35,000米高空因过热解体，7名宇航员全部罹难。 Sally Ride在2003哥伦比亚号灾难事故调查回顾说 ：我很诧异这两次事故的原因非常相似（她也是挑战者号事故调查组员），86年引起挑战者灾难的陋习又再出现 : 为了赶上计划升空日期，而忽略了之前性能报告的发现，没有注意前线技术工程人员提出的安全隐患，也缺乏安全保障措施。其实从哥伦比亚号在1981年首次升空开始，每次都有出现升空时燃料缸外的保护乳胶掉落的事故，但管理层一直都没有关注，工程师因为赶进度，每次升空前，都没有时间预先处理好。 |
虽然调查报告有找出事故的根因，但过了几年后，管理层只关注项目的成本与进度，忽略了质量与安全，没有再注意调研报告指出隐患，事故还是重复发生。
上面总经理的纠正措施，加强了审查与惩罚措施，能避免同类问题再次出现吗?
不一定。因为已经导致公司极大的损失，而且引发了高管的关注，开始的时候大家会注意，但并不能长久，因为这仅仅依赖于个人的习惯，很可能在几个月后还会再次发生。
| 根因分析的主要步骤 下图列举了根因分析(Causal Analysis & Resolution CAR)的主要步骤（参考CMMI模型）：
可参考附录A:“绅士俱乐部过程改进”了解QC圈如何按意识根因分析元素完成为期7个月的过程改进。本章附件也有二八原则与帕累托图的介绍。但不要误以为只要使用各种根因分析方法，如帕累托图、鱼骨图等，就能做好根因分析。 |
是否把以上的步骤都做了，便做好根因分析？
根因分析误解案例
| 某公司过程改进组（共4人）分析以往一年项目，做根因分析，希望改进交付的质量，减少交付验收时的缺陷数。 |
我：请问这帕累托图的依据？
组长：针对客户缺陷密度较高的现状，我们做了敏感度分析。发现需求引入的缺陷数跟它相关性最高，我们接下来就用鱼骨图分析，4个人一起头脑风暴，识别出以下十几项主要的原因种类，然后我们就按每人3票，各自单独投票得出这个排序，然后我们就依据二八原则选择了头3项原因是主要的对象，然后我们根据这3项原因发现，这些项目是导致需求缺陷的原因，包括流程图画不好等。
我听完以上根因分析故事，便在投影仪投出以下某机场某年导致航班延误的原因统计表，问项目经理：“假如你是顾问团队，要为机场管理层高层分析导致航班延误的主因并提出改进方案你会怎么利用二八原则画帕里托图？”
香港启德国际机场1996年航班延误统计:
然后我解释：
我们不应直接把几十条原因，按每条原因对问题的影响度，从最高排到最低做帕累托图，而应先把原因进行分类。用上面机场延误为例，比如哪些是不可抗力的天然原因（如天气原因），哪些是跟闸口管理相关的问题，哪些是跟机场打印登机牌相关等，例如识别出是跟闸口管理类的问题最多，后面便针对这进一步分析根因。分组才有针对性、有意义。
你们的分类，帕累托图依据的“数据”，都只是用数字形式表达你们头脑风暴的主观判断，所以你用这种帕累托图其实跟直接用头脑风暴做出结论没什么差异，只是你们用了投票数据使结果看起来“量化”了，其实是没有客观数据支撑。
你们的分类有问题：例如只有“功能描述不明确”，难道“非功能需求描述不明确”（如性能、安全性等）就不需要考虑吗?
你们现在的分类有不少是重复的，同样一个问题有可能归属于2、3个分类。
你们度量操作定义也有问题，例如如何根据历史项目的数据判断哪些原因归属于“功能描述不明确”。
建议应该预按想要解决的问题，识别出相关的度量项，针对这些度量项收集数据，然后才做分析。收集客观的数据，才是你们根因分析的第一步。(详见附件“二八原则与数据分类”)
= = =
我：你们现在的找出的其实并非根因，只是浮在水面上的现象，你们有听过5W吗？
组长：有，What When ..
我：不，你说的是5W+1H ，5W是五个为什么(Why)，所以你们应一直追问，才能更好地识别出背后的主因，并针对主因采取纠正措施，避免同类问题重复发生。
我继续向他们讲述丰田汽车大野耐一先生的5W故事。（详见第一章附件“5Why例子”）
除了通过问“为什么”之外，模型(例如 CMMI、XP 极限编程等)也可以帮你们更全面地找出根因。
很多原因会导致项目延误。“功能描述不明确”可能只是其中一个原因，例如:
利用检查单做好需求评审
与干系人（客户）确认需求
如果能做好这些，即可帮助团队确保需求质量，减少项目延误，以上两条都是 CMMI 里的最佳实践，所以模型可以帮助团队更全面地看问题。
从前面各例子看到，有些团队没有根因分析的意识：不理解核心思路，只是表面“做”了根因分析的步骤，其实未找到根因。所以，要做好便必须利用培训，提高大家的根因意识。大家从以下日本回国技术总监的故事可以更好理解什么是“根因意识”。
技术总监经验之谈
| 总监之前一直在日本带领开发团队，十年前回大陆。最近为他们做过程差距分析，总监开车送我去机场时分享他的日本经历。 你说我们团队没有找出真正根因，我非常赞同。日本人在根因分析方面做得特别好。我之前在日本工作，带领小组做开发，当时我们团队共5人，有2位来自中国，其他是日本人，有一次，因为我们开发计算公积金出错，QA一直追问问题的原因。当时我还没有找出根因的概念，不明白QA的意图，以为只是问责，希望找个人背锅。其实他们确实是希望找出问题的源头，避免同类问题再发生。当时主管追问原因，要求我发问题报告。我的报告只说了一些开发问题，人员经验不足等。主管一直追问为什么。“如果你说培训不足，你有什么相关的培训计划来避免?”我回答不上来。最后发现，原来是日本计算方法和大陆不同，他们不四舍五入，导致我们两位国内开发人员的计算便和日本的不同。 |
| 日本产品质量 98年,我在香港富士通工作，试图在香港市场推富士通的服务器，富士通服务器跟美国太阳（SUN）匹配(Compatible)，但价位反比美国太阳服务器高，一直想不出什么原因。后来我去东京出差，发现原来日本公司，例如富士通，对质量特别有要求，产品测试设计等都要通过很多关卡，才可以出厂。有些富士通在澳大利亚的工程师就不明白为什么总公司要求这么苛刻，需要不断测试，觉得浪费资源。他们不清楚原来日本本土客户对质量要求特别高，无论是消费品或电子产品，如果达不到高水平质量要求，基本上卖不出去。富士通公司电子产品以满足本土市场为主，所以必须有很高的质量要求。 |
所以如果公司高层没有产品质量的要求，单靠团队学习根因分析技巧不会有改进效果。
结束语
根因分析包括下图各主要元素：
从上面案例，大家看到如能用好根因分析，应可帮助团队避免同类问题重复发生，帮团队提升。
但要真正做好根因分析不能单靠学理论与方法，必须利用实际数据让团队成员动脑筋和讨论，才能真正用好根因分析，取得效果。
下一章，我们探索针对软件开发如何利用根因分析做好过程改进。
附件
二八原则与数据分类
帕里托(Pareto) ，16世纪意大利威尼斯人，他发现虽然威尼斯很富有，但财富并非平均分布，80%财富在20%手里，他也发现很多其他分布都非平均。
因为过程改进需要公司额外的资源投入，必须有针对性地找出最容易取得改进效果的原因，才可能拥有最大的成功机会。所以，应该利用二八原则去识别影响最大的几个因素. 以上图为例，原本A类问题出现最多，针对这类问题做过程改进之后， A类问题就少了很多，下一轮便应针对最多的B类问题做改进。
有些人以为，只需要对某个维度做分析即可，并没有从多个维度进行分析。例如，某纸制产品工厂会计数据显示，8成的产品问题相关成本都归属于5类。
例如，某纸制产品工厂会计数据显示，因纸质量问题被客户退货类的损失最大，共5560千美元，占总损失的61%。针对这类损失，发现里面八成是由6个产品引起（共有53个产品），共4480千美元，占5560的 80%。针对这6个产品把损失按缺陷种类细分，发现B产品容易断裂缺陷(Tear)的占比最高，612千美元，我们就应该针对这一问题研究如何改善。
首页
课程
文章
电话咨询