项目管理的五大过程

1、项目管理的五大过程一 . 商务谈判 ?1. 作人的姿态 ?作人似乎跟商务谈判不太有关系，很多技术人员相信 PMI需要的是本事，是如 何做好一个项目，而不是会搞好关系弄的四平八稳的人。随着PM在中国的悄悄兴起，越来越多的PMI开始在老总的授意下参与商务谈判，和销售们一起打 单子，这就比较实在的需要PM们去揣摩客户的心理。揣摩客户心理需要有多 方面的知识，需要深度和广度，然而，最重要的仍然是作人。如何放下架子， 降低作人的姿态，对从技术人员转型的 PM们来说，是至关重要的。？降低作 人的姿态需要从多个方面去实施，最主要应该记住：人不可貌相，更不可以 地位衡量。很多公司为了保持公司形象，会统一叫员工

2、打扮的好看一点，看 起来象个白领的样子。然而，老板多半是没有约束的。中国改革开放才二十 年，很多有钱的老板实业家文化层次都不高，往往是当大学生们只会把屁股 坐在板凳上肆意挥霍父母辛苦积攒的财富时，他们已经在各地奔波，积累丰 富的商业经验并对金钱，人生和社会的本质有了充分的认识，形成了自己稳 定的思维框架。这些人，很多都是穿着旧旧的衣服，戴着破破的手表，说话 的时候经常会带上三字经，钻进上海的人堆里，搞不好你会把他当成民工。 因为到他们所处的社会地位，已经不需要任何华丽的外表来衬托自己的身份， 他们有的是底气。对PM来说，这是个非常危险的挑战。虽然说项目在初期有 意向时会对对方的人事和关键人物有

3、一定的了解，然而大项目里能说的上话 的人太多了。上海人最瞧不起的就是土气，很多人谈项目的时候看到民工或 很俗气的表现不免会皱皱眉头，往往在皱眉头的时候就失去了项目，也就是 失去了市场和金钱。PM必须作到能与每一个层次的人交谈，尤其是看起来比 自己层次要低的群体，哪怕是公司里扫地的阿姨。只有作到谦虚谨慎，不摆 架子，尊重别人，才会得到别人的尊重，才有机会赢得项目。鼻子比眼睛高 的人只会把自己的鼻子撞扁。 ?2.丰富的知识面 ?光尊重别人还不足以赢得项目，准确的说是赢得对方关键人物的信赖。PM一般用不着陪客户喝酒吃饭，那是销售们的事情，但是 PM和客户讨论问题可能 是最多的。讨论问题的时候就是机会

4、，如何投其所好，是一大关键。金钱与 美女依然是常规的敲门砖，然而这种傻瓜也知道的办法人人都会去做。老板 的关系也只是一个方面，如今的大老板，哪个没有关系？同等条件下PM凭什么去胜过别人一筹？ ？我一个朋友（PM打一个单子时，发现对方对什么都不 太感兴趣，费了很大力气也找不到突破口。对方这个人非常顺利，金钱地位 美女样样不缺。他花了好多天和对方交谈，以自己的博学逐渐取得了对方的 信任。后来他隐约发现对方对数学和天文学的发展史有所涉猎，如获至宝， 回家花一个通宵的时间在网络上搜索相关资料。第二天他根本不谈项目的事 情，只跟对方大谈特谈哥白尼，布鲁诺，伽利略这些人的生平，整整吹了一 天。对方点头如捣

5、蒜泥，态度和热情都来个一百八十度转弯，隔天他就拿到 了单子。这是个经典的战例，谁能事先想到哥白尼会来帮助 IT 的人赚钱？这 个PM靠的就是博学和由博学引申出的敏锐的感觉抓住了机会，让客户产生共 鸣。客户感觉他层次也很高，而且和自己有共通之处，信任度大大增强，把 项目交给他放心。如今这种例子在商务谈判中已经屡见不鲜了。对 PM来说，并不要求在各个方面都很精通，那是不可能的事情，只要PM对一些流行的话题和天文地理历史各方面的知识有个大概的了解，在需要的时候能尽快的掌 握，才有机会创造机遇和把握机遇。3. 强大的沟通能力胸中有万千墨水却不知如何表达其实是比较少见的，但并非绝对没有。每个 人的人生轨

6、迹都有所不同，思维受环境的影响也各有差异。包括象我们目前 这个班级里的一些未来的 MSEil，一定有比较内向或者不太爱表达自己观点 的人，这些人比较被动，往往很难承担起谈判的重任。从今天开始，这类人 就必须重新学习如何说话，如何大声的争论。沟通，并不仅仅是大声说话， 而是在表达自己观点的同时发现问题并综合整理加以解决。除此之外，沟通 的能力与社会经验息息相关，与 PM的见识联系紧密。在日常生活中，PM就要 多留心，多思考，当别人想到某个层次的时候要争取比别人考虑的更深。当 然，也有一些不够踏实的朋友把沟通和吹牛当成了完全的一回事情，在和客 户交流的时候口若悬河的说一些不着边际的话。这种人，碰到

7、不懂，不太认 真或者好奇心强的客户是有一定市场的；而有水平，负责任的客户往往会觉 得这种人不可靠，一般不会把单子交给他。 PM需要把握好这个度，吹是肯定 要吹的，只是吹牛的时候一定要有基础的去吹，对从来没涉及过的领域或者 根本不懂的东西轻易不要发表意见，挑选自己熟悉的方向合理的进行发挥， 适当的留上一两手，给对方高深莫测的感觉，效果最好。4. 优秀的售前团队 ?这个团队一般是由总经理发起并组建的，通常不指定PMP对团队的成员如SALES PM SA ENGINEER的团队合作提出了比较高的要求。一般公司在接 下一个单子进行到一定程度的时候，PM往往会尴尬的发现协议上销售代表们 对客户的一些承诺

8、是几乎做不到或者根本做不到的事情。这种情况非常多 销售的任务是拿下单子，我听到的销售们说的最多的就是 "没问题"或者"NO?P ROBLEM"但是当我听到客户的要求和销售的回答时我总是心惊肉跳，很不自 然。销售是非常辛苦的，为了建立客户关系，尤其是空白的市场是很不容易 的，往往为了一个单子会牺牲非常多。在这种情况下，和销售进行协调自然 而然的又落到了 PM的头上。在销售和客户做承诺之前，PM要主动的跟销售交 流，提供粗略的总体设计框架和技术难关以及能考虑出的工作量，而不是等 出了问题再被动和销售在老板面前互相推委责任。在组建团队的时候，PM要根据团队里每

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

10、有多种版本，各不相同。实际操作中多分为范围，成本与进度， 其中最重要的莫过于范围。我们把项目最终生成并提交给用户的产品和文档 统称为递交件。谈判的时候一定要确立递交件的标准和要求，也就是范围。 尽管商战的时候不可避免的客户会不断提高标准和要求，而承诺的款项却不 会有一分钱的增加。但是这个标准对每个公司来说都有一个底线，一旦超过 了这个底线，那项目就肯定是亏的。除非是为了二期有利可图或者是为了搞 好关系，否则范围超过底线的时候情愿不做，再厉害的PM在这种情况下也是无能为力。建立范围需要的就是 PM的多年的实战经验，在大大小小的项目中 用血泪换来的一些体会。在这个时候，很能体现 PM与技术人员的区

11、别。成本 就是客户答应付的款项，与我们的投入成本并不是一回事情。进度就不用多 描述了。项目如何成功？也有一些关键的因素。个人的理解也不尽相同，通常包括以 下几个方面：界定工作目标及工作任务；老板或高层的支持；优秀的PM和开发团队；充足的资源；良好的沟通；对客户的积极反应以及适当的监控和反 馈。这里要注意的就是资源和高层的支持。一个上规模的公司总是同时会有 很多项目，可是再大规模的公司资源也不足以保证每个项目都能组建最合适 的开发队伍或拥有最好的环境。这时候各个团队或者部门之间不可避免的会 发生资源争夺战，摩擦再所难免。这时候对 PM的作人再次提出挑战。除了高 层对PM项目的重视程度，如果PM平

12、时在公司与同事相处的好往往能使很多 别人看起来很棘手的问题迎刃而解。相反，一个不会作人的PM由于人缘差，即使高层强压别的部门或团队配合，别人也会能拖就拖，延缓项目的进度和 质量。有时候，这种内耗对项目和 PM来说是毁灭性的。对客户的积极反应也比较关键。一般来说PM已经被项目里大大小小的事情搞的筋疲力尽，要 PM去主动要求客户配合是很吃力的事情。然而，这个时候，越是困难，越是觉 得累，越是要去主动。客户往往也不是特别的积极，主动与客户联系沟通和 测试能及早发现问题。从风险控制的角度来说，问题发现的越早，风险越小， 损失也就越小。积极的态度可以带动客户的积极性，在项目完工的时候，客 户对你的感激往

13、往是难以用语言描述的，这对以后接单或者做二期三期会打 下良好的基础。因为在和别的新客户谈判的时候，新客户自然会找你的老客 户了解情况，这时老客户随意的一句话顶的上你很费心的十句。项目具有商业行为的几个重要特征，有消费源，有参与者，有成功关键因素， 有财务目标，有风险。2. 启动阶段的主要任务根据PMI的解释，接单之后项目自然转入启动阶段。启动阶段 PM的主要任务是率领总体架构设计师和系统分析员收集尽可能详细的数据，确立尽可能详 细的需求，进一步确立详细的项目范围，预估资源，确立其他方案并获得进 入下一阶段的批准。在这个阶段，随着需求分析的深入，PM也开始在公司内部进行人员挑选和资源争夺，着手组

14、建自己的项目团队。项目即将进入计划 阶段。在收集完数据之后，PM要和客户开始明确项目的大小，成本，规格，期限等重要特征并将其写入合同文本，同时准备内部的包括预算，衡量标准等文档， 建立项目的评估标准。接下来就是需求分析。由于专业的原因，我们这里仅 讨论软件工程项目的需求分析（以下简称需求分析）。?需求分析的主要参与人员有PM总体架构设计师，系统分析员，熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队，我们叫做前期团队。随着需求分析的逐 步深入，新的团队成员不断加入，启动阶段结束的时候正式的团队将建立。 对一个已经启动的项目来说，需求分析直接决定了项目的成功与失败。最初 的需求体现在

15、客户的工作说明书或招标文件及附件上。这种需求一般比较含 糊，无法体现客户真正的需求。前期团队要根据自己的经验和客户沟通并引 导客户进入正轨。有时候客户会很不讲道理或者思路僵化，就要求按照他的 思维去定一些明显错误的需求。这个时候团队成员要耐心和客户举事实，谈 经验，讲道理，用图形或模型等直观的方式将需求描述出来，比如常见的数 据流图等。所以说，争论再所难免，客户有时候会吹胡子瞪眼睛拍桌子甚至 会说"这个东西不要你们做了 ”之类的话。PM此时除了要亲身参与需求分析综 合整理文档之外，还要处理好团队成员与客户的关系，确保关系不会恶化到 无法收拾的地步。只要PM尽力约束团队中的成员，这个度

16、还是很容易控制的。对快速开发和叠代开发来说，需求和实现往往是同步进行，开发速度快是一 大优势。对有相同或类似模式的小项目来说采用快速开发或叠代开发是很合 算的做法，时下流行的极限编程就是针对这方面建立的思维模式。然而，大 中型项目中有太多不一样的需求和模块。如果不是因为项目有差异，那么市 场上就只有产品而没有项目了。所以，大中型项目的需求要认真仔细的去做。 我们要讨论一个问题，究竟应该在需求分析和总体设计上花费多少时间？我 们熟悉的瀑布开发模式基本上分需求分析，总体设计，软件开发，测试等几 个阶段，然而究竟应该在前两个阶段上花多少时间却没有定论。实际项目操 作的例子表明，分析设计的时间越长，需

17、求设计做的越详细，测试的时间就 越短，返工率越低，风险也越小，成本越容易得到控制。而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展 顺利的时候问题不大，到了项目后期和测试阶段一些潜伏期比较长但是破坏 作用比较大的问题就会凸显出来，造成返工，延长测试时间。所以与其把问 题堆积到紧张的项目后期，不如把时间多花点到需求分析和总体设计上。基 础夯实了，金字塔就容易造了。 ?在日本公司打工的程序员们可能都知道，小 日本的软件规范非常厉害， 他们花在需求分析和总体设计上的时间通常在 40% 到 50%左右，远远超过国内软件项目的实施，效果也要强的多。他们总体设计 的规范甚至详尽到某个过程

18、该如何判断，确立什么样的条件，换言之就是把 什么时候该如何写 (if.else)语句都帮程序员定好了。在这样的软件规范下，程序员更象是装配流水线上的工人，对一个模块或技术熟悉到一定程序 就变成了完全的重复性劳动。所以在日本和欧美经常会有程序员是低级工作 一说，很多人不明就里，对国内程序员也照搬，对国内的程序员来说是很不 公平的。在国内，只会照抄别人代码，一点都不懂创新，凡事依靠别人，快 下班就盯着表看的程序员是不少，这种人一般很难有什么前途。但是，优秀 的不断进取的程序员也很多。由于国内没有象 CMM这样的软件规范或者很少， 所以这类优秀的程序员不少都是干着系统分析员甚至 PM的活，拿着程序员

19、的 工资。这类程序员虽然在起步时会吃很多亏，而且是主动找亏吃，然而几年 之后与前一种程序员的社会地位会出现明显的分化。 当上进的程序员们作为 P M进行商务谈判的时候，前者还在各个公司里频繁跳槽，跳来跳去都不满意。 有些扯开了，回到我们的话题。日本的软件规范与CMM有惊人的相似，其中至少有35%以上都是几乎一模一样 的。最近经济不景气，东京倒闭了 160家软件公司，这个数字是今年 6 月份 的，还在不断增加。这些公司纷纷抢滩上海，招收技术人员。如果去这样的 公司应聘就要考虑清楚了，进去可以学到他们的规范和质量控制，可是要想 从程序员成为系统分析员或 PM比登天还难。往往一个程序员进去干了好几

20、年，对自己的那一块熟的不得了，而对隔壁同事所做的东西一窍不通。拒传 华为正在尝试CMM4华为印度研究所已经通过CMM），对在华为工作的程序 员们来说可谓福祸难料。当然，已经作到 PM或 QA或者热爱CODING勺朋友例 外。 ?需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最 长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为 了确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字，不合格的打回重做。反馈表随之将提交给客户，第二遍第三遍等等等等接踵而 来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需 求。当PM最终合并了所有文档并确立需

21、求之后，最终生成的需求文档将提交 给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在将来 项目变更或者碰到重大问题时和客户扯皮的重要依据。需要说明的是，客户并非都是蛮不讲理，但是说实话，颇有无奈，国内目前 的项目大多数客户为了不让自己的钱白花，经常变着法子提需求。在启动阶 段明确需求并签字，无论最终情况如何，一份详尽的书面文档可以解决很多 口头承诺或概念模糊的文档带来的许多问题。 ?详尽的需求分析有一个额外的 好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进 行项目的判断标准。有时候，这种大项目在签单时双方都没有绝对把握保证 可以出成果，一旦在需求分析阶段发现难以

22、逾越的技术难关，就会放弃项目。典型的例子就是NMD洲际导弹防御系统。上世纪八十年代初美国搞星球大战计划，拖跨了苏联。大家对那段历史有些含糊，很多人认为苏联人上了美国 的当。其实并不完全如此，苏联人的情报机构无孔不入，并非那么容易上当 受骗。实际上当时美国国防部已经开始着手 NM系统软件的需求分析，前后 耗资数亿美圆，耗时两年，仅仅是做需求分析，终于发现存在着在当时技术 上无法达到的高度，随后项目被放弃。3. 项目启动项目启动要确定项目计划，与客户一起实施第一次项目审核，确认并对一些 产品和服务向下包厂商下订单。这个时候的 PM会忽然发现有开不完的会，一 天开三到四个会议是很正常的事情。这些会议

23、有与客户的会议，与下包厂商 的，有团队的，有公司高层的。团队的会议主要是建立正式的团队，提供团 队成员的角色和职责，提供绩效管理方法，向成员提供项目范围和目标。与 客户的一个主要会议将是项目启动会议。在这个会议上 PM会与客户确立正式 的交流渠道，项目综合描述，让项目参与人员相互了解，建立以 PM为核心的 管理制度。还有一些零零碎碎的东西甚至包括办公场地的大小，电话多少部， 所有人的联系方式等等都要在会议上确立，并做会议记录。这都是些非常琐 碎的事情，听起来婆婆 * ，却是非常必要，缺一不可。大概就是所谓三军未 动，粮草先行吧。 ?这时候，作为公司高层，应该向全公司发表申明，正式给PM发布项目

24、经理任命书和项目授权书。这个动作虽然在别人看来有些形式主义，但是对提高 PM 本人的士气和责任感是有很大助力的。三. 计划阶段1. 定义结构分工结构图（ WBS）?启动阶段结束后，项目进入计划阶段，也就正式进入实施。这里概念可能有 些不太对头，其实是翻译的缘故，反正大家明白意思就行，不用拘泥于字面。WBS是 一组要提交的项目元素，用来组织定义项目的总体范围，具体包括从工 作内容，资源，成本角度考虑项目范围；建立一套系统所需要的分层工作结 构；把项目分解成易于管理的几个细目，这概念有些模糊，其实跟资源管理 器里分目录是一回事情。可以说， WBS是计划阶段的核心。WB陰详细的分到 递交件，包括给自

25、己人用的项目使用的过程文件，给客户用的模块和说明文 档，完成每个细目的标准以及如何把这些细目的责任分配到具体的个人。 WBS 有缩进式和树状式，我这里也没办法画图，大家参考一些项目管理的书籍， 里面有详细介绍。我整个文章只挑我觉得需要注意的地方，如非必要，对技 术细节或者工具使用不做详细介绍。 WBS勺细目并不需要分解到同一水平， 最 下面的细目叫做工作包，分包的依据是个人的责任和可信度，也就是说到每 个人头上的任务是否能落实，是否有把握完成；还有就是准备对项目进行控 制的程度，程度越深，WBS寸也就越深。由于 WBS是实用性的东西，根据个人 理解也不一样，所以一个项目可能会有几个正确的 WB

26、S看PM的需要和最适 合当前团队状态的进行选择。 ?wbS勺定义还是很麻烦的PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式（ BRAINING? STORM思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标 准。在头脑风暴式思考时，会有很激烈的争论，PM要协调关系，调节气氛，从自己能考虑到的各个角度旁推侧敲，提示成员的思维角度和方向并加以总 结。尽管很麻烦，制订 WBS仍然是非常值得的。如同需求分析一样， WBSt备 的越充分，编码的进度越快。2. 风险管理既然是商业行为，那么项目的风险必然存在，相信阅读

27、这个帖子的朋友不少 人都经历过或大或小的风险。有些风险很容易解决，有些风险则大大损害利 益。不论什么样的风险，能避免尽量避免，所以有必要对风险进行管理。由 于风险的不可预知性，风险管理难度很大，概念也很难讲清楚，只能从一些 可行的角度去分析，进行管理。首先要识别风险。这是个难度很高的活。 PM要先召开风险识别会议，这个会 议面向公司，高层，跨部门的有经验的人都将参加。然后审核由项目小组生 成的风险清单并与重要成员进行风险沟通，检查一些重要的风险源如WBS成 本（时间）预估，人员计划，采购管理等等。最后就要用到PM本身在以前类似项目中得到的经验教训。识别之后要进行分析。我们可以进行粗略的量化分析

28、（精确分析是不可能的事情）。有经验的人可以一起参加讨论，把提交出来的风险进行分类。首先 按发生的可能性分，一般分成高，中，低三个级别，虽然很勉强，但是好歹 也有个量化了；然后按耗去的成本分，也是高，中，低三级。我们可以把这 两种类别的三个级别进行组合，碰到可能性也高，成本也高的风险就定位为 不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成本，否则 一旦亏起来不是亏一点点，有可能赔的很厉害。高和中，中和中的搭配都是 属于高风险，中和低，低和低搭配属于低，高和低搭配属于中。针对出现的可能性，需要采取一些手段降低风险。到目前为止也没有一个定 论说有绝对好的方式，只能尽其所能的避免。有几种方

29、法可以考虑，第一种 是将风险纳入项目管理计划并指定负责人，由外部人员定期检查项目风险， 一旦风险发生，执行风险管理计划；第二种是保险，这种属于风险转嫁；第 三种方式有点奸，不过最保险，就是把客户拖下水，让他们一起参与风险管 理，呵呵，到时候就好说话了：）？风险管理作为项目计划之后，PM需要更新WBS修改日程计划和更新风险管理计划。 ？风险预留通常是成本的8%3. 预估预估是从量化的角度对项目进行评估，主要包括工作量，任务期限，人力， 设备，材料，成本等，要注意预估不是财务策略或报价。 ？预估其实并不是一 次性工作，在整个项目过程中，预估始终需要。预估似乎没什么特别需要提 的地方，每个PM接到项

30、目的时候自然会有预估，在项目发生变更或进入下一阶段时也会预估。预估的作用主要还是让 PM作到心中有个底，安排计划时不 至于毫无头绪。4.进度计划？进度计划就是一个模块或功能要写多长时间，PM安排个日期，设 立里程碑，叫程序员们不能偷懒。进度计划是从 WBSI取过来的。对PM来说， 合理的安排进度计划对项目控制和激励团队士气有着很大的作用。对程序员 来说，进度计划毫无疑问是噩梦。 ？显示进度计划一般有先后顺序图，甘特图 和里程碑图表。上回邵卫老师讲课，推荐的工具是 m啲PROJECT这个工具 我还不会用，因为没时间去摸索。我的头倒是用的很溜了，近一个月来他就 用这个PROJEC画了一个又一个的里

31、程碑图，不停的折磨我和同事的神经。 我们一般都是一边开发一边做 UNIT?TEST效果上来看，因为有强大的时间压 力，效率上比之前确实要提高不少，可是我们也只能结结巴巴的赶完进度。由于TEAMS人少，我们都是一个人做几个人的活。我每天早晨六点多出门， 经过将近两小时颠簸，八点多点已经坐在位子上，中午吃 15 分钟的饭，干到 晚上八点下班，到家吃完饭往往已经 11 点了。一个多月我从来没吃过早饭， 没有睡过六个小时以上的懒觉。虽然强大的压力使我们能在短时间内掌握尽 可能多的技能，开发更多的模块，但是对我们的情绪也是有很大的影响。所 以说，项目里程碑是一把双刃剑，合理安排才能既促进效率也不至于打击

32、士 气。团队成员士气的逐级衰落会给项目后期的开发带来难以估计的影响，进 度将会大大延缓。关于PM和团队的问题我们后面会讲到，这里我先祥林嫂一 把，然后跳过。 ?里程碑图表的特征是任务，成员和时间，任务和成员用文字 标志，时间用数字描述并辅助以图线跨度，象阶梯一样非常形象，一目了然。 管理起来非常方便，完了的打个钩就可以了。网络逻辑图是表示任务和逻辑关系的示意图，可以用先后次序表示，也可以 用关键路径表示。其实把各个活动划分为 1，2，3，4 等阶段，每个阶段包括 小活动，等，日程计划也分四种，一般只提到从前向后 和从后向前两种。从前向后的概念就是某项活动必须相同或晚于直接指向这 项活动的的所有

33、活动的最早结束时间的最晚时间。有些绕口，我们打个比方： 2 阶段指向 3 阶段，那么 2 阶段里的 4 个子阶段也都指向 3 。假设结束时间为 1月12日，结束时间为 1月22日，结束时间为 1月 15日，结束时间为 1月 20日，那么， 2阶段中最晚的结束时间是的 1月22日，所以在 3阶段中的 3 个子阶段，的最早开始时间都不能早于 1月 22日。至于从后向前的例子大 家自己去推吧，我就不举了，刚才几个 123 打的我累死了：） ?项目经常需要 调整进度。在不改变项目范围的情况下，调整进度有几种方法：利用快速跟 踪手段来改变任务间的关系；将串行的任务改成并行；改变工作方法（可能 改变WB$

34、;改变日期限制，使关键路径上的任务开始或结束的更早。虽然方法多样化，在我看来只有一条，就是拼命的压榨程序员的劳动力。如 何压榨，还是个技巧。如前面所分析的，需求分析恨不得多分点时间给它， 压需求是不太可能;测试阶段后期接近完工，罗里巴唆的事情一大堆，忙都 忙不完，那时候PM一门心思提前/按时完工，好收钱，压那段时间似乎也不 太可能。说来残酷，最能压的还是 CODING编码阶段往往是压缩重点，总之 大家埋头苦干就是了，大项目压缩的时候程序员吃喝拉撒都在公司是很正常 的事情，相信不少人都有很深的体会，这里伤心事情也就不提了。只是我总 结一下，让未来的PM们有压榨后来人的依据，呵呵。测试前期也可以适

35、当的 压一压，那时候人刚完工，都比较懒散。国内一般企业规模都不大，没有专门的质量控制部门，所以质量保证和测试往往就是程序员或PM本身。其实质量保证和测试人员的人数和素质都应该要高于程序员。在日本和CMK实施的公司里，编码压缩是很容易实现的事情，因为那些程序员真的是技能熟练的 装配工人，压起来方便的很。他们这样培养人的目的或许就是为了压缩吧？！四. 控制和执行阶段1. 软件开发 ?实在没什么好说的，也是大家最不愿意谈的，平时在公司里谈的 已经够多的了，还要在这里受我唠叨。需要提醒的依然是团队合作精神和完 善的文档管理制度。SOURCESA这些工具有时候还是有必要使用的。经常看 到有人说天才程序员

36、不写注释什么的。我相信有这种天才程序员，因为我碰 到过几个。我爱人公司里也有一个， 他们的一套产品核心代码就是这个人写的， 4年过去 了，周边代码换了好几茬，核心算法始终没换过，可惜这小子跟了李洪痔， 如今已经不知所踪了。但是他的代码似乎也要有点注释的，没有注释过段时 间再天才的程序员也不能保证他是最有记忆力的。而且，对一个项目的编码 来说，靠一两个人打天下如今是不可能了。别人的公司都是团队，两人智慧 胜一人，这头还在靠一个天才支撑门面，实际上市场可就别人抢了去，那时 候再天才也没用了。编码的时候讲究技术公开，程序员不要藏着掖着，对大家没好处，PM要想办法调动大家创新思维的积极性，营造良好的技

37、术讨论氛围，碰到技术难关的 时候就容易攻破了。？有个问题需要单独对还没有PM觉悟的程序员说，其实 是在调研的时候就定了的，就是使用什么样的开发工具。没有经验的程序员往往会拿着C+或者JAVA的资格证书或者拥有一两个开发工具的一些经验而得意洋洋。其实老板和PM根本不看重这个，他们关心的是使用什么样的工具 能尽快的达到目的。管你什么 C+ DELPHI PB还是JAVA只要能做的出来， VFP都可以用。我举这个例子并非说不看中工具，而是提醒想转型为PM的程序员，第一要把工具当作工具，而不要被工具套进去，钻研一些一辈子都用 不上的技术；第二要掌握的并非是单独的一个工具，而是流行的程序设计的 思想，以

38、及在最短时间内掌握一门陌生工具的能力。只有建立了这样的思维， 才有可能转为PM否则一辈子都是技术工人，最多就是个技术总监。2. 变更?对任何项目，变更无可避免，无从逃避，只能去积极应对，这个应对 应该是从需求分析就开始了。对一个需求分析做的很好的项目来说，基准文 件定义的范围越详细清晰，用户跟 PM扯皮的幌子就越少。而需求没做好，基 准文件里的范围含糊不清，被客户抓住空子搞你一下是非常头疼的事情，往 往要付出无谓的牺牲，有时候甚至非常火大。?需求做的好，文档清晰又有客户签字，那么后期客户提出的变更就超出了合同的范围，需要另外收费。这 个时候千万不能手软，并非要刻意赚取客户的钱财，而是不能养成客

39、户经常 变更的习惯，否则后患无穷，维护的成本会让 PM吃不消。在客户提出变更请求时，要建立变更申请登记表和变更申请表，并让客户签 字。当然，有时候一些不是非常关键的模块 PM也不至于一点不讲情面，该卖 面子的时候还是要卖，尤其是当着对方领导的面，千万要卖面子，但是也别 卖的太干脆，不要让他们得到的太容易。 ?需求做的不好，客户抓住漏洞或者 非常不讲道理，麻烦就大了。有时候争论会很厉害，到非常白热化的地步， P M与客户代表几乎沟通不了。 PM在客户关系和短期利益两方面难以取舍，一 般都是向客户妥协，最终形成恶性循环。这种情况非常难办。一般这种情况 都是到了项目后期，做重大的更改几乎是不可能的事

40、情，如果白做就要亏钱。 而这个时候如果PM跟对方高层的人关系搞的定，可以透过对方高层把事情压 住。然而由于已经到后期，客户代表不会轻易更换，对方这次没有改成，必 然心怀不满，下回在别的模块依然会找麻烦或者在谈二期的时候动动手脚， 都是很让PM伤脑筋的事情，这方面目前还没有什么好的解决方法，所以尽可 能的做好需求比什么都重要。相对需求来说，什么 WBS风险管理，计划进度 都是扯淡，需求做好了，一帆风顺。还有一种办法就是装可怜，要装的非常 的象，在对方的领导面前装，而且不能让人看出是装的样子，要让你自己都 觉得你自己是真的可怜，那么就算这次客户硬是要求改了，下回他也必然不 好意思再叫你改。其实人心都是肉长的，如果可能的话，我还是不赞同使用 一些手段的，但是有时候客户非常难以在短时间打动而工期又将接近，这种 情况下就要靠PM耍一些手段了。各人有各人的方式，八仙过海，各显神通吧。 PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改 基准文件。3. 质量控制？大公司有质量管理部门（QA，QA的成员基本上都是由非常有经 验的PM转型过