我在上一篇文章:《从0到1创建高效的产品缺陷管理流程(1):缺陷是什么? 如何建立缺陷管理流程?》中对缺陷管理的流程进行了介绍。确认流程后,下一个问题就是如何合理的分配我们的资源来处理缺陷问题?
我们都知道,软件产品就中的缺陷是难以避免。 这些缺陷有轻有重,有一些缺陷如果没有得到及时和有效的解决,可能会造成非常严重后果,而另一些轻微的缺陷,即便没有修复几乎所有人都不会注意到。
这就像大多数事物一样,软件缺陷的修复也存在一条收益递减规律:除非您有无限的资源来分配好所有的缺陷修复任务,否则您需要优先将资源集中投资回报的缺陷修复上。那么问题来了——“如何确定合理的优先级?”
不要浪费时间去评估每一个缺陷问题
我曾经见过一些产品开发团队,他们会把所有已知的缺陷问题全部罗列出来,然后仔细评估每一个缺陷的严重程度,是否可以重新,发生的频率,缺陷修复的需要的工时,缺陷可能出现在哪些代码中等等。 这些评估看着好像很合理,但是浪费太多时间了。很多时候,评估的时间甚至多于问题修复的时间。
所以,当我开始带领产品开发团队时,我试图找到更有效的方式。
制定一套Bug处理准则
要高效的处理缺陷问题,就需要建立流程,要建立流程,就需要有制定一套团队间通用的Bug处理准则。这样,我们不用再对每一个缺陷问题进行详细的评估,而是按照我们制定的准则快速处理。起初由于理论与实践的差异,我们的准则可能无法适应于所有问题,但是随着实践,我们的准则变得越来越合理,越来越高效。因此在我们开发缺陷产品系统:Bugout的时候,我们甚至设置可以基于我们的准则设置一套自动化的Bug处理优先级评估功能,让我们的每一个缺陷问题自动按照预设的评判标准设置优先级别,并按照产品模块自动分配给开发人员进行处理。
我们对收集到的缺陷问题设置了两个维度:影响范围 和 严重级别
- 影响范围:受影响的用户数量或受影响的系统功能数量
- 严重级别:缺陷的重要性,例如:成数据丢失、数据损坏、外观问题等等
制定等级标准
以下是我们依据我们的产品形态设置等级标准,读者可以参考,并依据自身的实际情况来设置自己的等级标准:
影响范围
等级1:影响的用户非常少/影响的系统功能范围很小
等级2:影响一小群用户/一小部分系统功能
等级3:影响一批用户/系统功能
等级4:影响大量用户/大范围的系统功能
等级5:影响大多数或所有用户/更大范围的系统功能
严重级别
等级1:无关紧要的问题或某些功能不可用,但有一个简单的解决方法
等级2:辅助功能不可用,但有合理的解决方法
等级3:重要功能不可用,但有一个合理的解决方法
等级4:重要功能不可用,没有解决方法
等级5:数据丢失、数据损坏或系统不可用
影响范围×严重级别=优先级
我们将影响范围和严重级别两个变量相乘,得出了优先级分数,并依据分数设置优先级别:
然后,我们根据优先级别设置Bug处理准则:
- 最高优先级:必须立即处理,插入到当前的产品迭代版本中,高于其他需求开发。
- 高级优先:快速处理,插入到当前的产品迭代中,但是低于部分本次迭代需求开发任务。
- 中级优先:处理,可以随着下一次产品迭代进行处理。
- 最低优先:选择性处理,根据迭代进度可放入下次迭代或者下几次迭代中进行处理。
这种方法的关键优势在于,它大大减少了用于讨论如何处理每一个缺陷的时间。另外,团队考虑的两个因素影响范围和严重程度是相对客观的,减少了我们由于主观因素带来的误差,让衡量标准更容易判断,也就可以更简单和高效的制度Bug处理优先级别。
相关阅读
从0到1创建高效的产品缺陷管理流程(1):缺陷是什么? 如何建立缺陷管理流程?