项目管理小记
软件项目的项目管理从个人经验来看是一项是主要靠经验的积累，所以看到软件工程的硕士研究生的招生的时候就好奇能从书本上学习到什么？ 在学习项目管理的路上，我觉得自己是幸运的，因为我跟着老前辈们学习到很多珍贵的经验，书本上一般会面面俱到，它不会告诉你哪些重要的，哪些是不重要的，在遇到各种矛盾是如何权衡，而这些都是真正的项目中都会遇到。在这里我把8年里自己带的项目以及从老前辈身上学习到总结出来，希望对大家有用。
1、项目经理首先自己要相信没有做不成功的项目，这种信念是发自内心的，而不是挂在口头上，它体现在日常项目管理的事务中。
- 项目里不论遇到多大的困难，都相信并且积极的付出行动去解决，让团队所有成员都看到项目的进展，为团队树立信心。
- 当项目的事务乱如麻时，项目经理临危不乱，冲在一线，把事务安排紧紧有条
2、项目经理最重要的是关注计划，你的项目计划应该是每天上班都是打开的，甚至可以作为你的电脑的桌面。
- 这一点是从一个在IBM从事项目管理二十年的老前辈身上学习到的，项目计划是用来执行的，而项目经验就是这个计划执行的最忠实的捍卫者
- 计划不是不可以变化，而是经过深思熟虑的变化，随便的变化意味项目管理的随意，难以控制项目的成本
3、风险是项目难以按计划执行的最大阻力，项目经理应该善于识别风险并降低风险，这是非常考验项目经理的经验的地方。做项目多了以后，遇到困难多了，自然各种风险就知道了，所以在下面我把自己做项目经理遇到的项目的风险列出来供参考。如果是是新手，这些技能也可以向你的前辈们学习和请教.有兴趣的同学可以去看看《人月神话》和《与熊共舞》、《人件》这3本小书
- 工作量的估计一定要让丰富经验的工程师去估计，最好团队中采用固定的工作量估计方法，比如delphi估计法、FP估计法。工作量估计是一个非常有挑战的工作，大部分程序员会过于乐观估计，也有一些能力不足的程序员估计的过于悲观，总之项目经理在工作量估计的地方要做足功夫，因为后续所有的计划都是依据这个
- 项目计划的安排对外松，对内紧。对外松的原因是因为项目的开发过程中总会遇到一些意外，需要给项目留一定的buffer,对外承诺时间要谨慎。举个例子：一般开发完成以后自测通过以后，就会转测试，所以我们排计划就把2个紧挨在一起，但是在实际过程中可能测试环境的搭建并不是马上就好的，可能转测试的时候版本质量太差，转测试版本被打回等情况。相反，对内的计划要紧一些并严格的按计划执行
- 开发和测试团队的成员安排要考虑哪些是核心，哪些是非核心。核心的不能全让新人去开发，否则到后面测试阶段容易陷入问题单无法收敛的情况
- 开发过程中关键运作执行不要打折扣，项目经理不需要自己亲自亲为，但是要监控动作的落实并通过指标掌握这些动作是否执行到位。比如设计方案的评审、code review,通过评审的问题数以及项目组成员以及其它项目的基线缺陷数字来判断，举个例子：比如一个核心模块在设计方案评审时没有问题或者很少的问题，作为项目经理就要关注评审是不是走了形式，是不是参与评审的人员安排不合适等等。
- 核心的人员要有备份，否则整个项目成功可以就会有单点故障。有的项目实际情况做不到这一点，在这种情况下，关键的设计方案务必文档化，既使其它人接手慢一点但也不至于影响过大
4、计划赶不上变化，项目经理要将外部的变化变成“可控的变化”，这也是项目经理承受压力的地方，实际中遇到的场景比较多，项目经理将将外部零碎的变化变得有序，否则如果直接透传给开发人员，开发人员会很快给折磨奔溃的。常见的招式有：将需求排到下一期、需求的置换、工期的延迟等
5、项目经理大部分的时间是在沟通，而不是坐在那里看邮件，多走动式管理。项目经理不要只是在那看组员写的日报或者周报，要多与组员面对面沟通，更容易发现潜在问题，同时面对面的沟通多了以后，能够加深项目组成员之间的信任。
6、尽可能利用各种机会激励组员，这种激励多用精神层面少用物质层面，比如：让员工承担小组长或者承担核心的开发设计、组织活动、在更高层面的邮件表扬等。
项目管理知识博大精深，感觉更像是一门艺术，懂业务、懂流程、懂人，能把各种问题拿捏的恰到好处，而这些没有捷径，唯有实践。
