项目风险和管理能力
Q: 我当时认为 “打包” 这一环应该没什么问题，毕竟项目文档上已经给出了打包接口人与排期，到时间直接找他要包就行。
A:包构建过程中发生了各种意外，出包时间延期几天不说，最后出的客户端包甚至无法正常登录，好几次在测试过程中才发现打包参数有误
结论： 作为 Owner。在项目开始前，你不仅每一个小步骤都要去确认清楚。落地执行时的所有的细节你也必须完全掌握。一旦有一个步骤出了差错，造成的后果都是非常严重的，即使这可能并不是你的过错…
Q:开始变得没那么好说话，变得会 “坦诚清晰” 地质疑别人。我问清楚细节后，觉得这件事情根本没有必要再去做，用现有的资源已经能够很好满足。
A:除非是写进 OKR 里的工作，踢皮球即可，不然最后坑的一定是自己。
如果说测试工作效果的话，我们一般会有这几个度量指标：
1、用例完整度 、评审通过率
2、系统测试期间缺陷率
3、功能测试按时完成率
3、上线缺陷率
但这些指标的完成度，又和项目各个阶段又有关系，同时也会对项目其他阶段的一些内容进行管控：
1、需求变更次数（改动较大，或当出现需求歧义时，产品无法快速理清的，推动干掉）
在研发需求分析期间，允许需求变更可能性会大一些，但只要进入开发阶段后，需求变更通过率我们会控制的很低。
2、研发计划（所有的测试时间，都会根据研发计划进行，要求其所有功能全部迭代陆续进行提测）
我们同时也会控制研发计划的变更
，开发同学只要产品找来说改东西，一般都会接受，但未考虑后续流程是否有影响 ，我们会拒绝所有开发自接的需求，所有需求必须走需求变更
3、功能提测（跟进并推进研发开发进度，确保研发能如期提测）
所有不能如期提测的功能，功能测试只能延后或者进行计划调整
4、缺陷修改周期（严格控制缺陷响应、修改时间，所有超出约定的时间后，测试会进行测试计划调整，项目计划变更）
5、风险控制（研发或测试进度出现严重风险）
周知项目，安排加班或砍需求，推进闭环。
加班可以加，但是项目需要知晓为什么加班解决了，
6、资源日历（人员工作量情况，人员分布 情况）
记录所有资源分布情况，当出现强加需求或者无法拒绝需求时，与大家一起调整资源日历
当然这样的话，测试做的事情会有些多，像以前团队就负责了需求管理、计划管理、进度管理、风险管理，最终上线日期其实也是测试根据各种计划给出的。（当然固定发版日项目，所有计划全部向上逆推）
若有收获，就点个赞吧
0 人点赞
