项目经理的职责[很好很强大].doc

项目经理问：为什么总是只有我在加班 挂包袱现象 转自：/yihui823/article/details/6778351现象最近和一位项目经理聊天。这位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的人，以及以后希望在这方面有发展的人一些帮助。我该怎么安排下属的工作-项目经理如何分配任务 /yihui823/article/details/6778351记得自己第一次当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把接口函数定义好，原有的接口函数留一周，下