项目管理的几大过程

1、项目管理的几大过程是穿着旧旧的衣服，戴着破破的手表，说话的时候一. 商务谈判经常会带上三字经，钻进上海的人堆里，搞不好你会把1. 作人的姿态他当成民工。因为到他们所处的社会地位，已经不需要作人似乎跟商务谈判不太有关系，很多技术人员相信任何华丽的外表来衬托自己的身份，他们有的是底气。PM 需要的是本事，是如何做好一个项目，而不是会搞好对 PM 来说， 这是个非常危险的挑战。虽然说项目在初关系弄的四平八稳的人。随着PM 在 中国的悄悄兴起，越来越多的 PM 开始在老总的授 意下参与商务谈判，和销售们一起打单子，这就比较实在的需要PM 们去揣摩客户的心理。揣摩客户心理需要有多方面的知识，需要深度和广

2、度，然而， 最重要的仍然是作人。如何放下架子，降低作人的姿态，对从技术人员转型的PM 们来说，是至关重要的。降低作人的姿态需要从多个方面去实施，最 主要应该记住：人不可貌相，更不可以地位衡量。 很多公司为了保持公司形象，会统一叫员工打扮的好看一点，看起来象个白领的样子。然而，老板多半是没有约束的。中国改革开放才二十年，很多有钱的老板实业家文化层次都不高，往往是当大学生们只会把屁股坐在板凳上肆意挥霍父母辛苦积攒的财富时，他们已经在各地奔波，积累丰富的商业经验并对金钱，人生和社会的本质有了充分的认识，形成了自己稳定的思维框架。这些人，很多都期有意向时会对对方的人事和关键人物有一定的了解，然而大项目

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

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

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

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

7、任的客户往往会觉得这种人不可靠，一般不会把单子交给他。PM 需要把握好这个度，吹是肯定要吹的，只是吹牛的时候一定要有基础的去吹，对从来没涉及过的领域或者根本不懂的东西轻易不要发表意见，挑选自己熟悉的方向合测的感觉，效果最好。4. 优秀的售前团队理的进行发挥，适当的留上一两手，给对方高深莫这个团队一般是由总经理发起并组建的，通常不指定要的一关。接不到单子，PM 将失去存在的意义。与销PMP ，对团队的成员如SALES ，PM ，SA ，售有所不同，PM 在该阶段的任务除了接单，还要尽可ENGINEER们的团队合作提出了比较高的要求。一般公司在接下一个单子进行到一定程度的时候，PM 往往会尴尬的发

8、现协议上销售代表们对客户的一些承诺是几乎做不到或者根本做不到的事情。这种情况非常多，销售的任务是拿下单子，我听到的销售们说的最多的就是"没能的搜集客户关键人物的资料并与对方各个阶层的负责人建立良好的客户关系，以便在项目实施时充分调动资源。二 . 启动阶段1. 项目的一些基本概念问题 "或者 "NO PROBL EM"，但是当我听到客户的要求项目三要素有多种版本，各不相同。实际操作中多和销售的回答时我总是心惊肉跳，很不自然。销售是非分为范围，成本与进度，其中最重要的莫过于范围。我常辛苦的，为了建立客户关系，尤其是空白的市场是很们把项目最终生成并提交给用户的

9、产品和文档统称为递不容易的，往往为了一个单子会牺牲非常多。在这种情交件。谈判的时候一定要确立递交件的标准和要求，也况 下，和销售进行协调自然而然的又落到了PM 的头就是范围。尽管商战的时候不可避免的客户会不断提高上。在销售和客户做承诺之前，PM 要主动的跟销售交标准和要求，而承诺的款项却不会有一分钱的增加。但流，提供粗略的总体设计框架和技术难关以及能考虑出是这个标准对每个公司来说都有一个底线，一旦超过了的工作量，而不是等出了问题再被动和销售在老板面前这个底线，那项目就肯定是亏的。除非是为了二期有利互相推委责任。在组建团队的时候，PM 要根据团队里每可图或者是为了搞好关系，否则范围超过底线的时候

10、情个人的素质和任务进行因人置宜的信息传递。优秀的售愿不做，再厉害的PM 在这种情况下也是无能为力。建前团队合作是接单的重要保障。在商务谈判的实际操作立范围需要的就是PM 的多年的实战经验，在大大小小中，存在着各式各样的问题，PM 的职责和要求绝非以的项目中用血泪换来的一些体会。在这个时候，很能体上几点所能描述详尽。根据环境，政策，人文，关系等现 PM 与技术人员的区别。成本就是客户答应付的款各方面的不同情况，PM 的不同成长经历，每个PM 最项，与我们的投入成本并不是一回事情。进度就不用多终都会建立自己对商务谈判的看法和经验。但是有一点描述了。可 以肯定，这是PM 成为 PM 的第一道关，也是

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

12、人的PM 由于人缘差，即使高层强压别的部门或团队配合，别人也会能拖就拖，延缓项目的进度和质量。有时候，这种内耗对项目和PM 来说是毁灭性的。对客户的积极反应也比较关键。一般来说PM 已经被项目里大大小小的事情搞的筋疲力尽，要PM 去主动要求客户配合是很吃力的事情。然而，这个时候，越是困难，越是觉得累，越是要去主动。客户往往也不是特别的积极，主动与客户联系沟通和测试能及早发现问题。从风险控 制的角度来说，问题发现的越早，风险越小，损失也就越小。积极的态度可以带动客户的积极性，在项目完工的时候，客户对你的感激往往是难以用语言描述的，这对以后接单或者做二期三期会打下良好的基础。因为在和别的新客户谈判

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

14、成本，规格，期限等重要特征并将其写入合同文本，同时准备内部的包括预算，衡量标准等文对快速开发和叠代开发来说，需求和实现往往是同档，建立项目的评估标准。接下来就是需求分析。由于步进行，开发速度快是一大优势。对有相同或类似模式专业的原因，我们这里仅讨论软件工程项目的需求分析的小项目来说采用快速开发或叠代开发是很合算的做（以下简称需求分析）。需求分析的主要参与人员有法，时下流行的极限编程就是针对这方面建立的思维模PM ，总体架构设计师，系统分析员，熟悉业务流程的客式。然而，大中型项目中有太多不一样的需求和模块。户。 PM 统领的团队这时候还不是真正的开发团队，我如果不是因为项目有差异，那么市场上就只

15、有产品而没们叫做前期团队。随着需求分析的逐步深入，新的团队有项目了。所以，大中型项目的需求要认真仔细的去成员不断加入，启动阶段结束的时候正式的团队将建做。我们要讨论一个问题，究竟应该在需求分析和总体立。对一个已经启动的项目来说，需求分析直接决定了设计上花费多少时间？我们熟悉的瀑布开发模式基本上项目的成功与失败。最初的需求体现在客户的工作说明分需求分析，总体设计，软件开发，测试等几个阶段，书或招标文件及附件上。这种需求一般比较含糊，无法然而究竟应该在前两个阶段上花多少时间却没有定论。体 现客户真正的需求。前期团队要根据自己的经验和客实际项目操作的例子表明，分析设计的时间越长，需求户沟通并引导客户

16、进入正轨。有时候客户会很不讲道理设计做的越详细，测试的时间就越短，返工率越低，或者思路僵化，就要求按照他的思维去定一些明显错误风险也越小，成本越容易得到控制。的需求。这个时候团队成员要耐心和客户举事实，谈经而需求分析和总体设计没有做好就急忙上马进行开发验，讲道理，用图形或模型等直观的方式将需求描述出的项目在项目初期进展顺利的时候问题不大，到了项目来，比如常见的数据流图等。所以说，争论再所难免，后期和测试阶段一些潜伏期比较长但是破坏作用比较大客户有时候会吹胡子瞪眼睛拍桌子甚至会说" 这个东西的问题就会凸显出来，造成返项目后期，不如把时间多不要你们做了" 之类的话。 PM 此时

17、除了要亲身参与需花点到需求分析和总体设计上。基础夯实了，金字塔就求分析综合整理文档之外，还要处理好团队成员与客户容易造了。在日本公司打工的程序员们可能都知道，小的关系，确保日本的软件规范非常厉害，他们花在需求分析和总体设关系不会恶化到无法收拾的地步。只要PM尽力约束团队中的成员，这个度还是很容易控制的。工，延长测试时间。所以与其把问题堆积到紧张的计上的时间通常在40% 到 50% 左右，远远超过国内软件项目的实施，效果也要强的多。他们总体设计的规范甚 至详尽到某个过程该如何判断，确立什么样的条件，换言之就是把什么时候该如何写(if.else) 语句 都帮程序员定好了。在这样的软件规范下，程序员

18、更象是装配流水线上的工人，对一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。所以在日本和欧美经常会有程序员是低级工作一说，很多人不明就里，对国内程序员也照搬，对国内的程序员来说是很不公平的。在国内，只会照抄别人代码，一点都不懂创新，凡事依靠别人，快下班就盯着表看的程序员是不少，这种人一般很难有什么前途。但是，优秀的不断进取的程序员也很多。由于国内没有象CMM 这样的软件规范或者很少，所以这类 优秀的程序员不少都是干着系统分析员甚至PM 的活，拿着程序员的工资。这类程序员虽然在起步时会吃很多亏，而且是主动找亏吃，然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为 P

19、M 进行商务谈判的时候，前者还在各个公司里频繁跳槽，跳来跳去都不满意。有些扯开了，回到我们的话题。日本的软件规范与CMM 有惊人的相似，其中至少有 35% 以上都是几乎一模一样的。最近经济不景气，的，还在不断增加。这些公司纷纷抢滩上海，招收技术人员。如果去这样的公司应聘就要考虑清楚了，进去可以学到他们的规范和质量控制，可是要想从程序员成为系统分析员或PM ，比登天还难。往往一个程序员进去干了好几年，对自己的那一块熟的不得了，而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4 ( 华为印度研究所已经通过CMM4 ) ，对在华为工作的程序员们来说可谓福祸难料。当然，已经作到PM 或 QA 或

20、者热爱 CODING 的朋友例外。需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为了确立一个初期的需求模型。所有的文档将会提交给PM 进行复审并签字，不合格的打回重做。反馈表随之将提交给客户，第二遍第三遍等等等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需求。当PM 最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。需要说明的是，客户并非都是蛮不讲理，但是说实话，颇有

21、无奈，国内目前的项目大多数客户为了不让自东京倒闭了160 家软件公司，这个数字是今年 6 月份己的钱白花，经常变着法子提需求。在启动阶段明确需求并签字，无论最终情况如何，一份详尽的书面文档可责，提供绩效管理方法，向成员提供项目范围和目标。以解决很多口头承诺或概念模糊的文档带来的许多问与客户的一个主要会议将是项目启动会议。在这个会议题。详尽的需求分析有一个额外的好处就是对一些双方上 PM 会与客户确立 正式的交流渠道，项目综合描述，都很陌生或者从来无人尝试的领域将是一个决定是否进让项目参与人员 相互了解，建立以 PM 为核心的管理制行项目的判断标 准。有时候，这种大项目在签单时双方度。还有一些零

22、零碎碎的东西甚至包括办公场地的大都没有绝对 把握保证可以出成果，一旦在需求分析阶段小，电话多少部，所有人的联系方式等等都要在会议上发现难 以逾越的技术难关，就会放弃项目。典型的例子确 立，并做会议记录。这都是些非常琐碎的事情，听起就 是 NMD 洲际导弹防御系统。上世纪八十年代初美国来婆婆 * ，却是非常必要，缺一不可。大概就是所谓搞星球大战计划，拖跨了苏联。大家对那段历史有些含三军未动，粮草先行吧。糊，很多人认为苏联人上了美国的当。其实并不完全如这时候，作为公司高层，应该向全公司发表申明，此，苏联人的情报机构无孔不入，并非那么容易上当受正式给PM 发布项目经理任命书和项目授权书。这个动骗。实

23、际上当时美国国防部已经开始着手NMD 系统软作虽然在别人看来有些形式主义，但是对提高 PM 本人件的需求分析，前后耗资数亿美圆，耗时两年，仅仅是的士气和责任感是有很大助力的。做需求分析，终于发现存在着在当时技术上无法达到的三 .计划阶段高度，随后项目被放弃。3. 项目启动项目启动要确定项目计划，与客户一起实施第一次项目审核，确认并对一些产品和服务向下包厂商下订单。这个时候的PM 会忽然发现有开不完的会，一天开三到四个会议是很正常的事情。这些会议有与客户的会议，与下包厂商的，有团队的，有公司高层的。团队的会议主要是建立正式的团队，提供团队成员的角色和职1. 定义结构分工结构图( WBS ) 一个

24、项目可能会有几个正确的WBS ，看 PM 的需启动阶段结束后，项目进入计划阶段，也就正式进PM 要召开团队进行讨论，向成员提供与项目相关的入实施。这里概念可能有些不太对头，其实是翻译的缘所有详细资料，并把 WBS 树分解到二层三层。然后要故，反正大家明白意思就行，不用拘泥于字面。 WBS 是花上一段时间让成员进行头脑风暴式( BRA INING一组要提交的项目元素，用来组织定义项目的总体范围，STORM ) 思考，制订工作产出和相应人员的职责，记录具体包括从工作内容，资源，成本角度考虑项目范围；建立一套系统所需要的分层工作结构；把项目分解成易于管理的几个细目，这概念有些模糊，其实跟资源管理器里

25、分每一个工作包的完成标准。在头脑风暴式思考时，会有很激烈的争论，PM 要协调关系，调节气氛，从自己能考虑到的各个角度旁推侧敲，提示成员的思维角度和方向目录是一回事情。可以说，WBS 是计划阶段的核心。并加以总结。尽管很麻烦，制订WBS 仍然是非常值得WBS 会详细的分到递交件，包括给自己人用的项目使用的。如同需求分析一样，WBS 准备的越充分，编码的进的过程文件，给客户用的模块和说明文档，完成每个细目度越快。的标准以及如何把这些细目的责任分配到具体的个人。2. 风险管理WBS 有缩进式和树状式，我这里也没办法画图，大家参既然是商业行为，那么项目的风险必然存在，相 信考一些项目管理的书籍，里面有

26、详细介绍。我整个文章只阅读这个帖子的朋友不少人都经历过或大或小的风险。有挑我觉得需要注意的地方，如非必要，对技术细节或者工些风险很容易解决，有些风险则大大损害利益。不论什么具使用不做详细介绍。WBS 的细目并不需要分解到同一样的风险，能避免尽量避免，所以有必要对风险进行管水平，最下面的细目叫做工作包，分包的依据是个人的责理。由于风险的不可预知性，风险管理难度很大，概念也任 和可信度，也就是说到每个人头上的任务是否能落很难讲清楚，只能从一些可行的角度去分析，进行管理。实，是否有把握完成；还有就是准备对项目进行控制的程首先要识别风险。这是个难度很高的活。PM 要先召度， 程度越深，WBS 树也就越

27、深。由于 WB S 是实用开风险识别会议，这个会议面向公司，高层，跨部门的性的东西，根据个人理解也不一样，所以有经验的人都将参加。然后审核由项目小组生成的风险清要和最适合当前团队状态的进行选择。单并与重要成员进行风险沟通，检查一些重要的风险源如WBS 的定义还是很麻烦的。WBS ，成本（时间）预估，人员计划，采购管理等等。最后就要用到PM 本身 在以前类似项目中得到的经验教训。识别之后要进行分析。我们可以进行粗略的量化分析（精确分析是不可能的事情）。有经验的人可以一起参加讨论，把提交出来的风险进行分类。首先按发生的可能性WBS ，修改日程计划和更新风险管理计划。 风险预留通常是成本的8% 。3

28、. 预估预估是从量化的角度对项目进行评估，主要包括工作量，任务期限，人力，设备，材料，成本等，要注意预估不是财务策略或报价。预估其实并不是一次性工作，在分，一般分成高，中，低三个级别，虽然很勉强，但是好整个项目过程中，预估始终需要。预估似乎没什么特别需歹也有个量化了；然后按耗去的成本分，也是高，中，低要提的地方，每个PM 接到 项目的时候自然会有预估，三级。我们可以把这两种类别的三个级别进行组合，碰到在项目发生变更或进入下一阶段时也会预估。预估的作用可能性也高，成本也高的风险就定位为不能接受。碰到这主要还是让PM 作到心中有个底，安排计划时不至于毫无种 风险只好让客户修改需求或者增加风险预留成

29、本，否头绪。则一旦亏起来不是亏一点点，有可能赔的很厉害。高和4. 进度计划中，中和中的搭配都是属于高风险，中和低，低和低搭配进度计划就是一个模块或功能要写多长时间，P M 安属于低，高和低搭配属于中。排个日期，设立里程碑，叫程序员们不能偷懒。进度计针对出现的可能性，需要采取一些手段降低风险。到划是从WBS 提取过来的。对PM 来说，合理的安排进目前为止也没有一个定论说有绝对好的方式，只能尽其所度计划对项目控制和激励团队士气有着很大的作用。对程能的避免。有几种方法可以考虑，第一种是将风险纳入项目管理计划并指定负责人，由外部人员定期检查项目风险，一旦风险发生，执行风险管理计划；第二种是保险，序员来

30、说，进度计划毫无疑问是噩梦。显示进度计划一般有先后顺序图，甘特图和里程碑图表。上回邵卫老师讲这种属于风险转课，推荐的工具是m$ 的 PROJECT , 这个工具我还不会嫁；第三种方式有点奸，不过最保险，就是把客户用，因为没时 间拖下水，让他们一起参与风险管理，呵呵，到时候就好说话去摸索。我的头倒是用的很溜了，近一个月来他就用这个了：） 风险管理作为项目计划之后，PROJECT 画了一个又一个的里程碑图，不停的折磨我和PM 需要更新同事的神经。我们一般都是一边开发一边做UNIT从后向前两种。从前向后的概念就是某项活动必须相同或TEST ，效果上来看，因为有强大的时间压力，效率上比晚于直接指向这项

31、活动的的所有活动的最早结束时间的最之前确实要提高不少，可是我们也只能结结巴巴的赶完进度。 由于 TEAM 里人 少，我们都是一个人做几个人的活。我每天早晨六点多出门，经过将近两小时颠簸，八点多点已经坐在位子上，中午吃15 分钟的饭，干到晚上八点下 班，到家吃完饭往往已经11 点了。一个多月我从来没吃过早饭，没有睡过六个小时以上的懒觉。虽然强大的压力使我们能在短时间内掌握尽可能多的技能，开发更多的模块，但是对我们的情绪也是有很大的影响。所以说， 项目里程碑是一把双刃剑，合理安排才能既促进效率也不至于打击士气。团队成员士气的逐级衰落会给项目后期的开发带来难以估计的影响，进度将会大大延缓。关于 PM

32、 和团 队的问题我们后面会讲到，这里我先祥林嫂一把， 然后跳过。 里程碑图表的特征是任务， 成员和时间， 任务和成员用文字标志，时间用数字描述并辅助以图线跨度，象阶梯一样非常形象，一目了然。管理 起来非常方便，完了的打个钩就可以了。网络逻辑图是表示任务和逻辑关系的示意图，可以用先后次序表示，也可以用关键路径表示。其实把各个活动划分为1，2 ， 3， 4 等阶段，每个阶段包括小活动1.1 ， 1.2 ， 2.1 ，2.2 ， 2.3 ， 2.4 ，3.1 ， 3.2 ， 3.3 ，晚时间。有些绕口，我们打个比方：2阶段指向 3阶段，那么2 阶段里的 4 个子阶段也都指向3 。假设 2.1结束时间

33、为 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 打的我累死了：）项目经常需要调整进度。在不改变项目范围的情况下，调整进度有几种方法：利用快速跟踪手段来改变任务间的关系；将串行的任务改成并行；改变工作方法（可能改变WB S ）; 改变日期限制，使关键路径上的任务开始或 结束的更早。虽然方法多样化，在我看来

34、只有一条，就是拼命 的压榨程序员的劳动力。如何压榨，还是个技巧。如前面所分析的，需求分析恨不得多分点时间给它，压需求是不太可能；测试阶段后期接近完工，罗里巴唆的事情一大堆，忙都忙不完，那时候PM 一门心思提前 /按时完工，好收钱，压那段时间似乎也不太可能。说来残酷，最能压的还是CODING ， 编码阶段往往是压缩重点，总4.1 ， 4.2 等，日程计划也分四种，一般只提到从前向后和之大家埋头苦干就是了，大项目压缩的时候程序员吃喝拉撒都在公司是很正常的事情，相信不少人都有很深的体核心算法始终没换过，可惜这小子跟了李洪痔，如今已经会，这里伤心事情也就不提了。只是我总结一下，让未来不知所踪了。但是他

35、的代码似乎也要有点注释的，没有注的 PM 们有压榨后来人的依据，呵呵。测试前期也可以释过段时间再天才的程序员也不能保证他是最有记忆力适当的压一压，那时候人刚完工，都比较懒散。国内一般的。而且，对一个项目的编码来说，靠一两个人打天下如企业规模都不大，没有专门的质量控制部门，所以质量保证和测试往往就是程序员或PM 本 身。其实质量保证和测试人员的人数和素质都应该要高于程序员。在日本和CMM 实施的公司里，编码压缩是很容易实现的事情，因为那些程序员真的是技能熟练的装配工人，压起来方便的很。他们这样培养人的目的或许就是为了压缩吧？！四.控制和执行阶段1. 软件开发实在没什么好说的，也是大家最不愿意谈的

36、，平 时在公司里谈的已经够多的了，还要在这里受我唠叨。需要提醒的依然是团队合作精神和完善的文档管理制度。SOURCESAFE这些工具有时候还是有必要使用的。经常看到有人说天才程序员不写注释什么的。我相信有这种天才程序员，因为我碰到过几个。我爱人公司里也有一个，他们的一套产品核心代码就是这个人写的，4 年过去了，周边代码换了好几茬，今是不可能了。别人的公司都是团队，两人智慧胜一人，这头还在靠一个天才支撑门面，实际上市场可就别人抢了去，那时候再天才也没用了。编码的时候讲究技术公开，程序员不要藏着掖着，对大家没好处，PM 要想办法调动大家创新思维的积极性，营造良好的技术讨论氛围，碰到技术难关的时候就

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

38、握一门陌生工具的能力。只有建立了这样的思维， 才有可能转为工人，最 多就是个技术总监。PM，否则一辈子都是技术这种情况非常难办。一般这种情况都是到了项目后 期，做重大的更改几乎是不可能的事情，如果白做 就要亏钱。而2. 变更这个时候如果PM跟对方高层的人关系搞的定，可以透对任何项目，变更无可避免，无从逃避，只能去积过对方高层把事情压住。然而由于已经到后期，客户代表极应对，这个应对应该是从需求分析就开始了。对一个需不会轻易更换，对方这次没有改成，必然心怀不满，下回求分析做的很好的项目来说，基准文件定义的范围越详细在别的模块依然会找麻烦或者在谈二期的时候动动手脚，清晰，用户跟PM 扯皮的幌子就越少

39、。而需求没做好，都是很让P M 伤脑筋的事情，这方面目前还没有什么好基准文件里的范围含糊不清，被客户抓住空子搞你一下是的解决方法，所以尽可能的做好需求比什么都重要。相对非常头疼的事情，往往要付出无谓的牺牲，有时候甚至非需求来说，什么WBS ，风险管理，计划进度都是扯淡，常火大。需求做的好，文档清晰又有客户签字，那么后期需求做好了，一帆风顺。还有一种办法就是装可怜，要装客户提出的变更就超出了合同的范围，需要另外收费。这的非常的象，在对方的领导面前装，而且不能让人看出是个 时候千万不能手软，并非要刻意赚取客户的钱财，而装的样子，要让你自己都觉得你自己是真的可怜，那么就是不能养成客户经常变更的习惯，

40、否则后患无穷，维护的算这次客户硬是要求改了，下回他也必然不好意思再叫你成本会让PM 吃不消。改。其实人心都是肉长的，如果可能的话，我还是不赞同在客户提出变更请求时，要建立变更申请登记表和使用一些手段的，但是有时候客户非常难以在短时间打动变更申请表，并让客户签字。当然，有时候一些不是非常而 工期又将接近，这种情况下就要靠PM 耍一些手段关键的模块PM 也不至于一点不讲情面，该卖面子的时了。各人有各人的方式，八仙过海，各显神通吧。候还是要卖，尤其是当着对方领导的面，千万要卖面子，PM 在变更管理中需要做的是分析变更请求，评估 变更但是也别卖的太干脆，不要让他们得到的太容易。需求做可能带来的风险和修改基准文件。的不好，客户抓住漏洞或者非常不讲道理，麻烦就大了。3.质量控制有时候争论会很厉害，到非常白热化的地步，PM 与客大公司有质量管理部门（QA），QA 的成员基本上户代表几乎沟通不了。PM 在客户关系和短期利益两方都是由非常有经验的PM 转型过来的老狐狸，是老总接面难以取舍，一般都是