title: 根因分析 author: Gamehu tags: [] categories:
1.当有问题出现时,往往根据现象再加上以往的经验或者直接拍出一个结论,这种情况在短期内的效果是可以的,但是从长期来看会掩盖掉很多底层的问题。结果就是问题该出还出,不仅没有提升团队的效率反而降低了团队的效率。
2.当问题出现时就代表甩锅以及互怼的开始,没有经过根因分析,上来先下个结论,开始界定责任,然后开始扯皮。
*(什么时间-什么地点-什么产品-什么人物-发生什么故障现象-造成什么影响)*
示例
时间:2019-09-02
地点:XX现场
产品:XX产品/XX版本
发现人:XX现场交付人员
故障现象描述:客服在正常登陆系统提单的时候报错,并且提交不了工单
【帮助】如有多个故障现象,应分别描述;
结果影响:系统XX时间不可用,导致客户非常不满,造成XXX损失
直接叙述工作过程,有问题的环节或阶段,什么人,做了什么事,当时是怎么考虑的,在这个动作后结果是什么。
*描述最终定位到的直接原因是什么。举个例子,比如某段代码编写存在XXX错误*
引入环节:
流出环节:
确定关键根因是什么:
如果有多个根因在逻辑层次上相同,则取关键的原因,根因应该是具体的、客观的、在目前组织能力下可被改进的。
【帮助】流程/制度方面:考虑组织管理上是否有合适的流程、指导书、管理Checklist;
组织因素方面:考虑人员分配、个人技能、培训、组织环境等原因;
执行方面:考虑计划、监控、沟通方面的原因。
| 根本原因 | 措施类型 | 措施内容 | 责任人 | 预定完成日期 |
|---|---|---|---|---|
| 技术根因: 例如,XX特性,在大规格、灵活配置等方面需求设计不充分 | 纠正措施 | 例如:对XX特性组织进行重新设计,刷新XX方案 | 2018/11/1 | |
| 预防措施 | 例如:更新××技术规范、工具、checklist等等 | |||
| *管理根因:*组织管理、流程方面的原因,比如xx,没有按照流程,但是最终还是交付了。 | 纠正措施 | |||
| 预防措施 |
上诉的内容,关键还是在于给一个框架,让问题发生人,根据框架的引导,能比较深刻的挖掘出问题的根因,按此框架填写后,往往会伴随着评审,最终判断分析的彻底性以及合理性。
当然这只是一种方式,一段时间实践下来,其实是有助于减少问题发生率以及增加个人问题的处理成本从而倒逼相关人员注意到质量的重要性。
本文引用的内容,如有侵权请联系我删除,给您带来的不便我很抱歉。