艾伟也谈项目管理,项目时间估算

  大学里跟老师做的项目几乎没有一个是按时间完成,都是在拖时间,一拖再拖,每次老师初步地估算这个项目需要多少时间,我脑袋里都下意识地想(老师估算的时间*2,或*3,或者更多),其中最糟糕的一个项目估计用一个月,结果用了一年才勉强结束,实际时间=估算时间*12,我的天呀,当时估计也就是学校这种地方做得出来。到了企业之后,实际时间是估算时间的两到三倍也是很正常的事,这还是在需求明确到85%以上的情况下,需求不清的情况下,时间就海了去了。

  项目开始时,客户简单的描述需求,开发方便豪言壮语一个时间(有时这个时间连需求分析都做不完),中间客户改了需求,开发方声称“绝对不是问题”(接项目时要人情、关系之类的,客户改点需求,一般不太好明说要加时间),到了时间了,还差很多没做完(项目组的人赶工都加了好几天的夜班了),给客户演示下,忽悠下客户,然后再说我们再完善一下(一般这时客户也会再提点新需求),如此反复,就不知道要完善到什么时候去了。最后提起这项目,开发方暗骂客户扯蛋,客户暗骂开发方混蛋。

  需求不清的情况下,本人暂时不知道怎么估算时间(不知各位有什么高招,分享下)。但为什么在需求明确到85%以上的时候,我们实际时间还是估算时间的两到三倍,或者更多,这种情况我想扯蛋是出在我们自己身上了,我总结了一下,分为两种:

  1, 自己豪言壮语“害”自己,拿到了一个需求或一个技术难点,看了一下,道:“这个容易,两三天搞定”,“这个系统简单,撑破天一个月”,真的动起手来发现挺难的,搞了N个两三天或撑破了N个天才搞定。

  2, 别人豪言壮语“害”我或整个小组,这个别人通常指市场人员,在软件公司基本是市场跟技术之争,而在国内,因为各种原因往往又是市场占主导,一个项目下来,市场人员感觉一下需要多少时间,技术的就得照办,你跟他说“时间不够”,通常都会回复,“加加班,抓抓紧”,往往按他估算的天数就是按24小时工作也不够(更离谱有的连需求都做不完),再说市场的不懂技术,实际时间往往是他估算的时间三、四倍也不足为奇。你直接跟他说你的估算时间=他估算时间*3,是不是从侧面贬低你上级的智商,他会接受吗?

  经过了一段时间的痛苦之后,我还是小有点心得了,如下:

  问题1是比较容易解决的,因为改变自己远比要改变别人容易得多,刚开始的时候,我们自己可能会夸海口,随着经验的非富,对自己的时间估算会慢慢地八九不离十,我就是这样的。刚毕业那会,我领到一个任务,看一下就估算个时间(通常很短,为了表现自己,再加上精力比较旺盛),工作时间做不完,就加班做(反正也没什么事),慢慢我也知道具体的任务我大概需要多少小时来做。
 不过刚开始带小组的时候,接到一个任务,我就估算了我大概要多少时间,然后小组多少个人就算是多少个我,估算时间=我要的总时间\小组人数(好笨的想法呀,不用时间跟组员交待任务的吗?个个组员都是我吗,比我强的还好,顶多做完了休息,差一点的就麻烦了),结果实际时间多了很多。后来我就吸取了教训,跟组里的人相处久了,心里也有底了,谁比我强,大概强多少,谁比我弱,弱多少(最好能量化,单凭感觉靠不住),这样一折算可以把时间算个大概;再把任务跟组员交流一下,基本估算的时间八九不离十。

  问题2就比较麻烦了,上级(非技术人员、市场人员之类)通常估算一个项目的时间少得离谱,说出来吓坏项目组长,我通常把这种情况叫做放卫星。面对上级放卫星,要想办法说服上级采用我们的时间或者让上级接受这个时间(特殊情况),因为上级是非技术人员的话,一般是凭感觉估算时间,所以一般不要试图用自己感觉的时间来证明别人的感觉的时间不对。(为什么你感觉的就对,我的就错,上级肯定不会采纳的,反而会让上级感得你做事不积极,想拖时间,怕苦怕累,对任务讨价还价,前期我也犯了这样的错误,给上级留下了不好的印象),后来我总结了一下,发现说服上级是需要一定的技巧的。
      1, 有理有据,用数据说话。上级凭感觉估算的时间与自己估算的时间有很大差距时,不要很着急地直接说出自己估算的时间(这样容易造成直接的对立,之后的交流会很僵),可以先描述推出时间的依据是什么,依据的数据支持是什么,然后当着上级的面根据这个依据把我们估算的时间给算出来,古语有云:事实胜于雄辩;想必上级会欣然接受的。(毕竟大家都是为了把工作做好)

      经历:
      有一个项目(信息系统,需求比较明确),在数据库设计做完之后(120多张表呀),我的上级(市场人员出身),跟我说:“这个简单呀,最多15天就搞定了,你看怎么样?”当时我一听心里就发毛,当时我估算的时间是45天呀(整整差了3倍);我首先表达了我的时间跟他算的有点差距(但没有直接说我的时间),然后列举了前面公司所做的几个信息系统的项目,如下:
项目A,3人,60天,140张数据库表,平均每人每天处理0.8张表
项目B,5人,30天,110张数据库表,平均每人每天处理0.7张表
。。。。
   然后我跟他说:现在我们效率提高了,再加上项目紧,我们会加下班,大概算每人每天处理1张表吧,小组共3人,也要45天这样呀。最后我还笑着跟他开了个玩笑:我们组每天24小时工作,一直干15天,都有点勉强呀!(当时在座的都笑了)。当时上级思考了一下,然后就采用了我的45天的计划。

      
      2, 把任务分配到组员,再请上级到小组中交流,依靠群众的力量说服上级,反过来每个组员都当着上级承诺了开发时间,对他自己也是一种鞭笞、激励,有利于按时完成任务。小组组长单独跟上级说,他官大一级压死人,再说自己心里也有点怕怕吧。把他请到小组里来,人多了自然胆也壮了,将每个人的开发任务给他看,每个人说说对自己任务的看法,难度怎么样,要多久才能完成(参照第一条,有理有据,用数据说话),注意控制气氛,尽量以聊天的形式,不要搞僵气氛,最后由自己进行一个总结,把总的时间明确化,这时上级面对群众的力量,一般也会同意你的估算时间。
      特殊的情况,假如上级就是要按他估算的时间来(原因可能有很多,他就认为他的是对的,客户摧得紧等等),实在无法说服上级完全采用自己估算的时间,能多加几天是几天,但是在心里一定要有个完成项目的估算时间,哪怕这个时间是上级指定的10倍(这个时间最好是比较可靠的,有依据),我始终认为一个项目完成的时间是多少就是多少,不为因为上级硬压一个很短的时间就真的是这个时间了(我发现加班做不了多少事,不知道大家的感觉怎么?),很多时候,上级宁可你最后延长或拖N倍于他的估算时间,也不采纳你的N-X倍比较可靠的时间(有点无奈)。假如你心里没底的话,会做到很郁闷(因为每次延时,整组人都会觉得很累,可能是因为一鼓作气,再而衰, 三而竭;延时越多,整组人会越疲倦);遇到这种情况,可以暗地按自己计划走,不停地延时到自己估算的时间就OK了(这是针对那种放卫星的估算时间,差距不大的时间赶赶工就可以,要积极地工作,呵呵)
       最后来个估算时间的总结:有理有据地估算时间,说服上级采用这个时间。遇到放卫星式的项目时间,自己心里要有底,不可盲从。

时间: 2024-10-24 20:18:29

艾伟也谈项目管理,项目时间估算的相关文章

艾伟也谈项目管理,《播客》项目总结——项目管理方面

引言:如果标题改成<被管理总结>的话,我可以滔滔不绝的说上个半天,但是如果是管理项目的话,我实在肚里的货有限,因为到至今做过的最高职位不过是个"班长"而已. 但是这次<播客>项目在管理方面的确出了问题,而且是满严重的问题,以至于到后来项目差点失控,而且最终的交付作品质量的确让人汗颜.如何避免下面程序员很累,但效率却很低:上面不停的催,产品却一个bug接一个bug,完全没法交付:项目经理累的要死,项目却仍然处于失控状态这样的问题和局面?在一个差点失控的项目刚刚结束

艾伟也谈项目管理,项目做完了,总结一下

在连续封闭N个月以及再后来的N个月的加班后,项目终于以延期N个月的结果结束了.不管曾经发生过什么,不管项目是否延期,重要的是项目结束了,所有的项目成员都可以松一口气了.曾经和同事开玩笑说:在我经过过的失败项目中多了一个项目,以后就能避免同样类型的失败了.同事们听了,都笑了.在那段时间里,很久没有听到过同事们畅快的笑了. 现在,我以我目前的知识水平,总结一下项目中存在的问题,这些问题的出现也不是一两个因素造成的.当然,专业水平太低,也总结不出什么高深的内容.不管怎么样,也算是对项目的总结吧.这里先

艾伟也谈项目管理,我的项目管理观点

    公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面.我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得.我把我所要分析的内容大概做了一个讲义,也希望更多人能够参与到这个Workshop中.项目经理好做吗?      项目经理好做吗?好做!项目经理好做吗?不好做.不同的人.不同的态度.不同的方法,其结果也就存在有极大的

艾伟也谈项目管理,我也发软件开发团队的思考(侧重点是人员)

//上个月给我们老板的mail.洋洋洒洒6000多字. //为了方便公开,改了一下.以致可能有些地方前言不搭后语. //不管他同意不同意,先在我们组实行了再说. //请多大家多提提意见,日后看有没有机会找老板当面交流 经历的几个项目,项目的进度老是不尽如人意.更重要的是市场的开拓因为这些项目拖住了后退而无所作为. 我们现有的情况是:项目期限和最开始的保守估计都相去甚远,最后提交给客户的产品60%都是最后一个多月开发出来的,还有20%左右是以前就固有的固定模块.这几个项目我参与了编码,我对整个系统

程序员必备的项目时间估算指南

有位 PM 最近告诉我她面临的一个难题:"软件工程师永远不能估算出他们的项目需要多长时间.我该怎么办?"还有两位 CEO 最近也告诉我同样的事情. <为什么程序员总是不能准确估测项目时间?>(http://blog.jobbole.com/24924/),我们都深有体会.我曾经遇到过一个项目,预计需要两天完成,结果做了四个月.在这种情况下,即使用"时间翻倍"的经验估算,也依然差出了一个数量级之多.这样真的非常影响业务.我曾见过整个公司为了举办一个发布活动

艾伟也谈项目管理,项目管理利刃之MSF

MSF,MicrosoftSolutionFramework,微软解决方案框架是一个在预算范围内按期创建一个业务解决方案需要一种经过检验的方法. 本文将结合MSF在项目管理中的实际应用进行讲解,如果您是软件项目的参与者,如项目经理.开发工程师.系统架构师.顾问.质量管理人员等,想找到项目管理中遇到问题的解决方案,相信本文会给您一定的帮助. MSF为成功地规划.设计.开发和部署IT解决方案提供了一套成熟的方法论.与具有固定框架的方法相反,MSF提供了一个可以伸缩的灵活框架,以满足任何规模的组织或者

艾伟也谈项目管理,和谐共进的项目组——产品经理提高技术理解力123

最近被同事问到产品经理怎样提高技术理解力,有哪些途径,这里结合之前做过的两个项目以及和这个项目组所有开发兄弟一起并肩战斗的半年感触来说说. 1. 产品经理与项目经理的互动 项目过程中,产品经理和项目经理之间多沟通,产品经理准确传达产品设计的思路,项目经理结合产品实现,给出技术实现的方案,然后一起共同评估选出最优的解决方案,这个过程中产品经理可以学习到自己所做的产品的技术实现方法.在beta1项目中我们在手机QQ.QQ浏览器结合中采用了不同于其他平台的纵向整合方案,从而大大提高了项目的实现周期.

艾伟也谈项目管理,大项目的思考

引言:进入现在这个我们内部号称"豪门"的项目已经两个多月了.现在回想起进入项目前一位前辈的话:"大项目有大项目的问题,但大项目也有很多东西可学",自己此时深表赞同.两个月的时间,自己从刚来前两周的观察学习,到现在的基本融入,在这个过程中自己有了很多的想法和思考. 为什么测试这么难写? TDD的开发实践保证了代码的可测试性,那么当TDD的T变的非常难写的时候,是不是现有的代码可测试性已然变的非常差呢?其中一些非常典型的场景就是: test的setup太难,而造成这个的

艾伟也谈项目管理,谁动了项目的时间?

项目进行到今天,我突然发现项目已经花费了快70%的时间,而离编码结束似乎还很遥远,面对着领导质问般的眼神和组员迷茫般的目光,我深深地吸了一口气,大脑开始了高速地运转,到底谁动了项目的时间? 项目情况 首先介绍一下项目的大概情况: 其实项目倒不是很复杂,一个处理业务流程的系统.接到项目的消息是七月底的时候,由于当时领导与客户谈妥之后,客户想在八月中旬就看到,所以当时就非常紧张.考虑到时间如此之紧,项目便匆匆开始.本来计划三个人的,但是考虑到时间太急,又加了三个人进来.在写SRS的过程中,客户那边传