项目估算.

转:http://www.iteye.com/topic/1118817

周末听了项目管理的课程,很有感触,有很多记忆深刻的点,比如不要揣摩要提问,要先管理后产品,胜者先胜而后战,败者先战而求胜。然而,让我印象最深的是估算工时这点事,不禁让我想起自己的经历来。

 

      最开始刚参加工作时是在一家翻译公司做它内部的协同系统,两个程序员,老大和我,老大是30岁的老程序员,安排工作很随性,每天早上,点点系统,然后想想接下来要做什么,然后,叫上我,说,把这棵树实现一下吧,然后,再说,需要多长时间?我想一会儿,不就是一棵树吗,说,1小时。老大点点头,说,好,1天。再一天,老大又交给我一项任务,这次任务量大一些,要实现一个完整的模块,我同样是想了想,说3天,老大点点头,说,好,9天。老大总是这样,只要是我作出的估算,他总要乘以3,对此我是不以为然的,这也太保守了。不过好消息是,一年下来我们从未加过班,几乎所有的工作都按计划完成了,日子过得轻松而又悠闲,经常有些时间写点自己喜欢的其他代码,一点也不像程序员。

 

      第二份工作就是IT公司了,做企业应用开发。老大使用干特图来进行工期管理,项目开始之前,老大已经分好大的模块了,这些模块比我第一家公司所谓的模块要大的多,需要以周来估算。这天,老大叫上我,问,这个门户的模块需要几周完成?我想一想,门户以前没有接触过,学习需要一周,开发需要两周,再留一周测试,说,四周。老大点点头,说,好,我再给你加一周学习时间,于是用鼠标在project上拖出一条长长的蓝线来。几个程序员每个都拖出一条蓝线来,三个程序员,八个模块,蓝线短的就再估算一个模块,这样,一条一条蓝线拼起来,最长的那条就成了关键路径,也决定了交付日期,交付日期定在五个月以后。于是就开始开发,那时年轻,无知者无畏,还是单身,加班就不是问题,三个人周六都在公司,吭嗤吭嗤,还真在五个月后给吭嗤完了。于是开始请测试妹妹测试,这一测试问题就来了,很多模块根本就是不可用,只是能够增删改查,很多功能点都没有考虑到,易用性就更别谈了,也难怪,系统设计、实现、测试都被一个只会写代码的程序员包了,既当运动员又当裁判员,能想清楚才怪,于是继续吭嗤,这不吭嗤还好,一吭嗤不得了,又吭嗤出五个月来,再看看jira,几百个bug,每个人都很绝望,老大手一挥,说,哪个软件没有bug,停止开发,修复最重要的bug,然后发布。

 

      第二个项目做完,开始反思,为什么延期这么长估算这么不准,想了很久,觉得是因为估算的粒度太大,时间超过一周,对估算的开发量实际就失去计算了,只剩下一个大概的印象,而为了不成为关键路径不在老大面前丢脸,拍胸脯的情况也发生了,没事,加几个班就搞定了。同时,缺少系统需求说明,这样,在一个错误时间内完成一个不可能完成的任务,质量可想而知,赶进度献礼工程不仅政府在做,程序员同样在做。

 

      这样,到了第三年,自己开始负责一个项目了,吸取了教训,开发估算时,估算的工作量不能超过1周,一旦超过就需要继续分解再进行估算。估算下来,这个项目需要四个月完成,又想起第一个老大的乘三法则,心里颤了一下,难道需要12个月?不能这样,这样这个项目就被取消了。自己带了侥幸的心理,团队的成员都很强,事后也证明这个团队的个人能力都很强,因为有两个人现在在知名外企,一个在淘宝,一个在腾讯,小公司组成这样豪华的阵容是很难得的,唯一不幸的是,我是那个项目经理。我把交付时间定在了四个月之后,开发进度整体还是顺利的,稍微有延期,每周需要延一到两天,这样,我把时间又延长了一个月。天知道,意外发生了,因为我的一句批评,一个成员离职了!我痛哭的发现,项目又要延一个月了,于是,接下来,我就流涕了,六个月时间,公司没有那么多钱投入了!我开始加班,要求其他人也加一些班,意外接着发生,有人生病了,有人有急事要请假了,到最后,终于发现,按估算完成是完全不可能的。最后,项目就被取消了,悲催的项目经理。

 

      继续反思,为什么估算不准,这次我自以为原因很清楚,就是没有考虑项目风险,没有考虑到人会离职,没有考虑到人会请假,没有考虑到人会生病,甚至,没有考虑到人一天工作的产出不是八小时。我太乐观了。我再一次想起来我的第一个老大。

 

      新的公司,新的估算方式,不再一个人估算而是一伙人估算,特性不估算,故事点再估算,没有需求不估算,不一次性估算,迭代估算。这次似乎没有问题了,但客户总是需要一个大的时间点的,于是每个迭代都会排定故事优先级,确保交付前交付的是最有价值的,此外,还有专职的业务分析和漂亮的测试美眉,一切看起来都很好。新公司第一个项目也确实轻松的,但第三个和第四个却都失败了,第三个项目在遇到一个很难解决的性能问题时陷入了一片混乱当中,迭代经理甚至自己都失去对整个项目的可视化了,她不知道项目上线究竟需要满足什么条件,于是项目在一次次的下周二上线的空头承诺中成了整个公司的笑柄。幸福的项目总是相似,不幸的项目各有各的不幸。第四个项目在一次项目中期的架构重写中崩溃了,重写耗去了团队太多的时间,而由于对未知领域知识的不正确估算再次令项目雪上加霜,而更加致命的是,项目目标直到最后一刻也没有发生变化,依旧是要在六个月后上线,于是,程序员们就内存溢出了。

 

      乐观、管理混乱、领域知识不熟,这些都导致了项目延期,工时等于工期吗?不等于,工期永远是假的,工时估计的准确,混乱的管理同样会毁掉它。更严重的不是项目延期,而是项目本来就是老板拍脑袋的结果,想想某个项目,如果不说我们能快速交付就根本得不到它,而得到它后怎么办,那只能拜春哥了!

猜你喜欢

转载自turnround.iteye.com/blog/1364898