一次错误估算带来的启示[转]

文章来源于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. 理性对待改变——你能处理多少改变,并且对于项目的成本有什么影响。而不是试图避免改变。

发表评论

电子邮件地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据