执行过程中，想要降低偏差，减少返工，你就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制。
开环与闭环之间的关键差异，就在于有没有反馈环节，以及系统是否会根据反馈自动调节。
image.png
方案评审（OARP决策机制）
评审的核心：在于背后的决策机制。典型的决策机制叫做OARP。
OARP：Owner、Approver、Reviewer、Participant四个关键角色。
- 负责人（Owner）: 负责给出方案，组织各方讨论并推进作出最终的决定
- 批准者（Approver）: 最终批准者。
- 审核者（REviewer）: 负责人和批准者挑选出的审核人，审核者有责任对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复。
-
参与者（Participant）：其他提意见的人。
image.png
image.png
冒烟评审
做计划时明确定义完成标准，而冒烟测试用例，可以说是开发和测试之间最基础的合约。
BUG bash
专门找一个时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找bug，目的是从各个维度衡量和体验产品。可以从时间、地点、参与者、现场安排等维度去进行思考。
- 时间：全面功能测试完成后，趋于收敛的时间段开展。需求类的bug bash，可以用于需求或设计稿完成后举行。
- 地点：单独的会议室，大家集中精力做这一个事情。
- 参与者： 不同的角色人员，都需要参与到这场活动中来。
- 现场安排：现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新bug或建议的排名情况。
- 活动结束：直接公式Bug或建议数，现场给奖品，并发邮件通报全组。
