[发明专利]一种研发团队交付的软件产品质量评价方法

说明书

本发明提供一种研发团队交付的软件产品质量评价方法，其中具体步骤包括：用户创建问题填写字段且描述问题与填写市场影响评价指标选项、用户反馈与提交、技术部门解决问题且更新问题状态，并且系统根据市场评价指标体系自动计算市场影响分、系统在接收到问题接收人已解决问题的确认后自动计算问题的解决用时、系统根据解决用时匹配到解决用时系数、系统在市场影响分与解决用时系数的基础上计算得出缺陷舆论分。本发明具有标准统一的质量评价、引入缺陷舆论分用来用来评价、评价标准设计合理、精准评价团队效率且提高反馈问题效率。

技术领域

本发明涉及互联网产品质量评价技术领域，尤其涉及一种研发团队交付的软件产品质量评价方法。

背景技术

产品质量是产品的根基，更是企业的命脉。“当软件上线后，并不代表开发工作的结束，这才是产品真正经历检验的开始。”当用户在使用我们的产品的时候，可能会遇到一些bug，我们会收集用户的反馈，进一步完善我们的产品。

用户反馈的bug对于市场拓展的影响如何，不同的组织、不同的人都有自己的一套主观评价标准，但因为大家的“评价标准”不一致，导致不同人对同一个问题的严重程度感知不一，意见难以达成一致，形成沟通损耗、士气内耗。

以下我们从“产品交付质量”、“线上bug修复效率”两个维度，来说明现在团队中存在的问题。

线上bug量并不能完全代表交付的质量情况，这个维度只关注了量，而没有关注单个bug对市场拓展的负面影响，导致技术部门对bug影响的感知和市场部门的感知不一致，在收集缺陷反馈信息时双方易发生冲突，产生内耗。例如有A、B两个团队，在相同的bug量下，并不能代表这2个团队的质量成绩是一样的，也许A团队总是在出一些阻碍业务开展、阻碍市场回款等严重影响产品口碑和市场拓展的bug，而B团队的bug是错别字、体验优化之类的影响较小的bug。

一方面研发团队被动接受了一个时间指标，缺乏主动提高修复效率的动力，本来可以在10分钟内修复，但因为指标是2小时合格，则解决线上问题时不急不缓，缺乏紧迫感、敬畏感。另一方面，修复效率与被修复问题的价值未构成映射关系，造成研发指标成绩好，但市场的实际感知不好的情况。例如研发团队80％的问题都在要求时间内完成了修复，但是这80％的问题恰恰是对市场拓展影响不大的问题，反而另外20％对市场拓展影响大的问题迟迟得不到有效解决。造成研发部门自我感觉良好，而市场部门叫苦不迭的情况。

发明内容

本发明提供了一种标准统一的质量评价、引入缺陷舆论分用来用来评价、评价标准设计合理、精准评价团队效率且提高反馈问题效率的一种研发团队交付的软件产品质量评价方法。

本发明为了解决其技术问题所采用的技术方案是：

一种研发团队交付的软件产品质量评价方法，具体步骤如下：

步骤一：软件产品中提供用户反馈的创建问题填写字段填写市场影响评价指标选项；

步骤二：在步骤一的基础上，用户对软件产品提供的问题填写字段进行填写并反馈提交；

步骤三：在步骤二的基础上，技术部门根据提交的问题填写字段所描述的问题进行接收，技术部门对问题解决且更新问题状态“已解决”，与此同时系统根据提交的的问题填写字段所描述的问题进行自动计算市场影响分，得出市场影响分；

步骤四：问题提出人在问题填写字段进行解决问题的确认状态，系统在接收到问题接收人已解决问题的确认后自动计算问题的解决用时；

步骤五：每个解决用时的时间段对应一个解决用时系数，系统根据解决用时匹配到解决用时系数；

步骤六：系统在市场影响分与解决用时系数的基础上计算得出缺陷舆论分，从而作为研发团队交付的软件产品的质量评价指标。

进一步地，所述步骤三中市场影响分＝∑(评价维度得分*权重)，所述评价维度得分为1-5分。