一次错误估算带来的启示

摘要：作为项目领导者，对于项目的进度和功能设计必须进行前期估算，以便项目能够按时完成。本文以Tagging为例，总结了三点经验教训仅供参考。正如作者说的：痛苦的过程常常能给我们带来经验教训，很值了！

文章来源于New Relic，作者David Celis根据自身经历，详细讲述了项目估算的重要性。错误的估算会导致项目延期完成，成本增加，士气低落等不利的后果。一起来看看他的亲身经历和对别人的建议。（以下是编译内容）

有时候很难估算出完成一个项目需要多长时间，开发者常常会低估一个功能的交付时间，尤其是遇到更改和迭代方面的事情。一旦工作上出了差错，队员们就会泄气，这是常有的事。

作为一个项目领导者，在经历过多次错误估算之后，我吸取了沉痛的经验教训。客户不断提出新的要求，还要扩大功能范围，以至于原本只需一个月的项目在经过反反复复的修改之后，竟然花费了五个月的时间。这是我所没想到的情况。

案例研究：Tagging

最近我在New Relic搭建了一个新功能，能够让用户在自己的应用程序、服务器和关键事务上贴上标签。其实Tagging是一个非常简单的创意和功能，为了保持事物的基本要素并有所增值，我们计划将添加标签的功能首先用在服务器上。我本来估算完成这个项目需要一个月的时间——每个星期都有合理的分配计划：

• 首先，为了分配标签，需要完成一个简单的后端和一个基本的UI。
• 其次，通过多个tag和在多个服务器上添加标签的方式来实现一个基本的UI过滤服务器。
• 然后，通过来自设计团队合并UI/UX的反馈，发布给前期预览用户。
• 最后，发布给每一个用户，并解决所有报告上来的问题。

前两周一切照常，没有什么问题。接下来，就是我们能够想象得到的——不可避免的，令人痛苦的修改，这打破了原来规定的时间计划。值得庆幸的是，痛苦的过程常常能给我们带来经验教训。

教训 1：要做两手准备

第三周，在召开的设计团队会议上，我明确表示低估了项目所需的收集和实施反馈时间。我原本打算只用一个星期就能在这个会议上宣布这个简单的功能，但是从我收到反馈数量上来看，我觉得现在的日程安排已经偏离了事先制定的计划。

这让我吸取了第一个教训：对一些事情做出假设的时候，应该把时间放宽，并想清楚这么做的原因。对于一些即将实施的项目，预算长时间和提前准备总要好过时间不够用以至于无限期延迟项目。

教训 2：重新评估贯穿整个项目过程

在New Relic，我们规定，将不断提升网站的性能放在首位，并且这个优先权把范围延伸引入到了添加标签项目当中。在我工作的网页上给UI添加标签的速度并不是很快，所以为了提高性能和减少技术上的问题，我们决定在用户端MVC框架（Backbone）上进行重写。

尽管重写过程超出了工作项目范围，但是必须得这么做。我仔细考虑如何让Tagging界面的Backbone查看起来更便捷和能够重复使用——这样就能够更加方便的将Tagging传送到应用程序和关键事务里。我喜欢这样有创意的想法：通过Backbone集合进行搜索而不是直接在DOM上的列表行里进行搜索。事实上，这有点让我洋洋自得，所以项目延长了两周时间，每周在Backbone里重写两个页面。

我并不后悔在这个项目里添加这个条件。为这些网页重写UI的确可以减轻项目的后续工作，而且网页的代码也变得更加简洁。真正令我感到后悔的是没有回过头来把计划作为一个整体再看一遍。

我的第二个教训是：不管在项目要求上做了多大的改变，都有必要重新进行评估。

教训 3：所有的修改都是可行的

这有点老生常谈了，但不要害怕改变。不管是在生活中还是在工作中，改变都是必不可免的。重要的是我们怎么应对这些改变：三思而后行。

如果这些改变能让初次发行变得更有用，或者能够减少技术上的问题，并且让以后的工作/维护变得更加简便，那么就可以考虑将这些更改方案加入到项目计划中。

重新评估整个项目是及其重要的，可以为接下来所要作的改变起到铺垫作用。之后改写的Backbone导致的一些变化是我在开始的时候没想到的。这些可能只会导致些许延迟，可是，延迟的次数太多了也会影响士气的。

一个单独的变化，和由此产生的额外费用，不能归结于是改变项目造成的，因为它会影响之后的每一个要求。

总结

我曾经认为只会耗费一个月时间就能完成的功能，最终却花了五个月，我没有信心按照预期计划交付项目。我一直在想，如果我以前足够小心谨慎，也许现在就不会有失败感了。

1. 把事情所需的计划时间延长，想想为什么，并依据个人需求，给自己更充裕的时间。
2. 微不足道的改变可以让你的在项目重新评估上更有保障。可以考虑长期的添加或改变要求。
3. 理性对待改变——你能处理多少改变，并且对于项目的成本有什么影响。而不是试图避免改变。