复盘会议，不是批斗大会，也不是吐槽大会，而是总结经验教训，学习成长，使未来的项目吸取本次的经验教训，更好的完成项目。
最近刚上线一个项目，需要准备下复盘，原来的复盘会议比较简单，一般都是项管组织相关方一起开个复盘会议，开始每个人自我陈诉，大概就是发表下每个人对项目期间的一些看法，问题的解决方案，项管记录会议纪要，会后统一发出来。其实大体来看没什么问题，但是一般情况下，很少有人提前准备，大家说的也都差不多，针对问题也没有一个可衡量的标准，慢慢的这种会议也就变为了吐槽大会，流于形式。
我认为每个人角色不同，职责不同，目标和衡量的标准也不同，比如：
项管比较关心需求优先级安排是否合理，资源是否合理，进度是否正常，是否实施整体变更控制等
产品比较关心需求文档是否清晰易懂（评审次数作为衡量标准），本期需求是否全部上线成功。
研发比较关心是否按时保质完成需求，提测及时率，通过率，生产BUG率等作为衡量标准
测试比较关心测试覆盖率，是否包含所有场景等
上面只是列举了大概内容，总体上来说不同职责的人都可以从范围，进度，成本，质量，资源，沟通，风险，采购，相关方等九个领域衡量。
回顾目标
作为研发，针对不同需求都大致有如下目标：
- 范围：开发完需求文档规定的范围内的功能，也可以包含一些非功能行需求，或者技术债的内容，比如内部代码优化，重构等。
- 进度：按照开发之前制定的进度计划执行。
- 质量：提测及时率90%以上，提测通过率90%,生产BUG数0
- 资源：本次计划投入的资源
在复盘开始前，可以先将相关资料准备齐全，例如：需求文档，排期计划，资源计划等。
评估结果
针对上述的目标，评估本次项目的结果
- 范围：完成情况，是否完成了目标中定义的所有功能，包含技术债的功能。
- 进度：进度是提前还是延迟，有无赶进度情况。
- 质量：及时率，通过率，生产BUG率等是多少
- 资源：有无新增或删减资源，是否富余或不足
在复盘开始前，可以将实际情况涉及的相关资料准备齐全，例如：实际完成的功能表，实际的进度表，开发中或者上线后，实际的BUG列表等。
分析原因
针对上述的目标和结果比较差异点，针对差异点分析原因，可以是好的，也可以是不好的，都需要分析，不能只关注不好的，而忽略好的，好的经验教训也需要分享出来。
多问几个为什么，答案自然就出来了。
总结经验
通过上述的分析，总结下本次项目中的经验教训，方便日后项目更顺利。
在写目标，结果，分析原因的时候能细致描述的就细致描述，不要太笼统，要拿事实说话，这样一次复盘下来才能让自己成长。
网友评论