四个小步骤,教你怎么做事故分析
- 2018-03-13 17:16:00
- 文小刀 原创
- 4006
阅读已有材料,提取重要因子
什么叫做”已有材料“?
开项目例会的时候,团队成员口头汇报的材料;
运维监控系统发出的事故警报短信;
项目组员处理事故的来往邮件;
外部人员的投诉邮件;
项目的需求文件,系统的设计文件;
…………
在小刀所在的公司,以上材料里面最先接触到的,是“事故警报短信”,一般发生事故的时候会提示是:XXXX时间点,XX系统的XX业务,发生了XXXX事件,现已通知某某某处理……
事故处理结束后会提示”XXXX时间点,XX系统XX业务上发生的XXXX时间,已经由某某某理完毕,恢复正常“。
那么在这组短信里面,我们就可以获取到发生事故的“系统和业务”“处理人”和“事故概述”这三大要素。
然后再结合其他几项:项目例会的交流、事故处理的来往邮件、项目的文件资料,可以稍微的对发生事故的业务内容以及事件经过有一个大概的概念。
这个概念的清晰程度,取决于QA融入项目的深度。
融入得越深,对事故的第一印象也就会越发清晰;
如果比较游离于项目工作之外,那么这个概念就会相对而言比较淡薄。
采访会谈,听听各方的描述
所谓的采访会谈,指的是需要跟各环节人员的进行面对面的沟通了解。
为什么是“各环节“而不是”就近原则“
什么叫做“就近”:QA工作日常密切联系的项目组的开发+测试+运维,而业务端的客服、运营等人员,是相对而言较“远”的。
那么在做采访会谈的时候,如果只跟“近处”的技术人员了解,那么我们很有可能也就只能了解到“系统上出了什么问题”,而不是“整个事件出了什么问题”。
所谓的“面对面”,指的是尽量当面谈。
带上笔、笔记本、笔记本电脑,而不是通过QQ/RTX/微信的谈。
这样才能够保证面谈的双方人员是专注在这件事,而不至于被其他工作打断节奏。
而且,面对面的对话,更能让对方回忆起“细节”。
记录有用信息
在面谈的过程中,尽量按照”先大后小“的顺序去记录事件。
也就是说,先记下事件的大要素”XX时间点,发生了XXXX事件,然后XXX去处理“。
然后再针对大要素去展开小要素。
所需要考虑的大小要素,我们可以参考学生时代“叙述文的六要素”来规划
(以上图中的列出点,仅仅是小刀所在部门经常涉及的因素,并不可能全面覆盖所有场景)
其中做了标记的点需要特别留意。
绿色对号: 这些是重点,在采访的过程中,一定要反复落实以保证其可靠性和真实性。
必要的时候,可以针对某一个细节反复采访不同岗位方向的相关人员,多方求证,才能力保它的真实性。
橙色叹号: 如果对此项内容没有要求,就一定不要去提及;如果有要求,在拟文的时候,一定要跟对应部门(比如人力资源部、行政管理部、财务部、法律事务部等)的人员落实其具体的数据、范围等。
因为这是容易引发劳务纠纷的点,要慎重再慎重。
整理材料,输出定稿文档
在第三步结束之后,我们收集到了很多有用的材料,但是这些材料还只是记在笔记本或者电脑上的零散片段,并没有形成一个完成的报告,而小刀所在的公司,是要求每个季度做分析会的,那么就需要将以上材料整理成正式的文档格式。
Word文件
用以向部门领导及公司管理层汇报事故过程。
那么在写文件的过程中,需要注意汇报的对象层次不同,关注的点不同:
部门领导可能会关注事故的技术因素,处理的过程,花了多少时间,有没有反复处理还有问题的;
而公司管理层则可能更关注事件的影响程度,如何避免以后再次出现的计划。
PPT稿件
用以向部门做分析会展示课件——毕竟,开会的时候,不可能把一份好多页的Word文字版内容投影给大家看吧。
那么这个,就很考验QA的课件制作水平啦。
做事故分析的过程,大概就是包括这几步啦,各位小伙伴你们有没有类似的经验,可以给我留言,互相学习哦~~~~
下一章,小刀将跟大家继续聊聊,做事故分析的时候,QA应该具备哪些技能或者说素质要求?如果你有什么想说的,也欢迎留言哦~~~~
本站文章以及相关内容除注明 转贴外,均为本站 原创或 翻译。
如果本站转载的文章涉嫌侵犯了您的权益,请在评论区留言或是邮件联系管理员及时删除 【admin@luckyframe.cn】
本站原创或是翻译的文章欢迎任何形式转载,但请务必 注明出处以及链接,尊重他人劳动成果,拒绝剽窃从你做起。