客户要求我们对我们遇到的每个错误进行时间估算。
尽管我们确实有一个固定的错误修复时间表并为此分配了时间，但我们没有为我们拥有的每个错误分配时间。简单地说，我们已经确定了我们的 bug 的优先级，并确保在分配的时间内修复最高优先级的 bug。
我不喜欢将时间分配给错误，原因很简单：
我们应该如何解决这个问题，我们不想提供每个错误的小时数，而只是一个关于修复哪些错误的时间框架？
你如何为你的 bug 分配时间？它有效吗？值得花时间和精力吗？
我能给出的唯一答案是非常保守。猜猜需要多长时间，并将您的猜测乘以四。用它作为你的估计。正如你所说，很难弄清楚事情需要多长时间才能解决，最好说这需要比实际时间更长的时间，而不是因为你不够保守而被抓到“超过你的最后期限”。
我工作的公司经常收到客户不合理的要求。 要记住的关键是客户希望了解情况。 我们发现最好的方法是状态报告。
所以，我们首先很好地解释了我们的立场。在您的示例中，这将是这样的：
我们有一个固定的时间表来修复我们项目中的错误，我们在历史上一直保持按计划进行的良好记录。但是，详细说明每个错误需要多长时间才能修复的过程很容易出错。我们很乐意为您提供关于已修复的错误和已测试的修复的每周更新（或每周两次或每天两次，具体取决于客户）。
但是，我确实认为最好尝试估计每个错误需要多长时间才能修复。这样做的原因是您需要了解修复所有错误的总时间。如果您无法估计修复各个部件需要多长时间，您将无法获得准确的估计。当然，这些可能是粗略的估计（估计不超过花一个小时研究问题）——你不想浪费太多时间进行估计。然后我通常会额外考虑 20%。所以假设错误的估计是 3 天、5 天和 2 天。然后我会向客户报告我们应该能够在 12 天内修复错误。当然，您可能需要花更多的时间来测试和重新包装您的产品，然后才能为他们提供可交付成果。
不要从估计修复错误需要多长时间的角度来考虑这一点，因为你不可能正确估计。
从管理客户愤怒的角度考虑这一点。如果您告诉他们这些错误根本不需要时间来修复并且最终需要 3 个月，那么您的客户现在会对您感到满意，并且将来会对您感到愤怒。
如果您告诉他们这些错误需要 3 个月才能修复，而他们实际上需要 3 个月才能修复（他们会这样做），那么您的客户现在会很生气，并且将来会对您感到满意。
我通常会说 bug 根本不需要时间（2-3 天似乎是一个很好的安抚数字）。
它应该与估计您拥有的任何其他任务相同。将其分解为尽可能小的任务，并尽可能准确地估计这些任务，并为意外情况进行填充。然后给他们一个范围，这样你就不会被限制在没有明确定义的任务上的特定日期。估计修复错误的时间和估计实现具有模糊需求的功能的时间之间没有区别。
你是对的，估计通常是不准确的。
也许您想问他们，如果每个错误未修复，他们会花费多少。然后你可以执行适当的计算来确定它们是否应该被修复，以及你（或者实际上，他们）有多少时间可以投入到每个 bug 上。
为什么不直接为错误严重程度选择几个波段，例如 1 小时、1/2 天、1 天、1 周并针对它们进行分配。通常你会对一个错误有一种感觉——那些你不知道的错误，把最坏的情况算出来！
由于您引用的原因（调查时间太长等），我认为您不会希望在比这更精细的水平上进行估计。
我不认为这是浪费时间。您的客户想要知道的不仅仅是错误的数量和它们的优先级——他们想要了解还有多少工作要做。
在任何情况下，这都不应该导致您产生更多的错误。你不应该急于解决这些问题。如果您估计 1 天而需要 10 小时，那没关系。如果您估计 1 周并花了 2 小时，那么结果很好！
这只是一个估计练习！
通常我们会同意必须为特定版本修复哪些错误，然后定义修复所有错误的时间范围。对于每个单独的错误，修复可能需要多长时间存在很多不确定性/可变性，但这往往会导致更多错误的平均数。对于某些您知道需要更长时间的错误，可能会给出一些估计，例如，如果您需要为其编写模拟器或测试框架。
如果这些是已发现并报告的错误，那么您应该能够估计修复它的时间（以及重新测试的时间）。估算的置信度可能与您在估算上花费的时间成正比，或许可以向客户解释这一成本。
如果有许多相关的小错误报告，也许您可以将它们合并为一份综合报告。这可以避免客户纯粹根据个人估计来挑选要修复的错误。