我参与的一个项目的继续总结:经验篇 | 迟思堂工作室
当前位置: 首页 > 代码生活 > 正文

我参与的一个项目的继续总结:经验篇

李迟按:
我看了很多关于项目管理的文章,但发现文章说的和我实际上做的,出入很大。后来和同样做项目经理的同事讨论,发现一个秘密:我们只是临时工,临时兼职项目经理。对于项目经理的权力,权利,均是官方套话。

这篇文章主要是从前面文章发的牢骚出发,提炼一些的事,当做是经验。

项目责任感
对于项目上的事,事无大小,首先问到的是项目经理。作为一个对整个项目负责的项目经理,有很多事是必须做的。但我做的不好。在这个项目中,很多事我都要亲自做。我要统筹整体项目。项目成员搞不定的,我要搞。
以前我是项目成员角色时,安排给我的东西,我都会主动去做,涉及不同部门的,我会先问清楚对方接口人,然后自己沟通,无须项目经理亲自出马,只有搞不定的,我才会和领导提出。但这个项目,我发现项目成员的主动性不够,应该是我没有再三强调造成的。
另外,我还要关心技术方面的东西。因为项目成员除了流程上的事问我,还有他们不懂的事也问我,当然,为了面子,我会自己去查,然后回复。实际上,一开始遇到这样的事,我会告诉他们如何做,比如需求方面和谁确认,项目流程方面在哪里看文档,某个模块和谁确认。但我发现有的人完全不理会,类似的问题还会继续问。几个回合下来,我发现了有的人的依赖性太强,没有主动性。为了时间,于是我决定亲自指导,亲自做时效做要求。不过以后还是不要这样做。累了自己,害了别人。
但我太关心技术方面的了,而忽视PM最基本的事:项目的管理。比如项目进度管理,监管项目的部门最关心的是进度,但我的管理能力不行,可能是我的权威还不够,人家不听。
在这个项目中,有太多的“猴子”我推不开,我以为能推开了,还最后还回到我的身上来。可以大言不惭地说这是我的责任心造成的。我负责的项目,我想把它搞好。

需求
这个项目,需求有很多是不明确的,说得难听一些,有些功能,需求提出的人也不知道是怎样了。我们公司的专门管理需求的人,但我觉得他的工作更多是收集需求,然后下发。做项目,会有需求分析这一阶段,但现实上做得不好。首先,需求分析的人是开发人员,要知道,开发人员往往限于知识面及见识,不会分析得很好,并不是所有的人都了解某个需求在客户那边是怎样用的,只是从自己使用的角度出发。其次,初期的需求可能是不明确的,后期会改,但其时已经在开发阶段,负责人没有专心重新考虑改动的需求,或许说没有时间考虑。这样说,对开发人员的能力有更高的要求了。但往往是一厢情愿。最后的结果的,做出来的东西不是领导想要的。如果公司有专门的人做需求分析,即从客户提出的需求做了分析后转换成研发方面的需求,我相信会比较好。
另外一点,我作为项目经理,对于需求说NO的机会很少,基本上是需求方提出来,就要做。后期修改需求时,我即使说NO,最后还是要做。可能是公司制度有关吧。

开发
我做得不好的地方是,有的人初期没有写概要设计——即使我作了要求,但还是没写,我就允许后期补充。后来延期申请时,因为涉及到技术原因,大领导要看概要设计,但我没能给出来,于是找了借口推了。类似的事,很有很多。这个教训很窝囊,不应该出现这种事的。如果再有机会,一定不会这样。
现在想想原因,一是这个项目启动的时机不好,人员都还没完全到位就开预备会,在预备会上讲了些项目开发的要求、注意事项,但未到位的人并不知道。二来在4、5月份启动,恰好是公司职员开始旅游的时期。比如在5月份,就有包括我在内的很多人去旅游(如果不去,等做了项目就别想去了),而6月份正式启动项目,但6月上旬也有人去旅游。这样就失去了宝贵的前期时间,这段时间,就是做需求分析和写概要设计的时间。这种事无法说什么的,最好不要再出现。
后来测试人员陪产假,只提前一天告诉我,打得我措手不及,换了人员测试,又要重新熟悉设备的使用。也耗了一定的时间。这种事如果能提前知会一下,做好准备就好一些。

人员
我太过相信项目成员了,以为所有的人都对项目流程熟悉,都有能力做。但中期我发现个别人不行,我无权力对某个人的能力做评价,但的确不是这个项目的这个模块最佳人选。我向上峰反映过,但我知道结果。我曾一度想过换人,但已然到中期,换人肯定不好,这也使得我被迫亲自指导。这个血的教训,使得项目监管部门考虑后续项目引入人员评价表,当然,是以我是做小白鼠为代价的。但如果下次还是不幸被做临时项目经理,我会亲自考核每个人。如果还有出现这种事(包括前文说的),我一定要反抗。
另外,还有一个比较郁闷的地方。在做项目计划时,每个模块都安排了人,看似很好,但实际上,很多问题不是计划表上所能知道的。在做项目时,会安排所谓的方案整合人。我便是从方案整合人做临时PM的。他的角色是救火队长。没有安排到的模块,他来做;测出来的bug,他先分析;去外场测试,他要去。在这次项目中,我就是PM和整合人的合体。

流程
公司很多人对项目流程是有意见的,但又没有提出更好的反对观点,于是只能服从。
项目的监理,更多的是催文档,催周报。当项目出现问题时,永远是相同的格式:对项目交付有影响吗?如有影响,评估延期多少天?
对于风险管理,我认为有些扯了。风险管理是必要的,但实际上无法做得好。已知和有消除措施的风险都不是风险。
在项目验收时发生的事,让我最终认识到流程的权威性,流程就是流程,就要遵守。——哪怕再耗时。

最后说点委屈的话。作为菜鸟级别的人,肯定是要人指点的。我发现在项目中,监管的人都在高高在上,只是对你做要求,不理会原因。动不动就说你对流程没意见就要努力执行到位。我曾一度放弃,他们爱说什么说什么,我只做我的事。而部门主管也没有指点。因为公司的制度,做项目的人是归项目经理和项目监管部门的,主管不过问。但在项目中,别的部门老大出面干预了,我们老大没有。作为新手,的确需要有人指导迷津。

李迟 2015.9.3晚

本文固定链接: /code-life/a-project-note3.html

如无特别说明,迟思堂工作室文章均为原创,转载请注明: 我参与的一个项目的继续总结:经验篇 | 迟思堂工作室

目前暂无评论

发表评论

*

快捷键:Ctrl+Enter