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

简介:   大学里跟老师做的项目几乎没有一个是按时间完成,都是在拖时间,一拖再拖,每次老师初步地估算这个项目需要多少时间,我脑袋里都下意识地想(老师估算的时间*2,或*3,或者更多),其中最糟糕的一个项目估计用一个月,结果用了一年才勉强结束,实际时间=估算时间*12,我的天呀,当时估计也就是学校这种地方做得出来。

  大学里跟老师做的项目几乎没有一个是按时间完成,都是在拖时间,一拖再拖,每次老师初步地估算这个项目需要多少时间,我脑袋里都下意识地想(老师估算的时间*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了(这是针对那种放卫星的估算时间,差距不大的时间赶赶工就可以,要积极地工作,呵呵)
       最后来个估算时间的总结:有理有据地估算时间,说服上级采用这个时间。遇到放卫星式的项目时间,自己心里要有底,不可盲从。

目录
相关文章
|
4月前
|
安全 数据安全/隐私保护 Windows
推荐5款经过时间检验的精品软件
今天来给大家推荐5款良心软件,每款都是经过时间检验的精品,用起来让你的工作效率提升飞快,各个都让你觉得相见恨晚!
59 0
|
10月前
|
移动开发 监控 数据库
分享5款经过时间检验的精品软件
今天来给大家推荐5款良心软件,每款都是经过时间检验的精品,用起来让你的工作效率提升飞快,各个都让你觉得相见恨晚!
38 0
|
敏捷开发 监控 算法
软件项目管理相关内容1:项目介绍与背景 2:乙方投标书 3:合同 4:生存期模型 5:需求规格说明书 6:WBS 7:成本估算 8:甘特图 9:进度计划 10:质量计划 11:项目总结
软件项目管理相关内容1:项目介绍与背景 2:乙方投标书 3:合同 4:生存期模型 5:需求规格说明书 6:WBS 7:成本估算 8:甘特图 9:进度计划 10:质量计划 11:项目总结
168 0
软件项目管理相关内容1:项目介绍与背景 2:乙方投标书 3:合同 4:生存期模型 5:需求规格说明书 6:WBS 7:成本估算 8:甘特图 9:进度计划 10:质量计划 11:项目总结
|
机器学习/深度学习 调度 项目管理
『软件工程8』软件项目进度安排与跟踪,一招学会计算关键路径
接下来的这篇文章中,将讲解软件项目的进度安排与跟踪!
『软件工程8』软件项目进度安排与跟踪,一招学会计算关键路径
|
项目管理
艾伟也谈项目管理,谁动了项目的时间?
  项目进行到今天,我突然发现项目已经花费了快70%的时间,而离编码结束似乎还很遥远,面对着领导质问般的眼神和组员迷茫般的目光,我深深地吸了一口气,大脑开始了高速地运转,到底谁动了项目的时间?   项目情况   首先介绍一下项目的大概情况:   其实项目倒不是很复杂,一个处理业务流程的系统。
1142 0
|
测试技术 项目管理
艾伟也谈项目管理,如何评估软件进度
  这是一个评估项目完成和剩余百分比的指导说明。   我还没看到了这个问题。 完成:0%, 剩余时间:2周左右。   我看到了这个问题。 完成:50%, 剩余时间: 还要2周左右。   我差不多都完成了。
952 0
|
项目管理
艾伟也谈项目管理,项目过程中所遇到的各种问题记录——有关MSChart的一些小技巧
完成了有关编辑器篇的内容,接下来记录下这一年里在有关图表使用过程中碰到的一些问题及个人的解决方法。   以下是本文所要介绍的内容: 1、MSChart基本概况介绍。 2、开发过程中碰到的问题及解决方法。
1123 0
|
项目管理 C#
艾伟也谈项目管理,切勿过早优化
  Donald Knuth说“过早优化是万恶之源”(premature optimization is the root of all evil)。这话也许有些夸张,但“过早优化”的危害我觉得不能忽视。
1208 0
|
程序员 项目管理
艾伟也谈项目管理,较大型项目的产品工作心得
  最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享。   立项前   1、统一元素设计需考虑周全   也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲。
1282 0
|
项目管理
艾伟也谈项目管理,动起来再调整 - 向项目经理推荐敏捷
  要成为一个好的项目经理需要学会逆水行舟。虽然顺水推舟有时也能到达目的地,但学会逆水行舟,你才能到达任何地方。   “虽然很有道理,但我认为现实不允许,很多项目都有规定的期限。中途还有给客户演示效果,往往实际项目中都是按最后上线日期来进行项目规划管理的。
983 0