————————————————————————————————

一.商务谈判

1.作人的姿态

作人似乎跟商务谈判不太有关系，很多技术人员相信PM需要的是本事，是如何做好一个项目，而不是会搞好关系弄的四平八稳的人。随着PM在中国的悄悄兴起，越来越多的PM开始在老总的授意下参与商务谈判，和销售们一起打单子，这就比较实在的需要PM们去揣摩客户的心理。

揣摩客户心理需要有多方面的知识，需要深度和广度，然而，最重要的仍然是作人。如何放下架子，降低作人的姿态，对从技术人员转型的PM们来说，是至关重要的。

降低作人的姿态需要从多个方面去实施，最主要应该记住：人不可貌相，更不可以地位衡量。很多公司为了保持公司形象，会统一叫员工打扮的好看一点，看起来象个白领的样子。然而，老板多半是没有约束的。中国改革开放才二十年，很多有钱的老板实业家文化层次都不高，往往是当大学生们只会把屁股坐在板凳上肆意挥霍父母辛苦积攒的财富时，他们已经在各地奔波，积累丰富的商业经验并对金钱，人生和社会的本质有了充分的认识，形成了自己稳定的思维框架。这些人，很多都是穿着旧旧的衣服，戴着破破的手表，说话的时候经常会带上三字经，钻进上海的人堆里，搞不好你会把他当成民工。因为到他们所处的社会地位，已经不需要任何华丽的外表来衬托自己的身份，他们有的是底气。对PM来说，这是个非常危险的挑战。虽然说项目在初期有意向时会对对方的人事和关键人物有一定的了解，然而大项目里能说的上话的人太多了。上海人最瞧不起的就是土气，很多人谈项目的时候看到民工或很俗气的表现不免会皱皱眉头，往往在皱眉头的时候就失去了项目，也就是失去了市场和金钱。PM必须作到能与每一个层次的人交谈，尤其是看起来比自己层次要低的群体，哪怕是公司里扫地的阿姨。只有作到谦虚谨慎，不摆架子，尊重别人，才会得到别人的尊重，才有机会赢得项目。鼻子比眼睛高的人只会把自己的鼻子撞扁。

2.丰富的知识面

光尊重别人还不足以赢得项目，准确的说是赢得对方关键人物的信赖。PM一般用不着陪客户喝酒吃饭，那是销售们的事情，但是PM和客户讨论问题可能是最多的。讨论问题的时候就是机会，如何投其所好，是一大关键。金钱与美女依然是常规的敲门砖，然而这种傻瓜也知道的办法人人都会去做。老板的关系也只是一个方面，如今的大老板，哪个没有关系？同等条件下PM凭什么去胜过别人一筹？

我一个朋友（PM）打一个单子时，发现对方对什么都不太感兴趣，费了很大力气也找不到突破口。对方这个人非常顺利，金钱地位美女样样不缺。他花了好多天和对方交谈，以自己的博学逐渐取得了对方的信任。后来他隐约发现对方对数学和天文学的发展史有所涉猎，如获至宝，回家花一个通宵的时间在网络上搜索相关资料。第二天他根本不谈项目的事情，只跟对方大谈特谈哥白尼，布鲁诺，伽利略这些人的生平，整整吹了一天。对方点头如捣蒜泥，态度和热情都来个一百八十度转弯，隔天他就拿到了单子。这是个经典的战例，谁能事先想到哥白尼会来帮助IT的人赚钱？这个PM靠的就是博学和由博学引申出的敏锐的感觉抓住了机会，让客户产生共鸣。客户感觉他层次也很高，而且和自己有共通之处，信任度大大增强，把项目交给他放心。如今这种例子在商务谈判中已经屡见不鲜了６訮M来说，并不要求在各个方面都很精通，那是不可能的事情，只要PM对一些流行的话题和天文地理历史各方面的知识有个大概的了解，在需要的时候能尽快的掌握，才有机会创造机遇和把握机遇。

3.强大的沟通能力

胸中有万千墨水却不知如何表达其实是比较少见的，但并非绝对没有。每个人的人生轨迹都有所不同，思维受环境的影响也各有差异。包括象我们目前这个班级里的一些未来的MSE们，一定有比较内向或者不太爱表达自己观点的人，这些人比较被动，往往很难承担起谈判的重任。从今天开始，这类人就必须重新学习如何说话，如何大声的争论。沟通，并不仅仅是大声说话，而是在表达自己观点的同时发现问题并综合整理加以解决。除此之外，沟通的能力与社会经验息息相关，与PM的见识联系紧密。在日常生活中，PM就要多留心，多思考，当别人想到某个层次的时候要争取比别人考虑的更深。当然，也有一些不够踏实的朋友把沟通和吹牛当成了完全的一回事情，在和客户交流的时候口若悬河的说一些不着边际的话。这种人，碰到不懂，不太认真或者好奇心强的客户是有一定市场的；而有水平，负责任的客户往往会觉得这种人不可靠，一般不会把单子交给他。PM需要把握好这个度，吹是肯定要吹的，只是吹牛的时候一定要有基础的去吹，对从来没涉及过的领域或者根本不懂的东西轻易不要发表意见，挑选自己熟悉的方向合理的进行发挥，适当的留上一两手，给对方高深莫测的感觉，效果最好。

4.优秀的售前团队

这个团队一般是由总经理发起并组建的，通常不指定PMP，对团队的成员如SALES，PM，SA，ENGINEER们的团队合作提出了比较高的要求。一般公司在接下一个单子进行到一定程度的时候，PM往往会尴尬的发现协议上销售代表们对客户的一些承诺是几乎做不到或者根本做不到的事情。这种情况非常多，销售的任务是拿下单子，我听到的销售们说的最多的就是“没问题”或者“NO PROBLEM”，但是当我听到客户的要求和销售的回答时我总是心惊肉跳，很不自然。销售是非常辛苦的，为了建立客户关系，尤其是空白的市场是很不容易的，往往为了一个单子会牺牲非常多。在这种情况下，和销售进行协调自然而然的又落到了PM的头上。在销售和客户做承诺之前，PM要主动的跟销售交流，提供粗略的总体设计框架和技术难关以及能考虑出的工作量，而不是等出了问题再被动和销售在老板面前互相推委责任。在组建团队的时候，PM要根据团队里每个人的素质和任务进行因人置宜的信息传递。优秀的售前团队合作是接单的重要保障。

在商务谈判的实际操作中，存在着各式各样的问题，PM的职责和要求绝非以上几点所能描述详尽。根据环境，政策，人文，关系等各方面的不同情况，PM的不同成长经历，每个PM最终都会建立自己对商务谈判的看法和经验。但是有一点可以肯定，这是PM成为PM的第一道关，也是最重要的一关。接不到单子，PM将失去存在的意义。与销售有所不同，PM在该阶段的任务除了接单，还要尽可能的搜集客户关键人物的资料并与对方各个阶层的负责人建立良好的客户关系，以便在项目实施时充分调动资源。

二.启动阶段

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们，也献给我爱人。这些年风风雨雨，她跟着我，吃了很多苦，但是她从来不说什么。我要谢谢她！

希望能和大家共同度过愉快的两年！

链接地址：

新浪下载

链接地址：

depositfiles

购买原版

备注：本资源来自于互联网搜索，非本人制作或者上传，有兴趣的朋友可以下载学习，切勿用于商业目的，如侵犯了您的权益，请来信告知本人将此链接删除。

链接地址：

Rapidshare

购买原版

备注：本资源来自于互联网搜索，非本人制作或者上传，有兴趣的朋友可以下载学习，切勿用于商业目的，如侵犯了您的权益，请来信告知本人将此链接删除。

关键路径法(Critical Path Method, CPM)是一种基于数学计算的项目计划管理方法，是网络图计划方法的一种，属于肯定型的网络图。关键路径法将项目分解成为多个独立的活动并确定每个活动的工期，然后用逻辑关系（结束-开始、结束-结束、开始-开始和开始结束）将活动连接，

从而能够计算项目的工期、各个活动时间特点（最早最晚时间、时差）等。在关键路径法的活动上加载资源后，还能够对项目的资源需求和分配进行分析。关键路径法是现代项目管理中最重要的一种分析工具。

关键路径法的分类

根据绘制方法的不同，关键路径法可以分为两种，即箭线图（ADM）和前导图（PDM）。

箭线图（ADM）法又称为双代号网络图法，它是以横线表示活动而以带编号的节点连接活动，活动间可以有一种逻辑关系，结束-开始型逻辑关系。

在箭线图中，有一些实际的逻辑关系无法表示，所以在箭线图中需要引入虚工作的概念。

绘制箭线图时主要有以下一些规则：

1．  在箭线图（ADM）中不能出现回路。如上文所述，回路是逻辑上的错误，不符合实际的情况，而且会导致计算的死循环，所以这条规则是必须的要求。

2．  箭线图（ADM）一般要求从左向右绘制。这虽然不是必须的要求，但是符合人们阅读习惯，可以增加箭线图（ADM）的可读性。

3．  每一个节点都要编号，号码不一定要连续，但是不能重复，且按照前后顺序不断增大。这条规则有多方面的考虑，在手工绘图时，它能够增加图形的可读性和清晰性，另外，在使用计算机运行箭线图（ADM）这一条就非常重要，因为在计算机中一般通过计算节点的时间来确定各个活动的时间，所以节点编号不重复是必须的。

4．  一般编号不能连续，并且要预留一定的间隔。主要是为了在完成的箭线图（ADM）中可能需要增加活动，如果编号连续，新增加活动就不能满足编号由小到大的要求。

5．  表示活动的线条不一定要带箭头，但是为了表示的方便，一般推荐使用箭头。这一条主要是绘制箭线图（ADM）时可以增加箭线图（ADM）的可读性。

6．  一般要求双代号网络图要开始于一个节点，并且结束于一个节点。此要求可以在手工绘图增加可读性，而在计算机计算时，可以增加效率和结果的清晰性。

7．  在绘制网络图时，一般要求连线不能相交，在相交无法避免时，可以采用过桥法或者指向法等方法避免混淆。此要求主要是为了增加图形的可读性。

箭线图（ADM）要表示的是一个项目的计划，所以其清晰的逻辑关系和良好的可读性是非常重要的，除了箭线图（ADM）本身具有正确的逻辑性，良好的绘图习惯也是必要的。因此在绘图时遵守上面的这些规则就是非常重要的，另外，在绘图时，一般尽量使用直线和折线，在不可避免的情况下可以使用斜线，但是要注意逻辑方向的清晰性。

前导图（PDM）法又称为单代号网络图法，它是以节点表示活动而以节点间的连线表示活动间的逻辑关系，活动间可以有四种逻辑关系，结束-开始、结束-结束、开始-开始和开始-结束。

关键路径法的起源

关键路径法（CPM）最早出现于1956年，当时杜邦当时美国杜邦（Du Pont）公司拥有一台UNIVAC 1 计算机，他们使用这台计算机进行他们公司几乎所有的数据处理工作，但是仍然还有大量的剩余时间，杜邦（Du Pont）公司的管理层开始研究计算机在其它方面使用的可能性，因为当时电脑的费用是非常高昂的，他们考虑工程计划可能是应用电脑的一个方向。

他们联系了雷明顿兰德（Remington Rand）公司的Macuchy 博士，帮他们解决计算机使用的问题，后者派出了年轻的数学家James E. Kelly去协助杜邦（Du Pont）公司解决问题，杜邦公司方面的负责人是Morgan Walker。

他们要解决的问题是在工程项目中工期和费用之间的关系，他们研究的是如何能够采取正确的措施，在减少工期的情况下能尽可能少的增加费用。1957年5月7日，在特拉华州内瓦克召开的一个会议正式确定开始新计划技术的开发。Kelly借用了线性规划的概念来解决项目计划自动计算的问题，简单的说就是确定了每个活动的工期和活动间的逻辑关系，输入电脑后就能自动计算项目的工期，为了电脑的计算，Kelly在活动间使用了i，j这样的节点来表示活动间的前后逻辑关系。

当时遇到的一个问题是，杜邦公司的管理层并不理解Kelly所使用的方法，为了让其他人能够理解所使用方法的原理，Kelly就绘制了图形来解释电脑所作的工作，图形以箭线表示活动，以节点表示活动间的逻辑关系，这就是最早的箭线图（ADM）。

前面提到过，Kelly和Walker最初研究的目的是为了解决项目中工期和费用之间关系的问题，所以在Kelly和Walker最初提出的方法中，也包括费用的计划方法，其做法是，在每个活动上加载其相应的费用，从而得到整个项目的费用，就能分析与进度相关的费用问题，这种做法与现在所用的方法没有太大差别。不过，在当时的情况下，项目收集费用并分解到各个活动上存在较大困难。所以，在之后的很长时期内，关键路径法主要还是用于进度的计划和控制方面。Kelly和Walker还提出了资源加载和分配的方法，当然也存在和费用分析一样的问题。

尽管存在这些问题，在1957年7月24日，他们已经做了一个简化的例子，称为”George Fischer Works”，这个计划包括了61条活动，其中有8个时间限制和16条虚工作。在刚开发出这种方法时，他们将这种方法称为Kelly-Walker法，而计划中的关键线路，他们称之为主链路（Main chain）。

根据Kelly和Walker的论文和其它相关书籍的记载，当时他们一共进行了三个试验对Kelly-Walker法进行检验。第一个试验是在1957年12月份，杜邦公司成立了一个测试小组对这种新的计划方法测试，有一个传统的计划组与他们同时独立对一个价值1000万美元的化学设备项目进行计划。这个测试小组的成员没有参与Kelly-Walker法的开发，但是在开始测试之前，他们接受40个小时的培训。此项目的计划从初步设计的完成开始，在编制计划时，他们首先将整个项目分解成一些较小的工作包，然后再将这些工作包最终分解成为活

动，项目共有800条活动，其中包括400条施工活动，150条采购和设计活动。根据记载，在此项目中显示出的Kelly-Walker法的最大优势在于，此项目在实施中出现了较大的变更，相对于传统计划方法，使用Kelly-Walker法更容易更新计划，其工作量仅有最初建立计划的10%，另外，在设计信息只有30%的情况下，能够比较准确的预测劳动力，还有就是能够比较准确的识别关键的采购工作。

1958年，他们进行了第二次试验，此试验所针对的是一个价值2000万美元的化学设备项目，根据Kelly和Walker在1959年发表的论文，此次试验显示的最主要的优点是能够比较容易的包含设计部分的计划。

不过现在人们最常提及的一个试验是他们随后进行的维护设备的试验，在此项目中，他们使用Kelly-Walker法进行分析和计划，使得设备维护时间减少了25%。

1959年，Kelly和Walker共同发表了”Critical Path Planning and Scheduling” 论文，在这篇长达25页的论文中，Kelly和Walker不仅阐述了关键路径法的基本原理，还提出了资源分配与平衡，费用计划的方法。我们今天所使用的方法的原理，与Kelly和Walker在论文中提出的方法，并没有原则上的不同。

不过随后关键路径法的发展并不是很顺利，杜邦公司开发此项技术的领导层更换之后，不再使用这项技术，而雷明顿兰德公司也认为这项技术没有太大前途。

对于关键路径法的发展起到重要作用的是Mauchly博士和Kelly随后成立的Mauchly合伙公司。在60年代初期，在Kelly的带领下，此公司进行了大量的关键路径法的培训和推广工作。

与此同时，另外一个对关键路径法（CPM）的发展起到重要作用的是美国海军北极星计划开发的计划评审技术（PERT）。在1955年11月17日，美国海军北极星计划成立了一个特别项目管理办公室（SPO），管理其Fleet Ballistic Missile计划，负责人是Admiral Raborn。在1956年和1957年期间，他们研究了各种已经存在的项目管理技术，在大约1957年秋季的时候，他们接触到了杜邦公司开发的计划管理技术，这对他们开发PERT起到了重要的作用。1958年1月份，SPO研究了在计算机上实现计划和控制的可行性，1958年1月27日，SPO正式成立了一个小组开发PERT技术，在大约一年以后，PERT技术成为一种可操作性的技术，计划评审技术（PERT）和关键路径法（CPM）基本上一样，唯一的区别是计划评审技术的每个活动的工期不是确定的，而是包括了悲观值，乐观值和最有可能值三个值。比较有趣的是，1959年，北极星计划的这个特别项目管理办公室（SPO）开了一个招待会，介绍他们的这种新技术，并希望参会者能给出更多的意见，Kelly和Walker在被邀请之列，在会上，他们发现SPO开发的PERT和他们的Kelly-Walker法原理上完全一样，而SPO所说的关键线路（Critical Path），就是他们的Kelly-Walker法中的主链路（Main Chain）。回去之后，他们决定将它们的方法的名称改为关键路径法（Critical Path Method）。

在60年代初期，PERT的发展比较迅速，据统计，到1964年，关于PERT的参考书目和论文达到了1000多种。到1961年，各种基于PERT的类似的方法出现，如PERT/Cost, PERT-RAMPS（Resource Allocation & Multi-Project Schedule），MAPS，SCANS，TOPS，PEP，TRACE，LESS和PAR等。其中PEP法是将甘特图的活动赋以逻辑关系，这是现在的计划软件一般采用的一种图形输出方法。在1962年的时候，时任美国国防部长MacNamara在起草一项法令时，指出计划评审法和关键路径法同时并存的局面容易引起混淆，以后国防部的所有部门一律使用计划评审法（PERT），这在当时对于关键路径法的提倡者是一个重大打击，不过在随后的发展中，关键路径法（CPM）逐渐占了优势，现在真正使用计划评审法的其实已经很少。而且即使是在当时，很多所谓的计划评审法（PERT），其实质其实是关键路径法（CPM）。如美国航空局（NASA）当时使用的NASA-PERT，实际就是关键路径法（CPM）。

无论是关键路径法（CPM）还是计划评审法（PERT），最初使用的表示方法都是箭线法（ADM），在之后很长的一段时间箭线法（ADM）都是人们主要使用的方法，直到70年代以后，前导图（PDM）才开始逐渐流行起来，但是箭线法（ADM）仍然使用极为广泛。在90年代以后，美国Primavera公司开发出其Windows版本的计划管理软件时，只采用前导图（PDM）作为其计算平台，从根本上改变了这一局面，从此以后，前导图（PDM）成了人们主要使用的方法，而箭线图（ADM）则很少使用。

在早期对于前导图（PDM）的发展起到重要作用的是美国斯坦福大学的John W. Fondahl,他是60年代初期的非计算机关键路径法的权威，1961年他发表了一篇题为”A Non-computer Approach to Critical Path Methods for the Construction Industry”，在这篇论文中，他阐述了前导图系统，并把它作为一种效率比较高的手工绘制关键路径法的方法，因为当时使用计算机运行CPM是非常昂贵的。Fondahl从1958年开始作为斯坦福大学的成员，受美国海军委托为其研究提高生产效率的方法。其中最主要的成果就是这份论文，这份论文当时一共出售了20000份。

在这份论文中，根据习惯使用的流程图方法，Fondahl提出了以节点表示活动以连接线表示活动间的逻辑关系。论文论述了流程图的简易性和使用手算在较少的人力投入下采用关键路径法的可能性，同时论文也论述了费用工期互为反比的问题。斯坦福大学之后继续研究了前导图（PDM）的手工进度更新的问题，并在1964年发表了相关的技术报告。

虽然Fondahl博士极力强调他提出的方法是为了手工计算关键路径法，但是H.B Zachry公司在1962年开始研究将前导图法用于计算机上，1963年3月他们与IBM公司联合进行该项研究，之后形成了IBM的计划软件，名为”Project Control System（PCS）”。该系统还是第一个在计划中引入时间间隔（LAG）的软件。虽然前导图法最初被应用于大型机，但是随后被广泛应用于小型机和个人电脑上的软件，这一趋势使得前导图（PDM）逐渐成为主要使用的方法，到现在，在国外前导图（PDM）基本已经成为唯一在使用的方法，而箭线图（ADM）只有在教学和培训中还有时用到。而发展势头曾一度压过关键路径法（CPM）的计划评审技术（PERT），现在使用的已经很少了。

在美国发展出关键路径法（CPM）和计划评审技术（PERT）的同时，其它一些国家如欧洲和英国等，也曾经开发出一些类似的项目管理技术，但是现在关于这些技术的记载已经很少。

关键路径法（CPM）最初被开发是用于项目管理，不过，在发展过程中，它逐渐在工程项目的合同索赔和纠纷解决上起到重要作用。最早在诉讼中涉及到要求使用关键路径法（CPM）是1972（Appeal of Minmar Builders, Inc, GSBCA No. 3430, 72-2 BOA）年，在此案例中，法庭由于承包商没有使用关键路径法（CPM）而拒绝了承包商的索赔，因为其使用的横道图不能显示具体的活动是否在关键线路上，从而无法判断活动耽误对于整体的影响。之后，关键路径法（CPM）逐渐成为工期延误索赔中必须的做法，并逐渐形成了很多专门的分析方法，现在甚至有很多人专业从事工期延误分析的工作。

关键路径法的一些主要时间参数

在关键路径法中，一般有以下一些时间参数：

最早开始时间（Early Start）活动最早开始时间由所有前置活动中最后一个最早结束时间确定。

最早结束时间（Early Finish）活动的最早结束时间由活动的最早开始时间加上其工期确定。

最迟结束时间（Late Finish）一个活动在不耽误整个项目的结束时间的情况下能够最迟开始的时间。它等于所有紧后工作中最早的一个最晚开始时间。

最迟开始时间（Late Start）一个活动在不耽误整个项目的结束时间的情况下能够最早开始的时间。它等于活动的最迟结束时间减去活动的工期。

总时差(Total Float) 指一项活动在不影响整体计划工期的情况下最大的浮动时间。

自由时差（Free Float）指活动在不影响其紧后工作的最早开始时间的情况下可以浮动的时间。

如果是对于箭线图法，用到的时间参数还常有：

最早节点时间（Early Event Occurrence Time）最早节点时间由其前置活动中最晚的最早结束时间确定。

最迟节点时间（Late Event Occurrence Time）最迟节点时间由其后置活动中最早的最迟开始时间确定。

关键路径法的时间计算

在进行计算时，箭线图和前导图的计算过程有所不同。

箭线图（ADM）的计算一般有正推法（Forward Pass）和逆推法（Backward Pass）两种，正推法用于计算活动和节点的最早时间，其算法如下：

1.       设置箭线图（ADM）中的第一个节点的时间，如设置为1。

2.       选择一个开始于第一个节点的活动开始进行计算。

3.       令活动最早开始时间等于其开始节点的最早时间。

4.       在选择的活动的最早开始时间上加上其工期，就是其最早结束时间。

5.       比较此活动的最早结束时间和此活动结束节点的最早时间。如果结束节点还没有设置时间，则此活动的最早结束时间就是该结束节点的最早时间；如果活动的结束时间比结束节点的最早时间大，则取此活动的最早结束时间作为节点的最早时间；如果此活动的最早结束时间小于其结束节点的最早时间，则保留此节点时间作为其最早时间。

6.       检查是否还有其它活动开始于此节点，如果有，则回到步骤3进行计算；如果没有，则进入下一个节点的计算，并回到步骤3开始，直到最后一个节点。

活动和节点的最迟时间采用逆推法（Backward Pass）计算，逆推法（Backward Pass）一般从项目的最后一个活动开始计算，直到计算到第一个节点的时间为止，在逆推法的计算中，首先令最后一个节点的最迟时间等于其最早时间，然后开始计算，具体的计算步骤如下所示：

1.       设置最后一个节点的最迟时间，令其等于正推法计算出的最早时间。

2.       选择一个以此节点为结束节点的活动进行计算。

3.       令此活动的最迟结束时间等于此节点的最迟时间。

4.       从此活动的最迟结束时间中减去其工期，得到其最迟开始时间。

5.       比较此活动的最迟开始时间和其开始节点的最迟时间，如果开始节点还没有设置最迟时间，则将活动的最迟开始时间设置为此节点的最迟时间，如果活动的最迟开始时间早于节点的最迟时间，则将此活动的最迟开始时间设置为节点的最迟时间，如果活动的最迟开始时间迟于节点的最迟时间，则保留原节点的时间作为最迟时间

6.       检查是否还有其它活动以此节点为结束节点，如果有则进入第二步计算，如果没有则进入下一个节点，然后进入第二步计算，直至最后一个节点。

7.       第一个节点的最迟时间是本项目必须要开始的时间，假设取最后一个节点的最迟时间和最早时间相等，则其值应该等于1。

上面介绍了活动的最早和最迟时间的计算方法，以上的过程可以用比较简单的公式来表达。

上面所讲述的方法，我们一般称为节点计算法，节点和活动的最早时间按照正推法进行计算，起点节点未规定时间时，我们取其时间为1，即

ET_i=1（i=1）

对于任意一个节点，如果其之前只有一条活动时，则其最早时间按照下式计算，

ET_j= ET_i+D_i-j

如果该节点之前有多条活动时，则其最早时间按照下式计算，

ET_j= max{ET_i+D_i-j}

其中D_i-j为活动i-j的工期

对于活动的最早时间，最早开始时间为：

ES_i-j=ET_i

最早结束时间为

EF_i-j= ES_i-j+ D_i-j

计划的总工期

T=ET_n-1

节点和活动的最迟时间以逆推法计算，计算时，首先令最后一个节点的最迟时间等于其最早时间，即

LT_n=ET_n

对于其之后只有一条活动的节点，最迟时间如下式所示

LT_i=LT_j-D_i-j

对于其之后有多条活动的节点，最迟时间如下式所示

LT_j=min{ LT_j-D_i-j}

工作i-j的最迟完成时间以下式计算，

LF_i-j=LT_j

最迟开始时间为

LS_i-j=LF_j- D_i-j

以上的算法是节点计算法，另外，也可以采用一种叫做工作计算法的方法进行活动时间的计算，具体如下。

对于最早时间，采用正推法计算。在没有指定节点的开始时间时，则起点开始活动的最早开始时间定为1，即

ES_i-j=1

当工作i-j只有一条紧前工作h-i时，其最早开始时间按如下公式计算

ES_i-j=ES_h-i + D_h-i

当工作i-j有多条紧前工作时，其最早开始时间按照以下公式计算

ES_i-j=max {ES_h-j + D_h-i}

工作i-j的最早完成时间按照下式计算

EF_i-j=ES_i-j+ D_i-j

网络计划的计算工期按照下式确定

T=max {EF_i-n}-1

活动的最迟结束时间和最迟开始时间需要采用逆推法计算。

以终点节点为箭头节点的活动的最迟完成时间按照网络计划的工期确定，即

LF_i-j=T+1

其它活动的最迟开始时间按照下式计算

LF_i-j=min {LF_j-k – D_j-k}

活动的最迟开始时间以下式确定

LS_i-j=LF_i-j – D_i-j

对于总时差和自由时差可以采用如下的公式计算。

总时差可以按照下式计算：

TF_i-j= LS_i-j – ES_i-j

或者

TF_i-j= LF_i-j – EF_i-j

当工作i-j有紧后工作j-k时，自由时差可以按照下式计算：

FF_i-j=ES_i-k – ES_i-j – D_i-j

或者

FF_i-j=ES_j-k-EF_i-j

由于引入了多种逻辑关系，前导图（PDM）的时间计算和箭线图（ADM）有一些差别。除了前导图（PDM）中不存在节点最早时间和最迟时间，在箭线图（ADM）中提及的其它时间参数也都适合前导图（PDM）。

对于活动的最早开始和最早结束时间，采用正推法计算，其算法如下所示：

1.       将第一个活动的最早开始时间设置为1.

2.       在活动的最早开始时间上加上其工期，得到活动的最早结束时间。

3.       根据该活动与后置活动的逻辑关系，计算后置活动应该的最早开始时间，并与其已有的最早开始时间对比，如果其后置活动还没有设置最早开始时间，则将此时间设为其最早开始时间，如果此时间早于其后置活动已有的最早开始时间，则保留后置活动的原有最早开始时间，如果此时间迟于其后置活动已有的最早开始时间，则将此时间设置为后置活动的最迟开始时间。

4.       重复步骤2和3，直到所有活动的时间被计算完为止。

对于以上所示的最早时间的计算过程，可以以公式的形式表示如下：

当活动间的逻辑关系为SS，则计算如下

ES_j=max{ ES_i + STS}

当活动间的逻辑关系为FS，则计算如下

ES_j= max{ES_i+ D_i+ FTS}

当活动间的逻辑关系为FF，计算如下

ES_j= max{ES_i+ D_i - D_j +FTF}

当活动间的逻辑关系为SF，计算如下

ES_j=max{ ES_i - D_j +STF}

在计算出各个活动的最早开始和结束时间之后，就可以计算活动的自由时差，在计算前导图（PDM）的自由时差时应注意，由于引入了多种逻辑关系，并且活动间可以存在延时，所以其计算方法与箭线图（ADM）的计算方法不一样。

对于前导图（PDM）的活动间，除了延时还可以存在时间间隔（LAG），一般可以按照下面的方式计算。

当活动间的逻辑关系为SS，则计算如下

LAG_i-j= ES_j- ES_i- STS

当活动间的逻辑关系为FS，则计算如下

LAG_i-j= ES_j- EF_i- FTS

当活动间的逻辑关系为FF，计算如下

LAG_i-j= EF_j- EF_i- FTF

当活动间的逻辑关系为SF，计算如下

LAG_i-j= EF_j- ES_i- STF

则对于任意一个活动，其自由时差为

FF_i=min{ LAG_i-j}

最后一个活动的自由时差为0.

对于总时差，终点节点的总时差为0，对于其它任意一个节点，总时差按照下式进行计算

TF_i=min{TF_j+ LAG_i-j}

对于任意一个活动的最晚开始时间可以由其最早开始时间加上总时差得到，同样，其最晚开始时间可以由最早结束时间加上其总时差得到，公式表示如下

LS_i=ES_i+TF_i

LF_i=EF_i+TF_i

根据Kelly和Walker的论文和其它相关文章和书籍的记载，

在关键路径法出现时，一共做过三次试验，第一个实验是在1957年12月份。杜邦公司成立了一个测试小组对这种新的计划方法测试，有一个传统的计划组与他们同时独立对一个价值1000万美元的化学设备项目进行计划。这个测试小组的成员没有参与Kelly-Walker法的开发，但是在开始测试之前，他们接受40个小时的培训。此项目的计划从初步设计的完成开始，在编制计划时，他们首先将整个项目分解成一些较小的工作包，然后再将这些工作包最终分解成为活动，项目共有800条活动，其中包括400条施工活动，150条采购和设计活动。根据记载，在此项目中显示出的Kelly-Walker法的最大优势在于，此项目在实施中出现了较大的变更，相对于传统计划方法，使用Kelly-Walker法更容易更新计划，其工作量仅有最初建立计划的10%，另外，在设计信息只有30%的情况下，能够比较准确的预测劳动力，还有就是能够比较准确的识别关键的采购工作。

1958年，他们进行了第二次试验，此试验所针对的是一个价值2000万美元的化学设备项目，根据Kelly和Walker在1959年发表的论文，此次试验显示的最主要的优点是能够比较容易的包含设计部分的计划。

但是现在人们最常提及的一个试验是他们随后进行的维护设备的试验，在此项目中，他们使用Kelly-Walker法进行分析和计划，使得设备维护时间减少了25%。

从笔者的角度来看这三个试验，虽然Kelly和Walker在论文和其它一些书籍都提到这三个试验的成功，但是实际上，在当时的情况下，前面两个试验，并不能显示Kelly-Walker法的优势，如在第一个试验中所提到的其更新比较容易，但是这是基于建立了强大的计算机程序的前提下，对于当时来说，这可是一笔昂贵的费用，相比之下，在当时情况下以这样大的投资来编制计划是否划算是值得商榷的，但是第三个试验，针对的是一个小型的项目，通过分析能够减少项目时间，则确实显示了这种具有严谨逻辑的方法的优点，而不是使用计算机带来的好处。虽然，在今天的情况下，关键路径法对于计划编制的重要性已经是不言而喻，但是在当时情况下，使用昂贵的大型机编制计划，并不见得对很多项目有实用性，除非是对于如美国海军北极星计划那样的大型项目。很多文章和书籍出于其开发者或者是早期的推动者，则难免夸大在当时的意义。但是上文提到的第三个试验，则显示了利用关键路径法这种原理，即使在简单的手算的情况下，对于项目的计划和分析也能带来很好的效果。我国著名的数学家华罗庚先生在60年代中期引入关键路径法，当时称之为统筹法，也主要是通过手算分析，来优化计划的过程。

作者：牛永宏

四、 关于计划的综合论述

上述的六个步骤就是计划编制的主要过程，在Fidic合同下的项目，对于计划提交要求的比较严格，Fidic《施工合同条件》与计划相关的条款主要有8.3 进度计划，14.4 付款计划表，

4.21 进度报告，4.4 分包商，计划的内容包括施工进度计划，物资采购计划，设备计划，分包采购计划，付款计划或称现金流量表，月进度报告，同时，很多项目会修改合同或者在项目规范中对计划做出进一步的要求，如棕榈岛的项目要求采用CPM法并使用P3软件进行编制。

计划一旦被批准，就会作为合同的一部分，合同各方都应该遵守，工程中的各种活动，都要与计划结合，比如索赔，付款等。最明显的例子，就是指定分包商和甲供材料，在计划中都需要给出具体时间，一旦业主不能按照这个时间执行，就可以提出索赔，同样，如果承包商不能按照计划执行，业主也可追究对于业主和或者场地中的其他承包商的影响。在这种模式下，编制和使用计划就不是只看竣工时间或者几个里程碑就可以，每一个细节，每一道工序的时间都需要注意。

除了在合同方面，计划对于现场的指导的作用也是非常重要。比如劳动力，我们在海外的项目，主要的劳务都是国内提供，一个工人的派出时间是比较长的，所以随时调整是非常难的，这就要求必须计划准确。实际上，我们在海外的项目，劳动力一直是一个主要的问题，这与我们计划不准确是很有关系的。

一个项目计划，无论是出于合同的目的还是指导施工，最主要就是它的准确性。影响计划编制准确性的，主要是工序定义，工序持续时间定义和资源的加载这三个步骤。编制一个准确的与实际情况相符的计划，首先就是参考历史信息，建立数据库，对于工序定义，需要的信息是工序的模板，对于定义工序持续时间，是工期定额，对于资源加载，是资源定额，如人工定额。对于一个施工企业或者说对于单件产品的生产系统，这三种数据库是非常重要的。这里需要注意的是，这里所提到的工序，不止是施工工序，还包括采购活动，设计活动等，比如，一个分包采购活动，从招标到合同签订，需要多长时间，一栋楼的某部分的设计需要多长时间，多少设计人员，在这些方面，我们的经验更加缺乏。另外，我们决不能只依靠某个人，某些人定性式的经验，而必须建立系统的数据库。

编制一个计划，另外一个重要的方面，就是需要项目各个部门的配合，如现金流需要合约，工序的划分需要技术和工程部门，采购活动需要物资部门，仅靠一个计划员，是难以完成任务的。一方面这需要计划部门能够整合整个项目的资源，另一方面，也需要各个部门都有这样的意识。

编制计划第三个需要注意的就是它的可读性，计划是为了指导施工，这需要项目的每个人能读懂，可能还要汇报给公司领导，外部人士，所以它的可读性是非常重要的，这就像软件编制中提倡面向对象的方法一样，一个计划，不止是编制人员能看懂，还要其他人也年能轻松看懂，才是一个成功的计划。这一点，对于一个3、4百条工序的计划，这一点并不明显，但是对于棕榈岛这样有6000条工序，并且包括资源，采购、设计等内容的计划，就非常重要了，而多哈高层办公楼项目，有9000道工序。要做到可读性，首先，必须要有说明书，对工序的划分，资源定义，编码方式等作出详细说明，其次是要有清晰的结构，而WBS是必须的，工序的编码尽量统一，不要随意定义。

第四，由于计划在合同执行中的作用，所以在计划编制中，要考虑一定的技巧，使自己处于有利位置。例如在如果有业主指定分包，承包商就可以尽可能压缩指定分包的施工时间，这样一方面可以使自己处于有利位置，一方面也可能增加向业主索赔的时间。但是，这样对于承包商的要求比较高，在没有把握的情况下，最好不要使用，否则会弄巧成拙，而且，现在国际流行的理念，是提倡承包商与业主的合作关系，以索赔为目的的做法是不被提倡的。

最后一点，就是在执行过程中，必须注意计划的跟踪和调整，计划作的再好，也不可能与现场完全符合，所以必须随时跟踪，根据实际情况不断调整，是非常必要的。

五、棕榈岛项目的案例分析

棕榈岛项目是一个800套别墅组成的别墅群，采用的合同是在87版Fidic的《施工合同条件》上修改而成，要求采用CPM法用P3软件编制。由于国内缺乏能够编制这样计划的人员，项目开始是请国外的人员编制的，中间曾经让国内人员编制，后来又换成当地的一个工程师，最后换成新加坡的一位工程师编制。从使用的软件、理论方法、编制的内容、以及提交的程序等各个方面来说，棕榈岛项目计划都是严格按照惯例和合同要求来的，做的都非常规范。但是从实际的效果来看，该项目的计划是失败的，计划与现场的进度的符合程度非常差，而且，提交给业主的计划从来没有用于现场指导施工，实际上，现场工程师从来没有见过这个计划。

造成这个计划失败的原因，是多方面的，首先这个计划的工序定义，工序工期定义和资源都与现场情况差别很大，我们公司没有自己的工期和劳动力的定额，对于工序的划分也没有系统的经验，而当地的计划工程师对于国内工人的工效，工期等情况都不是很熟悉，显然他也不能与各部门的人员很好的合作，无法调动项目的资源，所以，这个计划从开始就是失败的。

而在工程施工过程中，这个计划从来没有用来提供给现场，用来指导施工，所以也就难以随着施工的行调整了。

这个计划的可读性，也是非常差的，即使对于项目上的人员，要弄懂这个计划也不是非常容易，如果对于项目外的人员，如公司领导等，那就更难理解了，而这个项目的人员又变动非常大，计划的可读性就显得异常重要了。

总之，这个项目的计划的失败，不是出在理论和计划软件的应用，以及对于程序的不理解上，当地的计划工程师对于这一点是非常擅长的，问题的根源，就在于我们的基础积累不足，没有任何定额，没有历史信息库，另外，由于项目大部分人员是国内派出的，而当地的工程师难以整合这些资源。我们在这些项目实施过程中，一直缺乏我们自己的计划工程师，而且也一直没有有意识的培养这方面的人才，在未来，我们应该要注意培养我们自己的计划工程师。培养计划工程师最好的方法，我觉得就是让我们自己的工程师跟着我们聘用的计划工程师一起工作，虽然，这些计划工程师给我们做的项目计划实际效果并不理想，但是这是多方面的客观原因造成，并非水平所致，我们要学的是计划编制的整个流程，使用软件的方法，计划编制的理论。

六、P3软件的应用

目前，国际上在建设工程中使用最广泛的计划软件就是P3，它的功能也是其它软件所不能比的，特别是对于大型的复杂项目，一般的软件比如我们国内常用的MS Project或者梦龙都是很难满足要求的，比如MS Project在用于500条以上的项目，它的计算和跟踪就非常困难。

P3软件基于的理论基础类似于国内网络图规程中的单代号搭接网络图，只是在关键工作的确定上，规程是总浮时最小的工作，而P3有两种确定方法，一种是总浮时小于某个时间的工作，一种是最长路径，比较适用的是最长路径的方法。

传统的单代号搭接网络图限制比较多，在P3中在很多方面作了调整：

1. 集时间、资源、费用管理为一体。
2. 可以给活动加载限制条件。
3. 可以有多个起点、终点。
4. 工序可以使用不同的作息时间。
5. 资源的分配可以非线性化。
6. 可以实现基于目标计划的跟踪控制。

这些是国际上计划软件比较常用的理论基础，比如MS Project也可以实现前面五种功能。当然其功能的完美，是难与P3相比的。

以下是P3的一些主要功能的介绍：

1. 最大可以加载10万条工序，WBS可以有20层结构。
2. 在结构组织上，可以选择采用WBS或者活动分类码进行组织。活动分类码是一个非常好的方法，在过程管理中可以通过筛选等手段迅速调出需要的信息，对于计划的管理特别是比较复杂的项目的管理是非常有用的。
3. 在活动的创建上，可以采用以前的信息作为模板，迅速创建新项目。对于计划的调整，可以使用总体更新的方法。
4. 在费用管理方面，可以采用有赢得值（BCWP）、计划值（BCWS）和完成赢得值所发生的费用等参数来反映项目的费用情况，可以生成现金流量曲线。
5. P3提供了200多种报告和图表形式。
6. P3还提供了很多附带工具或者功能用于报告，费用等管理。比如infomaker、Postoffice MPX转换工具（转为MS Project）。
7. P3提供了RA引擎，可以进行二次开发。

在工程建设领域，目前P3软件应用非常广泛，美国、英国、德国、加拿大、法国，中东以及香港、新加坡等国家地区，P3软件都非常普及，中建总公司在中东现在承接的项目，全部都是采用P3软件编制计划，在国际上，很多项目的业主都要求采用P3软件编制计划。在国内，目前在电力、石油等大型项目，P3的应用已经非常普及，但是在房屋建筑项目，P3软件还使用的很少，只有一些国际性的大项目才初步开始使用P3软件，比如现在的央视项目，就是使用P3EC编制项目计划。随着国内市场的逐步开放，越来越多的国际公司开始进入国内，同时国内市场的竞争也越来越激烈，未来无论是在国内还是海外，要想有立足之地，提高内部管理水平已经是必然，而计划作为项目管理的核心内容，提高其水平采用高水平的计划软件也是必然。

P3软件的功能非常强大，对于计划的编制考虑的非常的细致，在这里难以具体论述。学习P3软件的最好的书籍是P3软件附带的几本参考手册，其中最主要的两本是《Primavera Project Planner- planning and control guide》《Primavera Project Planner- reference manual》，其中前一本书300页，主要对理论基础、功能、应用进行概要式的介绍，后一本书774页，是P3软件的参考手册，对于P3的每一中功能的用法都进行了详细的讲述，在学习过程中，可以结合这两本书共同学习。普华公司是P3软件在国内的唯一代理，其法人代表包晓春先生本来是在火电项目做P3的应用工作，普华公司成立10几年来，在P3软件在国内的推广上作了大量工作，他们也写了关于P3软件应用的书籍，主要有《工程计划方法论》《P3应用技巧问答》等，相对于软件参考手册，这两本书写的简略的多，但是对于我们国内的学习者，可以把这两本书作为参考，与P3软件的参考手册结合来学习。除了参考书之外，学习P3的最好方法就是P3软件编制的实际项目的计划，在这方面，我们在中东的项目，如阿联酋的一些项目以及现在卡塔尔的高层办公楼项目都是采用P3 3.1编制的项目计划，国内的央视项目使用的是P3EC编制的计划。

在Primavera的公司网页www.primavera.com和普华公司的网页www.p3china.com上也能找到大量的资料，普华公司可以免费提供学习版的软件。一般正版的P3软件，根据用户数的不同，以及维护时间不同，其价格从6万人民币到100多万人民币不等，现在的P3EC价格基本与此差不多。

七、结论与展望

前面已经简单介绍了工程计划编制的理论基础，编制步骤已经P3软件的一些情况。在这里，对于文章内容总结如下：

1. 国际工程建设项目对于计划的要求非常规范、严格，批准后的计划作为合同的一部分，对各方都存在约束力，所以我们必须重视计划在合同上的严肃性。
2. 由于在海外项目中，资源的调配、调整相对国内项目更加困难，所以在海外项目中，高水平的计划管理更加必要，其效益也更加明显。
3. 在计划的编制过程中，最重要的是各个步骤的准确性，每一部都能与工程实际相符合，特别是工序的划分，工序持续时间的定义以及资源的加载。做到这些步骤的准确性，就我们公司而言，还需要进一步加强基础建设，主要是历史信息数据库的建立，包括工序划分模板，工期定额以及资源定额，在资源定额中，劳动力定额的建立尤为重要。
4. 由于国际项目计划的复杂性，以及其在合同中的严肃性，一个计划的编制，必须融合项目各个部门的力量，需要各部门相关人员的配合才能完成。
5. 现在我们在海外的大量项目，由于我们自己缺乏计划工程师，都是聘用其他国家的人员，由于对于以国内管理人员和工人为主的项目情况的不了解，实际上，这些项目的计划管理都不是很成功。但是，我们直到现在都没有有意识的培养自己的计划工程师，在未来，有计划的培养我们自己的工程师必须被注意。
6. P3软件是目前国际上在工程建设领域中使用最为广泛的软件，无论是出于应付合同或者是内部管理的目的，它的功能都是相当完善的。目前在海外项目中，P3的使用较多，所以P3软件普及学习很有必要。

作者：牛永宏

一、绪论

计划是项目管理的核心内容。美国PMI的《项目管理知识体系指南》在其综合管理一章中就将项目管理的主要过程概括为计划的编制、执行和控制。

无论国内和国外，在工程建设项目实施过程中，

计划的编制都是必不可少的工作。但是，相对于目前国内的情况，海外的项目对于计划的要求更加规范、严密和细致。比如FIDIC的《施工合同条件》（红皮书），1999年第一版第8.3款就对计划的提交时间、包含的内容以及计划与实际进度不符合时的修订做了详细的规定。一般在海外工程中，对于计划编制的工具和方法等还会有明确的规定，比如，阿联酋棕榈岛别墅项目要求采用CPM法并使用P3软件编制计划，正在施工的卡塔尔高层办公楼项目要求采用CPM法编制计划。

需要说明的是，国内的合同对于计划的编制、调整等也都有要求，比如建设部、国家工商行政管理局1999年12月24日印发的《建设工程施工合同（示范文本）》（建建[1999]313号）在其第10款就对承包商计划的提交和改进等做出了要求。但是在实际执行过程中，国内现在的情况与海外项目的情况是有实质性的差别的。本文在这里对这些区别简单的加以列举：

1. 国内的项目计划的内容一般主要包括现场施工活动，但是海外项目的计划包括设计，分包、物资的采购以及业主指定分包和甲供材料等都要有详细的计划。
2. 国内的计划的进度计划和资源计划一般都是分开编制的，比如劳动力计划，一般都是根据工程情况的一个粗略的估计，而且一般不会做现金流量计划。而在海外项目中，资源计划和现金流量与进度都是结合在一起的，也就是给每一道工序配置资源和资金，自动生成总的资源和现金流量。
3. 在实际控制中，国内也都提交周进度和月进度计划等，但是一般很少做原计划的跟踪控制，一般都是在大的节点上控制，而海外项目中，是必须定期提交原计划的跟踪计划的， 在过程中控制。
4. 国内的计划编制，一般对于WBS（工作分解结构）没有严格要求，而在这方面，海外项目是经常要求的，比如棕榈岛项目的WBS是业主提供的。
5. 在编制方法上，国内一般采用双代号网络图和甘特图，使用这两种方法时，一般会采用两种不同软件，采用甘特图时，一般不会严格定义工序间的逻辑关系。海外项目一般要求采用CPM法，具体的表现形式就是单代号搭接网络图和加逻辑关系的甘特图（单代号时标网络图），采用一个软件，严格定义工序的逻辑关系。

以上这些，是国内和海外项目计划管理的一个简单对比，从中我们可以看出我们在这方面的一些差距。作为一个国际化的建筑承包商，在提高其管理水平时，应该是不分国内外的，不过，由于以下一些情况：

1. 海外的项目在惯例和合同上对于计划的要求远高于国内的项目。
2. 由于我们目前在海外的项目，大量资源都来自国内，比如大部分劳动力，部分材料，因此资源调度的难度远远大于国内项目，一旦调度上出现问题，损失也远高于国内项目。
3. 一种方法的使用，不只是一个公司的事情，而是涉及到社会各个方面，就目前国内的大环境，贸然采用海外的这种方法，可能效果并不理想，实际上我们在海外的计划管理上就出现了很多的问题，但是我们在海外又必须采用这种方法，所以我们就只能尽快提高我们的水平。

所以，从各个方面来说，首先从海外项目来提高我们的计划管理水平再逐渐向国内推广似乎是必要的也是比较现实可行的。本文将首先结合海外项目的实践，对于计划编制的过程、内容以及我们在计划编制过程中存在的问题，进行简单的论述，并提出自己的一些想法。现代项目的工序动辄数千道，计划的编制必须借助功能强大的计划软件，目前海外项目应用最广泛的是P3软件，本文在最后将会对这个功能臻于完美的软件的理论基础、功能和应用进行简单介绍。

二、 计划编制的理论基础

现在主要使用的计划编制方法主要有1917年甘特提出的甘特图和1956年杜邦公司提出的关键路径法（CPM），1958年美国海军发射北极星导弹计划提出的计划评审法（PERT）与关键路径法基本类似，基本的不同就是活动的持续时间的确定方法不同，由于于工程建设的实际情况，目前主要应用的是关键路径法。网络图的表现形式有两种，即箭线图（ADM）法和前导图（PDM）法，国内主要采用的是前者，而国际上则主要采用后者。目前我们最常用的计划软件P3和Project的理论基础都是基于单代号搭接网络图，其表现形式主要是带逻辑关系的甘特图和传统形式的单代号搭接网络图，前者的应用是最广泛的，实际上我们在计划的编制和输出中，基本上用的都是前者。带逻辑关系的甘特图实际就是一种单代号时标网络图。

鉴于篇幅关系，这里对项目计划的基础理论不进行详细的论述。值得指出的是，从关键路径法产生以来，其基础理论一直都没有大的变化，但是从整个计划的编制方法来说，国际上已经有了很大的发展，如WBS的概念、加载资源的广义网络计划、现金流量的编制以及在此基础上的挣值管理等，国外关于计划方面的系统专著非常多，但是国内在这方面相对比较落后，普华公司在这方面做的是比较好的，但是其所出的书籍都没有公开出版。

关于计划理论方面的书籍可以参考Jimmie W. Hinze 著的《Construction Planning and Scheduling》，清华大学影印版，普华公司刘运元著的《大型工程建设项目管理方法-火电篇》，O’Brien,J.J.的《CPM in Construction Management》是这方面的经典之作，可惜在国内没有出版。关于网络图的基础理论，最好的参考书是建筑学会统筹法分会编写的《工程网络计划技术规程》，目前最新版本为JGJ/T121-1999。

三、 项目计划编制的步骤

编制项目计划的第一步，是选择一种计划编制的方法。在本文前面一节已经论述，现在用的最多的计划的编制方法是单代号搭接网络图，输出形式主要是基于单代号搭接网络图的甘特图，现在主要的计划软件也是采用这种方式，所以在本文中，如不是特殊说明，都将采用这种方法。采用不同的理论基础，对于工序的划分要求有一定的影响，概括地说，使用甘特图和单代号搭接网络图，对于工序的划分的要求是一样的，但是使用传统的单代号网络图和双代号网络图，对于工序的要求与前面两者有些不同，主要是出现搭接时，可能需要将事实上的一个工序拆分。

在确定了所使用的理论基础后，计划编制可以分为以下几个步骤：

1. 工序的定义
2. 确定工序持续时间
3. 定义工序间的逻辑关系
4. 定义资源与费用
5. 计划的计算与控制

国内一般计划方面的书籍，主要集中于讨论计划的理论和在此基础上的计划的计算和优化方法等，而且一般都是以甘特图或者是网络图为主线，讨论计划的编制，普华公司的一些书籍在国内首先在一个系统的理论框架中讨论建设工程计划的编制，但是主要还是集中于大的方面和理论方面，对于工程的细节考虑的不多，而且由于主要是做火电厂方面的工作，对于建筑工程方面不曾涉及。在本节，本文将结合工程实践，对于以上的步骤进行具体的分析，特别是前面四个步骤，对于计划的计算，由于各种书籍论述的非常多，这里只简单提及。

1、工序的定义

对于建设工程，工序定义在很大程度上可以参考历史数据。工序定义主要的考虑的因素包括：

1. 施工方案的选择。这是最主要的影响因素，方案不同，对于工序的影响很大，包括工序的逻辑关系和工序的持续时间。所以在编制计划之前，最好是方案已经确定，但是很多情况下，可能这并不非常现实，在计划编制时，可能只会有一个比较粗略的方案，所以工序的划分就要很大程度上依赖历史数据以及计划编制者的经验了，同时在后续阶段的调整也是必不可少。
2. 合同的要求已经工程量清单等因素。为了对承包商的计划编制进行约束，业主往往会对计划的编制详细程度等做出要求，同时，海外项目的计划一般都要求提供现金流量，而且一般都会进行赢得值的分析，这些都要求在编制计划时必须结合合同的要求而且一定要参照工程量清单的划分。
3. 采用的计划编制方法以及软件等因素的影响。采用不同的计划编制方法，对工序的划分的影响很大，比如采取的是双代号网络图，工序间的逻辑关系只有完成-开始，则在定义工序时，必须考虑工序间不能存在搭接，但是如果采用甘特图，则没有这种限制。现在的计划一般都采用计划软件进行编制，由于受软件计算能力以及操作等的因素等的影响，对于计划的编制也有很大的影响。

以棕榈岛项目的计划的为例，虽然棕榈岛项目都是两层的小别墅，但是方案对于工序的划分仍然有重要的影响，比如其条基与地梁是否同时浇筑，在浇筑一层柱子时是否先将一层楼板的模板施工，这些都是可以进行选择的，而在装修阶段，工序的划分受到方案的影响更大。在合同方面，棕榈岛项目在合同有明确的要求，合同的最底层的工序的持续时间不得超过14天，这一要求对于计划的编制影响极大。棕榈岛项目的计划一共有6000道工序，这个量远远大于国内一般项目，但是这仍然是将24套别墅作为一个施工段进行编制的，如果是将每一套别墅作为一个工作段的话，那么总的工序数将会超过14万条，P3软件的最大限制是10万条工序，而且即使是软件允许，如此大的工程计算量在操作上也是不现实的。

2、工序持续时间的确定

项目的计划的关键是时间进度计划。而项目进度计划的准确性主要依赖于工序持续时间的确定，工序持续时间的确定的方法主要有：

1. 历史信息，比如已经实施项目的积累的信息，工期定额等。
2. 专家判断，很多情况下可能并不能完全参考以前的历史信息，则需要有经验的专业人员根据以前的经验，结合具体情况进行分析判断。

工序的持续时间的确定，必须还要考虑资源的限制和经济性的要求，比如，象棕榈岛别墅这样的项目，对于每一栋别墅，我们如果不考虑经济性的要求，整体的安排，那么一栋别墅的结构可能只要一个月就能完成，甚至是更快，但是这对于这样的别墅群项目显然是不合适的，我们在确定工序持续时间的时候，就同时必须要考虑到资源的平衡，比如劳动力的平衡，因为一般的软件即使是P3这样的软件，在自动平衡资源时，都是不会调整工序的持续时间的，而只是改变工序的开始时间。

在计划编制中，工序的持续时间的确定并不是一件容易的事情，下表是计划编制时估计的工序的持续时间和笔者在现场观察的实际的工序时间的对比。

棕榈岛项目计划与实际工序历时的对比  表1

从表1中可以看出，计划工序历时与实际情况的差别还是非常大的，虽然一栋别墅的总工期相差不是很大，但是具体工序情况还是很大的，从大的方面来说，在计划中考虑的下部结构的工期40天，上部结构工期31天，而实际上下部工期为21天，而上部结构为42天，这显然有根据高层项目过分考虑基础结构的复杂情况而致，而在条基和地梁的施工中，又是前期方案考虑不周导致的，实际上在条基和地梁施工之间是没有防水施工的工序的，而且防水施工前需要养护的时间也没有开始考虑的7天那么长。

实际上，确定工序历时最好的手段，还是系统的历史信息，也就是工期定额，但是可惜我们公司没有这方面的积累。如果注意积累，以我们公司如此多的项目，对于未来项目的管理，将是非常有益的。以棕榈岛而言，经过800套项目的施工，在各个方面，比如工期定额、劳动力定额，都是可以积累非常丰富的经验的。

3、工序间逻辑关系的确定

相对于工序的定义和工序时间的定义，工序的逻辑关系得定义相对容易些。但是，这一点往往比较容易被忽略，在Eric Uyttewaal 著的《Dynamic Scheduling With Microsoft Project 2002》指出的现在项目计划编制存在的问题之一就是不定义工序间的逻辑关系，而通过强制时间来限定一个工序的开始结束时间。对于手工编制的计划，这样的做法的影响还不是很大，但是对于使用电脑编制计划来说，则情况完全不同。如果在计划中加入过多的限制条件，则在后期进行计划的跟踪和计划的调整都是非常困难的，而且，对于一个有数千条工序的计划，如果过多地依靠限制条件，则编制的计划中很容易出现错误，而这样的错误，也是非常难发现的。网络图对于建设工程的最大作用就是在电脑普及之后，对于软件自动计算计划提供了理论基础，如果过多依靠强制条件来确定工序时间，则计划软件就只是一个画图工具而已了。

4、资源与费用的加载

计划的主要目的是安排资源以确保生产能够按时完成。资源的计划是整个计划中非常重要的一环，国内项目作计划，一般只做进度计划，而不加载资源，资源都是另外编制，一般比较粗略。广义的计划，都是逐条工序上加载资源，从而生成总的资源需求，这样的资源计划是非常详细的。资源计划一般不会把所有资源都加载到活动中，这样的计划就太过臃肿，可读性会非常差，一般主要是劳动力，资金，大宗材料和机械，但是由于一般材料的采购会编到进度计划中，而对于建筑工程，机械的数量很少，所以实际最重要的资源就是劳动力和资金。

劳动力的加载是计划编制的一个难点，其难度在于消耗量的确定，一般的方法一是参考历史信息，所谓历史信息最主要的就是定额，目前我们并没有公司定额，可参考的一般都是国家定额或者是北京定额，其次就是专家判断，这是我们经常会采用的手段，但是其不确定性就非常大，所以有可能的话还是尽可能采取前一种方法。

实测单位用工量与定额用工量的比较 （上部结构部分）     表2

实测单位用工量与定额用工量的比较 （基础部分）     表3

表2和表3给出了棕榈岛别墅项目实际劳动力消耗与北京市2001定额之间的对比关系，这些实测值是作者在棕榈岛工作期间统计的。

通过这两个表中实测值与定额值的比较可以看出，两者之间的差别还是比较大的，而且不同的项目其偏差的差别也是较大的，所以，在项目中积累经验，编制自己的定额还是必要的，特别是在海外项目中，劳动力的调度极为困难，所以准确的计划劳动力就显得更为重要。但是在目前的清况下，采用定额并乘以一个折减系数，不失为一种有效的方法。

关于资金的加载，一般是把资金作为一种”资源”加载于工序上，所有工序的资金加起来要等于合同额。这样用活动的资金乘以进度就是赢得值，就是业主要付给承包商的进度款，把每期的进度款连接起来就是现金流量曲线。

5、计划的计算与控制

在前三步的工作完成以后，就可以进行计划的计算，资源的加载即可以在计算前也可以在计划的计算后。现在一般采用软件编制计划，目前最常用的P3和MS Project都是基于类似国内所说的单代号搭接网络图的方法进行计算。

在计划编制之后，最重要的是要进行计划的跟踪控制，国内一般很少进行这样的工作，虽然编制周滚动计划和月滚动计划，但是一般这些计划的编制都是和原计划的分开操作的。但是在国际上，都是在原计划的基础上进行跟踪控制，定期将进度输入原计划，进行跟踪，同时也就自动生成新的计划，现在的软件一般都能提供这样的功能。在计划与实际情况出现大的偏差时，则要对原计划进行大的修改。

关于P3软件，大家都说了很多，关于这个我也是感触良多，因为我刚毕业那会，曾经专门下了段功夫学习P3软件，就因为如此，我又做了专门的计划工程师，因为做了项目的计划工程师，

所以介入了一个很重要的索赔，有机会跟很多高手学习，所以又学习了很多关于索赔的东西，其中以工期延误分析方法为主，由此又回头去看合同的东西，发现不知不觉中，又加深了很多理解，我曾经发过一个推荐国际工程管理书籍的帖子，那里面提到的大部分书籍我都读过，也都是在参与索赔之后，受了点启发才开始去学习，另外，我从2007年末写了本关于计划管理的书，大概到今年年底能下印厂，虽然是东拼西凑，写的我也很累，所以我在建筑管理的生涯中的发展，跟学习P3的关联真是太密切了。

我最初学习P3的时候，感觉到非常的困难，有很多的概念不理解，之前其实我对project和大学里面学的网络图还是比较熟悉的，我在大学里面学网络图时候，就对这个东西感兴趣，所以大家学习完了（因为这在大学课程里面只能算副科）都忘了，我还记得清清楚楚的。但是为什么学着觉得费劲呢，当时我当然觉得这个软件是比较难的了，比如说我首先就在WBS和Activity Code这两个概念上就搞迷糊了，然后用Project时候，你只要给活动输入一个日期，他自动就跑到那个日期上了，可是在P3里面不行，你必须要schedule一下才行，还有进入更新的概念，既没有学习过，也没有用过，资源加载，在国内时候也不怎么用，所以上手就全糊涂了。当然后来是学会了，慢慢也理解了这些概念，后来我读了很多关于项目管理和国外的计划管理的书，然后我就理解了为什么当初学那个软件觉得困难呢，这是因为我们国内学校里面关于计划和项目管理的课程讲的内容实在是太少了，并且也太陈旧了，所以一般国内在学校里面的学生对于计划管理和项目管理的知识学的是比较少的，对于这一点，我后来在网上查国外学校的课程，他们一般都有比较详细的计划管理的课程。

关于P3或者是计划，我随便说说了：

1. 目前国内关于软件似乎在走两个极端，一方面呢，在建筑工程等领域呢，用的东西是比较落后的，基本上是Project了，梦龙了之类，一般就是开始编制个简单的计划，中间不会定期更新之类的。另外一个方面，在电力等领域，是软件不停的升级，P6已经是漫天飞了，这一点比国外走的快多了，我在中东，整个中东地区现在基本上还是在用P3呢。其实对于现在国际上的这种操作模式呢，P3是足够实现了，国内一窝蜂的上P6，基本上是跟风了，当然这和软件公司有关。当然P6本身的使用效率还是比P3高的，所以我自己都早就用P5了，就是因为效率的问题，用起来很方便。

其实本身P3和Project之间的差别，最重要的也就是在工作效率上的差别上，如果你要是有功夫的话，用Project也可以实现进度更新、资源加载，就是有点自虐自己。

当然也不能过度贬低软件在计划理论发展起的作用，软件对于计划的发展也是起到了很多关键性的作用的。

首先，计划中的一件大事，就是1956年关键路径法的开发，其实这就是杜邦公司为了充分使用他们的UNIVAC 1 计算机，不至于使空闲的时间浪费了。然后James E. Kelly就给他们建立电脑算法，可是弄出来之后别人不理解，他就画成网络图给大家解释，这就是最初的双代号网络图了。所以关键路径法的产生是为了用计算机。

其次，最初的时候双代号是占优势的，而Fondahl博士在60年代初推动单代号是说单代号用于手算比较方便。而单代号几乎完全取代双代号就是Primavera的软件在90年代推出其应用于windows的版本后，完全采用了单代号算法，由此可见其影响力了。

而且有很多有用的概念也都是在软件中首先出现的，比如Activity Code, Activity ID和Data Date等，这些概念都大大方便了应用，但是如果说跟着软件去学项目管理思想（呵呵，我这么说可能和何丰写的一本书的名字有冲突了），那就是反了，我想还没有人提过跟Auto CAD学设计的吧，道理相同。

2. 就是关于关键路径法的问题了，大家说了很多关于软件的应用，项目管理，不过提到关键路径法本身的很少，关键路径法是现代计划管理理论的核心，没有关键路径法，现在的那些软件都不可能出现，因为只有通过关键路径法，计划的自动计算才成为可能。

但是关键路径法本身是有缺陷的，它是项目进度的一个模型，但是这个模型并不总是符合实际情况的，比如对于一栋高层建筑，他从下到上的结构确实是比较严格遵守关键路径的，没有第一层绝对不能做第二层，可是对于它的装修呢，就只能是按照施工组织来加逻辑关系了，这个逻辑关系是很弱的，所以在PMI的项目管理指南体系中就会有强制逻辑关系和非强制逻辑关系的说法。我们在迪拜做棕榈岛的时候，一共有800套别墅，你有资源的话，完全可以平行展开，这时的所谓关键线路，完全是人为加上去的，所以过程中变化极大。从管理角度上来说，从资源的角度来看待问题，比从关键路径的角度来看要更加合理，所以在将计划用于管理时，关键是要看资源，在关键路径法中，资源是被动的加载到活动上的，人们很容易过度注意关键路线，而忽略资源。

不过最大的麻烦是在于工期延误分析中，现在的工期索赔或者是纠纷的解决，工期延误分析都是基于关键路径法来分析的，由于上面我说的原因，其实这一做法也是存在很多问题的，以迪拜棕榈岛项目来说，其实就很难用这种方法的。不过，由于合同问题涉及到两方的问题，所以必须有一种比较严格意义的方法，所以它比在管理中的问题更难解决，也许在未来能够找到一种更好的方法吧，这种方法应该是要最后全部转化到费用的差别上，其实这也是索赔的最终本质，工期也好，费用也好理论上最后都能转化到费用上来看。

3. 关于上面有人提到的国内用P3是装样子的，其实就我的经验来看，国外估计大量项目也是如此，我经历的中东项目就很多如此，基本上十之八九都是做个样子来看的，反而不如国内的很多项目编制的简化的计划来的更实用。

4. 现在很多人强调应该编制细化的计划，对于这一点，我并不太同意，我认为在计划开始的时候，计划还是不应该编制的太远，十之八九的情况，开始编制的太过细致的计划，往往并没有实质意义，比如我见过的很多计划，一个塔楼可以分出上万条活动，然后一层楼还要分成模板、钢筋、混凝土之类的，这和一层楼分成一道工序，效果不会有太大差别，但是前者很可能把编计划的人搞晕了。实际上，现在很多人已经对PMI的项目管理体系指南提出质疑，因为太过强调计划了。在传统的管理学教材中，也强调一个公司的计划不可能太细，否则没有实际的意义。美国精细化建筑管理协会实际也是这个意见。从这个角度来看，现在的所谓公司级的项目管理，项目组合管理，可能走的太远了。

5. 上面有人说到，他们在编制计划的时候，往往就是拍脑袋，很少真正去算资源什么的，关于这一点，如果是简单的项目，特别是在国内的时候，是可以这样，但是做海外项目绝对不行的，我说中国公司做海外项目。试想，如果补充劳动力，至少要3个月以上，国内进的材料要经过3个月，如果你不提前都算好了，项目的进度根本无法保证，所以我们一些同事做过了海外项目，都能意识到计划的重要性。当然实际我们做计划，虽然也用P3，也算资源，但是并不是就依靠P3给我算。我往往是P3，电子表格等一起用，来估算进度、资源，分析的时候很少把资源一个个活动中去加载。关键是拍进度的时候你要考虑资源的安排，所谓计划就是资源的安排。这是个思维问题。

看了之后，我非常的后悔我的21块钱。

这样说我没有贬低作者的意思，看得出，作者在这方面还是有很多的想法，在实践中对于传统的网络计划用的也是非常的娴熟，这样的水平在工程界的人也不是很多。不过还是非常的可惜，作者对于网络计划的了解还限于建设部的工程网络计划规程那样的水平，或者说的不客气一点，跟华罗庚先生引进中国时水平基本上差不多。而对于当代国外网络计划技术的发展，显然是根本不了解的。网络图的理论基础，非常的简单，跟它被刚提出时是完全一样的，这个一直是没有变的，所发展的，是在实践中应用的方法。从作者写得书中可以看出，他对于现代的很多东西根本是不知道的，比如WBS的概念，现代的计划软件，对于资源和活动的概念也不是很清晰，基本没有涉及到资源的加载的论述，而整本书的核心是作者所谓的横道网络图，其实就是双代号时标网络图，最可惜的是，作者显然看到了单代号网络图的有点，可是竟然说，单代号网络图以节点表示工作，实际应用比较困难。可是，只要给横道图加上逻辑关系，就是单代号时标网络图，这个要比作者用的双代号时标网络图简单的多。

其实作者真的是一个比较爱思考和务实的人，看出了传统的网络图实际应用的困难，这个是很有见地的，在工程界，实际使用的人们其实都是理解这一点，对于作者一个外行人能够也看到这一点，真的很好，可惜，由于对于先进的理论的不了解，以至于，作者辛辛苦苦琢磨的东西，根本就不是最先进的，而且，其实早就存在的，只是除了国内已经很少用了而已。像作者说的横道网络图，也就是双代号时标网络，对于非工程界的人来应用，真的还是比较难的，而用加逻辑关系的横道图，是最适用的。

我看到说，作者在国内很多地方作过讲座，似乎名气很大。他的书，有复旦的教授写序，可是，我希望我们先看看别人先进的东西，不要别人已经到90年代了，你还在60年代的基础上创造，牛顿说，只所以看得远，是因为站在巨人的肩膀上。牛顿尚且如此，我们就不要再闭门造车了。