一个完整产品的输出,离不开产品、设计、开发、测试的共同努力。
产品质量的好坏,也与各个环节的交付质量密切相关。
2020,为了更优质的产品,在这里提出一个“产品质量委员会”的概念。涉及到多个团队,希望能与大家一起探讨其可行性及可靠性。
请多多提意见~
Category | Description | Comments |
参与成员 | XX、XX、XX、XX、XX | 产品、设计、开发、测试各团队责任人 |
工作内容 | 当线上出现事故时,产品质量委员会需要进行事故分析。 | 事后分析报告案例参考 |
工作流程 | 1、线上出现事故,各团队优先配合解决问题; 2、事故解决后,由QA写事后分析报告Wiki,并@事故直接相关人员补充细节; 3、委员会成员详细阅读该报告,重点关注”事故描述“和”方案改进“; 4、委员会成员对该报告进行确认: 若不存在异议,勾选”确认,不存在异议“; 若存在异议,勾选”存在异议“,并在Comments中详述异议; 5、根据异议内容,委员会以会议形式展开讨论,并得出一致结论; 6、针对报告中提出的改进方案,督促相关成员完成。 | |
Q&A | 1、什么级别的问题是事故? | 根据损失金额、影响用户数、是否需要hotfix、恢复时间等多个维度考量 |
| 2、什么时候需要委员会开会讨论? | 对本次事故的事后分析报告内容存在异议(如责任占比、事故定级等)时,可以发起会议讨论。 |
| 3、为什么事后分析报告由QA来写? | 事后分析报告应由事故主要责任人来写。 当前阶段,由于出现事故时QA一定要关注,且目前Kion写过事后分析报告的人不多,所以暂由QA来写。 希望今后每个人都有事后分析的能力,都能主导事后分析。 |
| 4、产品质量委员会,只在出现线上事故时起作用吗? | 不。 但就当前而言,委员会成立之初,主要是参与线上事故的事后分析。如果该模式可行,今后可以有更多的探索。 |
| 5、只有线上事故,才需要做事后分析吗? | 不。 事实上,我认为造成影响大的、多团队配合引起的问题等,都可以做事后分析。 事后分析是为了划分责任和寻找规避方案。划分责任重要,可以让相关人员为此事负责,提升责任感;但划分责任又不是最主要的,最主要的是为了能共同寻找规避方案。 |
【参考模板】
写该报告的意义在于反思,避免下次再发生同类型的事情。 |
一、事故描述
影响时间 | 20xx-xx-xx xx:xx ~ 20xx-xx-xx xx:xx |
跟进人 | ( 解决该事故的直接参与人 ) |
责任部门 | ( 造成该事故的相关部门 ) |
事故简述 | ( 简述事故结果 ) |
影响和损失 | ( 影响了多少用户、造成了多少损失等 ) |
事故定级 | ( 暂不定级。目前事故定级标准不够规范,流程不够完善,暂不具备定级条件。且解决问题才是最终目的) |
二、事故详情
时间 | 动作人、动作、结果 |
20xx-xx-xx xx:xx |
|
20xx-xx-xx xx:xx |
|
20xx-xx-xx xx:xx |
|
20xx-xx-xx xx:xx |
|
三、原因分析
原因追查 | 回答 |
事故的直接原因是什么? | |
为什么会出现上述问题? |
|
产品环节是否有问题? | |
教研环节是否有问题? | |
设计环节是否有问题? | |
开发环节是否有问题? | |
测试环节是否有问题? | |
运营环节是否有问题? | |
今后如何避免此问题再次出现? |
|
四、方案改进
任务描述(可附Task链接) | 跟进人 | 预期完成时间 |
短期方案:(两周内) 中期方案:(两周以上-三个月) 长期方案:(三个月以上) 不用过于纠结时间,仅供大致参考。 |
|
|
|
| |
|
| |
五、产品质量委员会确认
部门 | 确认状态 | Comments |
产品 |
|
|
| ||
设计 |
| |
开发 |
| |
测试 |
|
|