项目估算.

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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