我最近参加了一个关于软件预估的课程。对于这种本质上就是非精确的科学，我一向都非常谨慎，因为我深信预估可以创造价值。在这个历时两个小时的课程中，我发现了如何提醒大家进入预算而不必过度分析和思考的方法。 非常常见的例子我们经常能听到项目经理和开发人员之间类似于这样的对话：
呵呵！猜猜接下来是什么情况？如果你在下决定之前能快速考虑一下预算与目标之间的差距，那你就不至于这样草率，也不至于在接下来的时间里焦头烂额。 结论截然不同的简图在课程中有这么一张图片，它强调了精确预估的重要性。我粗略地照着原图重新画了一张：
图片表达的中心思想为，我们需要将精确预估作为目标。对此我不置可否。事实上，我想说的是，我们的预估永远达不到100%的精确。 为什么呢？因为预估本身就是一种并不精确的科学。虽然有很多很多方法（可能甚至比我们需要都要多）可以让我们擅长估计，但是总会有一些不确定性。没错，100％精确自然是最好的，但是在实践过程中，这是不可能的。 不仅如此，低估时间的成本也是不可承受之重。先看看例子：
有时候预估时间结果是非常重要的。因为如果你估高了，功能依然可以完成，其代价为耗费的时间多。但是如果你估低了时间，那么可能指定功能你甚至就完成不了。 预估后项目出现异常的原因之一软件项目中的混乱源于精确的预估。 你知道是什么原因造成一个软件项目出现混乱的吗？原因就是项目进度落后于计划！我们将这种现象称之为正反馈效应（不要望文生义，正的反馈并不都是好的）。 还有一个预估方法是给出一个范围。这么做的效益/成本我们暂时不考虑，下面是使用范围估计最后却发现低估的例子：
下面是高估的例子：
曲线下面的阴影部分代表需要付出的努力、成本和计划进度，看上去明显比上图高估所需要的少得多。 当然100%的预估精准度自然是最为理想的，但是在实际操作中，其错误成本太高。 你的团队是否需要常常加班熬夜？下面这句话是我在一篇文章中看到的，印象非常深刻：
这种思想在我们这个行业非常普遍。我真心是想举双手双脚反对！这种想法显然是不公平不公正的。 因为很多开发人员在预估时，大多会有20％-30％乐观余度，换言之就是，开发人员普遍性会低估实际完成项目所需要的时间。这一点我深信不疑。 由此看来，精确的预估精度很有必要。但是结合这些简图，更重要的是，宁可高估啊！ |
