01 背景
谈到质量管理,这其实是一个比较大的话题,因为到各行各业都有其质量的定义和要求,也包括质量管理的方式方法。
鉴于本人长时间在互联网行业,因此本文聚焦谈的是互联网项目如何做好质量管理。
互联网产品以快著称,敏捷开发,快速迭代。不过这是精品1.0时代下的产物。在那个时代,因为需要快速上线,抢占市场份额,这就使得发布的产品是某种程度上牺牲了产品的质量的。所以,那个时候有一个名词,叫做有损发布。
随着行业的不断发展,互联网行业的产品已经不再是以快著称。进入精品4.0时代后,提倡的是匠心思维。每一款产品正式发布时,对质量都是高标准,高要求。因为在一片红海时代,任何以牺牲质量为代价而发布的产品,都可能带来毁灭性的损失。
02 质量管理的原则
或许正是因为行业的演变,也让质量管理成为了项目整个生命周期的重中之重。我们知道项目管理四要素:时间、成本、范围和质量。在这个铁三角中,质量处于中心位置,项目经理在安排各项工作时,需要全局考虑,质量是默认必须要保证的,可以调整的是时间、成本(人力)和范围。这是质量管理的一个原则之一。
在实际项目推进过程中,质量管理的第二个原则:产品的质量是设计出来的,不是测试出来的。千万不要忽略过程,而把最压力放到最后的测试环节。项目经理不能最后只抓测试部门对质量的测试,更需要抓产品源头、开发设计、过程验收等全链条参与人员对测试的重视程度。
由此,也引出质量管理的第三个原则:质量管理是贯穿整个项目生命周期的,是一个体系化的事情。质量管理从项目启动之初就需要开始,而不是某个阶段,或某几个阶段才开始。要确保产品质量的稳定,在整个项目周期都需要做好质量的管理。
质量管理的第四个原则:一切的质量管理过程,都要提前做好规划,眼见为实。尤其是针对手游性能体验方面,优化前后的版本,是可以非常直观地感受到的。此外,眼见为实,也要求测试的整个过程可视化,做好质量风险评估,抓关键点。比如说最直接的,开发人员说改了什么什么bug,结果版本里面发现压根就没有改。所以,要实际地看交付的版本,眼见为实。
04 质量管理的方式方法
那怎么来做好质量管理呢?从我自己的理解,我梳理了十大要点:
一、明确目标
项目有项目的目标,质量管理,同样有质量管理的目标。
对于质量管理来说,目标包括目的和标准。质量管理需要有明确的目的;质量管理需要有明确的标准。
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分布情况和各模块的风险评估,特别指出一些系统功能模块的质量风险。一些数据或指标的提出,就会直接影响下一个版本的安排。
十、最关键的还是在于人
前面我们讲了很多,其实都是流程和具体的事情。
但真正的关键还是在于人。这是从软件行业的角度来说的,质量是设计出来的。如果团队有靠谱的人,有更专业,更厉害的人,那么就可以从源头避免很多质量的问题,这点其实是非常现实的。
带项目这么些年,这方面的感触非常之深,就是技术牛人写的代码和一般的人写的代码完全不是一个级别,其所交付的产品的质量更不是一个级别的。
所以,如果你发现做了上面的很多事情,产品的质量还是不达标,那就不仅仅是优化流程,对齐目标和范围的事情,要重点考虑人是否合适。
流程和体系是解决不了底层的质量问题的,所以最关键还是找到更合适的,更牛的人,从根本上解决质量的问题。
05 归纳总结
上面介绍了十大要点,助力做好质量管理。总结归纳一下,要做好质量管理,三个维度共同发力:
一、体系和流程
每个公司都会有自身的质量管理体系,借助公司的质量管理体系,可以有效地指导质量管理。若一些公司没有质量管理体系,项目经理可以根据实际情况,带领项目团队搭建一个质量管理体系,或者最简单的,制定一个最基本的质量保障标准。
目标,范围这些都可以归纳到整个项目的研发流程中,参照如下图:
项目经理需要严格执行研发流程中的每个环节,并跟进落实到位,同时以质量管理体系为参照标准,做好质量管理。
二、工具建设
工具的重要性不言而喻,在上面十大要点中,也有特别地提及。
项目经理需要有意识的推进或落实对质量管理有帮助的工具建设。
三、核心是人
人的能力高低、代码能力的深浅、技术经验丰富等,都是质量管理的有力保证。项目的质量管理中,最不可忽视的就是团队成员的能力。
作为项目经理,不能指望着从目标、流程、体系、工具等这些方面提升对质量的管理,如果一旦这些都努力做到了,产品的质量仍然没有明显的变化或提升,项目经理需要果断的从人员的维度进行考量,向核心管理层提出招聘经验丰富,能力更高的人,从根本上提升产品的质量。
06 结语
最后,我想说,质量管理的终极目标是挑战零缺陷。
“零缺陷”思想,是早在20世纪60年代,被誉为“全球质量管理大师”的菲利浦·克劳士比提出的,并在美国推行零缺陷运动。
克劳士比的“零缺陷”并不是说绝对没有缺陷或缺陷绝对要为零,而是指要以“缺陷等于零为最终目标,团队成员的每个人都要在自己工作职责范围内努力做到无缺陷”。
这其实是要求我们要变被动为主动,在设计之前,就做好设计的防患措施,为设计高质量的软件打下坚实的基础,是要求项目团队人员具备更高的视野,从技术的角度出发,提出更多、更实际的设计质量防控的措施。
一个项目的质量,是需要依靠整个团队的共同努力,从需求开始,产品人员就要对需求的设计、各系统的关联考虑得更周全。
开发人员要对底层框架设计,编码规范,异常情况的考虑更细致。产品人员验收环节深入的验收,确保需求的实现符合预期。
测试人员要对测试分析,风险预判更深入、更全面,在测试总结分析时,要追本溯源,找到问题的根源,分析后提出防范措施,并加以执行。
因此,“零缺陷”是一个体系,不是依赖于某个人、某个团队就能做好,需要围绕产品的整个开发链的所有团队、所有人都参加进来,同时需要有高层领导的支持和参与。
本文转载自公众号,原创 徐州起航 项目管理跃迁
创业项目群,学习操作 18个小项目,添加 微信:80709525 备注:小项目!
如若转载,请注明出处:https://www.ya58.com/4838.html