互联网项目如何做好质量管理

01 背景

谈到质量管理，这其实是一个比较大的话题，因为到各行各业都有其质量的定义和要求，也包括质量管理的方式方法。

鉴于本人长时间在互联网行业，因此本文聚焦谈的是互联网项目如何做好质量管理。

互联网产品以快著称，敏捷开发，快速迭代。不过这是精品1.0时代下的产物。在那个时代，因为需要快速上线，抢占市场份额，这就使得发布的产品是某种程度上牺牲了产品的质量的。所以，那个时候有一个名词，叫做有损发布。

随着行业的不断发展，互联网行业的产品已经不再是以快著称。进入精品4.0时代后，提倡的是匠心思维。每一款产品正式发布时，对质量都是高标准，高要求。因为在一片红海时代，任何以牺牲质量为代价而发布的产品，都可能带来毁灭性的损失。

02 质量管理的原则

或许正是因为行业的演变，也让质量管理成为了项目整个生命周期的重中之重。我们知道项目管理四要素：时间、成本、范围和质量。在这个铁三角中，质量处于中心位置，项目经理在安排各项工作时，需要全局考虑，质量是默认必须要保证的，可以调整的是时间、成本（人力）和范围。这是质量管理的一个原则之一。

由此，也引出质量管理的第三个原则：质量管理是贯穿整个项目生命周期的，是一个体系化的事情。质量管理从项目启动之初就需要开始，而不是某个阶段，或某几个阶段才开始。要确保产品质量的稳定，在整个项目周期都需要做好质量的管理。

质量管理的第四个原则：一切的质量管理过程，都要提前做好规划，眼见为实。尤其是针对手游性能体验方面，优化前后的版本，是可以非常直观地感受到的。此外，眼见为实，也要求测试的整个过程可视化，做好质量风险评估，抓关键点。比如说最直接的，开发人员说改了什么什么bug，结果版本里面发现压根就没有改。所以，要实际地看交付的版本，眼见为实。

04 质量管理的方式方法

那怎么来做好质量管理呢？从我自己的理解，我梳理了十大要点：

一、明确目标

项目有项目的目标，质量管理，同样有质量管理的目标。

对于质量管理来说，目标包括目的和标准。质量管理需要有明确的目的；质量管理需要有明确的标准。

1、质量管理的目的

质量是产品、人员、流程、服务和/或体系的特质和其内在固有或外在赋予特点的综合，显示其达到期望或满足陈述的需求、要求或规格的能力。

质量的焦点在于产品达到要求的能力。

所以说，进行质量管理的目的要清楚，而且也不言而喻，就是为了使得产品达到所设定的要求的能力。

2、质量管理的标准

谈到标准，仅从公司的角度来说，我想每个公司都会有其自身的质量管理体系。所谓质量管理体系就是项目/产品或组织的一整套质量标准、步骤和职责。这里我想分研发期的标准和正式上线发布的标准。

（1）研发期的标准

研发期的标准，是在符合整个公司的质量管理体系下，由项目组根据实际情况来定义的一个标准。

之所以要定这个标准，是因为项目在研发期的时候，因为项目有大量的系统功能要进行开发。从项目管理全局更优的角度出发，不太可能做完一个版本就绝对稳定一个版本。这是由互联网产品或游戏项目本身所决定的。尤其是游戏项目，系统与系统之间才存在强耦合，强关联或依赖关系，就更没有办法在项目初期、中期做到绝对的质量稳定。

项目经理需要有一个清晰的认知，迭代目标的制定，就是为了交付质量更加可靠的版本。所以，我们评判一个版本的质量达标与否，不是仅仅只看这个版本的bug修复情况，是看的整个全局，包括但不限于需求的实现完整度、资源的合入情况、开发的深度参与、体验问题的修改、bug的修改。

（2）上线的标准

上线的标准，通常是指要满足正式发布时，需要满足的标准。但这些标准并不是等到产品正式上线的时候才会进行，而是从项目立项之初就从多个阶段来进行保障。

鹅厂的质量管理体系（以游戏项目为例）称之为TDR评审指引及标准。TDR的全称是Technical Design Review，称作技术设计评审，分别有TDR1、TDR2、TDR3。针对项目的不同阶段，侧重点不一样。

TDR3重点针对的就是程序、测试、安全和政策。程序重点评审的是客户端和服务端的性能、适配、CPU和内存、crash率、弱网这些主要指标；测试则重点评审的是客户端性能基线、内存消耗、CPU占用率、帧率、适配、弱网、crash率、服务器性能、容错容灾；安全方面，重点评审的是客户端安全（是否加密）、游戏逻辑安全、敏感词接入等；政策主要是版号、备案、实名制。

到TDR3的时候，基本上是需要对外测试（上线）的时候，要达到这个标准，才能申请资源进行测试。

二、确定范围

这里的范围是指质量管理的范围。

具体到某一个版本来说，在版本正式进入开发阶段，是需要确定范围的。也就是说要明确清楚具体做的需求是哪些，范围确定了，才更好从源头狠抓需求的质量。对于质量管理来说，需求管理做的好与不好，也是直接影响质量管理的好与不好。

当需求的源头明确了，对开发和测试来说，目标则会更加的明确。关于需求的源头，抓需求质量的输出，在需求管理的篇幅里面有详细介绍。

三、对需求进行测试和评审

对需求的测试，是软件测试领域里面提到的一个重要策略。但这对测试资源的依赖或要求是非常之高的。事实上，很多互联网项目或游戏项目，没办法做到对需求进行测试。

但为确保需求理解的一致性，需求评审在整个研发流程里面是必不可少的。不管需求的体量如何，在需求正式进入开发阶段，需求评审是必选项，而且相关负责人都需要参与。

作为项目经理，不要认为需求评审（或宣讲）会耗费很多时间，不如直接发给开发人员进行方案的设计和工作量的评估。如果这么想了，质量管理做起来会非常的痛苦。因为这样做之后，很有可能会导致信息的不对称，使得执行时出现理解的偏差，结果做出来的产品不符合预期，引发各种问题。

所以，需求评审，则可以有效地保障需求功能点的遗漏，减少开发过程中的补丁，让整个设计在源头更加完整。

四、狠抓设计方案和WBS

或许写设计方案会耗费一定的时间，但这对整个质量管理来说至关重要。设计方案的输出，不仅仅只是输出，更需要进行论证和设计方案的评审。这是非常重要的环节。

对于设计方案，在项目启动之初的时候，我们还会请部门的一些专家一起进行论证和评审，目的就是确保设计框架没有大的缺陷。

设计方案评审确认后，是需要输出详细的工作量评估，也就是WBS。在做WBS的时候，我们有一个要求，即输出的详细工作量评估需要细化至0.5-2d的颗粒度。通常都是0.5d、1d，如果分解的任务里面，确实是有2d的工作量，还需要做特别的说明，否则就需要重新评估。

之所以要细化，是因为颗粒度细化的越细，说明具体执行人员对需求的理解和思考就更到位。结合设计方案，对需求的细节开发就更加有利。

正所谓磨刀不误砍柴工，多花些时间在设计方案和详细的工作量评估上，远比需求评审完直接开干而有利于质量管理。

五、接入一切可能的辅助工具

很多公司除了质量管理体系标准，还会有各种辅助工具，用来更好的辅助和发现代码的质量。

代码健壮性、可扩展性越高，代码的质量就越稳定，产品的质量也就越稳定。

在有利于质量管理的前提下，我个人是倾向于尽可能的接入。当然并不是为了接入而接入，需要思考是不是真的对质量管理有利。

代码扫描工具，可以在编译阶段就发现各种告警、报错，便于开发人员及时处理，防止出现大规模单元测试时出现异常。

日志上报系统，接入上报平台之后，还需要项目侧进一步完善日志打印，这样有利于问题的排查。当出现一些问题，尤其是一些偶现问题的时候，有比较健全的日志系统，就方便快速定位和排查，并深入地解决。

辅助工具，不一定是每个公司都会有的，那如果是一些没有这个条件的，可以考虑搭建一个或者找一找开源的工具。

辅助工具，除了公司已有的以外，如果是有条件的项目，还建议提前搭建自动化测试工具。

自动化测试工具的构建，是有利于节省测试资源，并提前发现问题的。对于互联网产品或游戏项目来说，大多是增量开发。

此前已经开发完的需求或功能，在搭建自动化测试工具之后，我们可以在版本自动构建阶段就使用自动化工具跑起来，提前发现问题，保证版本质量的稳定。

六、推行测试先行

开发的思维逻辑通常正向思维，而测试人员通常是逆向思维。借助测试人员的逆向思维，把一些问题前置。

比如我们现在通常的做法，就是大多数的时候，在需求评审完之后，会确定测试用例什么时候输出，在测试用例输出时，测试人员会输出思维导图，帮助开发提前做好一些异常、边界功能的补充，在编码的过程中就先行考虑，而不是等到版本交付后，测试过程中才来针对性的解决bug，这样会对整体代码健壮性有影响。当自测用例输出后，开发、产品和测试一起评审自测用例，有理解不一致或功能缺失，都会在开发阶段补全。

推行测试先行的目的，也还是从需求源头出发，利用测试的专业性，从逻辑架构上，提前规避或提前解决一些边界或异常的问题。

七、加强验收环节

质量管理一定不只是开发和测试的事情，因此，项目经理要特别重视验收环节。

验收环节也是整个项目研发流程中的重要步骤之一，以游戏项目为例，一个版本（或系统功能）交付之后，对应的产品人员结合美术人员需要参与版本的验收，并且输出验收的意见，或体验问题或bug。

因为我们是特性小组的模式，在具体负责需求的人员验收之后，整个特性小组还会参与一起验收。最后测试完成，项目的核心管理人员也会参与最后的体验。

除了让项目其他人员参与到验收环节，实际上，对代码本身的验收也是一个重要环节。代码验收就是我们常说的codereview（简称CR）。

项目其他人员在对功能进行验收时，开发的核心团队也会对代码的质量进行评审和验收，提出的代码问题也会一并在正式转测试的时候进行修复，从而更进一步的保证转测试的版本质量稳定。

八、高标准要求

高标准要求，其实目的很明确。项目在研发期的测试，用户体量是比较小的，一旦正式上线（公测），用户体量就上来了，对于一些偶现的问题或者crash的情况，都会随着体量的增加而增加。

所以，要满足项目侧的标准，以及公司的质量管理体系标准。在项目研发阶段，都需要高标准要求：

1、在测试期间，重点抓偶现问题的解决、弱网问题的解决、crash问题的解决及性能问题。尤其是偶现问题，不仅要高标准要求，还需要杜绝侥幸心理。曾经就因为侥幸心理，为了赶时间，而搁置了一些偶现问题，使得项目上线后，不得不紧急修复各种问题，紧急更新版本，也使得当时项目的数据很糟糕。

针对crash率，如果上线标准crash率不高于6%，那么在测试阶段crash率至少要控制在1%以内；如果上线标准crash率不高于1%，在测试阶段则要求crash率不高于0.5%。

所以，高标准要求，需要重点监控crash率的情况，在研发期间的crash率要控制其远远低于上线标准。

九、重视测试和风险评估

质量管理过程有了保证之后，并不代表产品的质量最终是有保障的。过程做的好，从项目的整个周期来说，会有一定程度的缩短，也给测试提供了极大的便利，但这并不意味着就可以忽略最后的测试环节。

从互联网产品或游戏项目来说，测试的效用还是非常大的，这是由项目本身的特点所决定的。因此，测试是质量最后的守门员，从项目经理的角度来说，一定要重视最后的测试环节。

怎么重视？清晰定义每个需求，每个版本的转测试范围，做好目标和标准的同步。同时，关切测试提出的诉求并及时地给予认可。

另外，专业的测试团队，在每个版本测试完成后，都会从测试的角度提出质量的风险，这方面，项目经理也尤其需要重视。往往测试团队提出的质量风险，都会直接或间接影响接下来项目的安排。

比如某个版本测试完成后，测试人员给出的bug分布情况和各模块的风险评估，特别指出一些系统功能模块的质量风险。一些数据或指标的提出，就会直接影响下一个版本的安排。

十、最关键的还是在于人

但真正的关键还是在于人。这是从软件行业的角度来说的，质量是设计出来的。如果团队有靠谱的人，有更专业，更厉害的人，那么就可以从源头避免很多质量的问题，这点其实是非常现实的。

带项目这么些年，这方面的感触非常之深，就是技术牛人写的代码和一般的人写的代码完全不是一个级别，其所交付的产品的质量更不是一个级别的。

所以，如果你发现做了上面的很多事情，产品的质量还是不达标，那就不仅仅是优化流程，对齐目标和范围的事情，要重点考虑人是否合适。

05 归纳总结

上面介绍了十大要点，助力做好质量管理。总结归纳一下，要做好质量管理，三个维度共同发力：

一、体系和流程

每个公司都会有自身的质量管理体系，借助公司的质量管理体系，可以有效地指导质量管理。若一些公司没有质量管理体系，项目经理可以根据实际情况，带领项目团队搭建一个质量管理体系，或者最简单的，制定一个最基本的质量保障标准。

目标，范围这些都可以归纳到整个项目的研发流程中，参照如下图：

项目经理需要严格执行研发流程中的每个环节，并跟进落实到位，同时以质量管理体系为参照标准，做好质量管理。

二、工具建设

工具的重要性不言而喻，在上面十大要点中，也有特别地提及。

项目经理需要有意识的推进或落实对质量管理有帮助的工具建设。

三、核心是人

人的能力高低、代码能力的深浅、技术经验丰富等，都是质量管理的有力保证。项目的质量管理中，最不可忽视的就是团队成员的能力。

作为项目经理，不能指望着从目标、流程、体系、工具等这些方面提升对质量的管理，如果一旦这些都努力做到了，产品的质量仍然没有明显的变化或提升，项目经理需要果断的从人员的维度进行考量，向核心管理层提出招聘经验丰富，能力更高的人，从根本上提升产品的质量。

最后，我想说，质量管理的终极目标是挑战零缺陷。

零缺陷思想，是早在20世纪60年代，被誉为全球质量管理大师的菲利浦·克劳士比提出的，并在美国推行零缺陷运动。

克劳士比的零缺陷并不是说绝对没有缺陷或缺陷绝对要为零，而是指要以缺陷等于零为最终目标，团队成员的每个人都要在自己工作职责范围内努力做到无缺陷。

这其实是要求我们要变被动为主动，在设计之前，就做好设计的防患措施，为设计高质量的软件打下坚实的基础，是要求项目团队人员具备更高的视野，从技术的角度出发，提出更多、更实际的设计质量防控的措施。

一个项目的质量，是需要依靠整个团队的共同努力，从需求开始，产品人员就要对需求的设计、各系统的关联考虑得更周全。