以上是个简化的描述，但是和大多数初当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的人，以及以后希望在这方面有发展的人一些帮助。