项目管理的五大过程组包括：
1）启动过程组。
2）规划过程组。
3）执行过程组。
4）监控过程组。
5）收尾过程组。
在项目执行的过程中，想要降低偏差、减少返工，就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制。三种最实用的方法如下：
1）方案评审（OARP 决策机制）。OARP 是 Owner、Approver、Reviewer、Participant 的缩写，分别对应四个关键角色：
1.负责人（Owner）：负责给出方案，组织各方讨论并推进做出最终的决定；
2.批准者 （Approver)：最终批准者；审核者（Reviewer）：负责人和批准者挑选出的审核人。
3.审核者有责任对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复；
4.参与者 （Participant）：其他提供意见的人。参与者会收到文档的相关信息，可以对相关问题做出反馈。
2）Bug Bash（Bug 大扫除）。需要从以下方面着手：
1.时间：测试类的 Bug Bash，你可以选择在全面功能测试结束后，Bug 趋于收敛的时间段开展；需求设计类的 Bug Bash，一般会放在需求或设计稿完成后举行。这个活动需要一到两个小时的时间，你一定要提前排除所有干扰；
2.地点：你需要设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力做这一件事。同时，作战室可以提供一些零食和饮料，让活动更有氛围；
3。参与者：除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群，都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角；
4.现场安排：你可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新 Bug 或建议的排名情况。需要注意的是，营造互动的氛围非常关键，如果因为空间受限，参与者做不到在同一地点进行，你至少也要在通信群中实时更新排名情况的变化。
5.活动结束：在活动结束后，要直接公示 Bug 或建议数，现场给奖品，并发邮件通报全组。最后，在对 Bug 进行去重后，还要分类定级，确定哪些是必须修，哪些是改了会更好。另外，千万不要忘记公示结果，明确修复计划。
3）冒烟用例评审。虽然“冒烟测试”这个概念很普遍，但是很多团队只是把它作为提测后的测试用例组，并没有真正发挥其合约的作用。要想避免掉进“差不多”的陷阱，在进入开发环节后，你需要安排专门的测试用例评审，让开发和测试对标准冒烟用例集达成约定，这个约定就会成为进入测试的准入标准。
此文章为4月Day27学习笔记，内容来源于极客时间《雷蓓蓓的项目管理实战课》
