在互联网环境下，要弄清楚开发什么产品，准确把握并实现用户需求，对产品人员的要求其实非常高。对于互联网产品而言，从最初的一个想法，到确定规模化的增长模式，通常要经历很多轮的螺旋式迭代，不断调整。
由于前期对需求和设计没有严格把关，匆忙投入开发，导致开发的错乱与不合理。很多时候。我们没有办法一步到位，但合理试错，减少不必要浪费，仍然是可以做到的。在项目执行的过程中，想要降低偏差、减少返工，你就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制。 关键资源参与的可行性分析，前期系统、全局评估需求，开发后根据反馈调节。
在产品研发的整个过程中，到底有哪些实用的闭环验证方法呢？我来给你介绍三种最实用的方法。
方案评审（OARP 决策机制）
往往有些项目是从不做需求评审和设计评审的，产品人员找某位开发单方面讨论一下，需求就算定下来了，可以直接往下走了，这就是典型的开环系统。这忽略了系统、全局性，可能存在冲突隐患，后期风险提高。
要想执行中不走样，你就必须把方案评审做到位。 有人会觉得评审不就是大家凑一块开开会吗？不，评审的关键在于信息的公开共享，以及背后的决策机制。只有决策机制清晰，职责分工明确，方案评审才会有好的闭环效果。
OARP 是 Owner、Approver、Reviewer、Participant 的缩写，分别对应四个关键角色：
负责人（Owner）：负责给出方案，组织各方讨论并推进做出最终的决定；
批准者 （Approver)：最终批准者；
审核者（Reviewer）：负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复；
参与者 （Participant）：其他提供意见的人。参与者会收到文档的相关信息，可以对相关问题做出反馈。
这张流程图清晰地展示了一个典型的方案评审流程。OARP 是一套决策机制，你需要为项目中每一类方案的评审，确定明确的角色和职责，让各角色应享有的权利、应履行的职责，都得到规则上的保障，这样才能更好地确保方案质量，把后期的返工降到最低。（事前充分沟通，事后少返工）
Bug Bash（Bug 大扫除）
Bug Bash，也叫 Bug 大扫除，最初来自微软，是指在项目开发里程碑的末期（比如 Beta 版发布前），划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找 Bug，目的是从各个维度衡量和体验产品。（阶段性扫除bug,防止bug积压,bug的积压可能衍生更多bug，导致返工更加困难）
那么，想要组织一场 Bug Bash 活动，该从哪些方面入手呢？
时间：测试类的 Bug Bash，你可以选择在全面功能测试结束后，Bug 趋于收敛的时间段开展；需求设计类的 Bug Bash，一般会放在需求稿或设计稿完成后举行。这个活动需要一到两个小时的时间，你一定要提前排除所有干扰；
地点：你需要设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力做这一件事。同时，作战室可以提供一些零食和饮料，让活动更有氛围；参与者：除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群，都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角；
现场安排：你可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新 Bug 或建议的排名情况。需要注意的是，营造互动的氛围非常关键，如果因为空间受限，参与者做不到在同一个地点进行，你至少也要在通信群中实时更新排名情况的变化。
活动结束：在活动结束后，要直接公示 Bug 或建议数，现场给奖品，并发邮件通报全组。最后，在对 Bug 进行去重后，还要分类定级，确定哪些 Bug 是必须修的，哪些 Bug 是改了会更好的。另外，千万不要忘记公示结果，明确修复计划。
活动的组织，加入更多的游戏的玩法，最大程度调动团队成员热情，将问题更早发现。 对于计划越不详细的项目，bug bash的使用频率就会越高，越能提前发现问题，避免后期返工。问题越早解决成本越低
冒烟用例评审
虽然“冒烟测试”这个概念很普遍，但是很多团队只是把它作为提测后的测试用例组，并没有真正发挥其合约的作用。要想避免掉进“差不多”的陷阱，在进入开发环节后，你需要安排专门的测试用例评审，让开发和测试对标准的冒烟用例集达成约定，这个约定就会成为进入测试的准入标准。开发发起提测以后，测试人员就会依照这个标准用例集进行冒烟，并记录冒烟测试通过率，如果通过率不达标，就打回修正并再次提测。
如果你是在完全没有基础的团队中推行这个做法，可以先从测试人员记录冒烟测试通过率开始。接着，你要收集相关数据，和你的团队在回顾会上一起看看冒烟用例失败所导致的后期返工成本，讨论出一种更好的确保质量的做法。在我直接管理的项目中，冒烟通过率的要求通常是 100%，你可以选择从一个合适的起点开始，比如 80%，然后再一步步地逼近更好的提测质量。
冒烟用例，可以控制一定的比例，涵盖主要功能路径，一步一步来，前期重点在于培养开发自测习惯。