研发质量系列之如何评估研发项目质量

如何评估项目交付质量

当我们交付一个项目后，很多研发人员对于自己的项目交付质量是否达标，最终的交付目标是否完成没有一个清晰的认知，好多人干了一年辛辛苦苦的把项目搞完上线了，但是却不知道自己的项目到底质量如何，在你把项目交付之后，别人却告诉你项目交付质量差你这个项目的奖金没有了，你是不是也很郁闷，所以到底如何评估一个项目质量，根据我多年经验来说基本上要从以下几个方面去评估

1.日常缺陷数

现在主流研发模式分为“瀑布模式”和“敏捷模式”又或是“瀑布+敏捷”的方式，这三种研发模式都需要对过程的缺陷数做统计，统计方式可以是：月度统计或者按照迭代进行统计，并且设置缺陷底线标准，如果超过底线缺陷数标准则需要对过程质量进行复盘，发现过程质量的问题，并对问题进行分析改进，以期望在下次的统计中能够改善，达成目标的缺陷数

2.线上缺陷数

对于产品发布上线后如果出现了缺陷逃逸，线上出现的问题则需要引起全体团队人员的高度重视，我们可以把线上缺陷分为：致命（用户无法正常访问产品界面），严重（用户核心操作流程受阻，无法完成功能闭环），一般（用户操作过程发现出现问题但是不影响正常使用），轻微（用户体验层面，操作不够友好导致操作成本高），当出现致命和严重缺陷时，必须第一时间内安排研发资源进行修复解决，必须要针对该缺陷拉上相关人员进行深度复盘，输出避免措施同时同步结论到整个研发团队，出现一般和轻微问题时需要对该问题进行及时响应问题，同时评估问题优先级排期解决该问题

3.技术文档数

如果你的项目交付或者中途换人之后，新接手的成员能够快速上手并理解原因项目，技术文档是非常重要的环节，也是能够反应项目交付质量的重要衡量标准，如果你的项目交付后，伴随的技术文档确寥寥无几，那说明过程中大家对于文档输出意识淡薄，无论是短期交付项目还是长期维护项目，如果没有相对应的技术文档，那对于后来的维护人员又或者是二次开发都是非常不友好的一件事，所以项目交付过程中的文档也是能够衡量项目交付质量的重要参考标准

4.事故发生率

项目交付给客户使用后，一个体现质量的重要标准就是事故发生率，如果说你的产品给用户使用后，隔三岔五就出现，访问报错，功能无法使用，界面无法进入这种致命和严重问题，那对于客户来说最直观的感受就是系统不稳定，那反应到研发质量就是质量不行，所以研发质量不仅仅是研发交付了就可以，同时要保证使用的稳定性，减少故障率一样很重要，这就需要你从系统架构层面考虑服务可用性设计，从流程机制层面保证故障恢复效率，增加自动化测试减少迭代发布改动导致的故障发生率

5.交付延期率

对于市场来说时间就是金钱，如果一个产品能够快速完成开发并进行市场验证，那绝对能够提前占领市场获取先机，所以项目交付往往不延期也是质量另外一种呈现方式，一个好的项目管理，能够在项目开始前就提前规划好项目交付的关键路径，提前识别项目中可能存在的风险，并且把各个阶段的排期都精准的计划出来，如果一个项目能够前期就能有一个完成计划，交付延期率也能够大大降低

6.体验问题率

用户体验问题也是能够反应交付质量的重要衡量标准，如果一个项目交付出去后，结果用户反馈了一大堆的体验优化问题，这些问题大多是在研发环境就能够识别的问题，结果确跑到了用户端，说明过程中大家没有良好的用户思维，没有从用户的角度去看待自己研发的产品，说到底就是设计不够人性化，没有从最终使用的角度去考虑功能设计，最终这些问题自然就传导到了客户上