06 | 执行：三种闭环验证方法，保证执行不走样
该思维导图由 AI 生成，仅供参考
学习场景：“这……不是我想要的！”
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
闭环验证方法对于产品研发过程至关重要。本文介绍了三种实用的闭环验证方法，以确保产品执行过程中不走样。首先，方案评审是其中之一，通过OARP决策机制，包括Owner、Approver、Reviewer、Participant四个关键角色，确保评审的闭环效果。其次，用户体验闭环验证方法，通过用户行为数据和用户反馈，不断优化产品体验。最后，自动化闭环验证方法，通过自动化测试和持续集成，提高产品质量和开发效率。这些方法能够帮助产品团队在研发过程中及时发现问题、减少返工，提高产品质量和用户满意度。 Bug Bash（Bug大扫除）是一种非常有效的产品闭环验证方法，可以在测试阶段或需求设计阶段组织，通过集中精力找Bug，提前发现问题，避免上线后的漏洞。冒烟测试用例评审则是在开发和测试之间建立基础合约，避免“差不多”陷阱，确保提测质量。这些方法都旨在保证执行过程不走样，可以根据项目情况有步骤地开展优化，在核心的输出环节设置合适的断点和关口，以更好地把控全局。 在实际执行中，这些方法都是为了降低偏差、避免返工，保证产品质量和用户满意度。读者可以根据自身项目情况选择合适的方法，并结合实际情况进行优化。文章还分享了一些实战经验，让读者更好地理解闭环验证方法的应用。
《雷蓓蓓的项目管理实战课》，新⼈⾸单¥59
全部留言(63)
- 最新
- 精选
X.J👸蓓蓓姐，问个私人问题，作为一个女孩子，你每天作息怎么安排，能做好网易项目经理工作，还能写书，备课，你怎样激励自己的。非常感谢🙏作者回复: 先说作息，实际上，人的作息弹性之大，超过了你的想象，挤一挤总会发现，还能继续加！！专栏期间，大体就是每天改稿到凌晨下班，醒来就是录音，周末全部把娃支走，都别理我的节奏。 再说自我激励，我见过很多非常优秀的人，努力的程度也超过我很多，所以我也会经常产生这样的感慨，无法想象他是怎么做到的？他是怎么坚持下来的？ 后来我发现，其实这些人背后，内心往往都有一个自己还不够好的声音，随时随地拿着个小鞭子对自己，不管别人怎么认可，他自己还觉得不够完美，没办法他只能往前做更多，哈哈哈 所以，千万不要羡慕这些人，每个人有自己发光的方式和节奏，找到你的那个独一无二的热情最重要，这样一来，并不需要什么意志力来坚持，我只是乐此不疲罢了！
2019-12-20495
看山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-161080
有心猴最坑的就是工期倒推,产品的东西你可以评审,评审不合格就改,可是占用的都是开发的时间,最终结果是产品文档改的合格了,工期到了,是开发没有完成.作者回复: 谢谢你的留言，这个问题很典型，我在09中有专门讲解我们的做法，希望给你些参考。
2019-11-11738
Ios王子最后说的冒烟测试没看明白是什么作者回复: 一般是指针对最基本的功能或最主要的业务流程进行的测试，用作提测验收条件。
2019-11-2013- Gechmind冒烟用例，我们公司也进行评审了，其中一个难点就是：用例过多，进行评审的时候很费劲，开发人员参与感不强，且非常抱怨浪费时间；开发完成后进行提测，测试人员反馈的冒烟通过率很低，原因是没有做自测，要求提测后，开发又抱怨用例多，造数据废时，然后就会提出造数据由测试来提供，这就会占用测试的时间，引起测试的反感
作者回复: 冒烟用例，可以控制一定的比例，涵盖主要功能路径，一步一步来，前期重点在于培养自测习惯。有些小工具可以帮助构造测试数据的，测试人员可以研究一下
2020-02-12411 
穷查理周末下午，阳光明媚，怀孕五个多月的老婆在旁边床上睡觉，睡的很安详。看了一眼老婆熟睡的胖胖的脸，能给她带来这份安详，我感觉很欣慰。 盯着电脑思考了这个问题一个多小时。想了写，写了又删，删了又想，想到了项目中的很多坑，以及迈过一个个坑痛苦的过程，同时也想到了大领导跟我说的一句话（他说：因为我们不专业）， 不知道为何，想到他这句话心里突然酸了一下，后来决定不细说这些坑了。说一点此刻的心情吧，O(∩_∩)O哈哈~ 其实对于项目管理，我自己也是懵懵懂懂的开始，两年多摸摸索索的前行。有过很多迷茫、焦虑，也带着小伙伴们取得过一些小小成绩，也在跌跌撞撞的探索过程中最终决定选择项目管理作为自己今后的职业发展方向，同时也意味着开启探寻和学习项目管理专业化和系统性之路。到目前为止，我感觉蓓蓓老师的课程带给我的就是这份专业性和系统化。 希望自己以后能以更加专业的水平到更规范的平台从事这项工作，也希望身边的妻儿睡得更加安详。作者回复: 被你的文字感动到……你一定会成为专业的项目经理，因为你遇到的每个坑，都带着一份礼物，哈哈，祝福你！
2019-11-105- maks我作为一个程序员，有一次接到需求之后。 按照流程需求分析，然后编写需求实施方案经邮件通知。 结果在开发完成，技术测试后。到业务测试环节，业务人员却说：“这不是我要的效果” 。 最可笑的是我们在核对需求都时候，却发现我从项目经理那拿到的是一个旧版本的需求书。 然后当我发现所谓的新版需求书根本连需求都没描述清楚，是几个系统的需求混合在一起（如果一开始是这一版我绝不会接受）。 连夜赶工按照当前需求所述考虑已开发的特性和系统可行性得出的实施方案（现在想来，我应该先让业务核实我的实施方案，不然又做无用功）。 实现之后立刻让业务人员核查一点一点确认，最后终于按时上线。 （现在回想我应该在事前在仔细沟通，至少一个电话确认，而非两份文档石沉大海，了无音讯）
作者回复: 反向验证，从我做起，嗯！
2019-11-095 
海罗沃德在敏捷開發團隊如何落實這些閉環？每個sprint時間都很短，沒有多餘時間進行這樣的閉環測試作者回复: 拆分成小迭代之后，你可能未必在每个迭代都这么做一遍，根据整体的里程碑规划，可以在封版测试的时候，设置相应的环节来做闭环测试
2019-11-1124
enjoylearning我们的设计稿都是产品一个人敲定，设计人员直接受产品经理管理。现在开需求会甚至都没有原型只有需求描述就开搞了，而且口头禅是 这个需求很简单，研发叫苦不迭作者回复: 你这种情况我也遇到过！可以看下第9讲，需求变更应对，我会详细展开，关键在于产生共识。
2019-11-094
霸波儿奔期待蓓蓓姐做一场直播作者回复: 蓓蓓姐正在超级马力通宵备课状态…… 现在，做好课程是第一位。直播会有的，让子弹飞一会～
2019-11-0934