为什么总是只有我在加班 – 挂包袱现象

转自：http://blog.youkuaiyun.com/yihui823/article/details/6769887

现象

最近和一位项目经理聊天。这位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要改。

以上是个简化的描述，但是和大多数初当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的问题。

第六天，       加班一天。A做完了###4和framework，B的问题自己终于解决了，虽然我也解决了，但是我不告诉他，只是夸他做的很棒。C把###4也做完了，虽然我还要把###4再改进一下。

我想，虽然工作很紧张，但是大家都加一天班，基本上就都搞定了。每个人都有机会做出贡献，虽然忙，但是项目组的气氛还是不错的。

挂包袱现象，是我自己提炼的，希望能给才做PM的人，以及以后希望在这方面有发展的人一些帮助

一些经典评论：

pm自己对项目要有个计划

把模块和完成模块需要的时间定出来

对于新手让他自己选一个负责的。剩下的难的交给有实力的组员。（让这些人最后选那肯定就是剩下的不好的了。）时间的定制要按照1.5如果时间充足的话2也行。就是估计1天完成的设定为1.5天。任务分完后不可以在追加新的模块到组员身上。分任务的时候不给自己分，新加的功能自己来。如果自己平时会多没时间，那就分任务的时候给一个中等实力的少点作预备。这样每个人都在一开始的时候知道自己要做哪些东西便于安排自己的工作。自己给自己定的加班也不会太排斥

 

计划一定是要调整的。软件开发的管理，最大的问题之一，就是预估无法精确估算。这里所说的，就是防止PM在估算有误的情况下，把问题逐步的揽到了自己手上。

 

面子问题、不能得罪人的问题、组员偷懒的问题、组员推卸责任的问题、PM检查，组员随便应付，甚至编造假结果蒙混过关的问题

 

关键是要做好任务分解，而不是一堆都自己来做，如果那样的话就没有PM存在的意义了

 

PM不能把自己的时间全安排到项目开发中去

 

对于公司来说，赢利是最终目的。我们只能在自己力所能及的范围内，保证项目组成员的加班量尽量少。我在刚才的评论里也说了，要防止老板从项目组里抽人，只好安排少量的轮值加班去撑场面。这就是一种权衡。

 

很多技术强人可以快速，高效的完成开发工作，但很有可能做不好一个大项目的管理工作。

现在的软件PM大多沉迷于技术。PM需要深刻领会管理精髓，技术只是管理的辅助

《别让猴子跳回背上》 《人月神话》 《最后期限》

公司的领导最终是看效果的，如果项目带的平稳，他也不会在是否加班的问题上计较太多。不过有时候，适当的安排一些加班，也可以防止上层领导抽人手。很多大领导，一旦看到你项目不忙，就会打你项目人手的主意。我以往的经验，安排项目组的人，轮值加班。最忌讳的就是，没有理由的强制加班，例如每周一三五，必须加到10点钟才能下班，哪怕没事做。

 

有时候，不是下属不能做，是项目经理不放手给他去做。人在适当的压力情况下，表现出来的能量会出乎人的意料。很多技术高手初做PM，总是喜欢把下属的事情揽到自己手上，结果下属就没压力了，就像例子里的B一样。这个时候，对自己，对下属，都是不利的。

PM要学的“懒”一点，多勤快勤快嘴。

 

要指导小弟们去做事情，做好事情，而不是看着不成，自己掳袖子干。真正的技术牛人应该能预知每个包的分量，看清每个人的能力然后进行分配。就像系统优化一样。