06 执行：三种闭环验证方法，保证执行不走样
你好，我是雷蓓蓓。今天我要跟你分享的主题是：打造品质，要从头开始“闭环”。在正式开讲之前，我想先和你分享一个小故事。
学习场景：“这……不是我想要的！”
这天，我在公司走廊上碰到了面如死灰的艾文。
蓓蓓：“怎么感觉你今天双眼无神，发生什么事了？”
艾文：“太惨了。我们团队一个多月没日没夜，可算是在618来临前，完成了购物节活动的所有功能，全部测试完毕，马上就要上线了。结果，刚刚产品负责人试用之后，皱着眉头说：“这……不是我想要的！” 你说，还有比我更惨的吗？他们早干吗去了呢？！”
蓓蓓：“是啊，为什么总是要最后做完了，才发现不是自己想要的呢？其实，这种现象并不少见，有些产品经理还美其名曰“允许试错”。但试错到最后，就发现付出的成本太高了。那么今天，我就来和你聊聊“执行”这件事，帮助你解决这个问题。”
之所以会出现这种情况，有很多潜在的原因。比如，在互联网环境下，要弄清楚开发什么产品，准确把握并实现用户需求，对产品人员的要求其实非常高。对于互联网产品而言，从最初的一个想法，到确定规模化的增长模式，通常要经历很多轮的螺旋式迭代，不断调整。
除了这个原因之外，更为常见的情况是，需求和设计根本没有经过严格的把关，就匆忙投入开发；同时，在传统的研发中间过程中，很难看到串连起来的功能效果，产品经理必须等到快上线了，才能看到和真实体验到可完整运行的产品。但是这个时候，再想大幅修改产品，代价已经非常高了。
很多时候，我们确实没有办法一步到位，但合理试错，减少不必要的浪费，仍然是可以做到的。在项目执行的过程中，想要降低偏差、减少返工，你就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制。
说到这里，我想先提一下，到底什么才是真正的闭环。我是学控制工程出身的，大学教科书里的一张展示开环和闭环系统的经典图片让我印象非常深刻。看了这张图，你就会明白，其实，开环与闭环之间的关键差异，就在于有没有反馈环节，以及系统是否会根据反馈自动调节。
那么，既然闭环如此重要，在产品研发的整个过程中，到底有哪些实用的闭环验证方法呢？我来给你介绍三种最实用的方法。
方案评审（OARP决策机制）
其实，需求评审、交互评审、视觉评审都是非常基本的闭环验证方法。我在留言区了解到，有些项目是从来不做需求评审和设计评审的，产品人员找某位开发单方面讨论一下，需求就算定下来了，可以直接往下走了，这就是典型的开环系统。
还记得我在刚开始举的“618购物节”的例子吗？那次返工，不仅让团队一个多月的辛苦打了水漂，还错过了最黄金的购物节时间。不得不说，这样的开环系统，在上线后出现偏差是很正常的，因为在这个过程中，根本没有任何矫正的机会。
要想执行中不走样，你就必须把方案评审做到位。而一说到评审，很多人会说，不就是组织一个会吗？大家就是坐在一起看一看，流于形式。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活动，该从哪些方面着手呢？
- 时间：测试类的Bug Bash，你可以选择在全面功能测试结束后，Bug趋于收敛的时间段开展；需求设计类的Bug Bash，一般会放在需求或设计稿完成后举行。这个活动需要一到两个小时的时间，你一定要提前排除所有干扰；
- 地点：你需要设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力做这一件事。同时，作战室可以提供一些零食和饮料，让活动更有氛围；
- 参与者：除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群，都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角；
- 现场安排：你可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新Bug或建议的排名情况。需要注意的是，营造互动的氛围非常关键，如果因为空间受限，参与者做不到在同一地点进行，你至少也要在通信群中实时更新排名情况的变化。
- 活动结束：在活动结束后，要直接公示Bug或建议数，现场给奖品，并发邮件通报全组。最后，在对Bug进行去重后，还要分类定级，确定哪些是必须修，哪些是改了会更好。另外，千万不要忘记公示结果，明确修复计划。
关于活动的组织方式，你可以加入更多游戏化的玩法，这些都是为了最大程度地调动团队成员的参与热情，让问题在早期得到更好地暴露。你可以在一些重要版本中尝试这样的方法，与很多低效冗长的评审会相比，这个活动在避免返工方面，会有非常好的实战效果。
实际上，有时候，视觉稿我们也会拿出来这么做。曾经，某个已经运营了三四年的重量级产品，要在一个月之内完成全网视觉改版，工作量巨大到难以想象，寻常做法很容易出问题，影响最终的用户体验。但时间非常紧张，我们根本来不及全部定稿，就必须开始并行开发，怎么办呢？
当时我就想到了Bug Bash，不过这回不是做一次，而是每天都做！我们把计划拆分到按天交付的颗粒度，每天晚饭后半个小时，大家会聚在一起，给刚刚做好的视觉稿找Bug。开发和测试人员的早期参与，让很多遗漏的视觉问题在早期就得以发现，避免了后期的很多返工。后来，这个视觉改版非常顺利地上线了！
让我没想到的是，在项目组的回顾会上，每天晚上的Bug Bash活动，竟然高票当选成为了最受欢迎的团队活动。仔细想想，Bug Bash也是非常好的团建活动，我至今都很怀念那段虽然无比辛苦，但有吃有喝、充满欢笑的“革命岁月”。
冒烟用例评审
有同学留言问我说，当项目成员说完成了某个模块的工作时，项目管理人员怎么知道100%完成了呢？其实，项目经理最怕听到的一个词，就是“差不多”，比如，差不多写完了，差不多测好了，差不多可以发布了……每项工作都是差不多，可是一到测试环节，就会发现，其实还差得很远呢。
在上一讲中，我提到，做计划时要明确定义完成标准，而冒烟测试用例，可以说是开发和测试之间最基础的合约。
虽然“冒烟测试”这个概念很普遍，但是很多团队只是把它作为提测后的测试用例组，并没有真正发挥其合约的作用。要想避免掉进“差不多”的陷阱，在进入开发环节后，你需要安排专门的测试用例评审，让开发和测试对标准冒烟用例集达成约定，这个约定就会成为进入测试的准入标准。
开发发起提测以后，测试人员就会依照这个标准用例集进行冒烟，并记录冒烟测试通过率，如果通过率不达标，就打回修正并再次提测。
如果你是在完全没有基础的团队中推行这个做法，可以先从测试人员记录冒烟测试通过率开始。接着，你要收集相关数据，和你的团队在回顾会上一起看看冒烟用例失败所导致的后期返工成本，讨论出一种更好的确保质量的做法。在我直接管理的项目中，冒烟通过率的要求通常是100%，你可以选择从一个合适的起点开始，比如80%，然后再一步步逼近更好的提测质量。
总结
总结一下，今天，我给你介绍了在项目执行过程中，有效降低偏差、避免返工的三种闭环验证方法，包括方案评审及OARP决策机制，Bug Bash（Bug大扫除）、以及冒烟测试用例评审。
其实说到底，这些方法都是为了保证执行过程不走样。需要注意的是，你并不需要在每一个版本中，把这些方法全都用上。你可以结合自己的项目情况，有步骤地开展优化，在核心的输出环节，设置合适的断点和关口，这样就能更好地把控全局了！
畅所欲言
这一讲中，我跟你分享的，都是我们自己在实战中积累下来的闭环验证方法。只有到了执行时，你才会发现，理想有多丰满，现实就有多骨感。我想请你来聊一聊，你在项目执行过程中踩过的最痛的“坑”。如果你可以再分享一些你的“爬坑指南”，那就更好了。
欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
- X.J👸 👍（97） 💬（4）
蓓蓓姐，问个私人问题，作为一个女孩子，你每天作息怎么安排，能做好网易项目经理工作，还能写书，备课，你怎样激励自己的。非常感谢🙏
2019-12-20 - 看山 👍（81） 💬（10）
1 产品说：这个功能很简单，就和xxx一样。（简单你来写啊） 2 上面这还不是最恶心的，最恶心是是你问他xxx的逻辑是什么的时候，他只能大体说出来，细节都不知道，细节得自己看代码。（你连细节都不知道，怎么说和xxx一样，谁给你的勇气） 3 产品说：这个是业务提的，拉个群你问问，技术的东西我不懂。（如果我没记错，产品是根据业务需求进行抽象延伸实现产品化的过程，难道你这个产品是看了《人人都是产品经理》就来了？再说了，我只想听到清晰的表达，不需要你懂技术） 4 业务说：这属于技术问题，我不懂。（1+1=2我觉得不属于技术范围，属于义务教育或者脑科医生的范围。） 5 业务说：怎么又出问题了，还会不会有问题？（会，肯定会，原来75个bug，修复完这个应该会变成90个bug） 6 业务在验收上线之后说：我还以为是xxx呢，变成xxx需要多久？（我手里还有你的验收单呢，刚验收完就不认账啦） 5 产品和业务一起说：因为时间很紧，咱们倒排期，大家有什么困难都提一下，保证项目顺利上线。（没别的困难，就是时间太紧，要不您老再多给点时间） 6 产品和业务一起说：你们（指开发）说我们该干什么，我们看你们这么累，想帮你们，但又不知道怎么帮，技术的东西我们也不懂。（少挖坑，谢谢） 9 开发说：差不多写完了（差不多是多少，85%还是99%？最后的1%不会卡住吧） 10 开发说：写完了，提测吧，出了问题我再改。（你也太不负责了吧，还会出问题叫写完了？） 11 欢迎补充。。。
2019-11-16 - 有心猴 👍（38） 💬（7）
最坑的就是工期倒推,产品的东西你可以评审,评审不合格就改,可是占用的都是开发的时间,最终结果是产品文档改的合格了,工期到了,是开发没有完成.
2019-11-11 - Ios王子 👍（13） 💬（1）
最后说的冒烟测试没看明白是什么
2019-11-20 - Gechmind 👍（11） 💬（4）
冒烟用例，我们公司也进行评审了，其中一个难点就是：用例过多，进行评审的时候很费劲，开发人员参与感不强，且非常抱怨浪费时间；开发完成后进行提测，测试人员反馈的冒烟通过率很低，原因是没有做自测，要求提测后，开发又抱怨用例多，造数据废时，然后就会提出造数据由测试来提供，这就会占用测试的时间，引起测试的反感
2020-02-12 - 穷查理 👍（5） 💬（1）
周末下午，阳光明媚，怀孕五个多月的老婆在旁边床上睡觉，睡的很安详。看了一眼老婆熟睡的胖胖的脸，能给她带来这份安详，我感觉很欣慰。 盯着电脑思考了这个问题一个多小时。想了写，写了又删，删了又想，想到了项目中的很多坑，以及迈过一个个坑痛苦的过程，同时也想到了大领导跟我说的一句话（他说：因为我们不专业）， 不知道为何，想到他这句话心里突然酸了一下，后来决定不细说这些坑了。说一点此刻的心情吧，O(∩_∩)O哈哈~ 其实对于项目管理，我自己也是懵懵懂懂的开始，两年多摸摸索索的前行。有过很多迷茫、焦虑，也带着小伙伴们取得过一些小小成绩，也在跌跌撞撞的探索过程中最终决定选择项目管理作为自己今后的职业发展方向，同时也意味着开启探寻和学习项目管理专业化和系统性之路。到目前为止，我感觉蓓蓓老师的课程带给我的就是这份专业性和系统化。 希望自己以后能以更加专业的水平到更规范的平台从事这项工作，也希望身边的妻儿睡得更加安详。
2019-11-10 - maks 👍（5） 💬（1）
我作为一个程序员，有一次接到需求之后。 按照流程需求分析，然后编写需求实施方案经邮件通知。 结果在开发完成，技术测试后。到业务测试环节，业务人员却说：“这不是我要的效果” 。 最可笑的是我们在核对需求都时候，却发现我从项目经理那拿到的是一个旧版本的需求书。 然后当我发现所谓的新版需求书根本连需求都没描述清楚，是几个系统的需求混合在一起（如果一开始是这一版我绝不会接受）。 连夜赶工按照当前需求所述考虑已开发的特性和系统可行性得出的实施方案（现在想来，我应该先让业务核实我的实施方案，不然又做无用功）。 实现之后立刻让业务人员核查一点一点确认，最后终于按时上线。 （现在回想我应该在事前在仔细沟通，至少一个电话确认，而非两份文档石沉大海，了无音讯）
2019-11-09 - 海罗沃德 👍（4） 💬（2）
在敏捷開發團隊如何落實這些閉環？每個sprint時間都很短，沒有多餘時間進行這樣的閉環測試
2019-11-11 - enjoylearning 👍（4） 💬（1）
我们的设计稿都是产品一个人敲定，设计人员直接受产品经理管理。现在开需求会甚至都没有原型只有需求描述就开搞了，而且口头禅是 这个需求很简单，研发叫苦不迭
2019-11-09 - 霸波儿奔 👍（4） 💬（3）
期待蓓蓓姐做一场直播
2019-11-09 - Stephen 👍（1） 💬（1）
闭环系统包括正反馈和负反馈，老自动化人了🤝
2021-04-23 - 乖，摸摸头 👍（1） 💬（1）
我们需求下来都是产品、测试、研发一起开会 完全理清楚需求，然后技术拆分任务准备开始，测试就开始写测试用例。 测试用例评审需要开发参与吗？ 大多数时候测试用例都会比技术先弄完，测试用例需要交给开发，让开发进行自测吗？ 每天晚饭后......很多时候相关人员就下班了，他才不管结果咋样，这种情况咋搞？
2020-11-17 - Jxin 👍（1） 💬（2）
来自产品的“很简单，和xxx老逻辑一样”。类比本身是好事。但当你的项目，又老又烂，而开发又嫩又懒时，这就是个噩梦。老项目功能可读性低，又不存在什么灵活扩展的空间。所以老逻辑想要兼容新的业务元往往需要投入高成本的阅读理解和适当的代码重构。而年轻的程序员由于缺少一定的业务背景和经验，阅读理解容易产生偏差，重构手法也不娴熟，还懒得一一验证当前功能所有case的准确性。于是往往就容易导致兼容出bug的现象，结果不仅新的业务元无法使用，老的业务还受到破坏，很可能最终就是这个迭代延期（并没有很好管理代码版本，迭代里多个需求的代码提交都是耦合的，没有提交的原子性，导致如果临近发版出问题，迭代里的需求难以再拆分，只能整个延期）。
2019-11-12 - Hunter Liu 👍（1） 💬（1）
任何功能必须让产品在各个环节多参与，多看效果，多与开发沟通，多让设计看Demo，因为每个人分工不同，思维方式不一样，产品人员是产品思维，设计人员注重细节和整体美感，开发人员是工程思维，当你思维方式不同，做出的东西可能就会有偏差，如果都弄好再看，是很难达成各方都满意的效果，为了避免后续大量返工，各种怨言，还是前期多参与多互动的好，不然，以我的经验，日程肯定是延期了，各方还都觉得输出了无用功，非常影响情绪和士气，大家都是满满的疲惫感和负能量。
2019-11-10 - javaadu 👍（1） 💬（1）
对于超过两周的项目来说，PRD评审、系分评审、测分评审、上线评审，看起来是增加了流程复杂度和工作量，但是实际上这些事情和时间本来就是要花的
2019-11-09