项目经理的职责很好很强大.docx
- 文档编号:28653800
- 上传时间:2023-07-19
- 格式:DOCX
- 页数:12
- 大小:25.32KB
项目经理的职责很好很强大.docx
《项目经理的职责很好很强大.docx》由会员分享,可在线阅读,更多相关《项目经理的职责很好很强大.docx(12页珍藏版)》请在冰豆网上搜索。
项目经理的职责很好很强大
项目经理问:
为什么总是只有我在加班–挂包袱现象
转自:
现象
最近和一位项目经理聊天。
这位PM之前是个技术大牛,没什么搞不定的东西,而且做事也认真,也卖命。
领导没理由不提拔这种牛人。
所以,这个项目让这哥们当PM。
聊着聊着,这位牛人发出一声感慨,现在的员工不好带啊,每天到了晚上7点,就只剩我和另一个小组长了。
项目组10多个人,都跑的精光。
我乐了。
其实这种情况,我也是碰到过的,在我带的第一个项目,也是类似的情况。
我不敢武断的下决定,就跟他多聊了几句。
问:
那你大概几点下班的?
答:
每天都11点之后。
问:
任务很重吗?
答:
其实也不重。
问:
那些走了的人,你没有安排任务给他们吗?
答:
安排不了。
问:
为什么不能给他们安排任务呢?
答:
他们搞不定。
问:
为什么搞不定啊?
答:
我也不知道。
我尝试给他们分配了任务,但是到头来,那些问题又到我和XXX(另一个小组长)手上了。
后面我也不需要多问了,大概就是我估计的情况。
我把这种情况,称之为:
挂包袱现象。
分析
为什么叫包袱现象呢?
我们可以这么来描述。
每个项目,其实是一个大包袱。
一个公司有大大小小的许多包袱,每个包袱合理完整的解开了,里面就有利润。
但是如果包袱解开不正确,就会减少利润,甚至破坏利润。
那么每个包袱,都交给一个项目经理来解。
项目经理带领一帮兄弟,负责把这个包袱合理的解开。
而包袱是可分解的,也就是说,包袱可以分成大大小小的子包袱,如何解开子包袱,也是每个项目组成员的工作。
对于一个项目经理来说,最重要的工作,是如何把大包袱,合理的分解成小包袱,然后合理的分配给项目组成员来解,并且需要随时监控小包袱的解开情况,一旦发现有小包袱解开的步骤不合理,立即予以干预;如果发现有大包袱分解方式不合理,也必须尽早的改正。
项目经理最重要的工作是不是,自己亲自撸袖子去解包袱呢?
答案很容易说,当然不是。
但是,一般初次做PM的人,就容易走进这个圈套。
例子
我们来说一个例子吧。
项目经理甲,在项目一开始分配任务的时候,这么安排的:
A同学,你做###1模块;B同学,你做###2模块;C同学,你做###3模块。
剩下最难的###4模块和framework我来做。
要求5天完成。
OK,貌似挺合理的,ABC三位工程师就去干活了。
A同学比较聪明,第一天就完成了50%,下班就走了。
第二天就做完了,下班也走了,然后就优哉游哉的玩了三天,等着最后的时候昂首挺胸的汇报佳绩。
B同学很卖力,但是偏偏###2模块比较麻烦。
B同学第一天完成了50%,加班到8点下班了。
第二天碰到一个难题,搞不定了。
于是向甲求助。
甲无奈去帮B同学分析了一下午,终于把这个问题解决了。
这时甲延迟半天。
第三天,B同学又碰到一个难题,再次请教甲,甲分析了一上午,搞不定了,于是扔下一句话:
这个等我有空来看吧。
于是,B同学第三天努力的分析问题,加班到10点。
第四天,B同学想着反正甲答应解决的,于是在下班后就回家了,也没有加班。
C同学是个新人,对于环境也不熟悉。
第一天熟悉了一天开发环境。
第二天毛毛糙糙的做了一点东西,感觉还不错。
于是,第三天第四天,不用加班就把东西做出来了。
第五天,C同学很开心的汇报说,工作做完了。
第五天下班的时候,甲自己已经延迟了2天的进度,其中1天是因为帮助B同学,还有1天是因为各种会议、各种报销等闲杂事情,忙的焦头烂额。
甲随便的问了下ABC的进度,发现A和C已经完成了,B的问题需要甲自己解决。
于是,甲周末来加班了。
在吃午饭的时候,随便瞄了一眼C的代码,乖乖,和自己的预期差的十万八千里。
于是,只好把C的东西去掉,自己开始从头做。
于是第二周,ABC都在等着甲。
A等着甲分配任务,B等着甲帮着解决问题,C等着甲改造自己的程序。
而甲还得赶紧把###4模块做出来,framework还有一堆BUG要改。
于是,甲开始向周围的人抱怨,说自己的项目组如何不努力。
在公司领导的干预下,甲公布了一条规定:
每周一二三四,必须晚上9点钟下班。
在第二周的周五,甲拖着疲惫的身躯,向大家宣布:
项目进展不顺,周六加班。
于是在抱怨声中,ABC只能无奈的周末来加班,陪着甲去解决问题。
以上是个简化的描述,但是和大多数初当PM的人碰到的现象大差不差。
对于项目经理甲来说,他分包袱的工作太随意,并且没有跟踪小组成员解包袱的进度,直接导致了最终的结果:
所有的包袱都在自己的手上。
这就是我所说的,挂包袱现象。
很多技术牛人,都会不服气项目经理,认为这个人只是在分配任务,整天追着我们要工作进度,自己不做事,碰到难题就扔给我。
但是一旦他自己做到了项目经理的位置,他就应该知道,分配任务,追着要进度,这就是项目经理的工作重心!
我只是说工作重心,不是全部的工作。
我也不会说,项目经理不需要写代码。
项目经理适当的写些代码,对控制项目会有很大的帮助。
这个我们以后再讨论。
我们来分析下,项目经理如何去规避“挂包袱”的问题,让项目组成员能够一起来完成项目呢?
改进
1. 首先,不要把组员想象的那么坏。
很多项目经理,一旦看到项目组的组员弃自己不顾,径直就下班走了,就会大发雷霆,然后把组员定义为:
坏孩子。
然后,就不敢分配给组员任务了,什么东西不如自己做。
就经常听到有PM抱怨,现在80后不好管,没有责任心。
其实,我带过的80后,虽然个性强一点,但是责任心并没有想象的那么糟糕。
虽然也有责任心不强的,但是不会一个项目组都那么差吧。
出了问题,要从自己身上找原因。
如果任务安排合理清晰,我想大多数工程师都会把任务的责任给担起来的。
所以要注意以下几点:
a) 定义任务,一定要清晰明确。
b) 分配了任务,不能到最后再去检查。
c) 随时根据任务完成情况,来调整后面的工作。
d) 不要随意把任务收回来。
2. 其次,不要把组员想象的那么笨。
很多技术牛人提拔上来的PM,都不敢相信自己下属的能力。
他们一旦看到下属的代码写的不好,结构不好,用的API不对,注释不够清晰等等,就对下属的技术能力打上一个叉叉。
在之后的工作中,什么都不敢放给下属做。
下属一旦工作有点失误,就大发雷霆。
记住,哪怕你的确是这个项目组里技术最牛的,你也不要这么做。
为什么?
a) 公司无法给10个像你这么牛的人,让你做项目经理
b) 如果真的给了10个人让你来管,你未必管的了他们
c) 你如果太牛了,下属哪里来的机会去犯错。
没有犯错的机会,怎么得到成长
3. 最后,不要把自己想象的那么神。
这句话看上去跟前面两句差不多,其实还是有差别的。
最大的意义就是:
不要什么事情都自己做。
记住,PM的目标是把项目做好,不是一个人的表演。
你再牛,你也没法一个人做完10个人的项目。
就算你做完了,也是10个人的功劳,不是你一个人的。
所以,要放手给下属去做。
改进例子
我如果是项目经理,以上那个例子,我会这么安排。
A去做最难的###4模块和framework。
B做###2模块,C做###3模块,我自己做###1模块。
第一天, 我不会立即开始做###1模块。
先看每人的工作。
发现C做的代码不好,就安排B去辅导。
第二天, B告诉我###2模块搞不定。
我让他自己解决。
我开始做我的###1模块。
第三天, B还是搞不定。
我帮他搞一上午,我发现了问题,然后告诉他如何解决,让B花一下午去解决。
第四天, B还需要帮助C,所以时间不够了。
我告诉B,你不要帮C了,你专心完成###2模块吧。
我自己来帮C。
A来向我抱怨工作太多,我说表现你的技术实力的时候到了。
第五天, B又碰到问题了。
我让他先自己解决。
C已经完成了###3了,我让C帮我做###4,我同时看B的问题。
第六天, 如果项目紧张,可以加班一天。
如果在BUFF的控制范围内,那可以在下周一完成。
A做完了###4和framework,B的问题自己终于解决了,虽然我也解决了,但是我不告诉他,只是夸他做的很棒。
C把###4也做完了,虽然我还要把###4再改进一下。
我想,虽然工作很紧张,但是大家都加一天班(或者项目里程碑延期一天),基本上就都搞定了。
每个人都有机会做出贡献,虽然忙,但是项目组的气氛还是不错的。
挂包袱现象,是我自己提炼的,希望能给才做PM的人,以及以后希望在这方面有发展的人一些帮助。
我该怎么安排下属的工作-项目经理如何分配任务
记得自己第一次当PM。
那是接手的项目,原来的PM,在项目需求分析做完之后,去接手另一个重要的项目去了。
当时我和另外两个小组长,自然就成了接手PM的人选。
最终原PM选择了我做他的接班人。
而我当时最头疼的就是,我怎么给另外两个小组长分配任务啊。
前一天大家还是平级的讨论问题,现在就轮到我指派他们工作。
时间流逝,从当时的不知所措,到现在得心应手,中间坎坷困惑都不少。
昨天的一篇文章,介绍项目经理需要合理分配任务,就有同学质问说,说起来容易,实际安排任务就会有各种问题。
今天我就把这方面的心得总结一下吧。
在总结之前,还是要谦虚一下的。
管理学,和我们学的数学不同。
数学是有标准答案的,1+1就是等于2,没什么讨论的。
但是管理学上,我认为是没有答案的。
每个人都有自己的管理理念,有自己的管理风格,有自己的管理手段。
只能说哪个好些,哪个不好些,但是没法说谁对谁错。
能达到管理的目标的,我觉得就是好的,就是可行的。
我这里写的,只是我自己的总结,希望能对大家有所帮助。
分配任务,我觉得可以从几个方面来分析。
首先,是PM自身的阶段。
1. 初始阶段
在刚开始做PM的时候,分配任务往往会局限在这样的一个心理:
这些以前我们都是平级的同事,现在我比他们高一个级别了,我说的话他们会不会听啊。
我想有这个心理,人之常情。
这个阶段,PM缺乏的是自信,缺乏在组员心中的威望。
在PM分配任务的时候,自己心里都犹豫不绝。
如果这个时候,组员说了一些与PM想法不同的话,说了一些他们自己的见解,PM往往就会误解为,这是对自己的不服,是自己分配不好。
这个时候,尴尬犹豫,往往就会煎熬着PM。
而组员在一个缺乏自信的PM的带领下,自然也会士气低落。
有些组员就会不发表自己的见解,以避免尴尬;有些组员就会故意按照有利于自己的方式去为难PM,以达到减轻自己工作的目的。
这里我可以说一下当时我的处境。
我在分配任务的时候,都是以商量的口吻,问另两个小组长。
例如,“你看这个东西,你来做下怎么样?
”另外两个小组长,也都是经验丰富的高手,往往都会说上几句。
于是我就认为是我没法管理他们,于是我就跑去找我的领导,咨询办法。
我的领导也没有多说什么,就是让我请他们吃一顿饭,饭钱公司报销。
这可是第一次,我心里虽然很犹豫,但是还是照做了。
吃饭的时候,我还在想我要不要说些什么,但是最终我什么都没有说。
饭局在很轻松的气氛下结束了,也就是聊了聊家常。
我心里就觉得,他们不是我想象中的那样,对我有敌意啊。
在后面的任务安排上,在他们发表出不同见解的时候,我就开始鼓起勇气与他们争论。
我大胆的把我自己的想法考虑说出来。
我竟然惊奇的发现,只要我说出了我的考虑,他们基本上都会听我的。
从这一顿饭,我其实得到了什么?
我自己后来反复思考,我得到的最大收获,就是—自信!
那顿饭的饭钱,我后来还是没去报销,几百块钱我觉得很值。
所以说,PM在初始阶段,分配任务最大的阻碍就是—自信!
只要你有足够的自信,什么“面子”问题,都迎刃而解。
分配任务,是你的职责所在,没什么不好意思的。
只要你有足够的自信,你就能给组员以足够的信心,让他们觉得,跟着你是能够走向成功的。
至于如何建立自己的自信,每个人都可以有不同的方式。
和组员保持良好的私人关系,或者对自己说些立志的话。
在项目立项会议上,由高层领导去说些鼓励的话,也会给PM带来不少自信。
我说的自信是最大阻碍,不是唯一阻碍。
在自信建立了之后,还是有许多要注意和学习的。
但是,前提是自信。
2. 提高阶段
在PM解决了自信问题之后,很可能就会来到另一个极端。
这个倒不一定每个人都如此,这个和性格有关。
自信的另一面,就是自负。
往往PM在度过了初期的不自信之后,就开始信心大增。
权利欲比较强的人,往往就会形成自我中心的现象。
这个时候,分配任务的口吻都是命令式的,例如:
“这个工作,你后天下班前一定要给我,不管你怎么完成”。
高度的自负,往往对项目组是有害的。
虽然他可以让组员精神高度集中,但是他们的创造性就被打压了。
软件行业是高度的创造性,而不是简单的填鸭式工厂作业。
PM再牛,在实现细节上也不会比组员更熟悉。
命令式的安排任务,往往会让组员不敢发表自己的想法见解。
这样的话,问题到最后才会暴露出来,往往给项目带来更多麻烦。
在这个阶段,PM要认清楚自己的自负,还是比较难的。
也许是吃过几次亏,也许是被领导批评过,也许是看了很多书籍,总之,随着经验的增长,总会慢慢的把这个阻碍给克服掉,否则这将成为个人成长的瓶颈。
3. 挥洒阶段
在度过自己的自卑-自负两个阶段后,PM基本上在分配任务方面,不会有什么心理障碍了。
这个时候,就需要在技巧上多磨练,达到挥洒自如的地步。
这个就不多说了。
其次,组员的性格。
说管理学是一门艺术,一点也不过分。
针对不同的人,施展不同的手段,往往就是事半功倍的效果。
组员的性格各有不同,如何让他们能够接受自己分配的任务,特别是困难的任务,这个还是有些技巧的。
虽然说每个人的性格都有不同,没有完全相同性格的两个人,但是还是可以把性格大致分类。
我以前在接受培训的时候,听过一种分类方式,很有实际意义,对我后来的工作起到了很大的帮助。
在这里介绍给大家。
人的性格,可以大致分为四类,每个类型都以一种动物来比喻。
1. 孔雀
这类性格的人,爱表现,爱出风头,自然也是爱表扬的。
对这种性格的人,尽量少批评,多夸他们,他们往往就乐意接受你安排的困难任务。
这种性格的人做事很快,雷厉风行,但是一般都比较毛糙,这一点在分配任务的时候需要注意。
2. 白羊
这类性格的人,内向,不爱多说话,感性大于理性,内心防御感比较强。
给他们关怀的同时,开开笑话,消除隔阂,是减少他们的敌意的好办法。
如果要分配比较困难的任务给他们,最好是先问一下他们自身是否有什么困难。
这类性格的人,做事勤勤恳恳,只要他们接受了的任务,一般是不会让你失望的。
3. 猫头鹰
冷静,具有极强的分析能力,对数据的敏感,极其理性的思维,是猫头鹰性格的特点。
与这种性格的人交往,“以理服人”是最好的钥匙。
你如果能说服猫头鹰们,他们会给你极大的帮助,会冷静的帮你分析各类问题。
如果你在说辞里,加上一系列的数据,例如我们的项目需要控制在多少人月以内,需要把BUG率控制在千行1个的水平,那么猫头鹰们会很欣赏你,自然会更加配合你的工作。
4. 老鹰
天生的领导者,一往无前的勇士,不畏困难,最喜欢接受有挑战性的任务。
跟这种人交谈,你不需要费口舌去讲细节,因为他们不在乎细节。
你需要有一个宏伟的目标,需要有一个远大的志向,并且需要表现出你想带领大家共同达成这个目标。
对于这种性格的人,你必须表现的十分的自信,因为他们喜欢强者,哪怕你用职权去“欺压”他们,他们也会接受。
你也不用担心给他们的任务太难他们不肯接受,只是要担心他们拿到任务做不出来。
不是他们偷懒做不出来,而是他们一般不是技术高手。
虽然可以按照性格分类来区别对待每个项目组组员,但是具体情况还是要具体分析,需要灵活掌握,毕竟每个人的思想都是不同的。
最后,是项目组合作的氛围
现在比较流行的敏捷编程思想,这的确是个好方法。
把当前的任务都列出来,然后每个人去领取任务。
这可以极大的调动项目组成员的积极性。
但是,这种方法也是要辩证的来看的。
1. 团队组建初期
如果是一个才组建的项目组,组员之间大家都互相不熟悉,甚至有些人之间有隔阂。
这个时候,让大家自己去领任务,无异于玩火。
每个人对项目组都会有戒心和抵触,每个人都怕自己背黑锅,每个人都怕别人做的少反而受奖励。
甚至,每个人都担心PM能力不足,担心无法齐心协力的去完成项目。
在领任务的时候,大家都会尽量去挑容易的做,出现问题的时候,都会尽量去推卸责任。
这个时候,PM可以表现的很强力,甚至很独断。
我记得看过一部电影,一个将军去做第一艘核潜艇的舰长,带领的船员都是临时拼凑起来的。
在出征之前的讲话中,船长说:
“你们必须听我的,没有我,你们什么也不是。
当然,没有你们,我也什么都不是。
”这种强势的态度,很快让每个船员都找到自己的位置,让每个船员都明确自己的责任。
其实最后,这个舰长的做法很人性化,但是在团队组建初期,人性化有时候是会对团队建设起到反作用。
所以,这个时期,尽量以指派任务为主,并且要随时跟进任务完成的进度,随时调整任务的分配。
指派任务需要注意方式方法,也要说清楚来龙去脉,否则组员可能会有抵触或者消极情绪。
2. 团队磨合期
在经历了团队组建初期的互相不信任之后,就应该进入了磨合期了。
这个时候,组员之间相互了解,是建立相互信任感的时候了。
PM在这个时候,去让大家自行领任务,已经可以达到很好的效果,但是监控不可少。
因为组员之间的配合还不可能很默契,不会完全按照各自的优缺点去分配,很可能是按照自身的兴趣爱好去领任务。
有些无趣的、难的、鸡肋的任务,会被一些不愿意说话、不喜欢出风头的人领走;而那些积极分子们,会先去领一些好玩的、他们自己觉得有趣的任务,哪怕这个任务不是他们自己擅长的。
如果任务之间的差异性不大,那么这个时期去自行领任务,基本也不会有什么问题。
但是如果任务之间差异比较大,那么PM不控制的话,会在磨合期出不少问题。
配置无法最优化不说,那些不愿意说话的人,领到了不好的任务,就会觉得不公平,但是他们又不愿意表达出来,自然就会在工作效率上打折扣了,而且也会影响团队的相互信任。
所以,在磨合期,用组员自己领任务的方式去分配任务,PM一定要参与进去,并且做一些微调。
这个微调,要有理有据,并且要信服于人。
如果还是指派任务,PM的压力会小很多,因为团队初步成型,指派的任务,组员会比较容易的接受。
在这个阶段,PM可以尽量鼓励大家独立思考,群体决策,以减少自己在项目组中的“独裁”地位,为进入第三个阶段做努力。
这个阶段,最担心的事情,莫过于“老鼠屎”了。
中国俗语,一滴老鼠屎,坏了一锅粥。
西方管理学里,也有“坏苹果”理论。
就是说,一个人品、性格、价值观与团队格格不入的人,这个时候对团队建设的破坏性会很大。
很多事情需要大家自觉去做的,而老鼠屎不去做,团队又不能自发的处理,将给团队的其他成员带来极大的心理冲击。
举个例子。
项目经理甲,在周一开会的时候说,我们需要改一下framework的界面接口,先由A把接口函数定义好,原有的接口函数留一周,下周一把原有接口删除,这周内大家逐步的把旧接口的调用改成新接口。
很明显,如果下周一不把接口调用改成新的函数,那么就会编译不过。
偏偏就有一个哥们,一周的时间就是不改,结果下周一,大家更新代码后,编译不过。
然后这个哥们再赶紧花个半天去改动接口,然后折腾一下,半天就没了。
10个人的项目组,5个人天,0.25个人月。
如果PM不对这个人做处理,那么剩下的组员,心理肯定是不平的,为什么他偷懒,造成了大家的这么多损失,竟然还不被处理。
团队的推卸责任、互相扯皮的事情,就会慢慢的蔓延,等到不可收拾的时候,PM再来发火,就已经晚了。
所以在磨合阶段,要及时发现“老鼠屎”,并且立即予以处理。
不要做老好人,老好人是对积极分子的一种不公平。
如果“老鼠屎”多次处理仍然没有改进,不如不要了。
不要担心项目组人少了,会完不成任务,因为多一个“老鼠屎”,对团队的副作用会更大,得不偿失。
3. 项目融合期
一个最优的项目配合。
组员之间都相互了解,相互信任。
每个人都愿意为项目组出谋划策。
每个人都知道自己在项目中的定位和责任,并且会及时“补位”。
一旦某个地方出问题了,每个组员会自动的去分担问题带来的后果。
这个阶段,PM是不需要太多的干预任务的分解,整个团队就是有机的整体,回去自动消化任务。
这个时候完全可以交给组员自行分解任务。
PM在这个项目组中的作用,就是对外汇报,给客户汇报,给领导汇报。
在内部管理中,PM基本上是没什么事情的,可以放心的去领几个自己擅长的任务去做。
说起来好像很神往,我带过一个项目组,到最后就是这个境界了。
一个大的任务来了,我只要把任务说清楚,组员们就自己去分析,然后开始列出分解后的任务,然后自动结对,领任务完成。
一旦某个组员发现了当时没有考虑到的问题,组员们自己会召集会议,并重新分摊任务。
我在这个项目中,解决了几个实际的问题,更多的时间去跟客户沟通,向领导汇报,只是在极少的时候,去做一些内部管理。
当然在一些里程碑上,我还是需要指导一下项目的方向,毕竟PM的经验还是宝贵的财富。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目经理 职责 很好 强大
![提示](https://static.bdocx.com/images/bang_tan.gif)