产品质量委员会+事后分析

一个完整产品的输出，离不开产品、设计、开发、测试的共同努力。

产品质量的好坏，也与各个环节的交付质量密切相关。

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
产品	确认，不存在异议 存在异议
设计	确认，不存在异议 存在异议
开发	确认，不存在异议 存在异议
测试	确认，不存在异议 存在异议