程序员软件项目预估的宝贵经验

我最近参加了一个关于软件预估的课程。对于这种本质上就是非精确的科学，我一向都非常谨慎，因为我深信预估可以创造价值。在这个历时两个小时的课程中，我发现了如何提醒大家进入预算而不必过度分析和思考的方法。

非常常见的例子

我们经常能听到项目经理和开发人员之间类似于这样的对话：

PM：“你能不能给我一个开发某某功能所需要的预估时间？”

程序员：“一个月”

PM：“一个月时间太长了，我们只有一周时间！”

程序员：“最好三周”

PM：“我只能最多给你两周时间”

程序员：“好吧，成交！”

呵呵！猜猜接下来是什么情况？如果你在下决定之前能快速考虑一下预算与目标之间的差距，那你就不至于这样草率，也不至于在接下来的时间里焦头烂额。

结论截然不同的简图

在课程中有这么一张图片，它强调了精确预估的重要性。我粗略地照着原图重新画了一张：

图片表达的中心思想为，我们需要将精确预估作为目标。对此我不置可否。事实上，我想说的是，我们的预估永远达不到100%的精确。

为什么呢？因为预估本身就是一种并不精确的科学。虽然有很多很多方法（可能甚至比我们需要都要多）可以让我们擅长估计，但是总会有一些不确定性。没错，100％精确自然是最好的，但是在实践过程中，这是不可能的。

不仅如此，低估时间的成本也是不可承受之重。先看看例子：

• 项目可能会失败（最坏的情况）。
• 不断地通宵达旦
• 高压和焦虑
• 项目可能会延迟
• 质量会受影响
• 成本增加
• 用户表示不满

有时候预估时间结果是非常重要的。因为如果你估高了，功能依然可以完成，其代价为耗费的时间多。但是如果你估低了时间，那么可能指定功能你甚至就完成不了。

预估后项目出现异常的原因之一

软件项目中的混乱源于精确的预估。

你知道是什么原因造成一个软件项目出现混乱的吗？原因就是项目进度落后于计划！我们将这种现象称之为正反馈效应（不要望文生义，正的反馈并不都是好的）。

还有一个预估方法是给出一个范围。这么做的效益/成本我们暂时不考虑，下面是使用范围估计最后却发现低估的例子：

下面是高估的例子：

曲线下面的阴影部分代表需要付出的努力、成本和计划进度，看上去明显比上图高估所需要的少得多。

当然100%的预估精准度自然是最为理想的，但是在实际操作中，其错误成本太高。

你的团队是否需要常常加班熬夜？下面这句话是我在一篇文章中看到的，印象非常深刻：

大多数软件开发，项目总是落后于原定计划。这样团队中的人就没有时间偷懒。

这种思想在我们这个行业非常普遍。我真心是想举双手双脚反对！这种想法显然是不公平不公正的。

因为很多开发人员在预估时，大多会有20％-30％乐观余度，换言之就是，开发人员普遍性会低估实际完成项目所需要的时间。这一点我深信不疑。

由此看来，精确的预估精度很有必要。但是结合这些简图，更重要的是，宁可高估啊！