不知道你是否经历过这样的场景：你的团队历经⼀个多⽉没⽇没夜的奋⽃ ，终于在圣诞节采购季来临前 ，完 成了“⿊五购物节”活动的所有功能 ，全部测试完毕 ，⻢上就要上线了。结果 ，产品负责⼈试⽤之后 ，皱着 眉头说：“这……不是我想要的！” 你说 ，还有⽐这更悲惨的吗？
实际上 ，这种现象并不少⻅ ，有些产品经理还美其名⽈ “允许试错”。 可是 ，最后做完了才发现不是⾃⼰想 要的 ，早⼲吗去了呢？！
之所以会出现这种情况 ，有很多潜在的原因。 ⽐如 ，在互联⽹环境下 ，要弄清楚开发什么产品 ，准确把握并 实现⽤⼾需求 ，对产品⼈员的要求其实⾮常⾼ 。对于互联⽹产品⽽⾔ ，从最初的⼀个想法 ，到确定规模化的 增⻓模式 ，通常要经历很多轮的螺旋式迭代 ，不断调整。
除了这个原因之外 ，更为常⻅的情况是 ，需求和设计根本没有经过严格的把关 ，就匆忙投⼊开发； 同时 ，在 传统的研发中间过程中 ，很难看到串连起来的功能效果 ，产品经理必须等到快上线了 ，才能看到和真实体验 到可完整运⾏的产品。但是这个时候 ，再想⼤幅度修改产品 ，代价已经⾮常⾼了。
很多时候 ，我们确实没有办法⼀步到位 ，但合理试错 ，减少不必要的浪费 ，仍然是可以做到的。在项⽬执⾏ 的过程中 ，想要降低偏差、减少返⼯ ，你就需要构建系统能⼒，在产品研发的整个过程中，建⽴起真正闭环反馈的产品验证机制。
说到这⾥ ，我想先提⼀下 ，到底什么才是真正的闭环。我是学控制⼯程出⾝的 ，⼤学教科书⾥的⼀张展⽰开 环和闭环系统的经典图⽚让我印象⾮常深刻。看了这张图 ，你就会明⽩ ，其实 ，开环与闭环之间的关键差异 ，就在于有没有反馈环节 ，以及系统是否会根据反馈⾃动调节。
那么 ，既然闭环如此重要 ，在产品研发的整个过程中 ，到底有哪些实⽤的闭环验证⽅法呢？ 我来给你介绍三 种最实⽤的⽅法。
⽅案评审（OARP决策机制）
其实 ，需求评审、交互评审、视觉评审都是⾮常基本的闭环验证⽅法。我在留⾔区了解到 ，有些项⽬是从来 不做需求评审和设计评审的 ，产品⼈员找某位开发单⽅⾯讨论⼀下 ，需求就算定下来了 ，可以直接往下⾛
了 ，这就是典型的开环系统。
还记得我在刚开始举的“⿊五购物节” 的例⼦吗？ 那次返⼯ ，不仅让团队⼀个多⽉的⾟苦打了⽔漂 ，还错过 了最⻩⾦的购物节时间。不得不说 ，这样的开环系统 ，在上线后出现偏差是很正常的 ，因为在这个过程中 ， 根本没有任何矫正的机会。
要想执⾏中不⾛样 ，你就必须把⽅案评审做到位。
⽽⼀说到评审 ，很多⼈会说 ，不就是组织⼀个会吗？ ⼤家 就是坐在⼀起看⼀看 ，流于形式。 No！你需要理解的是 ，评审的精髓不在会，⽽在于背后的决策机制。 只 有决策机制清晰 ，职责分⼯明确 ，⽅案评审才会有好的闭环效果。我来给你介绍⼀个典型的决策机制 ，叫作 OARP。
OARP是Owner、Approver、 Reviewer、 Participant的缩写 ，分别对应四个关键⻆⾊：
负责⼈（Owner） ：负责给出⽅案 ，组织各⽅讨论并推进做出最终的决定； 批准者 （Approver)：最终批准者；
审核者（Reviewer） ：负责⼈和批准者挑选出的审核⼈。 审核者有责任对⽂档进⾏讨论分析 ，并提出反 馈意⻅ ，负责⼈必须重视并给予回复；
参与者 （Participant） ：其他提供意⻅的⼈。 参与者会收到⽂档的相关信息 ，可以对相关问题做出反 馈。
这张流程图清晰地展⽰了⼀个典型的⽅案评审流程。 OARP是⼀套决策机制 ，你需要为项⽬中每⼀类⽅案的 评审 ，确定明确的⻆⾊和职责 ，让各⻆⾊应享有的权利、应履⾏的职责 ，都得到规则上的保障 ，这样才能更 好地确保⽅案质量 ，把后期的返⼯降到最低。
我把项⽬中常⻅⽂档所对应的OARP⻆⾊汇总在了下⾯这张表格⾥ ，你可以参考⼀下。
Bug Bash（Bug⼤扫除）
Bug Bash ，也叫Bug⼤扫除 ，最初来⾃微软 ，是指在项⽬开发⾥程碑的末期（⽐如Beta版发布前） ，划出 ⼀个专⻔的时间段 ，在这期间 ，所有参与项⽬的⼈员 ，集中全部精⼒⼀起来给项⽬找Bug ，⽬的是从各个维 度衡量和体验产品。
这是⼀个⾮常有意思的活动 ，在⽹易也很受欢迎 ，在反复的实战应⽤中 ，我们对Bug Bash做了很多的改
良 ，产⽣了很多有趣的变种。 除了应⽤于测试阶段 ，我们发现 ，Bug Bash还是进⾏产品闭环验证的⼀个⾮ 常有效的⽅法。通常 ，在版本的需求稿和交互稿完成之后 ，我会专⻔安排⼀段时间 ，组织团队成员⼀起 ，集 中精⼒给需求稿和设计稿找问题。
记得我第⼀次组织这样的活动时 ，程序员们开⼼坏了！ 因为 ，他们终于可以让策划和设计们 ，也尝尝修Bug 的滋味了！ 曾经 ，在⼀次活动的需求设计Bug Bash上 ，运营同学发现了现有产品的逻辑错误 ，避免了上线 后优惠券发放的漏洞 ，为我们提前规避了很⼤的损失。通过这些Bug Bash活动 ，我们把产品验证环节⼤⼤ 地提前了,不仅达到了更好的体验效果 ，还有效地保障了上线质量。
那么 ，想要组织⼀场Bug Bash活动 ，该从哪些⽅⾯⼊⼿呢？
1. 时间：测试类的Bug Bash ，你可以选择在全⾯功能测试结束后 ，Bug趋于收敛的时间段开展；需求设计 类的Bug Bash ，⼀般会放在需求稿或设计稿完成后举⾏ 。这个活动需要⼀到两个⼩时的时间 ，你⼀定要 提前排除所有⼲扰；
2. 地点：你需要设⽴⼀个单独的作战室 ，⿎励参与者⾃带笔记本 ，让他们尽可能集中精⼒做这⼀件事。 同 时 ，作战室可以提供⼀些零⻝和饮料 ，让活动更有氛围；
3. 参与者： 除了研发和测试 ，产品、设计、市场、运营、销售等项⽬组不同⻆⾊的⼈群 ，都需要参与到这 场活动中 ，这样你就可以获得更加丰富多维的视⻆；
4. 现场安排：你可以把现场反馈的问题直接贴在⽩板上 ，或者通过电⼦⽩板 ，来滚动更新Bug或建议的排名 情况。 需要注意的是 ，营造互动的氛围⾮常关键 ，如果因为空间受限 ，参与者做不到在同⼀个地点进
⾏ ，你⾄少也要在通信群中实时更新排名情况的变化。
5. 活动结束：在活动结束后 ，要直接公⽰Bug或建议数 ，现场给奖品 ，并发邮件通报全组。最后 ，在对Bug 进⾏去重后 ，还要分类定级 ，确定哪些Bug是必须修的 ，哪些Bug是改了会更好的。另外 ，千万不要忘记 公⽰结果 ，明确修复计划。
关于活动的组织⽅式 ，你可以加⼊更多游戏化的玩法 ，这些都是为了最⼤程度地调动团队成员的参与热情， 让问题在早期得到更好地暴露。你可以在⼀些重要版本中尝试这样的⽅法 ，与很多低效冗⻓的评审会相⽐， 这个活动在避免返⼯⽅⾯ ，会有⾮常好的实战效果。
实际上 ，有时候 ，视觉稿我们也会拿出来这么做。 曾经 ，某个已经运营了三四年的重量级产品 ，要在⼀个⽉ 之内完成全⽹的视觉改版 ，⼯作量巨⼤到难以想象 ，寻常做法很容易出问题 ，影响最终的⽤⼾体验。但时间 ⾮常紧张 ，我们根本来不及全部定稿 ，就必须开始并⾏开发 ，怎么办呢？
当时我就想到了Bug Bash ，不过这回不是做⼀次 ，⽽是每天都做！我们把计划拆分到按天交付的颗粒度，
每天晚饭后的半个⼩时 ，⼤家会聚在⼀起 ，给刚刚做好的视觉稿找Bug。开发和测试⼈员的早期参与 ，让很 多遗漏的视觉问题在早期就得以发现 ，避免了后期的很多返⼯ 。后来 ，这个视觉改版⾮常顺利地上线了！
让我没想到的是 ，在项⽬组的回顾会上 ，每天晚上的Bug Bash活动 ，竟然⾼票当选最受欢迎的团队活动。 仔细想想 ，Bug Bash也是⾮常好的团建活动 ，我⾄今都很怀念那段虽然⽆⽐⾟苦 ，但有吃有喝、充满欢笑 的“⾰命岁⽉ ”。
冒烟⽤例评审
有同学留⾔问我说 ，当程序员说完成了某个模块的开发⼯作时 ，项⽬管理⼈员怎么知道100%完成了呢？ 其 实 ，项⽬经理最怕听到的⼀个词 ，就是“差不多”。 ⽐如 ，差不多写完了 ，差不多测好了 ，差不多可以发布 了……每项⼯作都是差不多 ，可是⼀到测试环节 ，就会发现 ，其实还差得很远呢。
在上⼀讲中 ，我提到 ，做计划时要明确定义完成标准 ，⽽冒烟测试⽤例 ，可以说是开发和测试之间最基础的 合约。
虽然“ 冒烟测试”这个概念很普遍 ，但是很多团队只是把它作为提测后的测试⽤例组 ，并没有真正发挥其合 约的作⽤ 。 要想避免掉进“差不多” 的陷阱 ，在进⼊开发环节后 ，你需要安排专⻔的测试⽤例评审 ，让开发 和测试对标准的冒烟⽤例集达成约定 ，这个约定就会成为进⼊测试的准⼊标准。
开发发起提测以后 ，测试⼈员就会依照这个标准⽤例集进⾏冒烟 ，并记录冒烟测试通过率 ，如果通过率不达 标 ，就打回修正并再次提测。
如果你是在完全没有基础的团队中推⾏这个做法 ，可以先从测试⼈员记录冒烟测试通过率开始。接着 ，你要 收集相关数据 ，和你的团队在回顾会上⼀起看看冒烟⽤例失败所导致的后期返⼯成本 ，讨论出⼀种更好的确 保质量的做法。在我直接管理的项⽬中 ，冒烟通过率的要求通常是100% ，你可以选择从⼀个合适的起点开 始 ，⽐如80% ，然后再⼀步步地逼近更好的提测质量。
总结
总结⼀下 ，今天 ，我给你介绍了在项⽬执⾏过程中 ，有效降低偏差、避免返⼯的三种闭环验证⽅法 ，包括⽅ 案评审、 Bug Bash（Bug⼤扫除） ，以及冒烟测试⽤例评审。
其实说到底 ，这些⽅法都是为了保证执⾏过程不⾛样。 需要注意的是 ，你并不需要在每⼀个版本中把这些⽅ 法全都⽤上。你可以结合⾃⼰的项⽬情况 ，有步骤地开展优化 ，在核⼼的输出环节 ，设置合适的断点和关⼝ ，这样就能更好地把控全局了！
