11 | 质量管理：层层卡点，一次把事情做对

Aug 23, 2021

11 | 质量管理：层层卡点，一次把事情做对-极客时间



下载APP





关闭

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

渠道合作

推荐作者

11 | 质量管理：层层卡点，一次把事情做对

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

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

课程介绍



讲述：雷蓓蓓

时长11:47大小10.79M



你好，我是雷蓓蓓，今天我们来聊一聊质量管理的话题。
说到质量，很多人会说：“工期太紧了，能按期提测就不错了，Bug 多一点也正常。质量好不好？不好说。如何提升？不知道，QA 会保证的呀。”
我见过的大部分程序员，对自己的代码质量要求还是很高的。不过但是，一旦遇到赶工压力，尤其是在 Deadline 之前，就很可能会把完成度很低的代码交出去，心想“反正有人给我检查，到时候再说吧”。但是，这个时候，这些代码就好比是一台“行走的 Bug 制造机”，后患无穷。
我曾经在一个技术债特别严重的部门中，面向各级程序员做过一轮抽样的访谈调研。调研的结果是，程序员们只有 27.2% 的时间在做真正产生价值的编码工作。但是，他们会花 20.7% 的时间，进行需求质量和代码质量问题所引发的 Bug 修复、返工和紧急上线工作。
质量成本分为两类：一类是事前防止失败的一致性成本；一类是事后处理失败的非一致性成本，包括内部 Bug 引发的返工成本，以及外部 Bug 导致的用户侧成本。
近些年来，越来越多的公司在严格控制测试人员的比例，鼓励开发人员通过各类技术手段从上游保障质量，就是因为越发地认识到：事后检查处理的代价其实是最高的。
实际上，质量是规划、设计、建造出来的，不是检查出来的。预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多。
我们都知道，一次性把事情做对的成本是最低的。而一次性把事情做对就意味着，我们要有意识地提升预防类工作的占比，从根本上降低内部 Bug 率和外部 Bug 率。在这个质量改进的过程中，开发人员是绝对的关键力量，而非测试人员。
那么，作为项目管理人员，你该如何更好地规划质量管理活动呢？总体来说，你可以从三个方面入手。
质量规划，明确标准规划质量，是识别项目及产品的质量要求和标准，并确定用哪些质量保障方法、过程改进措施来达到这些标准的过程。
需要注意的是，在业务生命周期的不同阶段，质量标准应该是动态变化的。比如，业务初创期追求的是最小化 MVP 模型的快速迭代，在这个阶段，质量往往不会是最关键的因素。但是，当规模扩张到一定程度之后，对于质量的要求就非常高了。不同的项目对质量的要求也相差甚远，无法一概而论。因此，只能结合具体项目和具体阶段的质量诉求，对质量的标准进行合理定义。
你可以参考一下下面这张图片，它展示的是，一个已经进入规模增长期的稳定业务对客户端质量标准的定义。
定义好了质量标准，接下来你要思考的是，在整个项目的进程中，需要规划好哪些质量保障活动，以很好地达到这个标准。
我给你分享一张各个阶段的质量保障手段的列表图。其中，你需要特别关注研发过程中的质量保障手段，制定适当的编码规范、提交规范和分支规范，同时设计代码准入标准，代码 Review、单元测试、接口验证和 UI 验证等，确保这些手段与你的项目质量要求相匹配。
项目经理的视角始终聚焦在项目的整体目标上。在项目经理看来，质量作为目标的一部分，达到要求是最重要的，不需要追求质量的无止境提升。因为，质量终究也是有代价的，是否够用则取决于项目目标和要求。
质量分析，追根溯源质量分析，是指识别项目运行期间，整体质量上遇到的问题和制约因素，分析根本原因，并制定相应的预防措施和解决方案。
我曾经给一个底层核心模块的技术团队做项目管理，上层模块经常抱怨它的质量，有时候甚至在关键流程上都有问题，团队内外都对其质量失去了信心。
从数据上看，这个模块的线上 Bug 量占项目总 Bug 量的 17%，给上层其他模块和运维都带来了不少麻烦。随着越来越多的外部应用陆续接入，如果这个问题得不到有效解决，内部矛盾很可能就会升级为外部矛盾，不容忽视。
经过深入分析，我对频发的质量问题有了以下认识：
团队扩张得很快，在相当长的时间内，测试人员的配比都非常低，8 个开发对应 0.5 个测试。测试基本上只是给开发打工，只能保证最最基本的功能，其他更深度的测试类型根本无所涉猎；
没有从用户的视角来检验产品，上层模块的应用场景、运维的应用场景与测试的视角相差较大，测试效果很难保障；
约有五分之一的线上 Bug，是来自社区，用户侧出现问题以后才去社区找，再把这个补丁合进来，没有主动应对。
同时，根据用户调研的结论，用户对底层核心模块的期望更多的是稳定，至于新需求，用户普遍表示暂时没有需要。因此，盲目增加复杂功能其实并不明智，保持产品简单可靠才是王道。
定位完问题，再来看采取哪些措施来改进或预防：
新功能适当放慢：在基本功能已经成型的情况下，进一步控制新功能开发在迭代中的占比与优先级。当时我们定义的是不超过 70%，在一定时期内，核心功能不再做大的变动。。
回顾总结：将线上 Bug 分析作为周会的一项固定内容，集体讨论出整体层面上的改进措施，并跟进实施到位。
查漏补缺：对已有的测试用例进行全面梳理，与相关的开发、测试、运维一起集体 Review 完善，花大力气补充测试代码（增加异常、并发、稳定性测试等）。考虑到这是一项长期工作，要确保将其分解到各个迭代中，分批实施。
走到前面：紧密跟进社区 Bug，分析重现并评估影响，定期总结梳理，并组织讨论应对措施，主动引入必要的补丁。
以终为始：新功能需求确定后，测试用例同步设计并 Review 通过，然后开放冒烟测试标准，让开发人员在明确“什么是完成”的前提下，进行开发。
在坚持了两个月之后，整体的质量状况好了很多。总体来说，质量分析最重要的是要追根溯源，找到问题症结。我给你推荐几种简单实用的方法。
每月坚持开线上 Bug 分析会。你可以召集产品、研发、测试，一起对过去一个月的线上问题，进行深入的根因分析，制定策略并推进落实。
持续进行内部 Bug 分类。从不同维度分析 Bug 原因，你可以按照具体引入阶段给 Bug 分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发、覆盖升级、历史遗留等，也可以按照 Bug 类别分为功能问题、性能问题、界面问题、兼容性问题等。从数据统计上，你就可以准确地知道，自己项目的质量问题主要出在哪个环节，下一步是要先规范代码准入标准，还是加强需求评审，以及哪些保障措施会更有效。
建立质量大盘，拉通不同业务线或模块的每月 Bug 趋势，对齐千行代码 Bug 率、Bug 数 / 需求数的比率、Reopen Bug 率等，对低于平均线下的业务线或模块进行有针对性的原因分析。
质量控制，层层卡点如果说质量分析的要点重在追根溯源，那么质量控制，就是将一些明确下来的质量规范和做法，真正落地在各个环节的过程中。我给你分享一张样例图，它展示的是从需求到发布的整个过程中的质量活动概览。
想要推动质量改进措施的落地，与之相匹配的工具配套是必不可少的。在网易，我们使用 PMO 自主设计开发的企业效能平台 Overmind，来完成持续集成和持续交付，并在需求到发布的整个链条中，层层设置相应的质量卡点。你可以根据实际需要，逐步为自己的应用定制合适的持续集成方案，指定代码准入的阈值，比如静态扫描、单元测试、覆盖率测试、冲突检测、Jar 包版本检测的通过条件等。
需要注意的是，质量控制及卡点行为，是结合项目的质量要求和团队的质量成熟度，一层一层地加强质量把关和收口。即便是在同个项目的不同应用中，也会因为线上要求的不同，而对质量卡点有不同的侧重。通过质量卡点的在线工具化，才能做到真正有效的质量保障。比如，某些团队在特定阶段，会按照静态代码扫描问题的级别来分级计算缺陷值（如上图），提交测试申请时，如果系统检测到缺陷值有升高，就不能够成功提交。
总结总结一下，今天，我跟你分享了项目经理在质量管理过程中的工作，你可以从三个方面入手，分别是：
质量规划，明确项目的质量标准；
质量分析，追根溯源，找到质量差距的根本症结；
质量控制，在需求到发布过程中，设置层层卡点来控制质量。
要想一次把事情做对，你首先得明确什么是对，然后要分析差距，找到相应的质量保障方法，并不断迭代。这三个方面是个螺旋式循环上升的过程，你需要不断地根据质量分析的结果，设置合适的质量卡点，直到达到规划中的质量标准。
畅所欲言最后，我想请你来聊一聊，你所在的项目中技术债的整体情况，你在实践中有哪些好办法，来持续保障质量？
欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。

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

生成海报并分享

赞 20

提建议

10 | 风险管理：冰山下的风险，如何系统化应对？

12 | 高效会议：拒绝例行公事，开好最有必要的会

 写留言

精选留言(30)

小文同学
2019-12-10
质量管理在一个正在运行的项目里很重要。我2016~2018年所在的老项目(2011年)就曾经面临质量危机，它是公司收益非常大的项目，危机是不得不解决的。危机原因：技术债务堆积数年，开发已经陷入举步维艰的地步，大部分的技术同学一周都得忙两天时间修复线上bug。危机解决方法：小步快跑地重构崩坏的代码，对于不方便修改的代码，直接开发一套新的兼容代码，旧的代码让其尘封起来。解决关键：所有的小步快跑都要寻找反馈来证明有效；相信工具和自动化；项目的是周更新的，迭代速度很快，有利于项目的改动快速得到反馈，甚至说每一个人的努力都可能在下一周得到回应。我那时在团队里以上线晚上的加班时间为自己的反馈，假如超过12点而原因是研发进度问题，则优先解决最重要的研发瓶颈问题。17年花了半年时间不断地重构，重构获得更多的时间后，又可以进行新一轮更难、持续时间更长的重构，团队重新进入良心的循环，最终技术债务逐渐基本还清，17年下半年版本质量重新稳定了。后来我补充思考了一些关于防止项目质量重新陷入崩坏的问题。 1、在技术团队中强调代码的不仅仅是正确与否，有优劣之分，由于项目是快速迭代的，所以代码的可读性和稳定性优先于代码的性能问题。保证每个技术同学都知道这个原则，敢于对违反这个原则的代码自行进行重构（还得培训相关重构知识）。 2、在技术团队中，补充规范和文档、注释，把之前重构出来的成果以肉眼可见的形式留存下来，要求是一个实习生按照文档操作不会踩到坑。现在该项目已经又继续稳定运行了两年多，最重要的成就感莫过于自己留下的框架和规范还有用地指导着新同学去继续这个支持这个项目。现在新的项目依然有很多质量的问题需要处理，但是要处理的维度更高了，新项目的问题不仅仅是代码质量问题，而是更多是团队问题，这是我19年下半年最大的挑战。希望两年后回望也有我今日回望17年的成就感吧。
展开
作者回复: 佩服你的魄力和坚持，棒棒哒
40
super宋
2020-04-20
老师我想请问下，在我已经建立好代码规范，提交标准等等规章后，有个别人就是不按照规章制度去做事，甚至沟通后依然我行我素，成为了一个“坏榜样”。该怎么去处理这种情况呢？还有一种情况是有的开发人员自己的代码从来不测试，或者测试用例很少，质量低导致测试人员工作量非常大，也对他颇有微词，同样是沟通后无果，是否有方法去解决这种情况呢？
作者回复: 不清楚你在这里面的角色是什么，首先你需要某种程度的授权，然后跟团队定义好代码规则，达成共识，最后，你可以通过代码质量分榜单、效能数据周报等方式，按照约定好的机制和规则，公开客观地来对数据进行全员晾晒。执行过程中注意尽量不需要针对个人，而是建立机制让问题更好地暴露。
共 5 条评论
9
小学一年级
2019-11-21
质量控制从时间维度分为事前做好质量保证计划。事中时时监控节点，防止偏差。事后总结归纳分析根因，持续改进。感觉也是一个小的项目计划
7
leslie
2019-11-21
谈谈个人的现实感受吧：其实处理这种技术债应当是两类手段，其实也是两类人的处理方式。第一类：定期处理-做事情极度有魄力的CTO，定期会对现状做个总结然后还债，这个可能就像我们用花呗或者信用卡定期主动还款一样。第二类：知道一堆问题，可是就是觉得太杂、知道问题、记录下来、大不了这个爆了我还有其它的，总体上最后做到核心不出问题就行，其实这种CTO自己都不知道现有的有些项目哪天会爆了。一次性做好是不可能的：前几天刚和极客时间的老师在专栏中聊过类似的问题；有技术债不可怕，怕的是决策者不能确定技术债的风险且适当的时候定期还债，最终导致某些债务引发部分爆仓。以上是个人的一点切身体会和薄见：期待老师下节课的分享。
展开
作者回复: 谢谢，帮你总结下：技术债不可怕，定期主动还债，规避爆仓风险！
共 3 条评论
6
PM它不好转啊
2020-11-10
目前仍然是主开发角色，想吐槽一个可能比较常见的事情接手了一年多的很老的项目，没有一点文档保留，全靠同事之间的口口相传，接手初期跟产品过会需求，看着都很简单，但是找代码位置还有错综复杂的逻辑简直要崩溃，一个不小心就容易导致其他问题出现，后来忍不了了自己把各种说明文档开发文档补充上了，算是给古人还了一部分技术债。这种三无的项目如果不下定决心用很长一段时间还债的话，实在是不好意思把“质量”两个字说出口，刚接手的也没人能保证质量。大家还是要尽力预防风险遵守各种规范不要等风险降临在自己或者某个幸运儿身上再哭着加班，太难了
展开
4
quietwater
2019-12-15
质量管理最高境界还是治未病，需求质量决定了质量的上线，需求评审固然重要，但最有效的还是开发测试需求对需求的理解达成一致，包括验收条件。这样大家都心里有数，提高了效率。
作者回复: 没错
共 3 条评论
4
qh
2020-03-26
一次性把事情做好，就怕又要质量又要不合理的速度，最后先搞速度，后来号质量
2
亢（知行合一的路上）
2020-02-18
同理心发现了问题，也就是自己的痛点，要想团队其它人的痛点是什么？这两类痛点有哪些相同之处，也就是可以多赢的地方。设身处地为他人着想，谁不想解决自己的痛点呢？先花力气与重要干系人沟通团结一切可以团结的力量，然后，再向大家公布，阻力就小很多。定制同样的方法，针对不同的团队，适合落地的形式也不同，还是同理心。发心帮助团队，学习方法，积极尝试，不断优化。
展开
作者回复: 找到了真谛，同理心，团结一切可以团结的力量，说的很好👍
1
Raymond吕
2019-12-24
今天学习了新概念：质量大盘，质量卡点。公司有公司级的质量方针，质量目标，但针对项目层级质量规划却比较少见。在传统制造行业里，质量管理是单独的部门，虽然在项目组中存在质量代表，但其工作的模式并没有太多变化。我理解，软件工程领域和制造领域的区别在于，软件开发人员每个人都是生产者，代码是其直接产出；而制造一个产品，开发人员只是负责设计，生产制造是另一拨人，而制作的好不好除了设计的原因外，还有工艺本身的原因。一旦多因素混合，发生issue时想要定位根本原因，就比较困难了。质量不是一个人的问题，而是需要质量意识深入人心，从系统层面设置标准和卡点。没有标准，就是没有质量。
展开
共 1 条评论
1
MaxHu
2019-11-22
感谢老师的分享。如下2个问题请教一下：1.提测前的质量门禁和上线质量标准是PMO制定后与相关部门沟通达成一致后执行，还是PMO推进相关开发及测试部门/产品部门来完成并上级review拍板？这个问题主要问相关质量标准的制定和推广是怎样进行的？2.针对产线问题的根源分析和改进措施如何做到闭环及改进效果评估？质量提高需要一个过程，有些改进需要技术不能内部立项跟进。如果按月review发现改进方案还未见到明显成效并且review下来还是类似的问题和类似的解决方案，是否参与人会感觉到review是浪费时间，这种情况下您怎样处理的？谢谢
展开
作者回复: 第一个问题，不清楚你所在组织的具体架构，质量标准制定要结合业务不同阶段的需要来定义，PMO可以起到推进作用，需要产品和开发测试协同来做。第二个问题，我在复盘会也特意讲过，线上bug分析算是对线上问题的复盘，复盘最重要的就是改进措施落到实处，否则一再的开自然觉得无意义。这样的情况下，问题重点不在开会，而是你要持续去推进bug原因分类，用数据去加快技术部立项等改进措施的有效落地，这个更为重要。
1
furyboo
2019-11-21
要做到“一次性把事情做对”还需要一个前提，就是项目的干系人（包括产品、设计、开发、测试等）能够统一对产品需要、目标、质量等有比较一致的理解和认知。在我之前的一个团队中，有些项目业务逻辑会比较复杂，在产品需求沟通或者评审时，大家很少会有疑问或者问题，会后就根据各自的理解开始开发或者设计测试用例了，等功能做出来的时候，经常会发现有很大的偏差。后来我们采取了一个方案：每次产品讲完需求后，随机让几个参会成员讲解对需要的理解，这样避免了部分成员在开会的时候划水提高大家的参与度，也可以及时发现大家都需要理解的偏差。请问一下，大家有没有什么好的办法尽量减小团队成员对需求等理解或者认知偏差呢
展开
作者回复: 面对面的交流最有效，你用的复述讲解就是很好的方法，另外可以总结看看，经常理解不一致的地方，是否有必要建立一些共同的语境认知。除此之外，我们试过在一个团队中，讲完一个需求，就通过扑克牌来做简易的工作量估算，从大家给出的评估差异，就可以把理解上的差异提早暴露出来。
共 2 条评论
1
Cy23
2019-11-21
树立责任感，出来混迟早要还的，回头还债的时间远超发现问题及时修改的时间，因为你要把代码重新复读理解一遍。原来人多还可以安排固定的人做测试，现在设计、开发、测试、修复全都一个人。我只能干活的时候多加小心，尽量考虑全面减少bug出现率。
1
Echo就爱吃棉花糖
2022-09-20 来自上海
老师，请问一下，没有IT背景的如何去评估质量问题，以及IT部门给出的工期如何去把控呢
Jaising
2022-09-06 来自浙江
很羡慕重视质量管理的团队，以前做2C产品质量规划分析控制都相对健全，换工作后做2B，2G的产品后质量反而没那么高要求了，出现技术债的产品基本都是重写上线替换掉，试图推动建设质量体系但是发现困难重重，即使内部有一套还可用的基础设施，碍于产出考量，上层更重视大项目其他的都不经专门测试直接给到线上，下属对质量规范基本也不关注，没有软件崩溃没有用户反馈就万事大吉，但个人还没放弃对质量体系的建设和对自己的要求，也理解成立3年的部门还在建立机制和填旧坑没法重点关注到质量上来，质量真的体现一个研发团队的成熟度，对于产研团队的质量建设老师有什么建议？
展开
Geek_小棠
2022-05-07
蓓蓓老师，最新才开始学习，缺陷的大概率不是发生在需求设计阶段么。为什么要专注研发阶段呢
作者回复: 你说的很多，需求变更一节中有讲从源头抓起
热血战士
2022-04-25
技术债，单纯依靠程序员自身是无法有效推动的，即使程序员很想改变。技术债的改善需要高层来制定对应的计划和措施才能够推动，整体层面考虑。个人也遇到过技术债的，只要确保能够平稳运行，不出现严重问题或者业务没有反馈，尽量不需要修改，因为修改需要消耗大量的时间和精力，划不来。技术债的另一面是主要是测试没有做好，涉及开发和测试的比例问题：有些公司认为开发人员需要自己测试，但是开发对场景和需求的认知不是很熟悉，毕竟编码实现已经花费了大量的时间；有些公司认为研发和测试比例为1:1，这样虽然能够保证质量，但是花费太大。个人认为还是需要测试人员，但是测试人员不要占比过多且测试人员要全程参与项目，也要对需求和设计测试，不仅仅是功能。
展开
Lily
2022-01-19
请问蓓蓓老师，一般bug率怎么统计？分母用什么算比较合理？
作者回复: 有效bug数
Sam_Deep_Thinking
2021-08-08
这里面关于质量的流程，是不是QA团队参与更多会更好。
完美世界
2021-02-22
老师分析的太好了。项目刚起步时，进度时首要的，在项目中期，就需要把技术债搞搞了。我们是利用sonar平台，一期，先控制漏洞数、bug数，保证最起码的代码质量。二期，会严控覆盖率。三期，是必须满足所有的指标，才可以上线。同时，倒逼研发，尽可能提高代码质量。
展开
Geek_f65dfa
2020-11-18
请问，这里的测试用例是开发自己写的？？
共 1 条评论

