如何做一个好的项目经理

经过刚开始几次算是比较失败的项目和后面成功的项目后，我深刻的认识到，一个好的项目经理对一个项目的重要性。

百分之九十多的项目经理都是从开发一路走来的，所以都有一个毛病，不放心底下员工的能力，所有认为重要的功能都希望自己来完成，但是作为一个项目经理，需要管理项目进度，review代码，还需要调解项目问题等，如果再花很多时间去coding，那么项目经理任务越来越多，越来越累，而项目组员却闲着，如果组员较长时间没有任务，这样他们就会变得意志消沉，没有斗志和积极性。如果项目中再存在刚毕业或者经验不足的生瓜蛋子，经常找项目经理提问，项目经理被繁琐的事情所累，变得易怒，会发脾气，最后不放心代码，自己coding，这样就形成了一个恶性循环。在航天信息的时候做的一个项目就是很典型的例子，项目经理8年的开发+2年的管理，项目刚开始三个组员，一个同事负责一个模块的开发，但是需求了解的不是很清楚，当时同事去问项目经理，项目经理只是以自己的角度来考虑问题，说：你这都不懂，说了多少遍了。。最后那个同事再也不敢问他需求了，就按自己理解的来做了，后来这个模块开发完了，需要集成的时候，发现跟需要的差太远，项目经理把那个同事大骂了一顿，自己负责这块的coding了，到后来，自己累的不行，晚上有时候加班到1点，我们没活干也得陪着他，大家都很难受。

当然我们不否认一个好的项目经理是有很好的coding能力，但是作为一个项目经理，你的职责不是coding，你是站在一个项目总的角度上去考虑问题，你的目的是按时保质保量的交付项目。假如你陷入了coding的焦油坑，那么这个项目将很难完成，到最后你可能需要拼命的加班，你的组员你也会要求加班或者不要求，项目经理加班他们也不敢走，但是他们的工作量不饱和，又没事干，这样下去即使项目完成了，自己肯定也累的半死了，项目团队可能也差不多解散了。组员会因为没有太多提升空间和长期意志消沉而跳槽，而自己身体健康也受到了很大的威胁。

只顾自己埋头工作，而不管组员和项目进度，这是很愚蠢的，就像一句话说的：水桶能装多少水是由最低的那块决定的，突出的这一块再高也没用，需要的是把最低的那块补起来。

后来换了一家小公司，自己做了Manager，很庆幸我碰见了一个好的部门经理，因为是老乡我们经常一起吃饭时聊一些项目管理的事情，他是一个很厉害的人，很有宏观视野，给我了很多帮助，我跟他说，我怕自己也会陷入这样的困境，希望他可以监督我。后来发现我做的还是不错，我试着把任务都分散出去，自己主要负责把控项目进度和协调，还有就是review代码，但是刚开始效果不好，时间节点到了，大多数组员的进度都是落后的，士气也比较低落。后来经过跟组员交流，发现一方面是检查的少，另一方面是组员有技术疑难拖时间太久无法解决，于是每天早上召开半小时的小会，主要是确认进度，组员轮流主持会议，这样大大的调动了组员的积极性，效果立竿见影。会议的内容包括：

汇报前一天的工作进展
今天的工作计划
是否存在技术疑难

每周的周五下午例会，讨论内容：

投影组员代码review(检查代码质量问题)
遇到的问题，解决项目中的技术难题
组员心声，谈谈自己这一周有什么抱怨 (项目经理去协调资源)

希望说的这些能让大家收到启发和益处。