⻛险管理：系统化应对⻛险

说到质量，很多⼈会说： “⼯期太紧了，能按期提测就不错了，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包版本检测的通过条件等。

需要注意的是，质量控制及卡点⾏为，是要结合项⽬的质量要求和团队的质量成熟度，⼀层⼀层地加强质量把关和收⼝ 。即便是在同个项⽬的不同应⽤中，也会因为线上要求的不同，⽽对质量卡点有不同的侧重。通过质量卡点的在线⼯具化，才能做到真正有效的质量保障。⽐如，某些团队在特定阶段，会按照静态代码扫描问题的级别来分级计算缺陷值，提交测试申请时，如果系统检测到缺陷值有升⾼，就不能够成功提交。