根因分析

发表于 更新于 分类于

最近研发老大牵头组织了异常关于根因分析的讨论，目的在于让大家学会做根因分析，因为往往大家都是直接下结论（给答案），既容易发生矛盾也同时也没有解决根本问题。

现状

1.当有问题出现时，往往根据现象再加上以往的经验或者直接拍出一个结论，这种情况在短期内的效果是可以的，但是从长期来看会掩盖掉很多底层的问题。结果就是问题该出还出，不仅没有提升团队的效率反而降低了团队的效率。

2.当问题出现时就代表甩锅以及互怼的开始，没有经过根因分析，上来先下个结论，开始界定责任，然后开始扯皮。

根因分析

问题描述

（什么时间*-什么地点-什么产品-什么人物-发生什么故障现象-*造成什么影响）

示例

1
2
3
4
5
6
7
时间：2019-09-02
地点：XX现场
产品：XX产品/XX版本
发现人：XX现场交付人员
故障现象描述：客服在正常登陆系统提单的时候报错，并且提交不了工单
【帮助】如有多个故障现象，应分别描述；
结果影响：系统XX时间不可用，导致客户非常不满，造成XXX损失
过程还原

直接叙述工作过程，有问题的环节或阶段，什么人，做了什么事，当时是怎么考虑的，在这个动作后结果是什么。

问题定位

描述最终定位到的直接原因是什么。举个例子，比如某段代码编写存在XXX错误

技术根因分析

引入环节：

  1. 产品设计是否有问题？
  2. 需求分析是否有问题？
  3. 设计环节是否有问题？
  4. 代码编写是否有问题？
  5. 其他

流出环节：

  1. 各评审环节是否有遗漏？
  2. 是否进行研发自测？
  3. 测试场景、测试用例是否覆盖全？
  4. 是否进行了系统测试？
  5. 其他？

确定关键根因是什么：

如果有多个根因在逻辑层次上相同，则取关键的原因，根因应该是具体的、客观的、在目前组织能力下可被改进的。

管理根因分析
  • 流程/制度原因：
  • 组织因素：
  • 执行原因：

【帮助】流程/制度方面：考虑组织管理上是否有合适的流程、指导书、管理Checklist；

组织因素方面：考虑人员分配、个人技能、培训、组织环境等原因；

执行方面：考虑计划、监控、沟通方面的原因。

纠正、预防措施
根本原因 措施类型 措施内容 责任人 预定完成日期
技术根因： 例如，XX特性，在大规格、灵活配置等方面需求设计不充分 纠正措施 例如：对XX特性组织进行重新设计，刷新XX方案 2018/11/1
预防措施 例如：更新××技术规范、工具、checklist等等
管理根因：组织管理、流程方面的原因，比如xx，没有按照流程，但是最终还是交付了。 纠正措施
预防措施

小结

上诉的内容，关键还是在于给一个框架，让问题发生人，根据框架的引导，能比较深刻的挖掘出问题的根因，按此框架填写后，往往会伴随着评审，最终判断分析的彻底性以及合理性。

当然这只是一种方式，一段时间实践下来，其实是有助于减少问题发生率以及增加个人问题的处理成本从而倒逼相关人员注意到质量的重要性。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。