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的人,以及以后希望在这方面有发展的人一些帮助。