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