开篇

一、为什么写这个系列的文章？

1、自己的工作岗位发生变化有近一年了，有必要对前几年得工作心得做个系统的整理

2、工作有些时候像个魔咒，虽然不同的人的工作经历都是独特的，但是总有一些弯路被重复的走，希望此系列的文章能给予在路上不久的项目经理一些启迪。

二、个人简短的经历?

大学毕业后就来到现在的公司，有幸能和公司一同成长，在其中学到了很多宝贵的知识。在公司中先后担当过技术组长，资源组长，项目经理，开发经理，部门主管等职位，在项目管理方面参加过 CMMI的EPG改进，PMP培训及其他各种内外部的培训。

三、该系列文章的竞争力？

市场上现在有CMMI，PMP，敏捷开发等很多专业的书籍，相比这些，我这里所写的经验直接来源于实战，在这些年的项目管理中，我认为项目管理是有一些核心的基础，就像武林高手，内功练扎实之后，学习招式便能事半功倍，而空有其招式，顶多算是花架子。

一个知识领域要系统的进行整理或说明首先要有其自己的框架结构，例如：CMMI有5个成熟度和22过程域，PMP有5大过程组和9个知识域。

我将项目管理知识分解为以下结构，后续文章将以此为基础。

框架图

一、公司的主要框架

公司在横向可以分为三个部分，创新过程，运营过程，服务过程。我们这里讲得项目管理将集中在运营过程，但是项目管理在其他两个过程的影响是至关重要的，往往随着公司的变大，各个体系，各个部门之间的会形成很厚的墙。如果每个体系及部门都各自为营，最终项目将很难在客户那里取得最后的成功。项目管理和其他过程的影响，我将在关系人期望及沙盘的2个管理要素中进行覆盖。

二、项目管理的层面

我理解的项目管理分为3个层次，

1、最高层是研发体系对于整个公司各个部门（产品线）的项目的管理

2、中层次是部门对于整个部门内的所有项目的管理

3、最底层的是项目经理对当前项目的管理

此系列文章将从最底层向上依次讲起。

三、项目的主要框架

1、项目的主要里程碑和阶段，可以划分为以下13点，13框分为4个颜色：

1) 蓝色: 规划，用户需求通常由项目外的上级干系人发起

2) 黑色: 技术预研通常发生在用户需求前，用以评估技术风险及可行方案

3) 绿色: 项目质量形成期，在开发团队与测试团队分开的情况下，此时往往以开发团队为主导方。

4) 红色: 项目质量检查期，在开发团队与测试团队分开的情况下，此时往往以测试团队为主导方。

2、项目管理的5要素

1）关系人的期望

我对于项目成功的定义是：满足客户需求，达成干系人期望。我对于优秀项目的定义是：在主要干系人的期望上有亮点（即：超预期）。

因此项目要做到优秀，首先要搞清干系人的期望，尤其是主要干系人。

例如：对一个开发核心功能模块项目，上级主管可能更加关注质量及其后续可维护性，

而对另外针对某一个具体客户的定制项目，上级主管可能更加关注进度的准确性及客户需求的符合程度。

2）沙盘

沙盘一词来源于战场，战场上将军需要依靠沙盘做出战术决策，或分而击之或围而聚歼。一个项目的管理如果指挥一场战役，你的思路将决定这场战役的成败。而每场战争都是独一无二的，因此针对每个项目，都需要找出它的三寸，集中精力击之，如此才能确保项目或阶段启动前我们已经在正确的方向上就绪。

例如：对于一个性能提升为主要目标的项目，性能测试环境的及时搭建，相关模块改动对性能的影响，性能在某些场景下未达标需要调优，这些问题的及时跟进将成为三寸之地。

而对于一个有很多新需求，界面改动量很大的项目，客户需求的完整和清晰度，对其他已有需求造成的影响，如何保证客户的体验，这些问题将成为此项目的主要关注点。

3）计划制定

项目计划是整个项目得以有序控制的基本手段。好的项目计划要达成3个目标：

1、项目计划具有可行性，不能做明知完不成的计划（有不少项目经理习惯通过制定一个不可达成的项目计划，向项目团队施压，其实这是一种打击团队士气及丧失公信力的坏方法，非常不推荐）

2、项目计划需要能落实沙盘

3、项目计划需要和团队成员达成一致。正如孙子兵法云：上下同欲者，胜。

4）风险管理

风险管理的两个核心点在于：

1、有机制能够及时发现风险

2、发现风险后要立刻采取措施

工作中发现大多数项目经理困于第一点，无法及时的发现风险，风险识别早晚将决定项目组需要付出代价的多少。而也有一些少数的项目经理，发现风险后并不能立刻采取措施，一味的妥协和自我安慰，导致项目最后失败。

5）团队管理

团队管理涉及到沟通、激励等项目经理的软技能，项目经理的软技能将决定项目团队的氛围，战斗力。

规划

规划阶段通常是项目启动第一个阶段，在此阶段里产品经理会将项目目标传递给项目经理。

万事开头难，好的开始是成功的一半，此阶段里项目经理就应该打起精神，迅速进入状态，做好战事准备。

我将按项目管理的5要素来分解在此阶段中，项目经理应该重点关注的事项。

一、干系人期望

如下曲线可以看出，干系人的影响是随着项目进度的推进逐步变小的，如果在中后期干系人要进行相关变更，成本会比较高。

也就是“方向不对，越努力，结果越惨”，因此在项目前期管理好干系人期望至关重要。

在准备动手管理干系人期望前，需要知道项目存在的”三重制约“，即：范围，时间，成本。简单一句话概况：即领导通常希望项目做得“更多，更快，更便宜”，然而正常情况下，这三者不可兼得，此时理清项目的最关注点，便显得格外重要。

在规划阶段，干系人通常是产品经理、主管，客户。在我现在的公司常见是前两者，产品经理或主管通常会把市场目标转化为项目目标然后下派给项目经理。

这时的期望常见于3点：

1) 市场期望 能够明确此项目的使命和功能列表的优先级。 深刻理解项目对市场的意义，能够让项目经理更好的选择决策方式。

例1：小赖带了一个项目主要是为了争夺一个细分市场的份额，此市场份额不大，但是当前市场没有产品满足该市场的客户需求，从公司角度出发项目投入产出比符合要求，所以启动了该项目。但是在项目预研过程中，小赖从网上搜集资料时，意外发现最近已经有一家厂商出了类似产品，经过自己的进一步分析，小赖认为这家公司的产品目标和自己的项目标是一致的，于是向上级领导汇报了该情况并加入自己的分析，最后项目及时被叫停，公司避免了损失，小赖也因此得到表扬。

例2：小张带了另外一个大项目，项目里有很多功能要实现，但是由于预研时考虑不足，在一个功能的实现里遇到一个棘手的问题，此时有两种方法，一种花较高的代价修复这个问题，另外一种是使用规避措施绕过去，但是对该功能带来一个小的体验影响。因为在规划的定位里此功能优先级较低，所以小张决定和上级领导讨论下，最终项目采用了第二种方法。

2) 人力投入期望

投入产出比是任何主管都需要关注的事情，当一个项目的人力投入远超过预期时，可能该项目的重要性要重新评估。项目经理应该在项目的预研阶段及时反馈是否项目的方案已超过预期。

3) 时间期望

有时候有些是项目是有明确的市场时间预期的，这种情况下，项目经理应该有严格的倒推计划里程碑，当规划或预研时发现时间不可达时需要及时提出讨论，看是否分两期划分项目或是增多人力等。

二、沙盘

当规划评审确定下来后--即初步的目标已经明确，此时项目经理应该对项目进行下整体分析，理清出自己的思路，找出项目的难点和关注点在哪里。

例1：小李接到了一个跨很多部门合作的项目，他思路是：自己先制定一份初步合作计划，里面包含各部门配合方式及考核方法分配，并取得公司认可，以此对推动项目进展可控打下基础。

例2：小杨接到一个时间周期很紧张的项目，他的思路是：因为版本的各个模块的工作量分布不平均，为了充分利用时间，决定打破传统的瀑布式开发，选择迭代快速跟进，并在项目初期和公司流程团队和测试部取得一致。

例3：小邱接到一个性能改进的项目，他的思路是：

1、因为部门之前对性能测试方法不规范，首先界定清性能提高的验证方法

2、涉及的硬件配置开始前和硬件部门讨论

3、和主管预定1个性能优化相关的专家

例4：小吴接到一个将5个分支产品合入主线产品的项目，他的思路是：

1、将各分支产品之间和主线产品的功能影响细致的确认下来，将受到的影响的功能进行评估

2、项目开发过程中需要有机制跟进各产品的更新情况

3、开始合入前，评估各产品的代码质量及代码重复读，决定是否抽取公共代码或是重写部分分支产品

三 、计划制定

计划制定主要是产出预研项，以便做对应项的预研计划。对于大项目（超过10人规模），分解预研项将面临遗失问题。如果规划阶段的预研项分解不完全，会导致项目后期有大量返工。

这里常见有效方法：

1、项目管理上重视，对于实现不清晰的地方不放过。

2、使用经验库

3、专家咨询

4、风险管理

这里的风险管理同第3点。

五、团队管理

规划阶段时，通常只有项目经理1人投入，对于一些项目是项目经理、技术经理2人投入。 此时的团队还处理组建阶段，这时候最主要的事情便是和上级领导做好核心人员的预分配，即什么时间核心人员需要到位。

技术预研

当从规划中分解到预研项后，我们将进行预研工作。此阶段的工作会对项目中的重大风险或技术方案的不确定性进行攻关，能有效率完成此阶段，是项目经理的一个重要挑战。我见过很多项目经理对项目整体管理把握都很好，但是由于对预研阶段的工作把握度不够，导致项目失控。

按五要素分解预研阶段的工作如下：

一、干系人期望

此阶段的干系人主要是预研人员和产品经理。

1) 预研的方案复杂度在规划预期内

所有项目都需要在投入产出比做权衡，在预研启动前，我们要知道主管/产品经理的心理预期，如果当预研的方案实现的复杂度会远超过预期时，需要及时提出，并安排讨论，必要时需要停止预研。

2）预研要消除实现风险

预研阶段的主要目的是消除整个项目的实现风险，预研阶段结束，大家会有个共识，那就是项目可以被实现出来，整个项目计划的工作量估算将也重要参考预研结论。

二、沙盘

技术预研要做好，首先要有两个前提：有明确的目标值，有可操作的验收方法。

1）有明确的目标

例如：预研一个方案，最后提交的方案需要占用1G内存，而这个内存消耗不能被接受，这时便会带来返工，同时预研人员会新生怨念，为什么不早说呢，害伤神，伤身。

因此这里通常的办法是预研开始前，下发预研目标书，目标书里包含对此项预研所能消耗的资源进行详细限制，例如：内存，cpu，稳定性等。

2）有可操作的验收方法

没有可操作的验收方法，目标就会得不到执行，变成空口白话或脱离本意。因此在预研开始前确认好验收方法至关重要。

例1：目标：新增加的预研方法对原有的系统的性能影响不超过5%

可验收的方法：加载此模块与不加载此模块，在3个相同的业务流里统计所消耗的cpu周期，来计算是否超过5%

例2：目标：前端一个复杂页面的响应速度在客户正常使用过程中3S内返回。

可验收的方法：在2个典型的客户业务流下，非cpu空载情况下测试页面响应速度。

三、计划制定

1）预研项的整体计划

预研阶段的整体计划通常很难定的100%准确，尤其对于风险较大的定制，但是一个整体的计划的参考时间点，会给人一个目标，从而得到方向感。

2）快速跟进

快速跟进是预研阶段最靠谱的跟进计划的方法。因为当方案等没有确认下来时，很难有准确的计划，但是通过快速跟进我们可以及时调整当前的计划--滚动式计划。

快速跟进常见两种方法：阶段性，时间性。

阶段性即：将当前预研分为几个阶段（例如：环境搭建，思路1尝试，思路2尝试等），每个阶段汇报和讨论工作情况。

时间性即：每2天，每1周等确认预研进展。

当然根据所在项目要求可以调整使用两种方式的混合体。

四、风险

典型的三种情况：

1) 预研过度，常见于谨慎型或对技术缺乏自信的项目经理。他们要在预研阶段消除所有的风险，因为预研阶段的代码没有经过设计阶段，所以后续项目编码过程中很难复用，导致工作量浪费，从而导致整个项目周期变紧张。

2) 预研不足，常见于缺乏大局观或技术自信较强的项目经理，他们经常根据自己的判断在项目中选定出几个风险做重要跟进，他们经常不经意间忽略掉自己不擅长或不熟悉的领域的风险，导致项目进入后续阶段后，灾难频发，救火进行的总是如火如荼。

3) 预研思路不正确，导致工作返工较大。

消除这里三种典型情况的方法就是：在项目组中尽早形成良性的技术决策链，这里需要依靠团队管理提供基础

五、团队管理

1）团队组建

此阶段的项目核心人员应该已经或将陆续到位，这时候要开下项目启动会。主要要做两件事：

a、阐述整个项目的目标和意义

任何人都希望自己做重要的事情，而既然公司或部门决定投入人力去启动这个项目，自然是存在重要意义的，此时要将这个意义传达给项目组员，以便调动大家工作积极性。

如约翰·科特所说：“如果你想建造一艘船，首先要做的不是去采集木材、加工木板和分派工作，而应该去唤起人们对广阔无垠大海的向往。“

b、集中办公-座位搬到一

大多数时候项目组的成员来自一个或多个部门，之前的座位不是靠在一起的，项目组成立后，应该要把座位调到一起，集中办公是交流方式最有效率的方法之一，没有其二。

c、 需要给预研人员讲解规划，让其了解此预研项的意义

这样做的目的，是为了让预研人员能够理解启动该预研的目的，通常当我们深入研究某件事情时，很有可能触发其他解决问题的思路。明确的目的能让有些时候预研人员自主变通。

例如：项目组安排给小吴预研目标是：验证网卡的MSI多队列能否在linux2.4内核上实现，目的：提高性能

小吴最后给出这样预研结论，网卡多队列完整移植到2.4上工作量很大，而且有困难，但是有折中的办法，移植一部分MSI的功能，将触发方式改为定时器实现，如此即完成提高性能的目的，又能节约工作量.

2）形成技术决策方式

预研阶段的技术方案跟进或其中的疑难问题如何跟进和处理，需要明确。这里明确的好处如下：

a、项目组员思路受卡时，知道向谁请教问题

b、如果不是项目经理自己跟技术问题，技术相关决策人能够明确自己的责任