质量管理之互联网项目篇（二）

lsekfe

质量管理的方式方法
　　那怎么来做好质量管理呢？从我自己的理解，我梳理了十大要点：
　　一、明确目标
　　项目有项目的目标，质量管理，同样有质量管理的目标。
　　对于质量管理来说，目标包括目的和标准。质量管理需要有明确的目的；质量管理需要有明确的标准。
　　1、质量管理的目的
　　学过PRINCE2的朋友可能都知道，P2的7大主题之一就有质量主题。质量主题的目的是定义并实施项目用来创建产品并验证其符合目的的方法。
　　质量是产品、人员、流程、服务和/或体系的特质和其内在固有或外在赋予特点的综合，显示其达到期望或满足陈述的需求、要求或规格的能力。
　　质量的焦点在于产品达到要求的能力。
　　所以说，进行质量管理的目的要清楚，而且也不言而喻，就是为了使得产品达到所设定的要求的能力。
　　2、质量管理的标准
　　谈到标准，仅从公司的角度来说，我想每个公司都会有其自身的质量管理体系。所谓质量管理体系就是项目/产品或组织的一整套质量标准、步骤和职责。这里我想分研发期的标准和正式上线发布的标准。
　　（1）研发期的标准
　　研发期的标准，是在符合整个公司的质量管理体系下，由项目组根据实际情况来定义的一个标准。
　　之所以要定这个标准，是因为项目在研发期的时候，因为项目有大量的系统功能要进行开发。从项目管理全局更优的角度出发，不太可能做完一个版本就绝对稳定一个版本。这是由互联网产品或游戏项目本身所决定的。尤其是游戏项目，系统与系统之间才存在强耦合，强关联或依赖关系，就更没有办法在项目初期、中期做到绝对的质量稳定。
　　以我们项目为例，我们在项目铺量阶段制定的一个迭代标准，参考如下：

项目经理需要有一个清晰的认知，迭代目标的制定，就是为了交付质量更加可靠的版本。所以，我们评判一个版本的质量达标与否，不是仅仅只看这个版本的bug修复情况，是看的整个全局，包括但不限于需求的实现完整度、资源的合入情况、开发的深度参与、体验问题的修改、bug的修改。
　　（2）上线的标准
　　上线的标准，通常是指要满足正式发布时，需要满足的标准。但这些标准并不是等到产品正式上线的时候才会进行，而是从项目立项之初就从多个阶段来进行保障。
　　鹅厂的质量管理体系（以游戏项目为例）称之为TDR评审指引及标准。TDR的全称是Technical Design Review，称作技术设计评审，分别有TDR1、TDR2、TDR3。针对项目的不同阶段，侧重点不一样。
　　TDR1，策划（产品）重点是游戏的设计方向、核心玩法、题材包装等；美术重点评审的是游戏的整体定位风格及各细部风格是否已经确认完成，是否符合产品定位，是否有高品质同类产品的竞品供对比参考；程序重点评审的是系统架构设计是否合理。通常是在项目正式立项并确定时。
　　TDR2是根据不同的游戏品类所需要，主要是针对程序的技术设计评审。大多是在demo版本开启的时候进行。
　　TDR3重点针对的就是程序、测试、安全和政策。程序重点评审的是客户端和服务端的性能、适配、CPU和内存、crash率、弱网这些主要指标；测试则重点评审的是客户端性能基线、内存消耗、CPU占用率、帧率、适配、弱网、crash率、服务器性能、容错容灾；安全方面，重点评审的是客户端安全（是否加密）、游戏逻辑安全、敏感词接入等；政策主要是版号、备案、实名制。
　　到TDR3的时候，基本上是需要对外测试（上线）的时候，要达到这个标准，才能申请资源进行测试。
　　二、确定范围
　　这里的范围是指质量管理的范围。
　　具体到某一个版本来说，在版本正式进入开发阶段，是需要确定范围的。也就是说要明确清楚具体做的需求是哪些，范围确定了，才更好从源头狠抓需求的质量。对于质量管理来说，需求管理做的好与不好，也是直接影响质量管理的好与不好。
　　项目经理需要抓源头，让需求输出的质量更高，进而最后交付的版本质量也会更高。比如我们曾经就出现过典型的案例，某个需求输出本身的缺陷：需求逻辑不清晰，前后后有矛盾。这样一来，需求评审的时候就直接暴露出来这个设计缺陷。假设需求直接进入开发，则对质量的影响就更大了。所以，从需求源头开始，就需要对需求的质量进行管理了。
　　当需求的源头明确了，对开发和测试来说，目标则会更加的明确。关于需求的源头，抓需求质量的输出，在需求管理的篇幅里面有详细介绍。
　　三、对需求进行测试和评审
　　对需求的测试，是软件测试领域里面提到的一个重要策略。但这对测试资源的依赖或要求是非常之高的。事实上，很多互联网项目或游戏项目，没办法做到对需求进行测试。
　　但为确保需求理解的一致性，需求评审在整个研发流程里面是必不可少的。不管需求的体量如何，在需求正式进入开发阶段，需求评审是必选项，而且相关负责人都需要参与。
　　作为项目经理，不要认为需求评审（或宣讲）会耗费很多时间，不如直接发给开发人员进行方案的设计和工作量的评估。如果这么想了，质量管理做起来会非常的痛苦。因为这样做之后，很有可能会导致信息的不对称，使得执行时出现理解的偏差，结果做出来的产品不符合预期，引发各种问题。
　　所以，需求评审，则可以有效地保障需求功能点的遗漏，减少开发过程中的补丁，让整个设计在源头更加完整。
　　四、狠抓设计方案和WBS
　　质量是设计出来的，不是测试出来的。每个需求或版本对应的需求评审完成之后，需要和团队达成共识。一些大的需求或者复杂的系统，在正式启动编码时，需要输出详细的设计方案。这是和团队达成的共识。
　　或许写设计方案会耗费一定的时间，但这对整个质量管理来说至关重要。设计方案的输出，不仅仅只是输出，更需要进行论证和设计方案的评审。这是非常重要的环节。
　　对于设计方案，在项目启动之初的时候，我们还会请部门的一些专家一起进行论证和评审，目的就是确保设计框架没有大的缺陷。
　　设计方案评审确认后，是需要输出详细的工作量评估，也就是WBS。在做WBS的时候，我们有一个要求，即输出的详细工作量评估需要细化至0.5-2d的颗粒度。通常都是0.5d、1d，如果分解的任务里面，确实是有2d的工作量，还需要做特别的说明，否则就需要重新评估。
　　之所以要细化，是因为颗粒度细化的越细，说明具体执行人员对需求的理解和思考就更到位。结合设计方案，对需求的细节开发就更加有利。
　　正所谓磨刀不误砍柴工，多花些时间在设计方案和详细的工作量评估上，远比需求评审完直接开干而有利于质量管理。
　　五、接入一切可能的辅助工具
　　很多公司除了质量管理体系标准，还会有各种辅助工具，用来更好的辅助和发现代码的质量。
　　代码健壮性、可扩展性越高，代码的质量就越稳定，产品的质量也就越稳定。
　　对于我们来说，在项目启动之初，就会考虑接入公司的各种工具，比如代码扫描工具、crash上报平台、日志上报系统。
　　在有利于质量管理的前提下，我个人是倾向于尽可能的接入。当然并不是为了接入而接入，需要思考是不是真的对质量管理有利。
　　代码扫描工具，可以在编译阶段就发现各种告警、报错，便于开发人员及时处理，防止出现大规模单元测试时出现异常。
　　日志上报系统，接入上报平台之后，还需要项目侧进一步完善日志打印，这样有利于问题的排查。当出现一些问题，尤其是一些偶现问题的时候，有比较健全的日志系统，就方便快速定位和排查，并深入地解决。
　　辅助工具，不一定是每个公司都会有的，那如果是一些没有这个条件的，可以考虑搭建一个或者找一找开源的工具。
　　辅助工具，除了公司已有的以外，如果是有条件的项目，还建议提前搭建自动化测试工具。
　　自动化测试工具的构建，是有利于节省测试资源，并提前发现问题的。对于互联网产品或游戏项目来说，大多是增量开发。
　　此前已经开发完的需求或功能，在搭建自动化测试工具之后，我们可以在版本自动构建阶段就使用自动化工具跑起来，提前发现问题，保证版本质量的稳定。
　　六、推行测试先行
　　在整个质量管理的体系中，为从源头更好的保障产品的质量，我们还推行测试先行，测试驱动开发的策略。
　　开发的思维逻辑通常正向思维，而测试人员通常是逆向思维。借助测试人员的逆向思维，把一些问题前置。
　　比如我们现在通常的做法，就是大多数的时候，在需求评审完之后，会确定测试用例什么时候输出，在测试用例输出时，测试人员会输出思维导图，帮助开发提前做好一些异常、边界功能的补充，在编码的过程中就先行考虑，而不是等到版本交付后，测试过程中才来针对性的解决bug，这样会对整体代码健壮性有影响。当自测用例输出后，开发、产品和测试一起评审自测用例，有理解不一致或功能缺失，都会在开发阶段补全。
　　推行测试先行的目的，也还是从需求源头出发，利用测试的专业性，从逻辑架构上，提前规避或提前解决一些边界或异常的问题。
　　七、加强验收环节
　　质量管理一定不只是开发和测试的事情，因此，项目经理要特别重视验收环节。
　　验收环节也是整个项目研发流程中的重要步骤之一，以游戏项目为例，一个版本（或系统功能）交付之后，对应的产品人员结合美术人员需要参与版本的验收，并且输出验收的意见，或体验问题或bug。
　　因为我们是特性小组的模式，在具体负责需求的人员验收之后，整个特性小组还会参与一起验收。最后测试完成，项目的核心管理人员也会参与最后的体验。
　　这些验收环节，其目的之一就是传递给团队成员，对质量的保证，不只是开发和测试的事情，是整个项目组的事情。目的之二是确保需求开发到交付的一致性。
　　除了让项目其他人员参与到验收环节，实际上，对代码本身的验收也是一个重要环节。代码验收就是我们常说的codereview（简称CR）。
　　项目其他人员在对功能进行验收时，开发的核心团队也会对代码的质量进行评审和验收，提出的代码问题也会一并在正式转测试的时候进行修复，从而更进一步的保证转测试的版本质量稳定。
　　八、高标准要求
　　高标准要求，其实目的很明确。项目在研发期的测试，用户体量是比较小的，一旦正式上线（公测），用户体量就上来了，对于一些偶现的问题或者crash的情况，都会随着体量的增加而增加。
　　所以，要满足项目侧的标准，以及公司的质量管理体系标准。在项目研发阶段，都需要高标准要求：
　　1、在测试期间，重点抓偶现问题的解决、弱网问题的解决、crash问题的解决及性能问题。尤其是偶现问题，不仅要高标准要求，还需要杜绝侥幸心理。曾经就因为侥幸心理，为了赶时间，而搁置了一些偶现问题，使得项目上线后，不得不紧急修复各种问题，紧急更新版本，也使得当时项目的数据很糟糕。
　　2、拒绝侥幸心理，是为了更好地杜绝没有解决的偶现的bug。同时，对于crash率，更需要高标准要求。互联网产品（APP），运行稳定与否，crash率是一项重要的衡量指标。
　　针对crash率，如果上线标准crash率不高于6%，那么在测试阶段crash率至少要控制在1%以内；如果上线标准crash率不高于1%，在测试阶段则要求crash率不高于0.5%。
　　所以，高标准要求，需要重点监控crash率的情况，在研发期间的crash率要控制其远远低于上线标准。
　　九、重视测试和风险评估
　　质量管理过程有了保证之后，并不代表产品的质量最终是有保障的。过程做的好，从项目的整个周期来说，会有一定程度的缩短，也给测试提供了极大的便利，但这并不意味着就可以忽略最后的测试环节。
　　从互联网产品或游戏项目来说，测试的效用还是非常大的，这是由项目本身的特点所决定的。因此，测试是质量最后的“守门员”，从项目经理的角度来说，一定要重视最后的测试环节。
　　怎么重视？清晰定义每个需求，每个版本的转测试范围，做好目标和标准的同步。同时，关切测试提出的诉求并及时地给予认可。
　　在很多公司，测试部门的属于第三方支持团队，项目经理对于一些重要的事项，需要将测试团队考虑在内，增强测试团队的参与感和凝聚力，使其融入到项目组，成为项目的重要成员。
　　另外，专业的测试团队，在每个版本测试完成后，都会从测试的角度提出质量的风险，这方面，项目经理也尤其需要重视。往往测试团队提出的质量风险，都会直接或间接影响接下来项目的安排。
　　比如某个版本测试完成后，测试人员给出的bug分布情况和各模块的风险评估，特别指出一些系统功能模块的质量风险。一些数据或指标的提出，就会直接影响下一个版本的安排。
　　十、最关键的还是在于人
　　前面我们讲了很多，其实都是流程和具体的事情。
　　但真正的关键还是在于人。这是从软件行业的角度来说的，质量是设计出来的。如果团队有靠谱的人，有更专业，更厉害的人，那么就可以从源头避免很多质量的问题，这点其实是非常现实的。
　　带项目这么些年，这方面的感触非常之深，就是技术牛人写的代码和一般的人写的代码完全不是一个级别，其所交付的产品的质量更不是一个级别的。
　　所以，如果你发现做了上面的很多事情，产品的质量还是不达标，那就不仅仅是优化流程，对齐目标和范围的事情，要重点考虑人是否合适。
　　流程和体系是解决不了底层的质量问题的，所以最关键还是找到更合适的，更牛的人，从根本上解决质量的问题。