四.控制和执行阶段
1.软件开发
实在没什么好说的，也是大家最不愿意谈的，平时在公司里谈的已经够多的了，还要在这里受我唠叨。需要提醒的依然是团队合作精神和完善的文档管理制度。 SOURCESAFE这些工具有时候还是有必要使用的。经常看到有人说天才程序员不写注释什么的。我相信有这种天才程序员，因为我碰到过几个。
我爱人公司里也有一个，他们的一套产品核心代码就是这个人写的，4年过去了，周边代码换了好几茬，核心算法始终没换过，可惜这小子跟了李洪痔，如今已经不知所踪了。但是他的代码似乎也要有点注释的，没有注释过段时间再天才的程序员也不能保证他是最有记忆力的。而且，对一个项目的编码来说，靠一两个人打天下如今是不可能了。别人的公司都是团队，两人智慧胜一人，这头还在靠一个天才支撑门面，实际上市场可就别人抢了去，那时候再天才也没用了。
编码的时候讲究技术公开，程序员不要藏着掖着，对大家没好处，PM要想办法调动大家创新思维的积极性，营造良好的技术讨论氛围，碰到技术难关的时候就容易攻破了。有个问题需要单独对还没有PM觉悟的程序员说，其实是在调研的时候就定了的，就是使用什么样的开发工具。没有经验的程序员往往会拿着C++或者JAVA的资格证书或者拥有一两个开发工具的一些经验而得意洋洋。其实老板和PM根本不看重这个，他们关心的是使用什么样的工具能尽快的达到目的。管你什么C++， DELPHI，PB还是JAVA，只要能做的出来，VFP都可以用。我举这个例子并非说不看中工具，而是提醒想转型为PM的程序员，第一要把工具当作工具，而不要被工具套进去，钻研一些一辈子都用不上的技术；第二要掌握的并非是单独的一个工具，而是流行的程序设计的思想，以及在最短时间内掌握一门陌生工具的能力。只有建立了这样的思维，才有可能转为PM，否则一辈子都是技术工人，最多就是个技术总监。
2.变更
对任何项目，变更无可避免，无从逃避，只能去积极应对，这个应对应该是从需求分析就开始了。对一个需求分析做的很好的项目来说，基准文件定义的范围越详细清晰，用户跟PM扯皮的幌子就越少。而需求没做好，基准文件里的范围含糊不清，被客户抓住空子搞你一下是非常头疼的事情，往往要付出无谓的牺牲，有时候甚至非常火大。需求做的好，文档清晰又有客户签字，那么后期客户提出的变更就超出了合同的范围，需要另外收费。这个时候千万不能手软，并非要刻意赚取客户的钱财，而是不能养成客户经常变更的习惯，否则后患无穷，维护的成本会让PM吃不消。
在客户提出变更请求时，要建立变更申请登记表和变更申请表，并让客户签字。当然，有时候一些不是非常关键的模块PM也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领导的面，千万要卖面子，但是也别卖的太干脆，不要让他们得到的太容易。需求做的不好，客户抓住漏洞或者非常不讲道理，麻烦就大了。有时候争论会很厉害，到非常白热化的地步，PM与客户代表几乎沟通不了。PM在客户关系和短期利益两方面难以取舍，一般都是向客户妥协，最终形成恶性循环。这种情况非常难办。一般这种情况都是到了项目后期，做重大的更改几乎是不可能的事情，如果白做就要亏钱。而这个时候如果PM跟对方高层的人关系搞的定，可以透过对方高层把事情压住。然而由于已经到后期，客户代表不会轻易更换，对方这次没有改成，必然心怀不满，下回在别的模块依然会找麻烦或者在谈二期的时候动动手脚，都是很让PM伤脑筋的事情，这方面目前还没有什么好的解决方法，所以尽可能的做好需求比什么都重要。相对需求来说，什么WBS，风险管理，计划进度都是扯淡，需求做好了，一帆风顺。还有一种办法就是装可怜，要装的非常的象，在对方的领导面前装，而且不能让人看出是装的样子，要让你自己都觉得你自己是真的可怜，那么就算这次客户硬是要求改了，下回他也必然不好意思再叫你改。其实人心都是肉长的，如果可能的话，我还是不赞同使用一些手段的，但是有时候客户非常难以在短时间打动而工期又将接近，这种情况下就要靠PM耍一些手段了。各人有各人的方式，八仙过海，各显神通吧。 PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
3.质量控制
大公司有质量管理部门（QA），QA的成员基本上都是由非常有经验的PM转型过来的老狐狸，是老总接班人的有力争夺者。一个QA会管理多个项目，有时候甚至会亲身参与。PM和QA有些象猫和老鼠，不停的通过报表传递一些心照不宣的假数字。QA对PM的工作最终是有评定的：A级表示总体在控制下；B级表示当前在控制下；C级表示有显著问题；D级表示有重大问题。如果PM得了个D，那可不太妙，不但世界级的QA会每个月要收报告，地区QA会一个星期找来面谈一次，训一顿。得到A的PM是很逍遥的，基本上不会有人来过问。在没有QA的公司，质量控制只能由经过授权的团队成员进行，效果就要差的多了。质量管理贯穿整个项目周期，详细的可以参见CMM。
4.成本管理
PM经常通过控制进度和预估来控制成本。PM必须经常问自己，项目已经到了什么阶段？完成了多少？花费了多少？完成时成本是多少？挣值法的术语不少，象BCWS，BCWP， ACWP，但是关系比较简单，大家参阅一下相关资料，这里不再羸述。总之，PM要管理好成本，注意节约，但并非是拼命剥削程序员，该花的还是要花。
五.结束阶段
1.项目结束
项目结束时，PM要将最终系统方案提交给用户，完成项目所有的提交件，收集项目全部信息并结束项目，完成或终止合约，签署项目结束的相关文件。项目结束意味着可以收钱了。PM辛苦了那么多，终于可以高兴一下了，收到最后一笔款项，意味着递交件的移交和团队的解散，项目也转入维护阶段。不过收钱未必代表着赚钱，要看项目是否按时完工。一般来说，提前完工的项目很少，但是能赚大钱；按时完工的赚小钱；延期的要赔钱。一个人首次承担PM，如果没有人带，多半会失败。失败没什么，所有的PM（注意是所有，不是几乎所有）都失败过，然而失败会成为教训和经验，推动你继续前行。在美国，每年至少有40%的项目无法实施被搁浅。只有在项目中和生活中不断磨练，培养自身素质和作人的基本准则，才能成为赚大钱的PM。
2.项目完工会议
项目结束时，依然要开会，不过少多了。一般跟客户要开一个，主要是确定所有的提交件都已经被接收，对突出的个体进行表扬，对外宣传成功案例，标志并记录项目的正式结束。这时候开会很轻松，目的也很明确，做完了大家好聚好散，或者以后有机会再合作。团队要解散，内部会议肯定是要开的。也没什么好废话的，该表扬就表扬，该发多少奖金就发多少奖金，毕竟大家都累死累活的干了那么长时间。项目结束请客户出去泡温泉时PM们千万别忘记了辛苦为你工作的程序员和工程师们，当然，如果他们不愿意看到你的脸那么你就折现发到他们的存折上去，正好让他们回家好好休息休息。这样下一个项目需要他们的时候他们才会为你卖命。说出来奖金发出去似乎你损失了，其实你赚大了。
3.客户满意度
形势也好，历史记录也好，尽管项目结束的时候客户满意度PM心中已经有底了，但是还是有必要向客户各个层次的项目代表发一张信息反馈表，收回的信息将反应客户的满意度。其实真正体现客户满意度的地方有很多。第一就是付钱付的快，如果客户不满意，一分钱藏在他牙缝里你也很难抠出来；第二就是二期，二期非常非常重要，因为这里已经是属于一种无销售成本的项目，又有一期的经验，可以说二期的钱是最好赚的。这中间的感觉，只有经历过的人才明白。
