估算那点事

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

可以借鉴一下敏捷开发原则，构建周期越短越好，交付周期越短越好，最好2周一个版本，小计划精确到小时，大计划最多1、2个月，频繁的跟客户、产品经理、需求人员沟通，让他们也参与到项目中来，这样最大可能避免了交付时出现大量未达到共识的问题，防止项目进入恶性循环。

这个操作方式非常好，

给自己的计划，永远要多半天

可以采用scrum方式,所有的开发人员都参与估算,最后大家对每一个story确认一个都认可的时间,这样的话很大的程度上可以减少时间不够用的问题.
另外还要学会估算团队的工作速率，团队在一个固定周期内能够完成大约多少工作量的工作.这个速率不太好掌握,需要时间，但是速率估计的差不多的话对项目进度的掌控非常有力。

对于那些老板限定死日期的需求:
1、可以和老板讨论一下需求的优先级,哪些一定做完，哪些差不多能完，哪些有可能不能完成,这样前期就给你们老板把这种思想贯穿下去。
2、采用端周期交付的形式：比如2周交付一次,如果有持续的交付，老板和客户每次都能看到进度和功能有进展那么限定的日期可能就没有那么重要了.

出现这种情况不是敏捷能够解决的，敏捷只是一种开发方法，只是项目管理的一个子集
你能把决定项目方向、时间、需求的高层拉进敏捷团队么？
你能把客户方的BOSS拉进团队么？

都是不现实的。

我觉得LZ故事中失败的案例主要来自于以下几个方面：
1、不合理的目标，导致团队成员不认可（离职）
2、没有合理管理项目潜在的风险，导致风险最终发生

最初估算工期，制定项目里程碑的时候是非常关键的：
1、向我方领导、客户方反应项目的难度、工作量，让项目干系人建立合理的预期
2、项目每个环节都要预留缓冲时间，因为总有没考虑到的事情导致任务花费时间增加

我个人的经验是，很多项目做到最后才明白这个项目为什么要做，要做成什么样子，哪些人会左右项目

教你个歪门邪道。
做计划时候用两份schedule，一份给程序员看，一份给老板看。都懂得~~

LZ还是要多观察靠谱的PM是如何上下协调的。

估算项目之前需要完整、细化的需求，技术的风险、人员的风险都要估算在内，功能的划分一定要细致，每个任务不能超过一个星期，超过的要重新划分，重要的一点，项目的进度估算一定要项目组成员参与，他们是任务的实施者，他们对自己的能力和任务的把控都应该清楚