• 艾伟也谈项目管理,项目时间估算 狼人:


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

  • 相关阅读:
    关于 MySQL 的 General Log 功能
    Oracle VirtualBox & CentOS 7.9 Guest
    CentOS 7 环境下添加拥有 sudo 权限的用户
    CentOS 7 环境下部署 MySQL 5.7 服务
    CentOS 7 环境下部署 Metasploit Framework & Armitage 团队服务
    CentOS 7 环境下部署 Docker 服务
    window10下安装MySQL
    sticky
    Eclipse 打包Mac产品IDE 记录
    Halcon图像处理中的坐标系
  • 原文地址:https://www.cnblogs.com/waw/p/2158564.html
Copyright © 2020-2023  润新知