其实大家都应该清楚知道，一个项目，通常由三方面来决定其成败，Quality，Schedule，Effort，老板们也通常都会强调说，我们这个Project，我要求这三个方面都得meet到，meet不到也得OT给我meet到。但我觉得，通常往往这样强调的PM们，其实根本就不了解一个Project开发的具体情况，根本没有从Project Team的成员的角度考虑问题，没有做到以人为本，根本不是一个好的PM，也可以这么说，这个PM是没有开发经验，不是从第一战线打拼出来的。
 
为什么这么说？我个人觉得，在中国，符合中国国情的情况，大多数PM都是从第一战线升上去的。没有开发经验的PM，除非你是大型的公司，否则根本没有能力做好一个称职的PM。为什么，只有大型的公司，才能afford得起“管理与开发分离”。但更多的情况是，一个称职的PM，得考虑到所有的情况，包括Effort的估计，Resource的选定，Schedule的制定，Effort的控制，还有考虑Resource的培养，如果出现问题，能够给出正确的指令，得准确高效的指定分析解决人员，和User进行沟通协商，要做到所有这些，如果一个PM没有相当的技术基础和开发经验，根本做不到这些要求，而这些要求，往往又是中国的大多数IT公司理想的PM们。
 
我现在所在的公司的情况是，PL们做得往往比PM还多，上面提到的PL们都需要考虑，而PM们更多的情况是，只管PL一个人，PL去管下面所有的人。也不知道是幸运还是不幸运，我恰巧也是这么一个PL，从Project的立项开始，做TSR要参与，给出大的设计思路和解决方案，SDD要参与，给出系统级的设计，PS要Review，Code要Review，Resource的选定要考虑，Resource做完Project后有没有收获，Team Member有没有buildup起来要考虑，Effort要估计，Schedule要制定，还得和User讨价还价，还经常被User砍Effort。
 
我就遇到过被User砍掉一半Effort，而我的PM一句话不说，要我认了。最后结果证明我的估计是正确的，最终还是花掉了当初估计的Effort才能做完整个Project。这里我要强调的一点就是，作为一个PM，你得懂得疑人不用，用人不疑。如果你怀疑属下估计的Effort不准，那OK，你来估看看，我告诉你我手上的Resource情况，每个人的专长，他们的生产率有多高，你要是估得比我准，我马上辞职，你要是估得不准，你以后就给我闭嘴，OK？
 
我个人认为，Quality Priority最高，不管你是提前完成，还是delay了才完成，Quality我是最看重的，质量高于一切。Schedule的制定需要技巧，在制定Schedule的时候，你得留点Buffer，得考虑突发情况的时候，对Schedule的Impact，我往往的做法是对下属有个明确的Deadline，这个Deadline比真正交互的时间有个时间差，从而可以cover一些突发事件，例如，某某请病假。Effort往往就是Budget的直接体现，这个也是需要技巧的，但是这个是需要和User谈的时候要明明白白说清楚的，我们的Effort通常有一个contigency，也是用来handle一些突发事件的，在做planning的时候，这部分contigency是不能plan在里面的，通常的做法就是Schedule比实际的人月的工作duration要长。OT是最不可取的，出现OT，就证明了Project出现了预期外的问题了。而OT往往又会对员工的士气造成直接的打击。我这里想强调一点，在做估计的时候，一定要以员工的角度考虑问题，以现有Resource的Productivity来估计一个项目的进度和预算。
 
在管理一个项目的时候，除了要实时监控整个项目的情况，也要对Resource的情况进行监测，赏罚分明，例如某某表现好，就要公开表扬，某某表现差，就要私底下批评，整个项目做完后要明确知道每个人的所得，开个closure meeting，分享大家的经验，做好记录。看看哪些方面需要做improvement的，适当安排training来提升，从而提升下一个项目的时候team member的生产率。而且，resource的buildup情况一定要让resource本身了解到，只有当员工自己知道自己还存在哪些不足，他才能进步，也只有这样，员工才会对公司有更强的归属感。
 
其实这些cmmi的process都有提及，只是怎么结合真正的项目实施需要考虑的问题很多。cmmi是死的，人是活的，我觉得管理的核心就在于以人为本，只有人才是一个公司的命脉所在，人才build起来了，公司的企业文化深化了，就能留得住人才，公司的发展才有希望。