项目管理的几大过程文档格式.docx

项目管理的几大过程文档格式.docx

《项目管理的几大过程文档格式.docx》由会员分享，可在线阅读，更多相关《项目管理的几大过程文档格式.docx（10页珍藏版）》请在冰豆网上搜索。

这些人，很多都是穿着旧旧的衣服，戴着破破的手表，说话的时候经常会带上三字经，钻进上海的人堆里，搞不好你会把他当成民工。

因为到他们所处的社会地位，已经不需要任何华丽的外表来衬托自己的身份，他们有的是底气。

对PM来说，这是个非常危险的挑战。

虽然说项目在初期有意向时会对对方的人事和关键人物有一定的了解，然而大项目里能说的上话的人太多了。

上海人最瞧不起的就是土气，很多人谈项目的时候看到民工或很俗气的表现不免会皱皱眉头，往往在皱眉头的时候就失去了项目，也就是失去了市场和金钱。

PM必须作到能与每一个层次的人交谈，尤其是看起来比自己层次要低的群体，哪怕是公司里扫地的阿姨。

只有作到谦虚谨慎，不摆架子，尊重别人，才会得到别人的尊重，才有机会赢得项目。

鼻子比眼睛高的人只会把自己的鼻子撞扁。

2.丰富的知识面 

光尊重别人还不足以赢得项目，准确的说是赢得对方关键人物的信赖。

PM一般用不着陪客户喝酒吃饭，那是销售们的事情，但是PM和客户讨论问题可能是最多的。

讨论问题的时候就是机会，如何投其所好，是一大关键。

金钱与美女依然是常规的敲门砖，然而这种傻瓜也知道的办法人人都会去做。

老板的关系也只是一个方面，如今的大老板，哪个没有关系？

同等条件下PM凭什么去胜过别人一筹？

我一个朋友（PM）打一个单子时，发现对方对什么都不太感兴趣，费了很大力气也找不到突破口。

对方这个人非常顺利，金钱地位美女样样不缺。

他花了好多天和对方交谈，以自己的博学逐渐取得了对方的信任。

后来他隐约发现对方对数学和天文学的发展史有所涉猎，如获至宝，回家花一个通宵的时间在网络上搜索相关资料。

第二天他根本不谈项目的事情，只跟对方大谈特谈哥白尼，布鲁诺，伽利略这些人的生平，整整吹了一天。

对方点头如捣蒜泥，态度和热情都来个一百八十度转弯，隔天他就拿到了单子。

这是个经典的战例，谁能事先想到哥白尼会来帮助IT的人赚钱？

这个PM靠的就是博学和由博学引申出的敏锐的感觉抓住了机会，让客户产生共鸣。

客户感觉他层次也很高，而且和自己有共通之处，信任度大大增强，把项目交给他放心。

如今这种例子在商务谈判中已经屡见不鲜了。

对PM来说，并不要求在各个方面都很精通，那是不可能的事情，只要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%左右，远远超过国内软件项目的实施，效果也要强的多。

他们总体设计的规范甚至详尽到某个过程该如何判断，确立什么样的条件，换言之就是把什么时候该如何写（i