我们都知道,只要是软件就会存在某些缺陷,这些缺陷有轻有重,如果没有得到及时和有效的解决,一些缺陷可能会造成灾难性后果,而另一些则比较轻微,几乎所有人都不会注意到它。

像这个宇宙中的大多数事物一样,软件缺陷的修复也存在一条收益递减规律:除非您有无限的资源来分配好所有的缺陷修复任务,否则您必须将注意力集中在具有最高 ROI 的缺陷修复上。那么问题来了——“如何判定这些缺陷?”


...

在一个企业中,可以同时驱动开发团队开发方向的因素有很多,这些因素可以是销售团队、QA团队、财务部门、最终用户和在线媒体如博客、推特、论坛以及传统媒体等等,实在是太多了,而且所有这些因素都很重要(至少大部分都是如此)。比如说一个安装在电视台广播系统的软件,在黄金时段出现了缺陷,那我敢肯定这一定是领导层想快速解决的第一件事。如果您没有媒体方面的因素驱动您先处理哪种问题,那么就把全部注意力先集中在您认为最重要的问题上吧。

在这篇文章中我将用影响范围和严重级别来衡量缺陷等级,不用紧急度和业务价值衡量是因为紧急度和业务价值并不能准确反映出增加新功能和修复缺陷之间的重大差异。

  • 影响范围:受影响的用户数量或受影响的系统数量
  • 严重级别:缺陷的重要性,即造成数据丢失、数据损坏、外观问题等等

当然这只是我个人衡量缺陷的两个标准,您还需要具体问题具体分析。


影响范围


等级1:影响的用户非常少/影响的系统功能范围很小

等级2:影响一小群用户/一小部分系统功能

等级3:影响一批用户/系统功能

等级4:影响大量用户/大范围的系统功能

等级5:影响大多数或所有用户/更大范围的系统功能


严重级别


等级1:无关紧要的问题或某些功能不可用,但有一个简单的解决方法

等级2:辅助功能不可用,但有合理的解决方法

等级3:重要功能不可用,但有一个合理的解决方法

等级4:重要功能不可用,没有解决方法

等级5:数据丢失、数据损坏或系统不可用


影响范围×严重级别=优先级

...

处理方案


很多企业不知道如何处理缺陷的优先级导致系统陷入瘫痪状态,如下图所示,根据优先级判断如何处理缺陷。

...

上图就是一个缺陷卡,通过平衡优先级决定先处理何种缺陷。


团队协作促高效


通过以上方法可以轻松搞定缺陷处理的优先级,当然,上图只作为参考不是准则,到底如何确定还需团队协作,只有团队中每一个人的意见都达成了一致才可实施。