项目策划管理的几大过程

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.优秀的售前团队 那个团队一般是由总经理发起并组建的，通常不指定PMP，对团队的成员如SALES，PM，SA，ENGINEER们的团队合作提出了比较高的要求。一般公司在接下一个单子进行到一定程度的时候，PM往往会尴尬的发觉协议上销售代表们对客户的一些承诺是几乎做不到或者全然做不到的情况。这种情况特不多，销售的任务是拿下单子，我听到的销

8、售们讲的最多的确实是没问题或者NOPROBLEM，然而当我听到客户的要求和销售的回答时我总是胆战心惊，专门不自然。销售是特不辛苦的，为了建立客户关系，尤其是空白的市场是专门不容易的，往往为了一个单子会牺牲特不多。在这种情况下，和销售进行协调自然而然的又落到了PM的头上。在销售和客户做承诺之前，PM要主动的跟销售交流，提供粗略的总体设计框架和技术难关以及能考虑出的工作量，而不是等出了问题再被动和销售在老总面前互相推委责任。在组建团队的时候，PM要依照团队里每个人的素养和任务进行因人置宜的信息传递。优秀的售前团队合作是接单的重要保障。在商务谈判的实际操作中，存在着各式各样的问题，PM的职责和要求绝

9、非以上几点所能描述详尽。依照环境，政策，人文，关系等各方面的不同情况，PM的不同成长经历，每个PM最终都会建立自己对商务谈判的看法和经验。然而有一点能够确信，这是PM成为PM的第一道关，也是最重要的一关。接不到单子，PM将失去存在的意义。与销售有所不同，PM在该时期的任务除了接单，还要尽可能的搜集客户关键人物的资料并与对方各个阶层的负责人建立良好的客户关系，以便在项目实施时充分调动资源。 二.启动时期 1.项目的一些差不多概念 项目三要素有多种版本，各不相同。实际操作中多分为范围，成本与进度，其中最重要的莫过于范围。我们把项目最终生成并提交给用户的产品和文档统称为递交件。谈判的时候一定要确立递

10、交件的标准和要求，也确实是范围。尽管商战的时候不可幸免的客户会不断提高标准和要求，而承诺的款项却可不能有一分钞票的增加。然而那个标准对每个公司来讲都有一个底线，一旦超过了那个底线，那项目就确信是亏的。除非是为了二期有利可图或者是为了搞好关系，否则范围超过底线的时候情愿不做，再厉害的PM在这种情况下也是无能为力。建立范围需要的确实是PM的多年的实战经验，在大大小小的项目中用血泪换来的一些体会。在那个时候，专门能体现PM与技术人员的区不。成本确实是客户承诺付的款项，与我们的投入成本并不是一回情况。进度就不用多描述了。 项目如何成功？也有一些关键的因素。个人的理解也不尽相同，通常包括以下几个方面：界

11、定工作目标及工作任务；老总或高层的支持；优秀的PM和开发团队；充足的资源；良好的沟通；对客户的积极反应以及适当的监控和反馈。那个地点要注意的确实是资源和高层的支持。一个上规模的公司总是同时会有专门多项目，但是再大规模的公司资源也不足以保证每个项目都能组建最合适的开发队伍或拥有最好的环境。这时候各个团队或者部门之间不可幸免的会发生资源争夺战，摩擦再所难免。这时候对PM的作人再次提出挑战。除了高层对PM项目的重视程度，假如PM平常在公司与同事相处的好往往能使专门多不人看起来专门棘手的问题迎刃而解。相反，一个可不能作人的PM由于人缘差，即使高层强压不的部门或团队配合，不人也会能拖就拖，延缓项目的进度

12、和质量。有时候，这种内耗对项目和PM来讲是毁灭性的。对客户的积极反应也比较关键。一般来讲PM差不多被项目里大大小小的情况搞的力倦神疲，要PM去主动要求客户配合是专门吃力的情况。然而，那个时候，越是困难，越是觉得累，越是要去主动。客户往往也不是特不的积极，主动与客户联系沟通和测试能及早发觉问题。从风险操纵的角度来讲，问题发觉的越早，风险越小，损失也就越小。积极的态度能够带动客户的积极性，在项目完工的时候，客户对你的感激往往是难以用语言描述的，这对以后接单或者做二期三期会打下良好的基础。因为在和不的新客户谈判的时候，新客户自然会找你的老客户了解情况，这时老客户随意的一句话顶的上你专门费心的十句。

13、项目具有商业行为的几个重要特征，有消费源，有参与者，有成功关键因素，有财务目标，有风险。 2.启动时期的要紧任务 依照PMI的解释，接单之后项目自然转入启动时期。启动时期PM的要紧任务是率领总体架构设计师和系统分析员收集尽可能详细的数据，确立尽可能详细的需求，进一步确立详细的项目范围，预估资源，确立其他方案并获得进入下一时期的批准。在那个时期，随着需求分析的深入，PM也开始在公司内部进行人员选择和资源争夺，着手组建自己的项目团队。项目立即进入打算时期。 在收集完数据之后，PM要和客户开始明确项目的大小，成本，规格，期限等重要特征并将其写入合同文本，同时预备内部的包括预算，衡量标准等文档，建立项

14、目的评估标准。接下来确实是需求分析。由于专业的缘故，我们那个地点仅讨论软件工程项目的需求分析（以下简称需求分析）。需求分析的要紧参与人员有PM，总体架构设计师，系统分析员，熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队，我们叫做前期团队。随着需求分析的逐步深入，新的团队成员不断加入，启动时期结束的时候正式的团队将建立。对一个差不多启动的项目来讲，需求分析直接决定了项目的成功与失败。最初的需求体现在客户的工作讲明书或招标文件及附件上。这种需求一般比较模糊，无法体现客户真正的需求。前期团队要依照自己的经验和客户沟通并引导客户进入正轨。有时候客户会专门不讲道理或者思路僵化，就要求按照他

15、的思维去定一些明显错误的需求。那个时候团队成员要耐心和客户举事实，谈经验，讲道理，用图形或模型等直观的方式将需求描述出来，比如常见的数据流图等。因此讲，争论再所难免，客户有时候会吹胡子瞪眼睛拍桌子甚至会讲那个东西不要你们做了之类的话。PM现在除了要亲身参与需求分析综合整理文档之外，还要处理好团队成员与客户的关系，确保关系可不能恶化到无法收拾的地步。只要PM尽力约束团队中的成员，那个度依旧专门容易操纵的。 对快速开发和叠代开发来讲，需求和实现往往是同步进行，开发速度快是一大优势。对有相同或类似模式的小项目来讲采纳快速开发或叠代开发是专门合算的做法，时下流行的极限编程确实是针对这方面建立的思维模式

16、。然而，大中型项目中有太多不一样的需求和模块。假如不是因为项目有差异，那么市场上就只有产品而没有项目了。因此，大中型项目的需求要认真认确实去做。我们要讨论一个问题，究竟应该在需求分析和总体设计上花费多少时刻？我们熟悉的瀑布开发模式差不多上分需求分析，总体设计，软件开发，测试等几个时期，然而究竟应该在前两个时期上花多少时刻却没有定论。实际项目操作的例子表明，分析设计的时刻越长，需求设计做的越详细，测试的时刻就越短，返工率越低，风险也越小，成本越容易得到操纵。 而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展顺利的时候问题不大，到了项目后期和测试时期一些埋伏期比较长然而破坏作用比

17、较大的问题就会凸显出来，造成返工，延长测试时刻。因此与其把问题堆积到紧张的项目后期，不如把时刻多花点到需求分析和总体设计上。基础夯实了，金字塔就容易造了。在日本公司打工的程序员们可能都明白，小日本的软件规范特不厉害，他们花在需求分析和总体设计上的时刻通常在40%到50%左右，远远超过国内软件项目的实施，效果也要强的多。他们总体设计的规范甚至详尽到某个过程该如何推断，确立什么样的条件，换言之确实是把什么时候该如何写(if.else)语句都帮程序员定好了。在如此的软件规范下，程序员更象是装配流水线上的工人，对一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。因此在日本和欧美经常会有程序员是低级

18、工作一讲，专门多人不明就里，对国内程序员也照搬，对国内的程序员来讲是专门不公平的。在国内，只会照抄不人代码，一点都不明白创新，凡事依靠不人，快下班就盯着表看的程序员是许多，这种人一般专门难有什么前途。然而，优秀的不断进取的程序员也专门多。由于国内没有象CMM如此的软件规范或者专门少，因此这类优秀的程序员许多差不多上干着系统分析员甚至PM的活，拿着程序员的工资。这类程序员尽管在起步时会吃专门多亏，而且是主动找亏吃，然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候，前者还在各个公司里频繁跳槽，跳来跳去都不中意。有些扯开了，回到我们的话题。 日本的软件

19、规范与CMM有惊人的相似，其中至少有35%以上差不多上几乎一模一样的。最近经济不景气，东京倒闭了160家软件公司，那个数字是今年6月份的，还在不断增加。这些公司纷纷抢滩上海，招收技术人员。假如去如此的公司应聘就要考虑清晰了，到里面去能够学到他们的规范和质量操纵，但是要想从程序员成为系统分析员或PM，比登天还难。往往一个程序员到里面去干了好几年，对自己的那一块熟的不得了，而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4（华为印度研究所差不多通过CMM4），对在华为工作的程序员们来讲可谓福祸难料。因此，差不多作到PM或QA或者热爱CODING的朋友例外。需求分析本身也存在着时刻分配的问题。

20、第一遍需求分析花的时刻会最长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水讲干，确实是为了确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字，不合格的打回重做。反馈表随之将提交给客户，第二遍第三遍等等等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需求。当PM最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在今后项目变更或者碰到重大问题时和客户扯皮的重要依据。 需要讲明的是，客户并非差不多上蛮不讲理，然而讲实话，颇有无奈，国内目前的项目大多数客户为了不让自己的钞票白花，经常变着法子

21、提需求。在启动时期明确需求并签字，不管最终情况如何，一份详尽的书面文档能够解决专门多口头承诺或概念模糊的文档带来的许多问题。详尽的需求分析有一个额外的好处确实是对一些双方都专门陌生或者从来无人尝试的领域将是一个决定是否进行项目的推断标准。有时候，这种大项目在签单时双方都没有绝对把握保证能够出成果，一旦在需求分析时期发觉难以逾越的技术难关，就会放弃项目。典型的例子确实是NMD洲际导弹防备系统。上世纪八十年代初美国搞星球大战打算，拖跨了苏联。大伙儿对那段历史有些模糊，专门多人认为苏联人上了美国的当。事实上并不完全如此，苏联人的情报机构无孔不入，并非那么容易上当受骗。实际上当时美国国防部差不多开始着

22、手NMD系统软件的需求分析，前后耗资数亿美圆，耗时两年，仅仅是做需求分析，终于发觉存在着在当时技术上无法达到的高度，随后项目被放弃。 3.项目启动 项目启动要确定项目打算，与客户一起实施第一次项目审核，确认并对一些产品和服务向下包厂商下订单。那个时候的PM会突然发觉有开不完的会，一天开三到四个会议是专门正常的情况。这些会议有与客户的会议，与下包厂商的，有团队的，有公司高层的。团队的会议要紧是建立正式的团队，提供团队成员的角色和职责，提供绩效治理方法，向成员提供项目范围和目标。与客户的一个要紧会议将是项目启动会议。在那个会议上PM会与客户确立正式的交流渠道，项目综合描述，让项目参与人员相互了解，

23、建立以PM为核心的治理制度。还有一些零零碎碎的东西甚至包括办公场地的大小，电话多少部，所有人的联系方式等等都要在会议上确立，并做会议记录。这差不多上些特不琐碎的情况，听起来婆婆*，却是特不必要，缺一不可。大概确实是所谓三军未动，粮草先行吧。 这时候，作为公司高层，应该向全公司发表申明，正式给PM公布项目经理任命书和项目授权书。那个动作尽管在不人看来有些形式主义，然而对提高PM本人的士气和责任感是有专门大助力的。 三.打算时期 1.定义结构分工结构图（WBS） 启动时期结束后，项目进入打算时期，也就正式进入实施。那个地点概念可能有些不太对头，事实上是翻译的缘故，反正大伙儿明白意思就行，不用拘泥于

24、字面。WBS是一组要提交的项目元素，用来组织定义项目的总体范围，具体包括从工作内容，资源，成本角度考虑项目范围；建立一套系统所需要的分层工作结构；把项目分解成易于治理的几个细目，这概念有些模糊，事实上跟资源治理器里分目录是一回情况。能够讲，WBS是打算时期的核心。WBS会详细的分到递交件，包括给自己人用的项目使用的过程文件，给客户用的模块和讲明文档，完成每个细目的标准以及如何把这些细目的责任分配到具体的个人。WBS有缩进式和树状式，我那个地点也没方法画图，大伙儿参考一些项目治理的书籍，里面有详细介绍。我整个文章只挑我觉得需要注意的地点，如非必要，对技术细节或者工具使用不做详细介绍。WBS的细目

25、并不需要分解到同一水平，最下面的细目叫做工作包，分包的依据是个人的责任和可信度，也确实是讲到每个人头上的任务是否能落实，是否有把握完成；还有确实是预备对项目进行操纵的程度，程度越深，WBS树也就越深。由于WBS是有用性的东西，依照个人理解也不一样，因此一个项目可能会有几个正确的WBS，看PM的需要和最适合当前团队状态的进行选择。 WBS的定义依旧专门苦恼的。 PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时刻让成员进行头脑风暴式（BRAININGSTORM）考虑，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。在头脑风暴式考虑时

26、，会有专门激烈的争论，PM要协调关系，调节气氛，从自己能考虑到的各个角度旁推侧敲，提示成员的思维角度和方向并加以总结。尽管专门苦恼，制订WBS仍然是特不值得的。如同需求分析一样，WBS预备的越充分，编码的进度越快。 2.风险治理 既然是商业行为，那么项目的风险必定存在，相信阅读那个帖子的朋友许多人都经历过或大或小的风险。有些风险专门容易解决，有些风险则大大损害利益。不论什么样的风险，能幸免尽量幸免，因此有必要对风险进行治理。由于风险的不可预知性，风险治理难度专门大，概念也专门难讲清晰，只能从一些可行的角度去分析，进行治理。 首先要识不风险。这是个难度专门高的活。PM要先召开风险识不会议，那个会

27、议面向公司，高层，跨部门的有经验的人都将参加。然后审核由项目小组生成的风险清单并与重要成员进行风险沟通，检查一些重要的风险源如WBS，成本（时刻）预估，人员打算，采购治理等等。最后就要用到PM本身在往常类似项目中得到的经验教训。 识不之后要进行分析。我们能够进行粗略的量化分析（精确分析是不可能的情况）。有经验的人能够一起参加讨论，把提交出来的风险进行分类。首先按发生的可能性分，一般分成高，中，低三个级不，尽管专门牵强，然而好歹也有个量化了；然后按耗去的成本分，也是高，中，低三级。我们能够把这两种类不的三个级不进行组合，碰到可能性也高，成本也高的风险就定位为不能同意。碰到这种风险只好让客户修改需

28、求或者增加风险预留成本，否则一旦亏起来不是亏一点点，有可能赔的专门厉害。高和中，中和中的搭配差不多上属于高风险，中和低，低和低搭配属于低，高和低搭配属于中。 针对出现的可能性，需要采取一些手段降低风险。到目前为止也没有一个定论讲有绝对好的方式，只能尽其所能的幸免。有几种方法能够考虑，第一种是将风险纳入项目治理打算并指定负责人，由外部人员定期检查项目风险，一旦风险发生，执行风险治理打算；第二种是保险，这种属于风险转嫁；第三种方式有点奸，只是最保险，确实是把客户拖下水，让他们一起参与风险治理，呵呵，到时候就好讲话了：）风险治理作为项目打算之后，PM需要更新WBS，修改日程打算和更新风险治理打算。风

29、险预留通常是成本的8%。 3.预估 预估是从量化的角度对项目进行评估，要紧包括工作量，任务期限，人力，设备，材料，成本等，要注意预估不是财务策略或报价。预估事实上并不是一次性工作，在整个项目过程中，预估始终需要。预估大概没什么特不需要提的地点，每个PM接到项目的时候自然会有预估，在项目发生变更或进入下一时期时也会预估。预估的作用要紧依旧让PM作到心中有个底，安排打算时不至于毫无头绪。 4.进度打算 进度打算确实是一个模块或功能要写多长时刻，PM安排个日期，设立里程碑，叫程序员们不能偷懒。进度打算是从WBS提取过来的。对PM来讲，合理的安排进度打算对项目操纵和激励团队士气有着专门大的作用。对程序

30、员来讲，进度打算毫无疑问是噩梦。显示进度打算一般有先后顺序图，甘特图和里程碑图表。上回邵卫老师讲课，推举的工具是m$的PROJECT，那个工具我还可不能用，因为没时刻去摸索。我的头倒是用的专门溜了，近一个月来他就用那个PROJECT画了一个又一个的里程碑图，不停的折磨我和同事的神经。我们一般差不多上一边开发一边做UNITTEST，效果上来看，因为有强大的时刻压力，效率上比之前确实要提高许多，但是我们也只能结结巴巴的赶完进度。由于TEAM里人少，我们差不多上一个人做几个人的活。我每天早晨六点多出门，通过将近两小时颠簸，八点多点差不多坐在位子上，中午吃15分钟的饭，干到晚上八点下班，到家吃完饭往往

31、差不多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，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

33、个子时期3.1，3.2，3.3的最早开始时刻都不能早于1月22日。至于从后向前的例子大伙儿自己去推吧，我就不举了，刚才几个123打的我累死了：）项目经常需要调整进度。在不改变项目范围的情况下，调整进度有几种方法：利用快速跟踪手段来改变任务间的关系；将串行的任务改成并行；改变工作方法（可能改变WBS）；改变日期限制，使关键路径上的任务开始或结束的更早。 尽管方法多样化，在我看来只有一条，确实是舍命的压榨程序员的劳动力。如何压榨，依旧个技巧。如前面所分析的，需求分析恨不得多分点时刻给它，压需求是不太可能；测试时期后期接近完工，罗里巴唆的情况一大堆，忙都忙不完，那时候PM一门心思提早/按时完工，好收

34、钞票，压那段时刻大概也不太可能。讲来残酷，最能压的依旧CODING，编码时期往往是压缩重点，总之大伙儿埋头苦干确实是了，大项目压缩的时候程序员吃喝拉撒都在公司是专门正常的情况，相信许多人都有专门深的体会，那个地点难过情况也就不提了。只是我总结一下，让以后的PM们有压榨后来人的依据，呵呵。测试前期也能够适当的压一压，那时候人刚完工，都比较懒散。国内一般企业规模都不大，没有专门的质量操纵部门，因此质量保证和测试往往确实是程序员或PM本身。事实上质量保证和测试人员的人数和素养都应该要高于程序员。在日本和CMM实施的公司里，编码压缩是专门容易实现的情况，因为那些程序员确实是技能熟练的装配工人，压起来方

35、便的专门。他们如此培养人的目的或许确实是为了压缩吧？！ 四.操纵和执行时期 1.软件开发 实在没什么好讲的，也是大伙儿最不情愿谈的，平常在公司里谈的差不多够多的了，还要在那个地点受我唠叨。需要提醒的依旧是团队合作精神和完善的文档治理制度。SOURCESAFE这些工具有时候依旧有必要使用的。经常看到有人讲天才程序员不写注释什么的。我相信有这种天才程序员，因为我碰到过几个。 我爱人公司里也有一个，他们的一套产品核心代码确实是那个人写的，4年过去了，周边代码换了好几茬，核心算法始终没换过，惋惜这小子跟了李洪痔，现在差不多不知所踪了。然而他的代码大概也要有点注释的，没有注释过段时刻再天才的程序员也不能

36、保证他是最有经历力的。而且，对一个项目的编码来讲，靠一两个人打天下现在是不可能了。不人的公司差不多上团队，两人智慧胜一人，这头还在靠一个天才支撑门面，实际上市场可就不人抢了去，那时候再天才也没用了。 编码的时候讲究技术公开，程序员不要藏着掖着，对大伙儿没好处，PM要想方法调动大伙儿创新思维的积极性，营造良好的技术讨论氛围，碰到技术难关的时候就容易攻破了。有个问题需要单独对还没有PM觉悟的程序员讲，事实上是在调研的时候就定了的，确实是使用什么样的开发工具。没有经验的程序员往往会拿着C+或者JAVA的资格证书或者拥有一两个开发工具的一些经验而得意洋洋。事实上老总和PM全然不看重那个，他们关怀的是使

37、用什么样的工具能尽快的达到目的。管你什么C+，DELPHI，PB依旧JAVA，只要能做的出来，VFP都能够用。我举那个例子并非讲不看中工具，而是提醒想转型为PM的程序员，第一要把工具当作工具，而不要被工具套到里面去，钻研一些一辈子都用不上的技术；第二要掌握的并非是单独的一个工具，而是流行的程序设计的思想，以及在最短时刻内掌握一门陌生工具的能力。只有建立了如此的思维，才有可能转为PM，否则一辈子差不多上技术工人，最多确实是个技术总监。 2.变更 对任何项目，变更无可幸免，无从躲避，只能去积极应对，那个应对应该是从需求分析就开始了。对一个需求分析做的专门好的项目来讲，基准文件定义的范围越详细清晰，

38、用户跟PM扯皮的幌子就越少。而需求没做好，基准文件里的范围模糊不清，被客户抓住空子搞你一下是特不头疼的情况，往往要付出无谓的牺牲，有时候甚至特不火大。需求做的好，文档清晰又有客户签字，那么后期客户提出的变更就超出了合同的范围，需要另外收费。那个时候千万不能手软，并非要刻意赚取客户的钞票财，而是不能养成客户经常变更的适应，否则后患无穷，维护的成本会让PM吃不消。 在客户提出变更请求时，要建立变更申请登记表和变更申请表，并让客户签字。因此，有时候一些不是特不关键的模块PM也不至于一点不讲情面，该卖面子的时候依旧要卖，尤其是当着对方领导的面，千万要卖面子，然而也不卖的太干脆，不要让他们得到的太容易。

39、需求做的不行，客户抓住漏洞或者特不不讲道理，苦恼就大了。有时候争论会专门厉害，到特不白热化的地步，PM与客户代表几乎沟通不了。PM在客户关系和短期利益两方面难以取舍，一般差不多上向客户妥协，最终形成恶性循环。这种情况特不难办。一般这种情况差不多上到了项目后期，做重大的更改几乎是不可能的情况，假如白做就要亏钞票。而那个时候假如PM跟对方高层的人关系搞的定，能够透过对方高层把情况压住。然而由于差不多到后期，客户代表可不能轻易更换，对方这次没有改成，必定心怀不满，下回在不的模块依旧会找苦恼或者在谈二期的时候动动手脚，差不多上专门让PM伤脑筋的情况，这方面目前还没有什么好的解决方法，因此尽可能的做好需

40、求比什么都重要。相对需求来讲，什么WBS，风险治理，打算进度差不多上扯淡，需求做好了，一帆风顺。还有一种方法确实是装悲伤，要装的特不的象，在对方的领导面前装，而且不能让人看出是装的模样，要让你自己都觉得你自己是确实悲伤，那么就算这次客户硬是要求改了，下回他也必定不行意思再叫你改。事实上人心差不多上肉长的，假如可能的话，我依旧不赞同使用一些手段的，然而有时候客户特不难以在短时刻打动而工期又将接近，这种情况下就要靠PM耍一些手段了。各人有各人的方式，八仙过海，各显神通吧。PM在变更治理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。 3.质量操纵 大公司有质量治理部门（QA），QA的成员差不多上差不多上由特不有经验的PM转型过来的老狐狸，是老总