我最近上了一门关于估算软件的课程。我一直对一门本质上不精确的科学非常谨慎，因为我坚信可以通过估算创造价值。在这两个小时的课程中，我发现了如何提醒大家在不过度分析和思考的情况下制定预算。很常见的例子我们经常听到项目经理和开发人员之间这样的对话：PM：“你能给我一个预计的时间来开发某个功能吗？”程序员：“一个月”PM：“一个月太长了，我们只有一周！”程序员：“***三周”PM：“我最多只能给你两周”程序员：“好吧，成交！”呵呵！猜猜接下来发生了什么？如果你能在做决定之前快速考虑预算和目标之间的差距，那么你就不会那么仓促，下次也不会被烧死。结论大相径庭的图课程中有这样一张图，强调了准确估计的重要性。我把原图粗略的重新画了一遍：图片表达的中心思想是我们要以准确估计为目标。对此我不置可否。事实上，我想说我们的估计从来都不是100%准确的。为什么？预测本身是一门不精确的科学。虽然有很多很多方法（可能比我们需要的更多）可以很好地进行估算，但总会有一些不确定性。是的，100%准确率自然是最好的，但在实践中，这是不可能的。不仅如此，低估时间的代价更是难以承受。让我们先来看这个例子：项目可能会失败（最坏的情况）。经常熬夜高压和焦虑项目可能会延迟质量受到影响成本增加客户不满意有时估计时间结果很重要。因为如果你高估了，功能仍然可以以更多的时间为代价来完成。但如果你低估了时间，那么你可能连指定的功能都完成不了。事后估算项目异常混乱的原因之一软件项目中的混乱源于准确的估算。你知道是什么导致了软件项目的混乱吗？原因是项目进度落后了！我们把这种现象称为正反馈效应（不要照字面意思，并不是所有的正反馈都是好的）。另一种估计方法是给出一个范围。暂时忽略这样做的好处/成本，这里是一个使用范围估算***并发现低估的例子：这是一个高估的例子：曲线下的阴影区域代表工作量、成本和进度，并且它看起来比上图中高估所需的要少得多。当然，100%的预测准确率自然是最理想的，但在实际操作中，错误成本实在是太高了。您的团队需要加班和熬夜吗？下面这句话是我在一篇文章中看到的，印象非常深刻：大多数软件开发项目总是落后于原计划。这样团队里的人就没有时间偷懒了。这种想法在我们这个行业很普遍。真想对它举手投足！这种想法显然是不公平和不公正的。因为很多开发商在预估的时候，乐观的利润率在20%-30%。换句话说，开发人员通常低估了实际完成项目所需的时间。我对此深信不疑。从这个角度来看，准确的估计精度是必要的。但结合这些草图，更重要的是，我宁愿高估它！
