中国第一本项目管理小说——《最后期限》

影子为伴

"这本关于管理的书读起来明白有趣。《最后期限》是一个创新性与趣味性并重的故事，每章结尾都有基于团队的项目管理方面的原则。"
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　--John Aculley

"……这是一部技术力作。它涵盖了大量主题，从项目评估到度量标准，从相冲突的决定到处理含糊不清的说明…每章结尾的要点已经足以让您这本书成为超值之选了……《最后期限》像Dilbert的漫画书一样有趣，却没有那么讽刺。更重要的是，书中包括一些深刻的智慧，以及一些帮助您实现最后期限的实用积极的建议。我强烈推荐这本书。"
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　--Ed Yourdon
内容与特色：

　　汤普金斯先生是一位经验丰富的项目经理，却也难免被炒鱿鱼的命运。这时有人出双倍的价钱将他"请"到一个海上的小国管理六个软件项目，资金、人员、设备等所有外部条件都万事俱备，可以放手去做，还可以将自己的奇思妙想付诸实践。本以为因祸得福，却逐渐发现事情并没有那么简单，最后期限似乎变得不可能，但他已骑虎难下……
　　书中用一个虚构的故事阐述了真实世界中关于项目管理的一些原则，虽然它并不能解决任何软件问题，但它绝对会让你对项目管理的重要原则终生难忘。它将看似高深莫测的项目管理理论以浅显易懂的方式展现出来，改变了项目管理书籍一贯枯燥乏味的形象，让你在轻松阅读小说的同时受益非浅。书中每章都以汤普金斯先生的日记结尾，是他逐渐收集的经验，有了这些，你也可以成为一个优秀的项目经理。　

作译者介绍

　　作者简介：汤姆·迪马（Tom DeMarco）可是大西洋系统行会（www.atlsysguild.com）的负责人之一，同时他也是 ... 的《软件艺术的状态》（Software State-of-the-Art），以及《为何软件开销那么大？》（Why Does Software Cost So Much?）和一套基础培训录像（与蒂姆·利斯特合作的《高产团队》）的作者。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　译者简介：熊节，UMLChina翻译组成员，喜欢探索新技术，常用写作和翻译的方式进行学习。研究方向包括C++、设计模式、重构、Web Service、基于组件的软件工程等。马姗姗，北京师范大学中文系2002级研究生，文笔优美，喜爱中国古典文学作品。　　　　　　　　　
　　　　　　　　　　　　　　 前言

　　在二十世纪三十年代，科罗拉多大学的物理学家乔治.伽莫夫开始撰写一系列关于"汤普金斯先生"--一位中年银行职员--的小故事。故事中讲述的汤普金斯先生对现代科学很感兴趣。他总是去听当地一位大学物理教授在晚上的演讲，然后在中途他必定会睡着。当他醒来的时候，他会发现自己身在另一个宇宙之中，在那里某个物理常量发生了明显的变化。
　　比如说，在这个系列中的一个故事里面，汤普金斯先生醒来所在的宇宙中，光速只有每小时15英里。这意味着他可以骑在自行车上观察到相对论的效果：当他加速时，城市的街区在他前进的方向上变短了，而且邮局的时钟也变慢了。在另一个故事里，汤普金斯先生旅行到了一个普朗克常量为1.0的世界，在那里他可以在一张台球桌上看到量子力学所起的作用：台球拒绝直线穿过球桌，而是随机地出现在各个离散的位置上。
　　第一次读到伽莫夫的故事时，我还是一个少年。就象汤普金斯先生一样，我对现代科学非常感兴趣。当时我已经看过很多关于相对论和量子力学的资料，但是，直到我看了《汤普金斯先生在奇境》之后，我才真正对这些理论有了自己的理解。
　　我一直都推崇伽莫夫独创性的教育方法。这让我决定用相似的方法来阐述一些关于项目管理的原则。我需要做的就是描绘这样一个故事：一个经验丰富的项目经理被送到一?quot;奇境"，那里项目管理的规则发生了有趣的变化。这就是《最后期限》最初的灵感来源--我应该感谢伽莫夫，因为我借用了他的灵感。这个故事介绍了一个名叫汤普金斯的经理和他在摩罗维亚共和国的软件项目中得到的不寻常的经验。

影子为伴

二.启动阶段

1.项目的一些基本概念
项目三要素有多种版本，各不相同。实际操作中多分为范围，成本与进度，其中最重要的莫过于范围。我们把项目最终生成并提交给用户的产品和文档统称为递交件。谈判的时候一定要确立递交件的标准和要求，也就是范围。尽管商战的时候不可避免的客户会不断提高标准和要求，而承诺的款项却不会有一分钱的增加。但是这个标准对每个公司来说都有一个底线，一旦超过了这个底线，那项目就肯定是亏的。除非是为了二期有利可图或者是为了搞好关系，否则范围超过底线的时候情愿不做，再厉害的PM在这种情况下也是无能为力。建立范围需要的就是PM的多年的实战经验，在大大小小的项目中用血泪换来的一些体会。在这个时候，很能体现PM与技术人员的区别。成本就是客户答应付的款项，与我们的投入成本并不是一回事情。进度就不用多描述了。
项目如何成功？也有一些关键的因素。个人的理解也不尽相同，通常包括以下几个方面：界定工作目标及工作任务；老板或高层的支持；优秀的PM和开发团队；充足的资源；良好的沟通；对客户的积极反应以及适当的监控和反馈。这里要注意的就是资源和高层的支持。一个上规模的公司总是同时会有很多项目，可是再大规模的公司资源也不足以保证每个项目都能组建最合适的开发队伍或拥有最好的环境。这时候各个团队或者部门之间不可避免的会发生资源争夺战，摩擦再所难免。这时候对PM的作人再次提出挑战。除了高层对PM项目的重视程度，如果PM平时在公司与同事相处的好往往能使很多别人看起来很棘手的问题迎刃而解。相反，一个不会作人的PM由于人缘差，即使高层强压别的部门或团队配合，别人也会能拖就拖，延缓项目的进度和质量。有时候，这种内耗对项目和PM来说是毁灭性的。对客户的积极反应也比较关键。一般来说PM已经被项目里大大小小的事情搞的筋疲力尽，要PM去主动要求客户配合是很吃力的事情。然而，这个时候，越是困难，越是觉得累，越是要去主动。客户往往也不是特别的积极，主动与客户联系沟通和测试能及早发现问题。从风险控制的角度来说，问题发现的越早，风险越小，损失也就越小。积极的态度可以带动客户的积极性，在项目完工的时候，客户对你的感激往往是难以用语言描述的，这对以后接单或者做二期三期会打下良好的基础。因为在和别的新客户谈判的时候，新客户自然会找你的老客户了解情况，这时老客户随意的一句话顶的上你很费心的十句。
项目具有商业行为的几个重要特征，有消费源，有参与者，有成功关键因素，有财务目标，有风险。

2.启动阶段的主要任务
根据PMI的解释，接单之后项目自然转入启动阶段。启动阶段PM的主要任务是率领总体架构设计师和系统分析员收集尽可能详细的数据，确立尽可能详细的需求，进一步确立详细的项目范围，预估资源，确立其他方案并获得进入下一阶段的批准。在这个阶段，随着需求分析的深入，PM也开始在公司内部进行人员挑选和资源争夺，着手组建自己的项目团队。项目即将进入计划阶段。
在收集完数据之后，PM要和客户开始明确项目的大小，成本，规格，期限等重要特征并将其写入合同文本，同时准备内部的包括预算，衡量标准等文档，建立项目的评估标准。接下来就是需求分析。由于专业的原因，我们这里仅讨论软件工程项目的需求分析（以下简称需求分析）。
需求分析的主要参与人员有PM，总体架构设计师，系统分析员，熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队，我们叫做前期团队。随着需求分析的逐步深入，新的团队成员不断加入，启动阶段结束的时候正式的团队将建立。对一个已经启动的项目来说，需求分析直接决定了项目的成功与失败。最初的需求体现在客户的工作说明书或招标文件及附件上。这种需求一般比较含糊，无法体现客户真正的需求。前期团队要根据自己的经验和客户沟通并引导客户进入正轨。有时候客户会很不讲道理或者思路僵化，就要求按照他的思维去定一些明显错误的需求。这个时候团队成员要耐心和客户举事实，谈经验，讲道理，用图形或模型等直观的方式将需求描述出来，比如常见的数据流图等。所以说，争论再所难免，客户有时候会吹胡子瞪眼睛拍桌子甚至会说“这个东西不要你们做了”之类的话。PM此时除了要亲身参与需求分析综合整理文档之外，还要处理好团队成员与客户的关系，确保关系不会恶化到无法收拾的地步。只要PM尽力约束团队中的成员，这个度还是很容易控制的。
对快速开发和叠代开发来说，需求和实现往往是同步进行，开发速度快是一大优势。对有相同或类似模式的小项目来说采用快速开发或叠代开发是很合算的做法，时下流行的极限编程就是针对这方面建立的思维模式。然而，大中型项目中有太多不一样的需求和模块。如果不是因为项目有差异，那么市场上就只有产品而没有项目了。所以，大中型项目的需求要认真仔细的去做。我们要讨论一个问题，究竟应该在需求分析和总体设计上花费多少时间？我们熟悉的瀑布开发模式基本上分需求分析，总体设计，软件开发，测试等几个阶段，然而究竟应该在前两个阶段上花多少时间却没有定论。实际项目操作的例子表明，分析设计的时间越长，需求设计做的越详细，测试的时间就越短，返工率越低，风险也越小，成本越容易得到控制。而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展顺利的时候问题不大，到了项目后期和测试阶段一些潜伏期比较长但是破坏作用比较大的问题就会凸显出来，造成返工，延长测试时间。所以与其把问题堆积到紧张的项目后期，不如把时间多花点到需求分析和总体设计上。基础夯实了，金字塔就容易造了。
在日本公司打工的程序员们可能都知道，小日本的软件规范非常厉害，他们花在需求分析和总体设计上的时间通常在40%到50%左右，远远超过国内软件项目的实施，效果也要强的多。他们总体设计的规范甚至详尽到某个过程该如何判断，确立什么样的条件，换言之就是把什么时候该如何写(if...else)语句都帮程序员定好了。在这样的软件规范下，程序员更象是装配流水线上的工人，对一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。所以在日本和欧美经常会有程序员是低级工作一说，很多人不明就里，对国内程序员也照搬，对国内的程序员来说是很不公平的。在国内，只会照抄别人代码，一点都不懂创新，凡事依靠别人，快下班就盯着表看的程序员是不少，这种人一般很难有什么前途。但是，优秀的不断进取的程序员也很多。由于国内没有象CMM这样的软件规范或者很少，所以这类优秀的程序员不少都是干着系统分析员甚至PM的活，拿着程序员的工资。这类程序员虽然在起步时会吃很多亏，而且是主动找亏吃，然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候，前者还在各个公司里频繁跳槽，跳来跳去都不满意。有些扯开了，回到我们的话题。日本的软件规范与CMM有惊人的相似，其中至少有35%以上都是几乎一模一样的。最近经济不景气，东京倒闭了160家软件公司，这个数字是今年6月份的，还在不断增加。这些公司纷纷抢滩上海，招收技术人员。如果去这样的公司应聘就要考虑清楚了，进去可以学到他们的规范和质量控制，可是要想从程序员成为系统分析员或PM，比登天还难。往往一个程序员进去干了好几年，对自己的那一块熟的不得了，而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4（华为印度研究所已经通过CMM4），对在华为工作的程序员们来说可谓福祸难料。当然，已经作到PM或QA或者热爱CODING的朋友例外。
需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为了确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字，不合格的打回重做。反馈表随之将提交给客户，第二遍第三遍等等等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需求。当PM最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。需要说明的是，客户并非都是蛮不讲理，但是说实话，颇有无奈，国内目前的项目大多数客户为了不让自己的钱白花，经常变着法子提需求。在启动阶段明确需求并签字，无论最终情况如何，一份详尽的书面文档可以解决很多口头承诺或概念模糊的文档带来的许多问题。
详尽的需求分析有一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。有时候，这种大项目在签单时双方都没有绝对把握保证可以出成果，一旦在需求分析阶段发现难以逾越的技术难关，就会放弃项目。典型的例子就是NMD洲际导弹防御系统。上世纪八十年代初美国搞星球大战计划，拖跨了苏联。大家对那段历史有些含糊，很多人认为苏联人上了美国的当。其实并不完全如此，苏联人的情报机构无孔不入，并非那么容易上当受骗。实际上当时美国国防部已经开始着手NMD系统软件的需求分析，前后耗资数亿美圆，耗时两年，仅仅是做需求分析，终于发现存在着在当时技术上无法达到的高度，随后项目被放弃。

3.项目启动
项目启动要确定项目计划，与客户一起实施第一次项目审核，确认并对一些产品和服务向下包厂商下订单。这个时候的PM会忽然发现有开不完的会，一天开三到四个会议是很正常的事情。这些会议有与客户的会议，与下包厂商的，有团队的，有公司高层的。团队的会议主要是建立正式的团队，提供团队成员的角色和职责，提供绩效管理方法，向成员提供项目范围和目标。与客户的一个主要会议将是项目启动会议。在这个会议上PM会与客户确立正式的交流渠道，项目综合描述，让项目参与人员相互了解，建立以PM为核心的管理制度。还有一些零零碎碎的东西甚至包括办公场地的大小，电话多少部，所有人的联系方式等等都要在会议上确立，并做会议记录。这都是些非常琐碎的事情，听起来婆婆***，却是非常必要，缺一不可。大概就是所谓三军未动，粮草先行吧。
这时候，作为公司高层，应该向全公司发表申明，正式给PM发布项目经理任命书和项目授权书。这个动作虽然在别人看来有些形式主义，但是对提高PM本人的士气和责任感是有很大助力的。

影子为伴

三.计划阶段

1.定义结构分工结构图（WBS）
启动阶段结束后，项目进入计划阶段，也就正式进入实施。这里概念可能有些不太对头，其实是翻译的缘故，反正大家明白意思就行，不用拘泥于字面。WBS是一组要提交的项目元素，用来组织定义项目的总体范围，具体包括从工作内容，资源，成本角度考虑项目范围；建立一套系统所需要的分层工作结构；把项目分解成易于管理的几个细目，这概念有些模糊，其实跟资源管理器里分目录是一回事情。可以说，WBS是计划阶段的核心。WBS会详细的分到递交件，包括给自己人用的项目使用的过程文件，给客户用的模块和说明文档，完成每个细目的标准以及如何把这些细目的责任分配到具体的个人。WBS有缩进式和树状式，我这里也没办法画图，大家参考一些项目管理的书籍，里面有详细介绍。我整个文章只挑我觉得需要注意的地方，如非必要，对技术细节或者工具使用不做详细介绍。WBS的细目并不需要分解到同一水平，最下面的细目叫做工作包，分包的依据是个人的责任和可信度，也就是说到每个人头上的任务是否能落实，是否有把握完成；还有就是准备对项目进行控制的程度，程度越深，WBS树也就越深。由于WBS是实用性的东西，根据个人理解也不一样，所以一个项目可能会有几个正确的WBS，看PM的需要和最适合当前团队状态的进行选择。
WBS的定义还是很麻烦的。PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式（BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。在头脑风暴式思考时，会有很激烈的争论，PM要协调关系，调节气氛，从自己能考虑到的各个角度旁推侧敲，提示成员的思维角度和方向并加以总结。尽管很麻烦，制订WBS仍然是非常值得的。如同需求分析一样，WBS准备的越充分，编码的进度越快。

2.风险管理
既然是商业行为，那么项目的风险必然存在，相信阅读这个帖子的朋友不少人都经历过或大或小的风险。有些风险很容易解决，有些风险则大大损害利益。不论什么样的风险，能避免尽量避免，所以有必要对风险进行管理。由于风险的不可预知性，风险管理难度很大，概念也很难讲清楚，只能从一些可行的角度去分析，进行管理。
首先要识别风险。这是个难度很高的活。PM要先召开风险识别会议，这个会议面向公司，高层，跨部门的有经验的人都将参加。然后审核由项目小组生成的风险清单并与重要成员进行风险沟通，检查一些重要的风险源如WBS，成本（时间）预估，人员计划，采购管理等等。最后就要用到PM本身在以前类似项目中得到的经验教训。
识别之后要进行分析。我们可以进行粗略的量化分析（精确分析是不可能的事情）。有经验的人可以一起参加讨论，把提交出来的风险进行分类。首先按发生的可能性分，一般分成高，中，低三个级别，虽然很勉强，但是好歹也有个量化了；然后按耗去的成本分，也是高，中，低三级。我们可以把这两种类别的三个级别进行组合，碰到可能性也高，成本也高的风险就定位为不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成本，否则一旦亏起来不是亏一点点，有可能赔的很厉害。高和中，中和中的搭配都是属于高风险，中和低，低和低搭配属于低，高和低搭配属于中。
针对出现的可能性，需要采取一些手段降低风险。到目前为止也没有一个定论说有绝对好的方式，只能尽其所能的避免。有几种方法可以考虑，第一种是将风险纳入项目管理计划并指定负责人，由外部人员定期检查项目风险，一旦风险发生，执行风险管理计划；第二种是保险，这种属于风险转嫁；第三种方式有点奸，不过最保险，就是把客户拖下水，让他们一起参与风险管理，呵呵，到时候就好说话了：）
风险管理作为项目计划之后，PM需要更新WBS，修改日程计划和更新风险管理计划。
风险预留通常是成本的8%。

3.预估
预估是从量化的角度对项目进行评估，主要包括工作量，任务期限，人力，设备，材料，成本等，要注意预估不是财务策略或报价。
预估其实并不是一次性工作，在整个项目过程中，预估始终需要。预估似乎没什么特别需要提的地方，每个PM接到项目的时候自然会有预估，在项目发生变更或进入下一阶段时也会预估。预估的作用主要还是让PM作到心中有个底，安排计划时不至于毫无头绪。

4.进度计划
进度计划就是一个模块或功能要写多长时间，PM安排个日期，设立里程碑，叫程序员们不能偷懒。进度计划是从WBS提取过来的。对PM来说，合理的安排进度计划对项目控制和激励团队士气有着很大的作用。对程序员来说，进度计划毫无疑问是噩梦。
显示进度计划一般有先后顺序图，甘特图和里程碑图表。上回邵卫老师讲课，推荐的工具是m$的PROJECT，这个工具我还不会用，因为没时间去摸索。我的头倒是用的很溜了，近一个月来他就用这个PROJECT画了一个又一个的里程碑图，不停的折磨我和同事的神经。我们一般都是一边开发一边做UNIT TEST，效果上来看，因为有强大的时间压力，效率上比之前确实要提高不少，可是我们也只能结结巴巴的赶完进度。由于TEAM里人少，我们都是一个人做几个人的活。我每天早晨六点多出门，经过将近两小时颠簸，八点多点已经坐在位子上，中午吃15分钟的饭，干到晚上八点下班，到家吃完饭往往已经11点了。一个多月我从来没吃过早饭，没有睡过六个小时以上的懒觉。虽然强大的压力使我们能在短时间内掌握尽可能多的技能，开发更多的模块，但是对我们的情绪也是有很大的影响。所以说，项目里程碑是一把双刃剑，合理安排才能既促进效率也不至于打击士气。团队成员士气的逐级衰落会给项目后期的开发带来难以估计的影响，进度将会大大延缓。关于PM和团队的问题我们后面会讲到，这里我先祥林嫂一把，然后跳过。
里程碑图表的特征是任务，成员和时间，任务和成员用文字标志，时间用数字描述并辅助以图线跨度，象阶梯一样非常形象，一目了然。管理起来非常方便，完了的打个钩就可以了。
网络逻辑图是表示任务和逻辑关系的示意图，可以用先后次序表示，也可以用关键路径表示。其实把各个活动划分为1，2，3，4等阶段，每个阶段包括小活动1.1，1.2，2.1，2.2，2.3，2.4，3.1，3.2，3.3，4.1，4.2等，日程计划也分四种，一般只提到从前向后和从后向前两种。从前向后的概念就是某项活动必须相同或晚于直接指向这项活动的的所有活动的最早结束时间的最晚时间。有些绕口，我们打个比方：2阶段指向3阶段，那么2阶段里的4个子阶段也都指向3。假设2.1结束时间为1月12日，2.2结束时间为1月22日，2.3结束时间为1月15日，2.4结束时间为1月20日，那么，2阶段中最晚的结束时间是2.2的1月22日，所以在3阶段中的3个子阶段3.1，3.2，3.3的最早开始时间都不能早于1月22日。至于从后向前的例子大家自己去推吧，我就不举了，刚才几个123打的我累死了：）
项目经常需要调整进度。在不改变项目范围的情况下，调整进度有几种方法：利用快速跟踪手段来改变任务间的关系；将串行的任务改成并行；改变工作方法（可能改变WBS）；改变日期限制，使关键路径上的任务开始或结束的更早。虽然方法多样化，在我看来只有一条，就是拼命的压榨程序员的劳动力。如何压榨，还是个技巧。如前面所分析的，需求分析恨不得多分点时间给它，压需求是不太可能；测试阶段后期接近完工，罗里巴唆的事情一大堆，忙都忙不完，那时候PM一门心思提前/按时完工，好收钱，压那段时间似乎也不太可能。说来残酷，最能压的还是CODING，编码阶段往往是压缩重点，总之大家埋头苦干就是了，大项目压缩的时候程序员吃喝拉撒都在公司是很正常的事情，相信不少人都有很深的体会，这里伤心事情也就不提了。只是我总结一下，让未来的PM们有压榨后来人的依据，呵呵。测试前期也可以适当的压一压，那时候人刚完工，都比较懒散。国内一般企业规模都不大，没有专门的质量控制部门，所以质量保证和测试往往就是程序员或PM本身。其实质量保证和测试人员的人数和素质都应该要高于程序员。在日本和CMM实施的公司里，编码压缩是很容易实现的事情，因为那些程序员真的是技能熟练的装配工人，压起来方便的很。他们这样培养人的目的或许就是为了压缩吧？！

影子为伴

四.控制和执行阶段

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心中已经有底了，但是还是有必要向客户各个层次的项目代表发一张信息反馈表，收回的信息将反应客户的满意度。其实真正体现客户满意度的地方有很多。第一就是付钱付的快，如果客户不满意，一分钱藏在他牙缝里你也很难抠出来；第二就是二期，二期非常非常重要，因为这里已经是属于一种无销售成本的项目，又有一期的经验，可以说二期的钱是最好赚的。这中间的感觉，只有经历过的人才明白。

影子为伴

六.团队管理

1.建立团队
挑选人材依然是PM头疼的一个大问题，有时候一个在别的项目里很优秀的人材，挖过来未必能适应。所以，PM还是要拓展知识面，培养自己的敏锐度，因人置宜，才能挑选对自己项目有帮助的人材，才能真正对项目起作用。

2.核心程序员
任何项目都有核心程序员。核心程序员背负着很重的责任，平时要和普通程序员一样没日没夜的加班，碰到重大的技术难关更是整个人扑在电脑上，熬上几个通宵是家常便饭。常有人抱怨程序员工资高，真想请这些人来尝试一下程序员的工作，看看他们付出的精力是否配那份工资。前面说过的，中国的程序员不同于日本和欧美，他们很多人参与了系统分析和建模，对脚踏实地工作的程序员来说，这份工资实在是委屈了。看看行业里努力工作的程序员们，有几个不是头发花白，高度近视，未老先衰的？上星期五晚上我加班到10点，隔壁公司的一个技术总监特意留下来跟我说：“我们这种人，前半生拿命去换钱，后半生拿钱来买命！所以，工作的时候一定要注意劳逸结合！”道理我并非不懂，我也不想透支自己的身体，但是我有选择么？
PM要特别注意爱护核心程序员，尤其是他们的生活困难和精神状况，有时候，他们耍性子或者不合作PM要妥协，要从自己身上找原因。其实在国内，我还没碰到过敢这么做的程序员。相对PM来说，程序员是绝对的弱势群体，没有任何发言权，几乎可以说PM想怎么做，想怎么改，程序员就要付出一切代价去达到目标。

3.奖励与惩罚
奖励是不用说的了，相信所有阅读我这篇文章的PM，未来的PM，程序员和未来的程序员们都知道如何去做，这里只说惩罚。惩罚似乎很不好办，其实对PM来说再简单不过。一个程序员把模块做砸了，骂，扣工资，开除都不顶用，在项目没完成之前不是追究责任的时候。一个优秀的PM应该给他一个机会，当作没事一样让他去做别的事情，把他做砸的事情交给别人去做，就是对他最大的惩罚。这样既能激励他上进又不会让他尴尬，他会感激你一辈子，因为你给了他一次机会。而PM挑选这个人进团队并给予他责任，他没有完成，PM本身就有责任，应该自我检讨。

4.管理冲突
无论团队里的成员相互之间很熟悉还是不熟悉，冲突再所难免。在发生冲突的时候PM要牢记以公开，公正的方式处理冲突，不能因为其中之一是自己的小姨子就干掉另一方；处理事情的时候必须对事不对人。有时候，成员与PM之间也会有冲突，一般情况下都可以几乎肯定是PM的责任，因为很少有成员敢吃豹子胆来反抗自己的顶头上司。这时候PM除了要及时的做自我检讨之外，要有宽广的心胸。绝对不可以利用职权打击与自己有矛盾的成员，否则团队里所有成员都会心寒，项目的质量将会大打折扣。如果他确实不对，也要忍住，等项目完了慢慢收拾他不迟。PM的心胸还表现在不能嫉贤妒能上。当公司高层越级表扬团队某成员时，你应该高兴和光荣，而不是阴险的想着下次如何把这份光环戴到自己的头上。实际上在国内的很多PM都是这么做的，邀功的时候全是他的，有了责任都在下面。这种PM永远做不大，迟早会被淘汰。

5.承担责任
项目是有风险的，肯定会有失败的部分甚至整个项目失败。虽然说每个人都在WBS里定下了责任，在项目里程碑里都有任务。但是当整个项目危机来临的时候，PM要勇于站出来，承担起全部的责任。这是做人的方式，也能让你赢得团队所有成员的尊敬和爱戴。往往在这个时候我们才能体会到什么叫团队合作精神，就是大家齐心合力，共渡难关。

6.资源争夺
前面提到过，资源有限，如何争夺而不伤和气是对PM的另一个挑战。因为整个公司是一个大团队，内耗的厉害对PM没有好处。当然，摆平各路神仙是不可能的。但是一个健康的公司必然有健康的管理制度和优秀的成员。物以类聚，人以群分，PM应该在公司里主动结交志气相投的朋友，在拿到项目时这些朋友会给你很大的帮助，当然，在这些朋友需要你帮助的时候你也应该懂得怎么做。如果你性子很怪，很难找到脾气相近的朋友，没关系，交几个酒肉朋友也不错。我们公司数据统计，一个人在公司的人缘和他在公司请客吃饭的次数成正比。PM一定要尽心尽力的为公司打算，这样在需要高层支持的时候才会获得鼎立相助，而总是为自己打小算盘的PM是不长久的，总会被别人看穿的。




后记：写到这里实在写不动了，控制阶段的合约管理和项目跟踪没有写进去，一方面我不熟悉，另一方面让大家自己去做一些思索。其实前天我就在构思这篇文章了，本来还想把CMM也写一篇的，如今看来太高估自己的能力了，时间实在是不允许。抬头一看，东方已露鱼肚白，外面隐约传来麻雀的嬉叫声。今天我还要去跟人谈祖房子的事情，明天还要上课，星期一开始又要没日没夜的加班，多想睡个懒觉呀！
上回邓老师的课，我再次跟大家说声对不起，我的发言打扰了大家。作为非MSE成员，我的举动实在是有些过火。但是有一点我还是要申明，我不是为了我自己，我也想为大家好。
我看到了在课程讨论版面里关于我们课程太少，不如其他院校和课程安排不透明的讨论。因为上次的教训，我一直没有表态，担心会再惹麻烦。今天帖子写完，实在是忍不住想说几句了。我觉得课程安排不透明是复旦老师的责任。至于我们课程太少，不如其他院校的问题我觉得不是很有必要提。课程是死的，人是活的。再好的条件也有不成材的，再恶劣的条件也有脱颖而出的，更何况我们的条件并不比别人差很多。只要我们努力，我们不会输给清华的人。我一直不觉得在光坐在课堂里听课能学到什么真本事，MSE们如果不把学到的知识与自己的实际工作融合贯穿并领会其中的思想，那这个文凭拿到手也没用。看本科教育就知道了，大家都是过来人，如今也在工作，你们感觉当初在学校里学的知识在真正上了工作岗位之后有多少能派上用场？好象很多东西都要重新来过。这就是MSE相对普通研究生的优势所在，因为你们一边工作一边学习，理论与实践相结合，对知识的掌握会很快，而不是变成考试和拿文凭的工具。我今天看到亚联招聘的信息，上面根本不提高学历，而是换成了有本事。什么叫有本事我无法定义，但绝对不是一纸文凭能代替的了的。文凭只是个辅助和敲门砖，可以保证你进一个好公司三个月，三个月后你的命运如何还是取决于你能做多少事情。我就是高中毕业，大学退学了两次，无论计算机还是英语连个象样的证书都没有。但是无论你是清华，北大，复旦还是交大的MSE，两年后你毕业的时候你有把握在岗位竞争或商务谈判中击败我吗？
我们需要的是自觉，踏实，进取和拼搏。只有拥有不断努力的恒心，我们才能最终提高自己的社会地位和人生价值，说的难听点最起码不要让自己被淘汰。网络上所有的资料都公开，都有的当，我们的老师又很有能力。其实根本用不着攀比老师的能力，学历和目前的社会地位，只要他有可以传授给我让我学习的经验，我管他是博士还是文盲，管他是IT总裁还是扫大街的！呵呵，这话说出来又要得罪人了！唉，话多就话多吧，总要有人说的！
这篇文章有我一个晚上的心血，也让我复习了一下PM的知识。我把他献给复旦02年所有的MSE们，也献给我爱人。这些年风风雨雨，她跟着我，吃了很多苦，但是她从来不说什么。我要谢谢她！
希望能和大家共同度过愉快的两年！