几乎每个报告的错误都是高优先级错误[关闭]

我在处理多个软件项目时注意到一种模式：报告的大多数错误都具有高/非常高的优先级。我问了一些同事为什么会发生这种情况，他们提到如果一个bug的优先级不高，那么该Bug很少会引起开发人员的注意，这确实是有道理的。

因此，我想知道这个问题是否很普遍，或者我是否运气不好。我在Google上进行了快速搜索，发现一些团队实施了错误报告指南或拥有单独的“错误分类”团队。如果您已经面对并解决了这个问题，那么对您有用的方法是什么？

该问题专门针对“优先通胀”问题：如果您遇到这种情况，那么采取哪些措施可以有效解决此问题。

我向一些同事询问了可能发生的情况，他们提到如果一个bug的优先级不高，那么该Bug很少会引起开发人员的注意，这确实是有道理的

实际上，如果您问我，它不是。优先级越高（使用的水平），您拥有的信息就越多。如果您实际上只有一个优先级，那与根本没有优先级是一样的。

而且，由于您仍然要解决相同数量的错误，并且需要执行相同的工时，因此，将使用其他启发式方法，可能是空的-“先到先得”。因此，您现在有了一个错误优先级指标，除了那是到达时间并且不再受您控制。

这可能是没有足够的资源分配给错误修复的征兆（存在一些策略，例如“ 在修复错误之前没有新功能 ”，可以在此有所帮助。乔尔批准；理解限制和后果是业务决策）。

在我工作的一个项目中，传入的错误被累积在“无优先级缓冲区”中，每个星期一我们将审查错误列表，估算难度（非常粗略的估算；更多时候，我们通常只输入“ Average”），按可用时间对它们进行排序。这确实会降低无聊的，无趣的或被认为是硬错误的列表；为了弥补这一点，主管和市场营销人员每周有一定的信用额度，可用于抵销喜欢的错误的优先级，并为未解决的错误提供报销（这限制了可以推迟多少个开发人员期望的错误） 。

还可以合并，取消和拆分错误；我记得有一个模块是如此无可救药地存在缺陷，以至于我们将大约二十或三十个错误报告沉入了一个“从头开始重写此内容”，然后拆分为“清楚地陈述了该错误内容的输入和输出”，“编写测试”确保输入和输出符合规范”，依此类推。最后一个项目是“将旧代码打印在再生纸上，将其放到草坪上，放到火上烧”（我们也是这样做的。我记得那感觉很好。我们轮流悼词；这很有趣）。

经过一番讨价还价，我们有了本周的待办事项清单，分为“将要做”，“可能要做”和“不能做”这两个清单，这些清单已推迟到下周。这是另外一些讨价还价的地方：我们说要花50个小时来分配错误，而我们有95％的把握要修复前20个错误。管理层强烈希望修复第21个错误，并且没有信誉。然后，我们会建议将该错误与“将要做的事情”列表中的一个交换，或者有人会说“让我离开FooBazFeature子团队几天，然后我会做的”，或者我们会说“我们需要更多人手”。

该系统的确没有人满意，但这（至少在开发人员中）被认为是一个好兆头。

出现的其他一些负面模式是经理方面的“如意算盘”（“您指出错误57212需要八个小时。这是不可接受的。将其设置为四个”）和“由菲亚特调试”（“随您便”但是这40个错误必须在下周的大型演示之前修复。您不能拥有更多的时间，您不能拥有更多的人”）。还有Boxer综合症（“我会更加努力”），这种综合症在短期内效果很好，但通常会导致开发人员抓狂或离开而前往绿色牧场。

如果您在用户分配优先级更高的bug时遇到此问题，那么唯一可行的解​​决方案是分类机制。所有错误都会以他们喜欢的优先级进行报告，但是一些可怜的经理将不得不检查每个新报告的错误，并将其优先级重置为合理的水平。

一段时间后，您的用户将收到消息，或者您可以更改报告系统，以使每个错误都具有默认优先级。如果他们希望升级，他们将不得不与某人联系以解决问题，这需要一些理由。仅这个事实就将导致所有错误的99％被用户取消升级。

显然，您有更多的错误无法处理，因此也许您需要着手进行错误修复汇总以清除积压的产品。这将向用户显示他们的错误将得到修复，而无需将它们标记为“这次超级重要”。

免责声明：我还没有使用用户报告的错误优先级恶作剧的经验。我知道这个问题要求这样做，但是这可能有助于了解局外人的观点。

您的问题不是您有太多高优先级的错误。您的问题是您有太多人直接控制Bug优先级。如果每个用户都可以直接为其错误分配优先级，则他们几乎会自动将其问题报告为高优先级。

您可以这样设置，以便必须由经理或服务台无人机来配置错误优先级，但这可能会导致偏爱和社会工程，在这种情况下，客户端会由于其状态或知道如何处理消息而人为地获得较高的优先级使它们看起来更重要。这也需要大量劳动。

有一个中间点，您的用户可以控制优先级，但是这种方式使利用该系统更加困难。本质上，您迫使用户使用模板来报告错误。他们首先选择一个类别：

1. 当我做某事时，程序变得不可用或崩溃。
2. 该程序具有影响功能的图形缺陷。
3. 该程序不允许我执行应做的事情。
   该程序使我可以做一些我不应该做的事情。
4. 当我做某事时，程序给出错误的结果。
5. 该程序花费时间太长，无法执行某些操作。
6. 该程序具有图形缺陷，不会影响功能。
7. 该程序的缺陷不属于上述类别之一。

举例说明：

1. 当我收到包含希伯来符号的消息时，iPhone崩溃了。
2. 我的Android锁定屏幕以这样一种方式旋转，即其中一半落在屏幕上。
3. 即使我输入了正确的密码，我的Android手机有时也不接受我的锁屏代码。
4. 当我尝试导航到PhoneHub.net时，手机将我重定向到成人网站。
5. 当我打开Facebook应用程序时，即使在快速连接且没有其他应用程序运行的情况下，也需要一分钟才能打开。
6. 您的应用存在拼写错误。
7. 我在您的程序中发现一个安全缺陷，并想报告。

如您所见，这些错误中的每一个都具有不同的严重性等级，并且根据该严重性对类别进行了大致排序。然后，您可以根据类别，报告错误的人和描述中出现的关键字为每个错误分配优先级。类别7中的错误应手动分配其优先级。

注意，这可以完全自动发生，您应该让它自动发生。实际上，自动化是这里的关键。用户很容易高估自己对业务的重要性，因此，在将错误报告为比应有的优先级时，他们不会看到问题。他们不太倾向于故意将其错误放在不同的类别中，因为这要求他们基本上是对错误的谎言。

用户可能仍然会在错误的类别中输入错误。从版本1.0开始，您应该做的第一件事是显示一条友好的消息，鼓励用户提供有关该错误的准确信息，以帮助开发人员更快地找到并修复该错误。大多数用户将理解并停止错误报告错误。一些用户可能仍然继续提供错​​误的信息。发生这种情况时，请通过邮件向那些用户发送温柔的提醒，准确的信息很重要，并且请不要滥用系统。如果他们继续伪造记录，则向他们发出警告，告知他们故意滥用系统，并且继续滥用将导致其错误自动分配给较低的类别。如果它们仍然存在，则可以调整其错误倍增器。

您可以在高通量支持情况下看到该系统的各个部分：微软，Facebook，谷歌，大型游戏公司等大型科技公司，其中有很多用户如Valve和Blizzard，某些政府，...虽然我不确定在幕后工作中，您会注意到他们的面向用户的支持系统具有与我在此处建议的界面类似的界面，并带有严格的类别系统。

正如人们所说的，这就是为什么报告错误的人没有分配优先级的原因。您的开发团队应控制自己的任务分配（在上级管理层设置的范围内）。所以，有人进一步上涨说“工作这个应用程序，修复此功能，使其更好地在做这个 ”，和球队获得来决定如何去说，因为他们提供了评估如何在需要的技术专长的人最好实现管理层想要的。

报告错误的人员应该分配影响或严重性级别，这些级别已定义范围。您可以轻松地将人员召集为不遵守商定的严重性级别，因为您拥有针对这些级别的重要证据。例如：

1. 功能完全丧失
2. 功能部分丧失
3. 普遍降低效力
4. 局部降低效率
5. 烦恼或阻碍（存在解决方法）
6. 化妆品
7. 默默无闻的探索性测试中没有人发现

首先，您可以将这些级别用作钝器，以指出某些标题文本的未对齐不是1级错误，因为它不会使整个应用程序无法使用。一旦他们了解了这个想法，就可以对其进行更细粒度的介绍，并开始辩论在更新此文本框中是否出现故障的情况是第5级，因为您可以通过右键单击文本框几次或将其级别为4来解决此问题。因为这使“会计”中的每个人都变慢了，因此每小时他们处理的表格更少。

一旦获得有用的，可衡量的有关该漏洞对您的组织有多严重的信息，分配优先级就变得显而易见。当前导致组织最大问题的原因是利润损失，公众形象受损，员工不满等，而这一切都将成为高优先级，而您将为此而努力。

它有点像这样：

经理：你在做什么？开发人员：这个低优先级任务经理：您不应该从事高优先级任务吗？

客户：什么时候可以修复我的错误？开发人员：低优先级，我们有高优先级的任务。客户：哦，那就把我的错误状态设置为高优先级。

这将导致优先级不断提高。我看到您已经从高优先级转到非常高优先级。接下来将是：

1. 超高优先级
2. 超高优先级
3. 超级超级超高优先级。
4. 超级超级超级超级高优先级。

等等等

是的，这是正常过程。只要分配优先级不涉及任何成本，并且呼叫方具有影响力，他们当然会尝试以最快的方式解决问题并设置最高优先级。

基本上有两种方法可以解决此问题：

1. 将控制权从客户端转移到优先级上。
2. 为客户分配较高优先级的成本。

可以为系统添加越来越高的优先级，特别是在Jira的情况下。给新的高优先级越来越愚蠢，但可怕的名字可能会增加霍桑效应对各方做出的优先级选择质量的影响。如果最高优先级的名称确实很古怪，则效果可能是永久的。最终，当某人选择优先级时，他们必须权衡选择“死亡之虫”优先级与获得应有的重视所带来的社会后果。因此，实际上优先考虑的是CTO在客人面前在家中发生的事情，或其他具有同等可见度的事件。

介绍支持请求的费用。您只能允许用户报告给定时间段内X个高优先级项，Y个中优先级项和Z个低优先级。

当然，这也意味着开发团队和管理层将必须保证实际上其中的某些数目将得到固定-所有高优先级项目，大多数中优先级项目，以及（也许）某些在特定时间范围内的低优先级项目。

但是，如果这行得通，那么管理层实际上就要买账了，否则整个工作就浪费了时间。

归根结底，您的特殊情况似乎是一个问题的征兆，即您的管理层没有分配足够的资源来处理支持问题。如果问题得到及时处理，那么我认为这不会发生。

在我工作的第一家公司中实施了类似的操作，因为支持流程无法正常运行，并导致了一种情况，如果一切都紧急，什么都不是。在我们的案例中，在控制了内部情况之后，新的软件开发经理对客户可以提出的高优先级问题的数量进行了硬性限制，具体取决于客户在支持合同中支付的金额。如果超过限额，他们要么会掏出更多现金，要么优先解决支持问题。

在将IT视为辅助和/或外包IT的大型公司中，这种情况非常常见。商界人士不了解软件也不在乎，他们关心的只是“他们”的错误已在昨天修复，无论它有多重要。他们没有意识到或关心，还有一百个其他用户也在提交错误，而一个由5名开发人员组成的团队可以修复这些问题。

糟糕的管理，尤其是那些不能说“不”或只是让业务人员设置错误优先级的非IT经理，会加剧这种情况。（无论哪种情况，都说经理没有做他/她的工作。）大多数经理会优先考虑上次联系他们的错误，因为“这很紧急”。最终的结果是，开发人员最终会从一个bug跳到另一个bug，从而解决了一个错误所花费的时间更长（上下文切换），并且最终每个人都不满意。“当每个错误都是高优先级错误时，没有错误是高优先级。”

我一直处在这种情况下，通常逃脱它的唯一方法就是逃脱。错误报告准则总是被忽略，因为用户没有给出。尝试引入错误分类的尝试将被拒绝，或者将被实施，然后在用户下次致电您的经理来抱怨“他们的”错误时将其忽略。

基本上，如果开发人员无法控制优先级，那么您已经迷失了方向。

作为公司，您要解决具有最高重要性/成本比的问题。用户决定重要性，工程决定成本。如果用户对所有错误都赋予相同的重视程度，那么成本就很重要。

实际上，这意味着您将优先级定义为重要性/成本，并且不允许用户或开发人员直接设置该优先级。双方都没有全貌。

如果用户决定对所有问题都给予同等重要的评价，那就可以了-但这意味着工程（成本）可以决定要做什么。向他们解释重要性是他们影响（但不能决定）优先级的唯一方法。

一些因素...

• 通常，报告该错误的人不了解大局，也无法确定该错误的重要性。
• 通常，低优先级的bug永远不会被分类或考虑，因此最好给优先级过高，让进行分类的人降低优先级。
• 作为开发人员，我经常查看错误报告，发现该错误背后存在一个非常高的优先级问题，但是进行分类的产品经理并不关心该错误。

因此，我认为所有错误报告都需要由一到两个有经验的开发人员快速查看，将他们的想法添加到错误报告中，然后需要对错误进行分类。期望发现错误的人能够在发现错误的时间点设置有用的优先级，这只是要求太多。

提到的所有错误很可能都是高度优先的。我参与的项目资金不足且指定不充分，当测试开始进行质量检查时，用户只是放弃报告优先级低的项目，因为他们知道，如果项目的核心功能存在拼写错误或可用性故障，则会浪费时间完全用软管 如果您的自动行李系统将购物车撞在一起并破坏行李，谁在乎标签上的字体是否太小2pt？

在这种情况下，项目失败了。如果您怀疑这是有可能的，那么您需要全心全意地与那些报告缺陷的人一起找出来。如果人们夸大错误报告，那么其他答案将有所帮助。如果这些错误与所报告的一样严重，那么您需要采取极端的措施。

多数人已经说过了，但我将“ bug动物园”列表精简为以下内容：

答：该错误会阻止用户陷入困境，给出错误的输出，通常会使系统/功能/功能无法使用。那是一个“高优先级”错误。

B：其他的。 这些是“可协商的”错误。

可协商的错误有很多问题（按照您自己的特定顺序排列）：

1：影响安全性的错误；

2：影响可用性（适用于预期目的）的错误；

3：影响美观的错误；

4：影响性能的错误（也许是可用性的一部分？）；

5：破坏您作为专业程序员的敏感性的错误；

6：降低用户信任度的错误；

因此，这就是我们没人真正生活的乌托邦式世界。 叹息 为了完成对OP所述问题的回答，在整个软件行业中，开发工作通常都处于每个错误都被优先考虑的状态-一个超级危险特别。您知道他们对“特殊”的评价：每个人都很特别时，没有人特别。

基本上，此问题根源于分散优先级的问题。总是有一定数量的人具有优先团队工作量的能力，而3人太多了。因此，由1个人负责有效的分类。在咨询开发负责人/架构师之后，应该是经理/分析师。而且该过程非常简单，并且也可以应用于功能请求。进行开发的成本是多少？预期结果对企业的价值是多少？该功能的输出是分配的优先级。

当然，每个用户都希望首先解决他们的问题。只要您允许，就混乱了。您没有有效的优先级。您需要由具有授权（在必要时与他人进行咨询）的单一人员来完成此任务，该人员应对所有问题和业务需求具有可见性，并有足够的能力来收集所需的业务和IT专家建议，从而生成合理准确的指标估计值以上。

冒一个明显的风险，我将假设没有错误跟踪软件将默认错误设置为高优先级（或已设置为此设置）。

恐怕在没有控件的情况下，这是多个团队，客户等进行报告的默认方案。如果滥用现状，那么肯定会进行某种分类程序。

在过去，我很快见到了一个很好的效果，那就是P1（优先级最高的错误）产生了大量的管理警报。如果系统被滥用，则会立即崩溃。或者，如果真的很紧急，那么电话会议或物理会议会尽快解决此问题。

我在这里假设您是在谈论所有错误，而不仅仅是最初开发中的错误。如果您通常是一个绿色领域的发展大军，那么在最初的Alpha版本发布之后，大多数错误都具有很高的优先级，这当然并不少见。

您不能仅仅拥有优先权，并期望一切都能神奇地解决。有时人们会自己解决，但并非总是如此。

为了正确分配优先级，必须明确定义每个优先级的构成。这些标准必须是客观的，以避免偏爱漏洞和政治优先次序。如果不遵循客观标准，则需要让团队遵循。

确实没有解决的办法-如果您无法确定错误发生在哪里的客观标准，并且如果人们故意拒绝遵守这些标准，那么您可能还没有提交者分配的优先级-要么没有优先级，要么拥有第三方按照其他人的建议分配优先级。仅当提交者合作时，众包数据才有效，并且不会积极破坏数据收集。

如果由于无法创建客观标准而引起困难，则可以使用相对标准：

• 对所有错误进行简单的排队。用户可以在队列中的任何位置插入错误。如果他们认为自己的错误比它下面的所有内容都重要，那么他们应该只在给定位置插入。错误修复程序从队列的顶部开始。
• 假设您已经具有一组分类良好的错误，请告诉所有人将错误优先放置的条件X是，它必须比所有优先错误更重要X-1。
• 告诉提交者，具有优先级的bug的数量绝不能X超过具有优先级的bug的数量X-1。

但是听起来您的问题不是定义，而是提交者认为低优先级bug无法修复的信念。据推测，您不能以其他方式说服他们，因为（根据您的说法）他们的信仰实际上是有根据的。然后，为什么要让他们提交这些错误？最后只是忙碌而已。例如，您可以在达到一定数量的活动错误之后，告诉每个人不要打扰报告，除非他们觉得自己发现了比大多数未解决的错误更重要的东西。当然，这只是队列长度上限的队列解决方案。