《140项目管理的几大过程.doc》由会员分享，可在线阅读，更多相关《140项目管理的几大过程.doc（23页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、140项目管理的几大过程项目管理的几大过程 一.商务谈判 1.作人的姿态 作人似乎跟商务谈判不太有关系很多技术人员相信PM需要的是本事是如何做好一个项目而不是会搞好关系弄的四平八稳的人。随着PM在中国的悄悄兴起越来越多的PM开始在老总的授意下参与商务谈判和销售们一起打单子这就比较实在的需要PM们去揣摩客户的心理。揣摩客户心理需要有多方面的知识需要深度和广度然而最重要的仍然是作人。如何放下架子降低作人的姿态对从技术人员转型的PM们来说是至关重要的。降低作人的姿态需要从多个方面去实施最主要应该记住：人不可貌相更不可以地位衡量。很多公司为了保持公司形象会统一叫员工打扮的好看一点看起来象个白领的样子。
2、然而老板多半是没有约束的。中国改革开放才二十年很多有钱的老板实业家文化层次都不高往往是当大学生们只会把屁股坐在板凳上肆意挥霍父母辛苦积攒的财富时他们已经在各地奔波积累丰富的商业经验并对金钱人生和社会的本质有了充分的认识形成了自己稳定的思维框架。这些人很多都是穿着旧旧的衣服戴着破破的手表说话的时候经常会带上三字经钻进上海的人堆里搞不好你会把他当成民工。因为到他们所处的社会地位已经不需要任何华丽的外表来衬托自己的身份他们有的是底气。对PM来说这是个非常危险的挑战。虽然说项目在初期有意向时会对对方的人事和关键人物有一定的了解然而大项目里能说的上话的人太多了。上海人最瞧不起的就是土气很多人谈项目的时候
3、看到民工或很俗气的表现不免会皱皱眉头往往在皱眉头的时候就失去了项目也就是失去了市场和金钱。PM必须作到能与每一个层次的人交谈尤其是看起来比自己层次要低的群体哪怕是公司里扫地的阿姨。只有作到谦虚谨慎不摆架子尊重别人才会得到别人的尊重才有机会赢得项目。鼻子比眼睛高的人只会把自己的鼻子撞扁。 2.丰富的知识面 光尊重别人还不足以赢得项目准确的说是赢得对方关键人物的信赖。PM一般用不着陪客户喝酒吃饭那是销售们的事情但是PM和客户讨论问题可能是最多的。讨论问题的时候就是机会如何投其所好是一大关键。金钱与美女依然是常规的敲门砖然而这种傻瓜也知道的办法人人都会去做。老板的关系也只是一个方面如今的大老板哪个没
4、有关系？同等条件下PM凭什么去胜过别人一筹？我一个朋友（PM）打一个单子时发现对方对什么都不太感兴趣费了很大力气也找不到突破口。对方这个人非常顺利金钱地位美女样样不缺。他花了好多天和对方交谈以自己的博学逐渐取得了对方的信任。后来他隐约发现对方对数学和天文学的发展史有所涉猎如获至宝回家花一个通宵的时间在网络上搜索相关资料。第二天他根本不谈项目的事情只跟对方大谈特谈哥白尼布鲁诺伽利略这些人的生平整整吹了一天。对方点头如捣蒜泥态度和热情都来个一百八十度转弯隔天他就拿到了单子。这是个经典的战例谁能事先想到哥白尼会来帮助IT的人赚钱？这个PM靠的就是博学和由博学引申出的敏锐的感觉抓住了机会让客户产生共鸣
5、。客户感觉他层次也很高而且和自己有共通之处信任度大大增强把项目交给他放心。如今这种例子在商务谈判中已经屡见不鲜了。对PM来说并不要求在各个方面都很精通那是不可能的事情只要PM对一些流行的话题和天文地理历史各方面的知识有个大概的了解在需要的时候能尽快的掌握才有机会创造机遇和把握机遇。 3.强大的沟通能力 胸中有万千墨水却不知如何表达其实是比较少见的但并非绝对没有。每个人的人生轨迹都有所不同思维受环境的影响也各有差异。包括象我们目前这个班级里的一些未来的MSE们一定有比较内向或者不太爱表达自己观点的人这些人比较被动往往很难承担起谈判的重任。从今天开始这类人就必须重新学习如何说话如何大声的争论。沟通
6、并不仅仅是大声说话而是在表达自己观点的同时发现问题并综合整理加以解决。除此之外沟通的能力与社会经验息息相关与PM的见识联系紧密。在日常生活中PM就要多留心多思考当别人想到某个层次的时候要争取比别人考虑的更深。当然也有一些不够踏实的朋友把沟通和吹牛当成了完全的一回事情在和客户交流的时候口若悬河的说一些不着边际的话。这种人碰到不懂不太认真或者好奇心强的客户是有一定市场的；而有水平负责任的客户往往会觉得这种人不可靠一般不会把单子交给他。PM需要把握好这个度吹是肯定要吹的只是吹牛的时候一定要有基础的去吹对从来没涉及过的领域或者根本不懂的东西轻易不要发表意见挑选自己熟悉的方向合理的进行发挥适当的留上一两
7、手给对方高深莫测的感觉效果最好。 4.优秀的售前团队 这个团队一般是由总经理发起并组建的通常不指定PMP对团队的成员如SALESPMSAENGINEER们的团队合作提出了比较高的要求。一般公司在接下一个单子进行到一定程度的时候PM往往会尴尬的发现协议上销售代表们对客户的一些承诺是几乎做不到或者根本做不到的事情。这种情况非常多销售的任务是拿下单子我听到的销售们说的最多的就是没问题或者NOPROBLEM但是当我听到客户的要求和销售的回答时我总是心惊肉跳很不自然。销售是非常辛苦的为了建立客户关系尤其是空白的市场是很不容易的往往为了一个单子会牺牲非常多。在这种情况下和销售进行协调自然而然的又落到了PM
8、的头上。在销售和客户做承诺之前PM要主动的跟销售交流提供粗略的总体设计框架和技术难关以及能考虑出的工作量而不是等出了问题再被动和销售在老板面前互相推委责任。在组建团队的时候PM要根据团队里每个人的素质和任务进行因人置宜的信息传递。优秀的售前团队合作是接单的重要保障。在商务谈判的实际操作中存在着各式各样的问题PM的职责和要求绝非以上几点所能描述详尽。根据环境政策人文关系等各方面的不同情况PM的不同成长经历每个PM最终都会建立自己对商务谈判的看法和经验。但是有一点可以肯定这是PM成为PM的第一道关也是最重要的一关。接不到单子PM将失去存在的意义。与销售有所不同PM在该阶段的任务除了接单还要尽可能的
9、搜集客户关键人物的资料并与对方各个阶层的负责人建立良好的客户关系以便在项目实施时充分调动资源。 二.启动阶段 1.项目的一些基本概念 项目三要素有多种版本各不相同。实际操作中多分为范围成本与进度其中最重要的莫过于范围。我们把项目最终生成并提交给用户的产品和文档统称为递交件。谈判的时候一定要确立递交件的标准和要求也就是范围。尽管商战的时候不可避免的客户会不断提高标准和要求而承诺的款项却不会有一分钱的增加。但是这个标准对每个公司来说都有一个底线一旦超过了这个底线那项目就肯定是亏的。除非是为了二期有利可图或者是为了搞好关系否则范围超过底线的时候情愿不做再厉害的PM在这种情况下也是无能为力。建立范围需
10、要的就是PM的多年的实战经验在大大小小的项目中用血泪换来的一些体会。在这个时候很能体现PM与技术人员的区别。成本就是客户答应付的款项与我们的投入成本并不是一回事情。进度就不用多描述了。 项目如何成功？也有一些关键的因素。个人的理解也不尽相同通常包括以下几个方面：界定工作目标及工作任务；老板或高层的支持；优秀的PM和开发团队；充足的资源；良好的沟通；对客户的积极反应以及适当的监控和反馈。这里要注意的就是资源和高层的支持。一个上规模的公司总是同时会有很多项目可是再大规模的公司资源也不足以保证每个项目都能组建最合适的开发队伍或拥有最好的环境。这时候各个团队或者部门之间不可避免的会发生资源争夺战摩擦再
11、所难免。这时候对PM的作人再次提出挑战。除了高层对PM项目的重视程度如果PM平时在公司与同事相处的好往往能使很多别人看起来很棘手的问题迎刃而解。相反一个不会作人的PM由于人缘差即使高层强压别的部门或团队配合别人也会能拖就拖延缓项目的进度和质量。有时候这种内耗对项目和PM来说是毁灭性的。对客户的积极反应也比较关键。一般来说PM已经被项目里大大小小的事情搞的筋疲力尽要PM去主动要求客户配合是很吃力的事情。然而这个时候越是困难越是觉得累越是要去主动。客户往往也不是特别的积极主动与客户联系沟通和测试能及早发现问题。从风险控制的角度来说问题发现的越早风险越小损失也就越小。积极的态度可以带动客户的积极性在
12、项目完工的时候客户对你的感激往往是难以用语言描述的这对以后接单或者做二期三期会打下良好的基础。因为在和别的新客户谈判的时候新客户自然会找你的老客户了解情况这时老客户随意的一句话顶的上你很费心的十句。 项目具有商业行为的几个重要特征有消费源有参与者有成功关键因素有财务目标有风险。 2.启动阶段的主要任务 根据PMI的解释接单之后项目自然转入启动阶段。启动阶段PM的主要任务是率领总体架构设计师和系统分析员收集尽可能详细的数据确立尽可能详细的需求进一步确立详细的项目范围预估资源确立其他方案并获得进入下一阶段的批准。在这个阶段随着需求分析的深入PM也开始在公司内部进行人员挑选和资源争夺着手组建自己的项
13、目团队。项目即将进入计划阶段。 在收集完数据之后PM要和客户开始明确项目的大小成本规格期限等重要特征并将其写入合同文本同时准备内部的包括预算衡量标准等文档建立项目的评估标准。接下来就是需求分析。由于专业的原因我们这里仅讨论软件工程项目的需求分析（以下简称需求分析）。需求分析的主要参与人员有PM总体架构设计师系统分析员熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队我们叫做前期团队。随着需求分析的逐步深入新的团队成员不断加入启动阶段结束的时候正式的团队将建立。对一个已经启动的项目来说需求分析直接决定了项目的成功与失败。最初的需求体现在客户的工作说明书或招标文件及附件上。这种需求一般比
14、较含糊无法体现客户真正的需求。前期团队要根据自己的经验和客户沟通并引导客户进入正轨。有时候客户会很不讲道理或者思路僵化就要求按照他的思维去定一些明显错误的需求。这个时候团队成员要耐心和客户举事实谈经验讲道理用图形或模型等直观的方式将需求描述出来比如常见的数据流图等。所以说争论再所难免客户有时候会吹胡子瞪眼睛拍桌子甚至会说这个东西不要你们做了之类的话。PM此时除了要亲身参与需求分析综合整理文档之外还要处理好团队成员与客户的关系确保关系不会恶化到无法整理的地步。只要PM尽力约束团队中的成员这个度还是很容易控制的。 对快速开发和叠代开发来说需求和实现往往是同步进行开发速度快是一大优势。对有相同或类似
15、模式的小项目来说采用快速开发或叠代开发是很合算的做法时下流行的极限编程就是针对这方面建立的思维模式。然而大中型项目中有太多不一样的需求和模块。如果不是因为项目有差异那么市场上就只有产品而没有项目了。所以大中型项目的需求要认真仔细的去做。我们要讨论一个问题究竟应该在需求分析和总体设计上花费多少时间？我们熟悉的瀑布开发模式基本上分需求分析总体设计软件开发测试等几个阶段然而究竟应该在前两个阶段上花多少时间却没有定论。实际项目操作的例子表明分析设计的时间越长需求设计做的越详细测试的时间就越短返工率越低风险也越小成本越容易得到控制。 而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展顺利
16、的时候问题不大到了项目后期和测试阶段一些潜伏期比较长但是破坏作用比较大的问题就会凸显出来造成返工延长测试时间。所以与其把问题堆积到紧张的项目后期不如把时间多花点到需求分析和总体设计上。基础夯实了金字塔就容易造了。在日本公司打工的程序员们可能都知道小日本的软件规范非常厉害他们花在需求分析和总体设计上的时间通常在40%到50%左右远远超过国内软件项目的实施效果也要强的多。他们总体设计的规范甚至详尽到某个过程该如何判断确立什么样的条件换言之就是把什么时候该如何写(if.else)语句都帮程序员定好了。在这样的软件规范下程序员更象是装配流水线上的工人对一个模块或技术熟悉到一定程序就变成了完全的重复性劳
17、动。所以在日本和欧美经常会有程序员是低级工作一说很多人不明就里对国内程序员也照搬对国内的程序员来说是很不公平的。在国内只会照抄别人代码一点都不懂创新凡事依靠别人快下班就盯着表看的程序员是不少这种人一般很难有什么前途。但是优秀的不断进取的程序员也很多。由于国内没有象CMM这样的软件规范或者很少所以这类优秀的程序员不少都是干着系统分析员甚至PM的活拿着程序员的工资。这类程序员虽然在起步时会吃很多亏而且是主动找亏吃然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候前者还在各个公司里频繁跳槽跳来跳去都不满意。有些扯开了回到我们的话题。 日本的软件规范与CM
18、M有惊人的相似其中至少有35%以上都是几乎一模一样的。最近经济不景气东京倒闭了160家软件公司这个数字是今年6月份的还在不断增加。这些公司纷纷抢滩上海招收技术人员。如果去这样的公司应聘就要考虑清楚了进去可以学到他们的规范和质量控制可是要想从程序员成为系统分析员或PM比登天还难。往往一个程序员进去干了好几年对自己的那一块熟的不得了而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4（华为印度研究所已经通过CMM4）对在华为工作的程序员们来说可谓福祸难料。当然已经作到PM或QA或者热爱CODING的朋友例外。需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长分析员们在客户的各个部
19、门之间几乎把腿都跑断把口水说干就是为了确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字不合格的打回重做。反馈表随之将提交给客户第二遍第三遍等等等等接踵而来与客户反复讨论和磋商反复提交文档和表格目的只有一个明确需求。当PM最终合并了所有文档并确立需求之后最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。 需要说明的是客户并非都是蛮不讲理但是说实话颇有无奈国内目前的项目大多数客户为了不让自己的钱白花经常变着法子提需求。在启动阶段明确需求并签字无论最终情况如何一份详尽的书面文档可以解决很多口头承诺或概
20、念模糊的文档带来的许多问题。详尽的需求分析有一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。有时候这种大项目在签单时双方都没有绝对把握保证可以出成果一旦在需求分析阶段发现难以逾越的技术难关就会放弃项目。典型的例子就是NMD洲际导弹防御系统。上世纪八十年代初美国搞星球大战计划拖跨了苏联。大家对那段历史有些含糊很多人认为苏联人上了美国的当。其实并不完全如此苏联人的情报机构无孔不入并非那么容易上当受骗。实际上当时美国国防部已经开始着手NMD系统软件的需求分析前后耗资数亿美圆耗时两年仅仅是做需求分析终于发现存在着在当时技术上无法达到的高度随后项目被放弃。
21、3.项目启动 项目启动要确定项目计划与客户一起实施第一次项目审核确认并对一些产品和服务向下包厂商下订单。这个时候的PM会忽然发现有开不完的会一天开三到四个会议是很正常的事情。这些会议有与客户的会议与下包厂商的有团队的有公司高层的。团队的会议主要是建立正式的团队提供团队成员的角色和职责提供绩效管理方法向成员提供项目范围和目标。与客户的一个主要会议将是项目启动会议。在这个会议上PM会与客户确立正式的交流渠道项目综合描述让项目参与人员相互了解建立以PM为核心的管理制度。还有一些零零碎碎的东西甚至包括办公场地的大小电话多少部所有人的联系方式等等都要在会议上确立并做会议记录。这都是些非常琐碎的事情听起来
22、婆婆_却是非常必要缺一不可。大概就是所谓三军未动粮草先行吧。 这时候作为公司高层应该向全公司发表申明正式给PM发布项目经理任命书和项目授权书。这个动作虽然在别人看来有些形式主义但是对提高PM本人的士气和责任感是有很大助力的。 三.计划阶段 1.定义结构分工结构图（WBS） 启动阶段结束后项目进入计划阶段也就正式进入实施。这里概念可能有些不太对头其实是翻译的缘故反正大家明白意思就行不用拘泥于字面。WBS是一组要提交的项目元素用来组织定义项目的总体范围具体包括从工作内容资源成本角度考虑项目范围；建立一套系统所需要的分层工作结构；把项目分解成易于管理的几个细目这概念有些模糊其实跟资源管理器里分目录是
23、一回事情。可以说WBS是计划阶段的核心。WBS会详细的分到递交件包括给自己人用的项目使用的过程文件给客户用的模块和说明文档完成每个细目的标准以及如何把这些细目的责任分配到具体的个人。WBS有缩进式和树状式我这里也没办法画图大家参考一些项目管理的书籍里面有详细介绍。我整个文章只挑我觉得需要注意的地方如非必要对技术细节或者工具使用不做详细介绍。WBS的细目并不需要分解到同一水平最下面的细目叫做工作包分包的依据是个人的责任和可信度也就是说到每个人头上的任务是否能落实是否有把握完成；还有就是准备对项目进行控制的程度程度越深WBS树也就越深。由于WBS是实用性的东西根据个人理解也不一样所以一个项目可能会
24、有几个正确的WBS看PM的需要和最适合当前团队状态的进行选择。 WBS的定义还是很麻烦的。 PM要召开团队进行讨论向成员提供与项目相关的所有详细资料并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式（BRAININGSTORM）思考制订工作产出和相应人员的职责记录每一个工作包的完成标准。在头脑风暴式思考时会有很激烈的争论PM要协调关系调节气氛从自己能考虑到的各个角度旁推侧敲提示成员的思维角度和方向并加以总结。尽管很麻烦制订WBS仍然是非常值得的。如同需求分析一样WBS准备的越充分编码的进度越快。 2.风险管理 既然是商业行为那么项目的风险必然存在相信阅读这个帖子的朋友不少人都经
25、历过或大或小的风险。有些风险很容易解决有些风险则大大损害利益。不论什么样的风险能避免尽量避免所以有必要对风险进行管理。由于风险的不可预知性风险管理难度很大概念也很难讲清楚只能从一些可行的角度去分析进行管理。 首先要识别风险。这是个难度很高的活。PM要先召开风险识别会议这个会议面向公司高层跨部门的有经验的人都将参加。然后审核由项目小组生成的风险清单并与重要成员进行风险沟通检查一些重要的风险源如WBS成本（时间）预估人员计划采购管理等等。最后就要用到PM本身在以前类似项目中得到的经验教训。 识别之后要进行分析。我们可以进行粗略的量化分析（精确分析是不可能的事情）。有经验的人可以一起参加讨论把提交出
26、来的风险进行分类。首先按发生的可能性分一般分成高中低三个级别虽然很勉强但是好歹也有个量化了；然后按耗去的成本分也是高中低三级。我们可以把这两种类别的三个级别进行组合碰到可能性也高成本也高的风险就定位为不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成本否则一旦亏起来不是亏一点点有可能赔的很厉害。高和中中和中的搭配都是属于高风险中和低低和低搭配属于低高和低搭配属于中。 针对出现的可能性需要采取一些手段降低风险。到目前为止也没有一个定论说有绝对好的方式只能尽其所能的避免。有几种方法可以考虑第一种是将风险纳入项目管理计划并指定负责人由外部人员定期检查项目风险一旦风险发生执行风险管理计划；第二
27、种是保险这种属于风险转嫁；第三种方式有点奸不过最保险就是把客户拖下水让他们一起参与风险管理呵呵到时候就好说话了：）风险管理作为项目计划之后PM需要更新WBS修改日程计划和更新风险管理计划。风险预留通常是成本的8%。 3.预估 预估是从量化的角度对项目进行评估主要包括工作量任务期限人力设备材料成本等要注意预估不是财务策略或报价。预估其实并不是一次性工作在整个项目过程中预估始终需要。预估似乎没什么特别需要提的地方每个PM接到项目的时候自然会有预估在项目发生变更或进入下一阶段时也会预估。预估的作用主要还是让PM作到心中有个底安排计划时不至于毫无头绪。 4.进度计划进度计划就是一个模块或功能要写多长时
28、间PM安排个日期设立里程碑叫程序员们不能偷懒。进度计划是从WBS提取过来的。对PM来说合理的安排进度计划对项目控制和激励团队士气有着很大的作用。对程序员来说进度计划毫无疑问是噩梦。显示进度计划一般有先后顺序图甘特图和里程碑图表。上回邵卫老师讲课的工具是m$的PROJECT这个工具我还不会用因为没时间去摸索。我的头倒是用的很溜了近一个月来他就用这个PROJECT画了一个又一个的里程碑图不停的折磨我和同事的神经。我们一般都是一边开发一边做UNITTEST效果上来看因为有强大的时间压力效率上比之前确实要提高不少可是我们也只能结结巴巴的赶完进度。由于TEAM里人少我们都是一个人做几个人的活。我每天早晨
29、六点多出门经过将近两小时颠簸八点多点已经坐在位子上中午吃15分钟的饭干到晚上八点下班到家吃完饭往往已经11点了。一个多月我从来没吃过早饭没有睡过六个小时以上的懒觉。虽然强大的压力使我们能在短时间内掌握尽可能多的技能开发更多的模块但是对我们的情绪也是有很大的影响。所以说项目里程碑是一把双刃剑合理安排才能既促进效率也不至于打击士气。团队成员士气的逐级衰落会给项目后期的开发带来难以估计的影响进度将会大大延缓。关于PM和团队的问题我们后面会讲到这里我先祥林嫂一把然后跳过。里程碑图表的特征是任务成员和时间任务和成员用文字标志时间用数字描述并辅助以图线跨度象阶梯一样非常形象一目了然。管理起来非常方便完了的
30、打个钩就可以了。 网络逻辑图是表示任务和逻辑关系的示意图可以用先后次序表示也可以用关键路径表示。其实把各个活动划分为1234等阶段每个阶段包括小活动1.11.22.12.22.32.43.13.23.34.14.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阶段
31、中的3个子阶段3.13.23.3的最早开始时间都不能早于1月22日。至于从后向前的例子大家自己去推吧我就不举了刚才几个123打的我累死了：）项目经常需要调整进度。在不改变项目范围的情况下调整进度有几种方法：利用快速跟踪手段来改变任务间的关系；将串行的任务改成并行；改变工作方法（可能改变WBS）；改变日期限制使关键路径上的任务开始或结束的更早。 虽然方法多样化在我看来只有一条就是拼命的压榨程序员的劳动力。如何压榨还是个技巧。如前面所分析的需求分析恨不得多分点时间给它压需求是不太可能；测试阶段后期接近完工罗里巴唆的事情一大堆忙都忙不完那时候PM一门心思提前/按时完工好收钱压那段时间似乎也不太可能。
32、说来残酷最能压的还是CODING编码阶段往往是压缩重点总之大家埋头苦干就是了大项目压缩的时候程序员吃喝拉撒都在公司是很正常的事情相信不少人都有很深的体会这里伤心事情也就不提了。只是我总结一下让未来的PM们有压榨后来人的依据呵呵。测试前期也可以适当的压一压那时候人刚完工都比较懒散。国内一般企业规模都不大没有专门的质量控制部门所以质量保证和测试往往就是程序员或PM本身。其实质量保证和测试人员的人数和素质都应该要高于程序员。在日本和CMM实施的公司里编码压缩是很容易实现的事情因为那些程序员真的是技能熟练的装配工人压起来方便的很。他们这样培养人的目的或许就是为了压缩吧？！ 四.控制和执行阶段 1.软件
33、开发实在没什么好说的也是大家最不愿意谈的平时在公司里谈的已经够多的了还要在这里受我唠叨。需要提醒的依然是团队合作精神和完善的文档管理制度。SOURCESAFE这些工具有时候还是有必要使用的。经常看到有人说天才程序员不写注释什么的。我相信有这种天才程序员因为我碰到过几个。 我爱人公司里也有一个他们的一套产品核心代码就是这个人写的4年过去了周边代码换了好几茬核心算法始终没换过可惜这小子跟了李洪痔如今已经不知所踪了。但是他的代码似乎也要有点注释的没有注释过段时间再天才的程序员也不能保证他是最有记忆力的。而且对一个项目的编码来说靠一两个人打天下如今是不可能了。别人的公司都是团队两人智慧胜一人这头还在靠
34、一个天才支撑门面实际上市场可就别人抢了去那时候再天才也没用了。 编码的时候讲究技术公开程序员不要藏着掖着对大家没好处PM要想办法调动大家创新思维的积极性营造良好的技术讨论氛围碰到技术难关的时候就容易攻破了。有个问题需要单独对还没有PM觉悟的程序员说其实是在调研的时候就定了的就是使用什么样的开发工具。没有经验的程序员往往会拿着C+或者JAVA的资格证书或者拥有一两个开发工具的一些经验而得意洋洋。其实老板和PM根本不看重这个他们关心的是使用什么样的工具能尽快的达到目的。管你什么C+DELPHIPB还是JAVA只要能做的出来VFP都可以用。我举这个例子并非说不看中工具而是提醒想转型为PM的程序员第一
35、要把工具当作工具而不要被工具套进去钻研一些一辈子都用不上的技术；第二要掌握的并非是单独的一个工具而是流行的程序设计的思想以及在最短时间内掌握一门陌生工具的能力。只有建立了这样的思维才有可能转为PM否则一辈子都是技术工人最多就是个技术总监。 2.变更对任何项目变更无可避免无从逃避只能去积极应对这个应对应该是从需求分析就开始了。对一个需求分析做的很好的项目来说基准文件定义的范围越详细清晰用户跟PM扯皮的幌子就越少。而需求没做好基准文件里的范围含糊不清被客户抓住空子搞你一下是非常头疼的事情往往要付出无谓的牺牲有时候甚至非常火大。需求做的好文档清晰又有客户签字那么后期客户提出的变更就超出了合同的范围需
36、要另外收费。这个时候千万不能手软并非要刻意赚取客户的钱财而是不能养成客户经常变更的习惯否则后患无穷维护的成本会让PM吃不消。 在客户提出变更请求时要建立变更申请登记表和变更申请表并让客户签字。当然有时候一些不是非常关键的模块PM也不至于一点不讲情面该卖面子的时候还是要卖尤其是当着对方领导的面千万要卖面子但是也别卖的太干脆不要让他们得到的太容易。需求做的不好客户抓住漏洞或者非常不讲道理麻烦就大了。有时候争论会很厉害到非常白热化的地步PM与客户代表几乎沟通不了。PM在客户关系和短期利益两方面难以取舍一般都是向客户妥协最终形成恶性循环。这种情况非常难办。一般这种情况都是到了项目后期做重大的更改几乎是
37、不可能的事情如果白做就要亏钱。而这个时候如果PM跟对方高层的人关系搞的定可以透过对方高层把事情压住。然而由于已经到后期客户代表不会轻易更换对方这次没有改成必然心怀不满下回在别的模块依然会找麻烦或者在谈二期的时候动动手脚都是很让PM伤脑筋的事情这方面目前还没有什么好的解决方法所以尽可能的做好需求比什么都重要。相对需求来说什么WBS风险管理计划进度都是扯淡需求做好了一帆风顺。还有一种办法就是装可怜要装的非常的象在对方的领导面前装而且不能让人看出是装的样子要让你自己都觉得你自己是真的可怜那么就算这次客户硬是要求改了下回他也必然不好意思再叫你改。其实人心都是肉长的如果可能的话我还是不赞同使用一些手段的
38、但是有时候客户非常难以在短时间打动而工期又将接近这种情况下就要靠PM耍一些手段了。各人有各人的方式八仙过海各显神通吧。PM在变更管理中需要做的是分析变更请求评估变更可能带来的风险和修改基准文件。 3.质量控制大公司有质量管理部门（QA）QA的成员基本上都是由非常有经验的PM转型过来的老狐狸是老总接班人的有力争夺者。一个QA会管理多个项目有时候甚至会亲身参与。PM和QA有些象猫和老鼠不停的通过报表传递一些心照不宣的假数字。QA对PM的工作最终是有评定的：A级表示总体在控制下；B级表示当前在控制下；C级表示有显著问题；D级表示有重大问题。如果PM得了个D那可不太妙不但世界级的QA会每个月要收报告地
39、区QA会一个星期找来面谈一次训一顿。得到A的PM是很逍遥的基本上不会有人来过问。在没有QA的公司质量控制只能由经过授权的团队成员进行效果就要差的多了。质量管理贯穿整个项目周期详细的可以参见CMM。 4.成本管理PM经常通过控制进度和预估来控制成本。PM必须经常问自己项目已经到了什么阶段？完成了多少？花费了多少？完成时成本是多少？挣值法的术语不少象BCWSBCWPACWP但是关系比较简单大家参阅一下相关资料这里不再羸述。总之PM要管理好成本注意节约但并非是拼命剥削程序员该花的还是要花。 五.结束阶段 1.项目结束项目结束时PM要将最终系统方案提交给用户完成项目所有的提交件收集项目全部信息并结束项
40、目完成或终止合约签署项目结束的相关文件。项目结束意味着可以收钱了。PM辛苦了那么多终于可以高兴一下了收到最后一笔款项意味着递交件的移交和团队的解散项目也转入维护阶段。不过收钱未必代表着赚钱要看项目是否按时完工。一般来说提前完工的项目很少但是能赚大钱；按时完工的赚小钱；延期的要赔钱。一个人首次承担PM如果没有人带多半会失败。失败没什么所有的PM（注意是所有不是几乎所有）都失败过然而失败会成为教训和经验推动你继续前行。在美国每年至少有40%的项目无法实施被搁浅。只有在项目中和生活中不断磨练培养自身素质和作人的基本准则才能成为赚大钱的PM。 2.项目完工会议项目结束时依然要开会不过少多了。一般跟客户
41、要开一个主要是确定所有的提交件都已经被接收对突出的个体进行表扬对外宣传成功案例标志并记录项目的正式结束。这时候开会很轻松目的也很明确做完了大家好聚好散或者以后有机会再合作。团队要解散内部会议肯定是要开的。也没什么好废话的该表扬就表扬该发多少奖金就发多少奖金毕竟大家都累死累活的干了那么长时间。项目结束请客户出去泡温泉时PM们千万别忘记了辛苦为你工作的程序员和工程师们当然如果他们不愿意看到你的脸那么你就折现发到他们的存折上去正好让他们回家好好休息休息。这样下一个项目需要他们的时候他们才会为你卖命。说出来奖金发出去似乎你损失了其实你赚大了。 3.客户满意度形势也好历史记录也好尽管项目结束的时候客户满意度PM心中已经有底了但是还是有必要向客户各个层次的项目代表发一张信息反馈表收回的信息将反应客户的满意度。其实真正体现客户满意度的地方有很多。第一就是付钱付的快如果客户不满意一分钱藏在他牙缝里你也很难抠出来；第二就是二期二期非常非常重要因为这里已经是属于一种无销售成本的项目又有一期的经验可以说二期的钱是最好赚的。这中间的感觉只有经历过的人才明白。 第 23 页 共 23 页