从0到1创建高效的产品缺陷管理流程（2）：如何设置合理的Bu

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