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的人，以及以后希望在这方面有发展的人一些帮助。
版权声明：本文出自 fairyfox 的51Testing软件测试博客，欢迎转载......
