我经常听到老板经批评项目经理，做事一点章法也没有。所谓章法，就好比武术中的招式或套路，做项目没有章法，就会胡乱出招，项目要取得成功，那就好像猴子用打字机打出莎士比亚的作品一样希望渺茫。
要说项目管理的招式，最受欢迎的当数美国项目管理协会的《项目管理知识体系指南》（PMBok）了，他们提出的“九大领域、五大过程组和四十二个过程”，风靡天下，不懂一些的话，你不都好意思说你是项目经理。现在PMBok已经成为项目管理界的公认的全球性标准，国际标准化组织（ISO）以它为框架，制定了ISO10006标准。
1.项目经理成长的五个阶段
一个优秀项目经理炼成，并不是一朝一夕的事。特别是对于从程序员转型过来的情况，受制于其原有的思维方式、知识体系、管理经验乃至性格缺陷，往往要经过很长时间的才能逐渐胜任。我将这一过程分为五个阶段，每个阶段实际上也代表了一种类型的项目经理，以及项目管理的一层境界。
1. 混沌阶段
他们刚刚从程序员岗位上提拔为项目经理，也没有学习过项目管理知识，对项目管理完全处于是懵懂无知的状态。管项目基本上靠被动的等事情做，凭感觉去做，更可怕的是连感觉也没有。
如果用娃娃学走的来打比方的话，他们现在还是在襁褓中躺着睡觉的状态。如果项目就是一场马拉松，他们是没有机会到达目的地了，最后的结果只能是他的上司抱起他上路了。
2. 觉醒阶段
终于睡醒了，工作从被动到主动，这是一个巨大的飞跃。他们往往会维护一个事务列表，虽然这个列表往往只是项目的一部分工作，但比没有还要强多了。在他们眼里项目即等于产品，他们会有意识的将产品进行分解，按模块分给其他人做，然后一直往下做，什么到什么时候算什么时候，他们做事没有计划性。
他们算是会爬了。爬是慢了点，但总一天会到达终点的——如果有毅力能坚持足够长时间的话。
3. 入门阶段
处于入门阶段的项目经理，会有意识将项目划分为若干阶段，确定每阶段的可交付成果，并制定项目制定里程碑；有意识制定计划，并且希望按计划去做。对项目管理理论有一定了解，但缺乏深入理解。他们会有意识关注三大目标。他们的薄弱环节是控制和领导能力差，自己却没有意识到这一点，反倒将项目中的问题归咎于外部因素。许多有数年项目管理经验的项目经理仍然停留在这一阶段，这是因为他们不求上进的原故，以为天下的项目就只能做成这样了。
他们会走了。项目最终总是可以干到验收的，但返工或重做的现象经常会出现，并且往往员工的士气欠佳，其战斗力并不能充分的发挥出来。
4. 全面发展阶段
这一阶段项目经理不但具有比较丰富的实践经验，而且掌握了完整的项目管理理论知识，通过长期的学习、实践、思考、领悟、再实践，各方面的技能已经臻于完善。能顾及到项目中的方方面面，技能也比较全面，对项目控制和团队领导也颇有心得。
他们会跑了。是的，他们确实已经很优秀了，但我认为，到这一阶段才称得上真正合格的项目经理，你也许会觉得要求太高了，但马拉松赛场上的选手必须是跑着的，走完是赢不了比赛的。
5. 融会贯通阶段
他们逻辑性强，领导能力极强。他们不是照搬书上教导的知识来管理项目，而是凭借直觉，就能准确的把握项目中潜在的问题，并采取预防措施。他们有着非凡的领导能力，员工不但工作富有成效，而且能工作中得到快乐。到达这种境界，不仅是靠勤奋，还要靠天分。
这一类项目经理，不能用走路来形容他们了，他们就像天上的鸟儿一样，自由自在的飞翔。
2.把项目管理大卸九块
PMBok并不是专家们书房里琢磨出来的神秘东西，而中是将我们日常做事的方法进行提炼而已，项目管理本质是就是一套做事的思想和方法。PMBok将项目管理分为九大知识领域，其实也我们平时做事的思维息息相关。
我第一次参加项目管理培训的时候，那位老师非常循循善诱。第一天课堂上有一次令人难忘的对话：
老师问：“同学们，现在假设领导把你请到他的办公室，说请你做一件事事，你会问哪些问题呢？”
学生们纷纷回答：“具体要做什么事情，要求什么时候做完，做成什么样，还有有哪些人来做”
老师说：“很好。那对于自己做不了的事情，怎么办呢？”
学生：“请别人做！”
老师：“Very good!如果很多人一起来做一件事情，最重要的是什么？”
学生说：“每个人协调一致，统一思想和行动。”
老师：“Excellent!除了上面这些，还有什么需要考虑的吗？”
沉默片刻后，有一位学生回答道：“还要考虑一些可能会出现的问题。”
另一位学生接着回答说：“还要对所有的工作进行总体把控。”
老师惊喜的说：“Perfect!同学们，你们已经把项目管理的九大领域给总结出来了！请看下面这张幻灯片…”
老师展示的是这样的一张图：
这就是项目管理的九大领域：整合管理、范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理。
项目管理好像一头大象，将其大卸九块之后，要装进冰箱就容易多了。
看看书上是怎样解释这九大领域的：
●整合管理：包括识别、确定、结合、统一与协调各项目管理过程组内不同过程与项目管理活动所需进行的各种过程和活动。●范围管理：确保项目包括成功完成项目所需的全部工作，但又只包括必须完成的工作的各个过程。●时间管理：包括使项目按时完成必须实施的各项过程。●费用管理：包括涉及费用规划、估算、预算、控制的过程，以便保证能在已批准的预算内完成项目。●质量管理：包括保证项目满足原先规定的各项要求所需的执行组织的活动，即决定质量方针、目标与责任的所有活动，并通过诸如质量规划、质量保证、质量控制、质量持续改进等方针、程序和过程来实施质量体系。●人力资源管理：包括项目团队组建和管理的各个过程。●沟通管理：包括保证及时与恰当地生成、搜集、传播、存储、检索和最终处置项目信息的所需的过程。●风险管理：包括项目风险管理规划、风险识别、分析、应对和监控的过程。●采购管理：包括从项目团队外部购买或获得为完成工作所需的产品、服务或成果的过程。
3.五招四十二式
要把大象装进冰箱，分成九块还是太大了，还得切小一点。因此在PMBok第四版中，又将九大知识领域细分为42个过程，这些过程可以分为5个组，启动过程组、规划过程组、执行过程组、监控过程组和收尾过程组。这五大过程组42个过程，就是武术中的招式，可以直接用来实战中了，因此不妨称之为“五招四十二式”。
这一节牵涉到比较多的项目管理理论知识，如果你完全没有接触的过的话，读起来可能会比较困难，建议先啃一遍PMBok，或者跳过本节。
1. 五大过程组
五大过程组与九大领域一样，同样体现了做事的逻辑，只不过角度有所不同：
●启动：确定是否要做，以及做什么●规划：打算怎么做● 执行：按照计划去做●控制：做对了没有●收尾：做完了收工
可以看出，这是一个完整的做事流程。其中启动和收尾一进一出、一头一尾，就像我们常说的“做事要善始善终”，而规划、执行和监控则是项目的主体，与著名的“戴明环”（即PDCA循环）相对应，构成了一个循环。
在PMBok中用下面这张图来描述五大过程组：
图 PMBok中的五大过程组关系图（出自PMBok）
有人将五大过程组画成这个样子：
图 网上流传的五大过程组关系图
这张图广泛流传，但它其实是有问题的，就是把监控弱化了。跟PMBok中的原图比较，在这张图中，只有执行属于监控的范围，而在原图中，启动、规划、执行和收尾都是监控的对象，很明显，原图更加严谨。
很多人分不清五大过程组与项目生命周期的关系，两个概念确实比较容易混淆。生命周期，也是就一件事物从开始到结所经历的阶段，一个人的生命周期包括婴儿、儿童、少年、青年、中年、老年等几个阶段，项目也可以这样来分。为什么五大过程组和项目生命周期容易混淆呢？关键在于大过程组看上去很像是项目的几大阶段：启动→规划→执行→收尾，然而两者之间有着巨大的差异：
●生命周期是从时间维度来描述项目管理，而五大过程组则是从职能的维度来理解的，告诉项目经理应该做哪些工作：项目经理你要做项目启动的工作、你要制定项目计划、你要组织和指导大家开展实施工作、你要监控项目、最后不要忘了做收尾工作！●五大过程组还体现在了项目的过程化思想，五大过程组本身即具有“输入-处理-输出”的关系（启动为输入，收尾为输出），而生命周期仅是前后贯通的时间序列。●生命周期是前后连接的阶段，而五大过程组是一个有进有出的环，在项目中大环套小环，有点像套娃娃。整个项目可按五大过程组的思路来开展，每个生命周期的阶段也可以，甚至一项细化的开发任务也可以。
图 项目过程组与生命周期的关系（出自PMBok）
五大过程组与生命周期同时也存在紧密的联系。实际上，启动过程组在项目生命周期的开始阶段作用最为强烈，收尾过程组主要作用于接近完成的阶段，而规划、执行和监控过程组则主要作用于项目的建设实施阶段，如下图所示：
图生命周期与项目过程组的相互作用关系（出自PMBok）
2. 四十二个过程
现在我们知道了项目管理有九大知识领域和五大过程组，那项目经理具体要做哪些事情呢？那就要看项目管理的42个过程了，做什么、用什么方法做、做出什么成果全在这里，这对于那些像无头苍蝇一样到处乱飞乱撞的项目经理来说，简直就是雪中送炭啊。然而别高兴得太早，早就听说过PMBok很难啃，它难也就难在这42个过程，每个过程都由输入、工具和技术、输出组成，千篇一律，就如同经书一般乏味，估计你看两个过程就会昏昏欲睡，所有以我也叫它“四十二章经”。
看一看42个过程的分布情况：
|
知识领域 |
项目管理过程组 |
合计 |
||||
|
启动过程组 |
规划过程组 |
执行过程组 |
监控过程组 |
收尾过程组 |
||
|
项目整合管理 |
制定项目章程 |
制定项目管理计划 |
指导与管理项目执行 |
监控项目工作 实施整体变更控制 |
结束项目或阶段 |
6个 |
|
项目范围管理 |
|
收集需求 定义范围 创建WBS |
|
核实范围 控制范围 |
|
5个 |
|
项目时间管理 |
|
定义活动 排列活动顺序 估算活动资源 估算活动持续时间 制定进度计划 |
|
控制进度 |
|
6个 |
|
项目成本管理 |
|
估算成本 制定预算 |
|
控制成本 |
|
3个 |
|
项目质量管理 |
|
规划质量 |
实施质量保证 |
实施质量控制 |
|
3个 |
|
项目人力资源管理 |
|
制定人力资源计划 |
组建项目团队 建设项目团队 |
管理项目团队 |
|
4个 |
|
项目沟通管理 |
识别干系人 |
规划沟通 |
发布信息 管理干系人期望 |
报告绩效 |
|
5个 |
|
项目风险管理 |
|
规范风险管理 识别风险 实施定性风险分析 实施定量风险分析 规范风险应对 |
|
监控风险 |
|
6个 |
|
项目采购管理 |
|
规划采购 |
实施采购 |
管理采购 |
结束采购 |
4个 |
|
合计 |
2个 |
20个 |
7个 |
11个 |
2个 |
42个 |
如果你想看每个过程的详细讲解的话，那还是得自己动口、丰衣足食——动口啃PMBok。这里我们倒是可以对其进行简要解读，避免由于食物太硬引起消化不良。
PMBok中有三个重要的词：生命周期、五大过程组、九大知识领域，其实是看待项目的三个维度，即 ：时间维度、职能维度和管理对象维度。时间维度是要求项目经理将项目分成若干个阶段，逐步接近目标，项目更容易控制；管理对象维度是要告诉项目经理管什么，要关注什么，即范围、时间、成本、质量、人力资源、风险等；而职能维度则是代表要做什么，即要启动项目、规划项目等。
42个过程是按照后面两个维度进行划分的。为什么没有生命周期呢？这是因为不同类型的项目生命周期划分会千差万别，例如一个软件项目和一个房地产建设项目的阶段划分毫无疑问会相去甚远，而PMBok是适用于不同行业、不同类型项目的通用的指南，不可能将其固定下来。因此假如具体到某个软件公司，完全可以根据软件生命周期划分、参考PMBok中的过程，重新制定合乎本公司实际情况的项目过程，相信大部分软件公司的ISO9000文件正是这样干的。
主要疑惑点在于“制定项目管理计划”与“制定进度计划”、“制定进度计划”等过程之间的关系。
其实PMBok已经明确说了，它们之间是总子划和分计划的关系。在项目管理计划中，同样可以包括这些分计划的内容。也就是说，只要你愿意，完全可以把规划过程组中的所有工作放到“制定项目管理计划”这一个过程中来完成——总计划把分计划中的事全干了。
监控过程组中一共有11个过程，这11个过程的关系是比较让人迷惑的。在整合控制中有“监控项目工作”和“整体变更控制”两个过程，它们与别外八个领域的中的监控过程是什么关系呢？
通过研究各个过程的输入和输出，可以发现“监控项目工作”过程产生的的一个主要成果是批准的变更请求，而该成果又是另外八个领域中的控制过程的输入，这些控制过程又都有一个重要输出是请求的变更——该成果又是“整体变更控制”的输入。由此，各个过程的关系浮出水面，如下图所示：
从图上可以看出，“监控项目工作”主要是发现问题，提出变更请求，而“控制范围”等过程，则是确定怎样变更，真正的进行项目变更的动作是“整体变更控制”。
启动过程组在两个过程：“制定项目章程”和“识别干系人”。按照五大过程组的特点，这两个过程在项目每个阶段之初都需要执行。难道我们在设计阶段和编码阶段都需要重新制定项目章程和识别干系人吗？
这看上去有点奇怪，在实际项目中，项目章程和干系人一般不会有什么变化，每个阶段都要重新做一次这个工作似乎有点牵强。在PMBok中关于项目章程有一段话是这样说的：“在多阶段项目的以后各阶段，制定项目章程过程的作用是验证原来为项目制定与颁发的章程所做的各种决定。这一过程在必要时还核准项目下一阶段并更新该章程”。原来如此，简单来说，就是看原来制定的章程还好不好使，不好使就需要更新了，算是能说得通。
同样，识别干系人也就是看干系人有没有变化了，但这与项目监控又存在一定的雷同了。我们可以设想一下，如果干系人发生了变化，我们一定需要等到一下阶段初才对做出相应的对策吗？显然不现实，我们会立即做出反应，而能随时识别变化并做出反应的过程只能是监控过程组了。
曾经在培训课有一位老师告诉我们，项目经理主要做项目整合管理的工作。个人认为这种说法有失偏颇。
由于整合管理往往涉及多个领域，因此，由项目经理亲自把控是有道理的。但项目经理是不是只需要做项目整合管理，或者可不可以授权其他人来负责整合管理中有一部分工作，这就要视项目实际人力资源情况而定了。
如果你不幸领着一群毛手毛脚的毛头小子，那上面这个表里的工作只能全是你的了；如果你有几个得力干将，那就好办多了，授权嘛。整合管理中工作同样是可以授权的，没有谁规定一定要由项目经理来做。当然授权不等放权，绝不意味着放任不管，至于管到什么程度，只能由你自己拿捏了。
4.懂章法还要懂点心法
在武侠小说里，常有争夺剑谱之事，可是千辛万苦拿到剑谱，由于不懂“心法”，还是练不成。在项目管理领域，PMBok就好比是一本剑谱，项目经理要做什么、怎么做，书里面都有，但每个人运用起来，威力会大不相同。古人云：“运用之妙，存乎一心”，可见心法的重要性。
下面介绍一些项目管理的入门心法，帮助项目经理理解和运用书中的招式。至于高级心法在后续文章中会逐步介绍。
1. 项目管理是关于做事的方法
项目管理不是什么神秘东西，要以平常心来看它，它就是人们总结出来的一种有效的做事的方法而已。这种方法有几个要点：
以客户为中心，看上去很简单，却蕴含着项目管理的终极秘密：让客户满意。记住，是让客户满意，而不是开发一个软件，或者完成合同内容，也就是说我们的关注重点是客户需要什么，而不是软件本身。为什么那么多项目开发了大量强大功能，客户仍不满意，就是因为我们没有把关注焦点放在客户身上，去琢磨客户真正需要什么，而不是客户说要什么；去琢磨怎样满足客户的实际应用，让他们用起来更方便，而不是需求文档写着什么。
项目没有目标，就好像踢球没有球门，其重要性不言而喻。但是项目的真正目标并不一定等同于招标文件中提出的目标，招标文件是台面上的东西，是比较表面化的，而客户的真实目的也许并不在于此。因此，项目经理最好对项目的来龙去脉搞清楚，这样才能更好的把握客户心理，理解项目的重点，真正使到客户满意。
项目计划在项目中处于非常基础的地位，项目的实施都应该按照项目计划来进开展。如果项目没有制定计划，或者虽有计划，却是说一套、做一套，那么这不叫项目管理，这叫打乱仗。没有计划，项目实施也就失去了依据，也更谈不项目监控了，项目管理中的42个过程，也就基本失效了。
项目监控是很多人新任项目经理的薄弱环节，为什么那么多人说“计划赶不上变化”，其原因正是在于控制环节的缺失。项目不是一台机器，你只要启动马达，它就会按你设计的那样转个不停。项目的过程中产生偏差是正常现象，甚至是必然的事情，如果不加以控制，计划就会成为摆设，项目也会越偏越远，项目完工也就更加遥遥无期了。因此说控制是手段，是保证项目能按计划达到目标的手段，每个项目经理都必须主动监控项目，用好这一手段。
2. 结构化分析方法
还记得什么是结构化分析方法吗？说到它，很多人会想起数据流图、数据字典等等这些工具，但其内在的精神思想，即“自顶向下、由外到内、先整体后局部、逐层分解”，这才是它留给人们最宝贵的财富，
其实结构化分析法方不只是用于软件的分析设计，在人们生活的方方面面都有其用武之地，因为它是对复杂和大型事物的分析方法，符合人们对事物的认识规律。在PMBok中同样深刻的体现了结构化分析方法的思想。
首先PMBok本身就是一个自顶向下、逐层分解的知识体系。没有分解之前，项目管理是一个混沌的整体，PMBok将其按不同的维度分解为五大过程组和九大知识领域，然后又进一步分解为42个过程，每个过程又分解为输入、工作和方法、输出三个部分，这不正是完美的体现在结构化分析的思想吗？
项目经理组织项目实施更加离不开结构化思想。42个过程中有一个非常重要的过程是“创建WBS”，所谓WBS，中文名是“工作分解结构”，它其实就是一种按照“自顶向下、逐层分解”的思想建立的一种树形的项目任务清单，这是整个项目执行和控制的基础，如果你不会使用WBS，那基本上就也就等于说你不会管项目了。
结构化方法在编写项目文档以及汇报材料时同样有其用武之地。项目文档其实也是一种交流汇报的材料，为了能让别人看懂，我们先要把事情总体的讲一下，然后将其分为几个大点，每个大点可能又分成几个小点来讲，这样别人就有对你要讲的内容搞清楚了。我看过一本专门教别人写汇报材料的书，叫《金字塔原理》，其实也就是讲如何自上而下组织材料，让汇报变得更有条理。现在你懂了结构化方法，这本书你也就可以省了。
3. 过程思想
ISO9000有八项基本原则，其中一项就是“过程方法”，并将过程定义为：“一组将输入转化为输出的结果”。过程包括三要素：输入、活动、输出，对于这三要素，我想这三素对于程序员来说肯定不会陌生，因为我们在进行软件设计时，所使用的IPO图与它如出一辙，IPO图的三要素是“输入、处理、输出”，两者其实没有什么区别。也就是说，IPO图其实是表达过程的有效工具。
回到PMBok中五大过程组的那张图，它其实就是一张IPO图，它也有由输入-处理-输出组成，即启动-规划、执行、监控-收尾，由此可见，其实整个项目就是一个大的过程，同样，项目阶段也是过程。五大过程组又包含42个过程，每个过程都是由“输入、工具和技术、输出”组成，这与“输入、处理、输出”不是一回事吗？
需要说明的是每个过程并不是个独立的，而是相互关联和衔接的，前一个过程输出成为下一个过程的输入，从而形成了一个个过程链。下图是一个简要的过程链示意图：
图 项目管理中的过程链
转载自：http://www.cnblogs.com/watsonyin/archive/2013/03/10/2934687.html