UML软件工程组织

 

 

大项目中项目经理的作用
 
作者:郑德辉 来源:blogchina
 

前言:本文作者结合自己的经历谈谈项目经理在企业信息化建设项目中的作用和项目操作,以供大家参考,希望对大家的工作有所实际帮助。作者有幸参加了广东省联通、广东省电信以及其他更大的一些集团的项目运作,文章是从作者自身的角度和经历总结的一些问题,不足之处请广大同行指点,借此抛砖引玉以期和广大同行共勉共同进步。

序:大项目在本文的定义为企业信息建设中客户大名气高而且项目金额大,在我国,能签下大项目的单有一部分是靠草根阶层更专业化的服务和质量以及行业客户赢得的,但一般而言签下的这样的大项目对软件开发商而言都不可能是天平两端同样的法码,所以销售人员为了能签下这样的大单一般都不得不答应或是承诺一些超越公司目前实力和技术水平的需求,因为不这样根本就没有竞争的机会。这样的苦果程序员即使抱怨非常多,还是不得不照样加班加点去拼命实现。(想想国外的厂商做中国的市场真是爽,国内的客户无不乖乖地听他们的话)

目前国内的软件公司靠产品批发赚大钱的非常少,象金蝶和用友上也都有靠签大项目来发展,所以大项目的成败及效率就直接影响着公司运营成本和利润以及大家的薪金收入。因为一开始签定的就是不平等条约,所以项目经理的人选更是直接决定了项目的成败和收益。这样的项目经理有两种,一是为自己镀金的,那是非常光荣和开心的事,因为费用及人手配置都非常充足,第二种是很有责任心而且想做成功的项目经理,会做得非常辛苦,累得半死。如何让项目早些验收让领导放心,让下属开心和放松是项目经理时时刻刻都关注的事。

正文:结合自己的经验谈谈项目经理在主持项目实际运作时的二个要点三种避免和四个注意。希望对大家的实际工作会有所帮助!

两个要点

一、如何尽快地将项目验收回款,为公司和团队创造更多的利润,为下属带来更多的利益。

二、板回双方不平等中的劣势

这是项目中非常关键的一个心理预期,因为早期签的合同让开发商处于劣势,客户从你进场开始自然而然地在气势上压着你,如果你长期处于心理上的劣势,项目失败的风险就非常高,因为大公司中的人员都有一种出了事情后他们会将你原本认为是他们的责任的推得干干净净,如果你纠缠下去和他们的关系就搞僵了,项目的后期工作会非常难进行,公司高层考虑的就是更换项目经理,因为这时的客户真的是上帝,老板都不敢得罪的人你得罪的后果大家都知道会怎样。笔者当初和他们打交道时就花了一个月多的时间让整个团队在专业上体现出来是行家和经验娴熟,因为客户是大公司的,技术资源很丰富,他们懂的面很广,也有知道得深的,所以要抓住机会和他们多交流特别是非工作时间,首先你要认可他,然后让他感觉他专业,再然后你在合适的机会某些方面要自然而且不露痕迹地表现出你知道得更深更专业,当然当初没少花我银子。劣势板回后,后期他们才会注重你说话的份量,才可以指出哪些需求是不合理的,哪些是微软都没有办法做到的。

三个避免

一、避免事情太多杂乱无章

大项目也意味着需求多,参与的人员也多,如何保证项目的进度,避免事情太多,需求点太多而导致最后项目失控,就是项目组加班加点做了大量的工作,最后却发现什么都没有做好,客户不认可,领导很焦虑,下属很失望,你很郁闷的局面。在项目进行过程中不可避免地会遇到很多提出的需求和修改意见,如何快速把握这些需求提出正确可行的解决方案是项目经理首先要考虑的事情。别忘了项目合同上都是有时间限制的,如何在时间段之内完成项目而且完成得好就是关键。一味地否认抵制客户的需求当然不行,全盘照收只会让项目越变越大,项目组的人每日每夜地加班。笔者的作法一般是记录成文字性的文档,然后根据实际情况提出哪些现在做,哪些暂时不做,哪些到二期或三期工作时再考虑,并请他们确认。这套方法笔者常用不衰,希望对各位项目经理在项目运营过程有实际的帮助。

二、避免太多个性化的需求

这是最头痛的事情,因为客户是大公司,会议没完没了,每个会议都要求得非常正规,而且客户看起来确实是很正规,相关的制度文档相关的人员以及部门级的经理都甚至高层的领导也会请到会议室来和你谈需求,每个经理都会有自己的部门的特点和需求,如何尊重他们的意见并保持自己的思路是非常重要的。笔者早期参加这样的会议时也一样很听客户的话,程序实现的过程中则是非常痛苦,经历过多次后,笔者建议各位项目经理要保证突出你们的专业知识和经验,不要被客户的职位所迷惑了,因为他们的经验很丰富,但在专业特别是软件方面你是专家,而且他们提出的是现实中各个部门的特点,并没有要求软件一定要实现。所以现场一定要记住,不要答应得太快,笔者后面就养成了一句口头禅,我们回去研究讨论后再确定。

三、避免人浮于事的现象

大公司都会有的现象,如何让你的项目组成员在项目进行过程中最大限度地减少这样的消耗是项目经理要关注的事。大公司踢皮球的现象大家都有所耳闻,所以做为项目经理的你能做就是如何做好事前的工作,避免出了问题后指责,到时你会发现没有人和这有关,都是你的错。所以少些抱怨,事前尽可能多做准备。笔者最常用的方法就是在需求说明书(实际工作中提出,非早期完整的需求说明书)中注明这是某某人提出的,以及我们的意见是什么,你别指望他会签字,一个需求点如果要等他确认签字你就等个两个星期吧。

四个注意

一、注意内部团结一致,互帮互助和高度的热情保证得项目快速往前推进。

项目小姐的团结一致,这是基石,不论是在需求讨论分析,还是开发过程和项目内部测试,大家都团结一结,不断提出自己的看法一起交流,在最短时间内将问题细化和明确下来,大大缩短了开发周期。保持项目小组成员高度的热情使得项目讯速得到突破,达到了预期的要求,这是项目经理真正最重要的工作。在项目运作过程中,别忘记项目小组不是孤军奋战,背后还有整个公司的资源别忘了使用。

二、注意项目进度的严格控制

这是老生长谈的问题,核心还是《人月神话》,在现有的人手配置和资源上如何控制项目的进度,这是所有项目经理也是公司领导最关注的事情。因为大项目的进度要控制出了偏差,后期很多预想不到的事情会让你焦头烂额的。所以必要的会议还是要开,总结和安排工作是每周都必须要进行的工作,笔者当初是将工作总结工作安排和需求讨论严格分开的,即使是参加的人员一样。因为需求讨论需求分析有时是无底洞,有些实现起来是有难度的,这时在会议上一定要注意控制方向鼓励大家踊跃发言的同时要保证主题方向。因为需求的扩散和实现的难度将直接影响到项目的进度,很多项目最后失控追根结底相当一部分原因是需求没有把握住。笔者一同事负责的一个百万级的项目,超过签定合同时间的半年了还没有完成,公司后期调动了所有可调用的技术人员进入项目组,搞得人人疲惫,当初最大的原因就是客户的需求不断扩散导致程序开发无休止地进行。

三、注意搞好各方面的关系

项目经理首先要搞好的是你和你的领导的关系,特别是老板的关系,你要体会你的老板的心情,他是希望做成功大项目然后开始扩张,他的心里比你更关注项目的进展,要是出问题他心里比你更焦虑,所以记得要让你的老板参与到项目中来,别因为他不懂技术不懂项目管理就把他晾在一边。笔者的做法是每周都会将工作写成简单的总结发给上级领导,然后抄送给BOSS,有什么计划要执行或调整时预先做好书面材料发送给领导们,这时要忌讳的就是越级上报,所以这样的计划我一般是只发送我的直属上级,在MAIL中写到等计划正式拟定后请他转呈老总,大的事情一般是他都会在比你更期望的时间代你向老总汇报了,因为只有和老总搞好关系,他才会信任你,而且还会源源不断地支持你,不然一些公司接到一个大项目要失败了,公司搞不好就负债了,所以你要明白BOSS可能是将公司前途放在你身上。接下来就是要搞好下属的关系,他们是实现完成工作的核心和中流抵柱,平时要舍得花些银子请他们吃吃饭组织一些体育活动,程序员都是典型的亚健康状态,看看程序员那象怀胎三个月的肚子就知道了。再接着就是要搞好客户的关系了,除了言语上尊重他们外,必要的银子还是要花的,而且要花得有特色,因为他们聚餐也不少啊。所以大家明白我为何要将搞好和老总的关系放在第一位了吧,不然这些白花花的银子,老总不签字,项目再失败了,你赔了血本都不够啊!

四、注意项目验收的各个环节

这是大家都关心特别是老总最关心的问题了,有时你别看他表面上非常平静,一点都没有开心的样子,我的老总那天在去洗手间的路上就哼起了小曲,这是好几年都没有的事情。但是要达成这样的任务并不是象小项目那样双方有意向后谈一天就可以签字,大公司都有自己一套套的验收标准,如果按照他们那样的标准,你卖硬件都难,更不用说软件了,而且谁在这上面签了字以后出了问题谁就要负责,而且软件永远都没有100%没有问题的,你看微软还不是不断升级和发补丁包。如何采用让双方都能接受的方式签定验收合同就要求你平时就要做好准备,笔者一般是每个月都会有一个功能模块实现的清单请他们确认,要他们签字是不可能,笔者的做法是请他们指出哪些没有完成的或有意见的,这样日积月累下来,对方认可了你的工作,后面他个人这一关是可以通过了,后面一定是他的上级以及副总层层把关,记住这时谈的一定要是实现完成了哪些功能,对新需求的千万不能答应就改,可以放到后期,并在验收合同中注明哪些是新需求还没有完成的,层层把关让折磨你的性情考验你的耐性,两周之内要能签下字就算是顺利了。还有一点有过大项目经验的仁兄有没有注意到,项目验收签字的都是客户的最高层和最低层两三个人的名字一起签在上面,中间管理层做了许多幕后工作,所以在验收的过程中不要忘记向客户的每个上级多表扬一下项目中参与的他下属人员的业绩,当他们都是功臣时在最后一关卡住的机会会少很多。因为最后一关没有通过,所有的一切努力都是白搭!希望此篇文章对广大同行能有实际的帮助,祝各位同仁都能在项目验收的庆功宴上多喝两杯。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号