06 | 执行：三种闭环验证方法，保证执行不走样

Aug 23, 2021

06 | 执行：三种闭环验证方法，保证执行不走样-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

06 | 执行：三种闭环验证方法，保证执行不走样

2021-08-23 雷蓓蓓来自北京

《雷蓓蓓的项目管理实战课》

课程介绍



讲述：雷蓓蓓

时长14:58大小13.67M



你好，我是雷蓓蓓。今天我要跟你分享的主题是：打造品质，要从头开始“闭环”。在正式开讲之前，我想先和你分享一个小故事。
学习场景：“这……不是我想要的！”这天，我在公司走廊上碰到了面如死灰的艾文。
蓓蓓：“怎么感觉你今天双眼无神，发生什么事了？”
艾文：“太惨了。我们团队一个多月没日没夜，可算是在 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 大扫除）、以及冒烟测试用例评审。
其实说到底，这些方法都是为了保证执行过程不走样。需要注意的是，你并不需要在每一个版本中，把这些方法全都用上。你可以结合自己的项目情况，有步骤地开展优化，在核心的输出环节，设置合适的断点和关口，这样就能更好地把控全局了！
畅所欲言这一讲中，我跟你分享的，都是我们自己在实战中积累下来的闭环验证方法。只有到了执行时，你才会发现，理想有多丰满，现实就有多骨感。我想请你来聊一聊，你在项目执行过程中踩过的最痛的“坑”。如果你可以再分享一些你的“爬坑指南”，那就更好了。
欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 33

提建议

05 | 规划：扫除五大“延期地雷”，计划是用来对焦的

07 | 监控：“巧”用数据说话，让汇报告别流水账

 写留言

精选留言(62)

X.J👸
2019-12-20
蓓蓓姐，问个私人问题，作为一个女孩子，你每天作息怎么安排，能做好网易项目经理工作，还能写书，备课，你怎样激励自己的。非常感谢🙏
作者回复: 先说作息，实际上，人的作息弹性之大，超过了你的想象，挤一挤总会发现，还能继续加！！专栏期间，大体就是每天改稿到凌晨下班，醒来就是录音，周末全部把娃支走，都别理我的节奏。再说自我激励，我见过很多非常优秀的人，努力的程度也超过我很多，所以我也会经常产生这样的感慨，无法想象他是怎么做到的？他是怎么坚持下来的？后来我发现，其实这些人背后，内心往往都有一个自己还不够好的声音，随时随地拿着个小鞭子对自己，不管别人怎么认可，他自己还觉得不够完美，没办法他只能往前做更多，哈哈哈所以，千万不要羡慕这些人，每个人有自己发光的方式和节奏，找到你的那个独一无二的热情最重要，这样一来，并不需要什么意志力来坚持，我只是乐此不疲罢了！
共 4 条评论
86
看山
2019-11-16
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 欢迎补充。。。
展开
作者回复: 段子会火
共 10 条评论
74
有心猴
2019-11-11
最坑的就是工期倒推,产品的东西你可以评审,评审不合格就改,可是占用的都是开发的时间,最终结果是产品文档改的合格了,工期到了,是开发没有完成.
作者回复: 谢谢你的留言，这个问题很典型，我在09中有专门讲解我们的做法，希望给你些参考。
共 7 条评论
35
pkugsy
2020-05-20
反复听读这个课程，能学到很多。但是，贯穿始终，“加班”的情况被提到很多次，也许是错觉，文中完成好和不好的项目，貌似加班都挺多的，甚至多次说晚上的啥啥活动是记忆最深刻的事。个人觉得这样不好。项目管理的目标不应该是在截止时间完成，而是在每天有效8小时工作的前提下可以完成。如果有需要加班的需求点，如文中所述，可以在极端情况下对需求做取舍。加班是自己能力不行或者想学习更多东西，而不是被项目安排的必要加班。
展开
共 5 条评论
19
Ios王子
2019-11-20
最后说的冒烟测试没看明白是什么
作者回复: 一般是指针对最基本的功能或最主要的业务流程进行的测试，用作提测验收条件。
12
未未的未来
2019-11-09
坑很多，例如按照研发流程经过了立项评审，包括对需求和设计可行性的评审，领导也有参与，最后项目上线，没有达到客户预期。并不反对流程，但是在执行流程的过程中有些流于形式了，并未引起所有人员的重视，感觉公司有要求，就走走过场。最后，除了问题，都得挨批，研发还得返工，这中间的帐就是没算没明白，总认为流程耽误时间，回头一看，欠的帐总是要还的，只是时间未到而已。
12
Gechmind
2020-02-12
冒烟用例，我们公司也进行评审了，其中一个难点就是：用例过多，进行评审的时候很费劲，开发人员参与感不强，且非常抱怨浪费时间；开发完成后进行提测，测试人员反馈的冒烟通过率很低，原因是没有做自测，要求提测后，开发又抱怨用例多，造数据废时，然后就会提出造数据由测试来提供，这就会占用测试的时间，引起测试的反感
作者回复: 冒烟用例，可以控制一定的比例，涵盖主要功能路径，一步一步来，前期重点在于培养自测习惯。有些小工具可以帮助构造测试数据的，测试人员可以研究一下
共 3 条评论
10
牺牲
2020-04-11
之前遇到的是提测质量差，导致反复测试打回，无限延期的问题。后来通过跟踪回归次数，记录bug数量，提交开发自测用例，统计提测准时率、任务完成率、回归率。开发开始注意自己的提测质量和时间，效果很好。
6
maks
2019-11-09
我作为一个程序员，有一次接到需求之后。按照流程需求分析，然后编写需求实施方案经邮件通知。结果在开发完成，技术测试后。到业务测试环节，业务人员却说：“这不是我要的效果” 。最可笑的是我们在核对需求都时候，却发现我从项目经理那拿到的是一个旧版本的需求书。然后当我发现所谓的新版需求书根本连需求都没描述清楚，是几个系统的需求混合在一起（如果一开始是这一版我绝不会接受）。连夜赶工按照当前需求所述考虑已开发的特性和系统可行性得出的实施方案（现在想来，我应该先让业务核实我的实施方案，不然又做无用功）。实现之后立刻让业务人员核查一点一点确认，最后终于按时上线。（现在回想我应该在事前在仔细沟通，至少一个电话确认，而非两份文档石沉大海，了无音讯）
展开
作者回复: 反向验证，从我做起，嗯！
5
穷查理
2019-11-10
周末下午，阳光明媚，怀孕五个多月的老婆在旁边床上睡觉，睡的很安详。看了一眼老婆熟睡的胖胖的脸，能给她带来这份安详，我感觉很欣慰。盯着电脑思考了这个问题一个多小时。想了写，写了又删，删了又想，想到了项目中的很多坑，以及迈过一个个坑痛苦的过程，同时也想到了大领导跟我说的一句话（他说：因为我们不专业），不知道为何，想到他这句话心里突然酸了一下，后来决定不细说这些坑了。说一点此刻的心情吧，O(∩_∩)O哈哈~ 其实对于项目管理，我自己也是懵懵懂懂的开始，两年多摸摸索索的前行。有过很多迷茫、焦虑，也带着小伙伴们取得过一些小小成绩，也在跌跌撞撞的探索过程中最终决定选择项目管理作为自己今后的职业发展方向，同时也意味着开启探寻和学习项目管理专业化和系统性之路。到目前为止，我感觉蓓蓓老师的课程带给我的就是这份专业性和系统化。希望自己以后能以更加专业的水平到更规范的平台从事这项工作，也希望身边的妻儿睡得更加安详。
展开
作者回复: 被你的文字感动到……你一定会成为专业的项目经理，因为你遇到的每个坑，都带着一份礼物，哈哈，祝福你！
4
enjoylearning
2019-11-09
我们的设计稿都是产品一个人敲定，设计人员直接受产品经理管理。现在开需求会甚至都没有原型只有需求描述就开搞了，而且口头禅是这个需求很简单，研发叫苦不迭
作者回复: 你这种情况我也遇到过！可以看下第9讲，需求变更应对，我会详细展开，关键在于产生共识。
4
霸波儿奔
2019-11-09
期待蓓蓓姐做一场直播
作者回复: 蓓蓓姐正在超级马力通宵备课状态…… 现在，做好课程是第一位。直播会有的，让子弹飞一会～
共 2 条评论
4
海罗沃德
2019-11-11
在敏捷開發團隊如何落實這些閉環？每個sprint時間都很短，沒有多餘時間進行這樣的閉環測試
作者回复: 拆分成小迭代之后，你可能未必在每个迭代都这么做一遍，根据整体的里程碑规划，可以在封版测试的时候，设置相应的环节来做闭环测试
共 2 条评论
3
程序小白
2020-03-26
个人感觉在项目工作中尤其是多个渠道或者子系统关联的环节，冒烟测试用例是特别重要的，这个关系到业务的主流程是否能够通，作者说的第二种方法Bug Bash（Bug 大扫除）今天还是第一次接触听说，我个人感觉这种方法真的非常好，需要实施的话需要组织者非常具有号召力才行！如果组织者号召力不强的话是组织不起来的，在日常工作中的冒烟用例评审感觉就是走个过场！没有进行重视的，尤其今年新冠状病毒导致很多银行类系统都是按照监管要求增加疫情延期还款登记这个功能，从需求提出到开发整个环节都没有完整的沟通（在家办公）导致测试环节问题特别多！如何能够避免这种临时性增加的需求及开发测试能够达成共识呢？还望作者给出好的建议！感谢听您的讲课真是的是精神上的享受并且及时的补充工作中不足之处。
展开
2
Raymond吕
2019-12-23
本讲中的OARP让我想起了项目管理里的RACI矩阵，RACI是沟通管理的一种可视化工具和模型，OARP更强调了在流程中明确角色职责。其实，流程和速度总是相爱相杀，没有人愿意被流程束缚，每个人都认为对方知道自己该干什么，但实际上“应该思维”害死人！一个优秀的项目经理能够让流程闭环，在各个节点有响应和反馈，发动群众“搞运动”（bug bash）
2
程序员人生
2019-11-09
网上曾有过这么个段子，产品经理提给开发一个需求，app的皮肤要根据用户手机壳的颜色改变而改变，不知道这个公司有没有需求评审这个环节
2
Stephen
2021-04-23
闭环系统包括正反馈和负反馈，老自动化人了🤝
作者回复: 自动化专业，握爪
1
勇闯天涯
2021-04-01
关于执行，我们现在面临的最大的三个问题：一是写方案的人写不明白，内容不全面，要保证方案完备，评审会不整个3-4轮都不行；二是参与评审的外部专家，内部开发人员的绩效跟评审质量又不绑定，所以经常是你好我好大家好，而且评审的质量往往会在开发，测试乃至维护阶段才能暴露出来，时间上跨度较长；三是项目经理的压力往往也主要在进度上，排期都是倒推，高层虽然说重视质量，可一到排期上就是各种倒推，很矛盾。最后，往往是，重视质量的人最后都很惨，没有什么人愿意去搞好方案了，老师，这种问题有什么抽丝剥茧的解决方法吗？
展开
1
Nacol
2020-12-21
殊途同归, 本质上解决的问题有二 : 1. 如何实现甲方、业务、产品、设计、开发、测试、运维对工作流程以及相同业务的共识. 2. 如何发掘遗漏的业务.
1
乖，摸摸头
2020-11-17
我们需求下来都是产品、测试、研发一起开会完全理清楚需求，然后技术拆分任务准备开始，测试就开始写测试用例。测试用例评审需要开发参与吗？大多数时候测试用例都会比技术先弄完，测试用例需要交给开发，让开发进行自测吗？每天晚饭后......很多时候相关人员就下班了，他才不管结果咋样，这种情况咋搞？
作者回复: 需要开发参与的，冒烟测试用例需要开发自测，冒烟测试是一个提测很重要的节点，通常加班也要搞好的，团队中需要制定相应的规则来保障
1

