产品项目管理体系之范围管理

                                                作为一个产品人，你需要让自己保持饥渴的状态，运营、数据分析、项目管理等，都需要涉及。最新迷恋上项目管理的学习，我会把我自己目前在学的项目管理整个技能体系，都给大家做一个简单的分享。

项目管理铁三角

学习项目管理前先认识项目管理著名的铁三角概念，项目铁三角在项目管理中是属于比较靠前，需要先思考。铁三角有三个非常关键的要素：范围、时间、成本。三个基本元素相互影响且关联性强。
举个例子：
[ol]

范围增加，要么时间增加，要么成本增加；

时间缩短，要么范围缩小，要么成本增加；

成本缩小，要么时间增加，要么范围减少；

等等…
[/ol]
这些都是我们在现实场景中会出现的，比如领导要求范围不许动，时间、成本三项都要减少，就会产生产品质量降低的情况。所以在项目管理过程中，会决定着不同的选择，可能需要调整时间或者调整成本等。那么如何调质量？就要看客户满意度，在客户满意度的情况下，保证把项目质量尽力做到最好。
范围管理

范围管理是我们十大知识领域中靠前需要先思考先管起来。
为什么要管范围？
项目范围不好控制，项目的范围会经常变化，所以很多人经常会抱怨“计划赶不上变化”。在实际工作中常会见到公司的产品还处于研发中，但是市场、用户、资源等各个因素都时时发生变化，甚至会出现产品上市后，产品现用户与当初设立的目标用户不同，这些因素的变化都会导致项目定位、需求、方向等要素变化。当然项目管理不只是单纯告诉你“计划赶不上变化”这回事。
那么是不是不做计划，就不会出边“计划赶不上变化”的局面。
明白的人都清楚越是计划赶不上变化的情况下，越是要加强计划的制定，应当认清楚不做计划风险越大。那么做计划的前提基础，要先提明确项目范围，项目过程中哪些活该干，哪些不该干。如果从一开始连项目中什么该做什么不该做都搞不清楚，那么这个项目做成功的概率是非常小的。
所以项目范围管理的重要性，是在于我们在给我们的工作内容圈定范围，以保证我们的工作人员与项目相关的人，都在做这个范围内的事情，保证相关人员都在做范围内的事情，避免干了半天都在做不关项目的活，既浪费大家时间、还浪费公司资源。
项目管理的特点是目标导向非常强的一种管理模式，它本来就是临时性，就是为了短期临时去完成一个目标，只有当我们把所有的关注和资源全新投入到这个目标相关事情上面才能最快最好完成这个目标，不要去做与目标无关的其他事情。
一、收集需求
那么需求是从哪里来的？

常见的需求来源：
[ol]

公司内部（老板/其他部门）

产品经理（策划/挖掘）

外部（用户/客户）
[/ol]
在实际工作中，根据项目章程和项目干系人的分析，我们会发现老板、相关监管部门，不同的职能部门的需求占大部分。
所以在收集需求过程中我们需要去收集所有干系人的需求，然后从这些需求里面其分析哪些需求是可行的哪些需求是不可行的，这是圈定项目范围的第一步。
常用的收集需求方式，定性到定量的一个过程：

最常见的四种数据分析方法有用户访谈、问卷调查、数据分析、可用性测试，本文主要讲解项目管理体系，暂不详细分析每种收集需求方法。
二、定义范围
当我们把需求收集工作做好后，接下来就要去定义项目范围，定义项目范围是为了保证什么该做什么不该做。
定义范围的时候，我们需要对前一步收集来的需求进行分析，哪些需求是我们现在该做、能做、哪些不能做或者后期在做，白纸黑字的记录下来，我们知道需求并不能证明我们最后工作量，其实需求解决的问题是我们最后要交付哪些东西。跟所有干系人确定需求列表后，就能很好的定义项目范围哪些工作我们该做，哪些工作我们不该做。
在定义项目范围过程中，我们要先把我们要交付的产品弄清楚。

产品结构-产品分解
要把整个产品拆分成子产品，每个子产品要完成哪些工作。定义产品的话相对于定义每个子产品，所以要列出产品清单。通常产品清单会由不同模块组成，产品清单并没有唯一的模板。如下图，对汽车的分解。

对于一个IT类的项目，更要定义清楚范围，讲清楚产品产出与交付是什么。
产出一个系统具体是指什么？如CRM系统，那什么叫CRM系统，系统背后是一个集合。
当把CRM系统交付进行分解，可能会有软件、硬件、用户说明书、培训课件教程。不同企业的CRM系统还会出现不一样，有的里面有销售运营报表、有的有用户清单、等。所以每个点都能逐层进行分解，才不会落东西。实际中，我曾经遇到过，运营活动快上线了，才说没有预热；产品上线了才发现缺少产品日志等等。
所以前期的产品分解，分解的越清晰越不会落下东西。因此一开始如果不能定义好要交付的产品，后期会造成很大麻烦。
有了项目分解后，要与定义一份项目范围说明书：
[ol]

项目范围描述（我们要交付哪些产品）

产品验收标准（验收标准与验收人）

项目可交付成果

项目的除外责任（有哪些情况下，某些东西做错不负责任，如有些假设条件出现不可控的情况，负责人不担责）

项目制约因素
[/ol]
制约因素是受制于既定行为或不行为的状态、特性或感觉。可以是来自项目内部或外部的，会影响项目或过程绩效的限制因素。制约因素是已经客观存在的，往往对项目的范围、成本、进度、时间、资源等方面起限制与约束作用。
例如，施加于项目进度的、会影响进度活动时间安排的任何限制或约束，都属于进度制约因素，一般表现为固定的强制日期。如果项目是根据合同实施的，那么合同条款通常也是制约因素。
就像我国汽车售后市场规模已接近9676亿元，但是与整车市场的快速成长不相配，还在一定程度上制约了中国汽车行业的发展，制约因素如下：市场整体质量不高、市场集中度不高、服务水平较低、行业统计数据不到位，同时外资企业扩张较快。这就是项目制约因素。
项目假设条件
是一个将来概念，就是事情还没有发生，到底会出现什么情况谁都不知道。但是在项目管理中，你要对你现在的项目作出假设，假设会出现什么事情影响你的项目，然后提前作出准备，减低不必要的损失。就比如一个户外活动定在周六，结果周六出现暴风雨天气，那么其实在项目开展前就要准备好顶棚之类的东西。
三、创建WBS（核心）
1.创建工作分解结构–WBS。
我们在定义范围的时候，前期理清要交付的东西，然后明白我们需要干什么活，通过工作分解方式去了解我们要干什么活。
分解结构WBS，不止是项目管理，在其他领域都可以使用，当大家发现一件事非常难干不知道怎么做的时候，往往是因为大家将杂乱无章并且把无关的事情与核心工作揉在一起而导致事情难做。当大家没有理清工作顺序、思路时候，它把原来叫一个活进行分开分开，越分解对工作内容越清楚，当把工作分解到一定大小时候，就能将工作落实到负责这工作的人身上。通过拆分成不同层面、不同颗粒度，我们就能更好的把工作关起来。所以不用分解结构工作，是很难将项目管理起来的。
2.什么是WBS？
[ol]

面向可交付成果的对项目工作的层次化分解。

定义项目整个范围，范围内的颗粒度越细越好，这样的话不会再产生超出范围外的需求。

将项目工作分解为较小的，易于管理的多项工作。管理的难度通常取决于要管理这个工作的复杂程度，拆成越小，越好管理。好比一个人管理一大堆事和一个人管理一两件事，后者肯定是比较好管理。

每分解下一层代表对项目更详细的定义。
分解得越细，对项目越了解。就像对某个需求，进行逐层分析，才能想到很多涉及到该需求的其他功能没有想到。所以分解得越细能帮我们再次去分析用户需求对实现需求的理解。
[/ol]
3.常见分解维度
按阶段分解：先把项目工作按照生命周期划分成不同的阶段，再分解每个阶段要做的事情。
如打算迭代一款社交产品V4.0版本的开发工作，收集需求阶段>详细设计阶段>构建开发阶段>整合措施阶段。每个阶段下，都有需要完成的工作。好处：可以看到哪些交付物是属于这个阶段该完成的，有利于阶段性的管控。
按成果分解：他的第一层不是以阶段维度，而是不同类型的交付物。然后为了完成某类交付物，我需要去完成哪些分解后的交付物。如我们去分解产品兼容设备，我们可以划分基础兼容设备、特殊兼容设备，细化层次的兼容设备。好处：保证了我们不会落下交付物，应为我们第一层分解的就是交付物类型。
4.工作包
当进行WBS时候，我们把所有东西都分解到最底层的时候，会形成一种概念——工作包，也叫工作细目。
定义工作包的目的，是为了找到合适的人去承担完成这个工作包这一部分的职责。
什么时候称为分到底了，我们可以监控进度、估算成本和资源，那就可以打包成为一个工作包。并找到一个合适的人与承担的时候，那么这个东西就可以称为一个工作包。
5.WBS分解
WBS分解-最基本远侧
[ol]

100%划分原则，项目中所有工作都要进行WBS划分，所有项目工作都在WBS中提现，如后期发现有遗漏，那就没有100%划分了，就算超出项目范围外。

分解到工作包水平的时候，必须要有人去承担职责，由责任人来自己决定完成工作所需要的资源等。

每一层的分解不能只有一个，常见一个分解成多个才算分解，一个分解一个并不算分解。

要描述合格交付物的状态，特别是产品工作包后，要清楚描述工作包的状态，让责任人能清晰理解工作包的状态。
[/ol]
WBS-最佳实践性质的原则
[ol]

基于可交付物和期望的状态（期望的状态指：开发阶段的状态、测试阶段的状态…）来进行分解。

重点描述产出而不是动作。产出指WBS分解出来的每一要素最好是名词，不是动作。当我们进行WBS分解时候，每一层分解出来的要素都要是名词，如合同、说明书，合同的上传功能，合同审批的功能；动作：创建合同上传功能，创建合同审批的功能，创建一个业务流程的儿描述。为什么要重视产出，应为我们做项目重点要的是输出物，而不是动作，动作是输出物的过程，如打印照片，照片是输出物，打印是动作。有些项目经理分解出来大量的动作，如分析XX需求，开发XX软件等等，所有动作都在，但是把交付物都落下了。我们做项目重要的是动作后能得出产出。所以对于WBS分解也是一样，WBS我们定义的是一个范围，如果我们定义的是一个个产出物，那么其实我们定义的目标是当我们得到某个产出才算完成。

每层分解不要超过9个，超过9个难以控制，建议3-7个。

每个要素只能指定一个负责人，尤其是在我们国家，指定给多个人那基本就是没制定人。由负责人去分配给一些配合人员。一担落到几个人身上，几个人都会觉得不是自己的事情。

每层级别尽量做到100%分解完，再分解下一层，常见的错误分解完一层后，抓住一个点深入分解下去，接着再分解其它层，这样容易出现，一条线分解完后，再分解另一条线同层级的维度会出现不同。
[/ol]
6.WBS表达形式-层次结构图和锯齿列表
[ol]

图形式表达：非常直观，让大家一下就能看出层次之间关系，但是占地大。

锯齿形列表方式：通常不直观，但是能在一张纸里面显示出来。
[/ol]

7.WBS词典
当我们通过WBS把我们主要的交付和工作都理清时候，我们还需要建立WBS词典，WBS词典是对每一个工作分解结构要素的工作和技术文件做详细说明，文档表格根据自己所需制定。

通常WBS词典里需要有11个内容：
[ol]

分解代码：一个项目的WBS可能分解出成千上百的项不同任务，这时候如果不编码会造成混乱。同时编码也能帮助我们标识每个分解出来的任务关系。

工作描述：分解出来的工作描述，如做某个功能的开发，这个开发主要实现什么功能，包括开发语言是什么？负不负责测试？等

负责组织：每个分解出来的任务指派给相关负责人与负责部门。

里程碑清单：标识几个关键的里程碑，这样我们才能知道任务进行到什么阶段，进展是快还是慢。

进度活动：进度需要有一个描述。

所需资源：所需要有哪些资源。

成本估算：时间成本、开发成本、金钱成本等

质量要求：什么程度算完成，测试到什么程度算通过等

验收标准：每个工作完成后，谁去验收、用什么方式去验收。

参考文献：有些活动需要参考不同文档，需要写出参考哪些文档。

合同信息：有些项目需要外包，还需要签署相关合同。
[/ol]
通过WBS分解后的任务活动，如果没有这些注解和解释，很容易产生各种注解和误会，不同的人对活动的注解理解是不一样的，所以产出WBS词典，保证每个人对注解的理解是一致的。
四、核实范围
需求说明书+范围说明书+WBS+WBS词典=项目范围基准（基线）
[ol]

通常项目正式实施之前，需要把基线定义出来，这个基线定义项目需要完成哪些工作才算完成。将来进行项目评价与绩效考核时候，会将产出项目与定义的基线、WBS词典做对比得出偏差有多大。偏差越大则代表项目已经偏离范围。

核实产品是否在范围内，首先要通过【需求跟踪矩阵】去保持客户联系，确定产品范围有没变，确保【需求文档】最新后，用它去核实“确认过质量的产品”【确认的可交付成果】的范围，核实没有问题就可以验收这个产品；如果有问题就要提交一个变更请求。注意在核实和控制过程还是用需求文件，而没有用范围说明书，因为相对需求文件，范围说明书比较粗略。

实际企业中，前期工作没搞这么复杂，只是把项目过程中关键任务关键活动列出来，做个计划，但是这样的计划是不准确的。因为通常意义上，我们做计划前需要把WBS分解到最底层并且找到合适的责任人。最怕的是没将项目WBS分解清楚并且任务责任人也没找着，就开始做计划，这样会导致计划执行不下去，且过程中会一直调整，造成这样的情况就是因为一开始计划就没做清楚。
计划没做清楚还会导致部门/成员合作之间容易产生误会，比如，销售部门的理解和运营部门的理解都是不一样的，我们常说“一千个人眼里就有一千个哈姆雷特”就是在这个道理。
所以为了避免过程中需求一直被调整，计划不断被调整，项目一开始WBS就要分解到最底层，分解清楚，而且每一个分解出来的工作包或者元素能有一个准确的定义，并且整个团队能对此达成共识，这个项目范围就不会容易被改变。

当项目进行实施阶段，项目经理需要检查实际工作范围与实际产出的结果是否与范围基准一致。这时候需要进行范围核实，范围核实是正式验收项目已完成的可交付成果的过程。这个过程中项目经理要做的是组织合适的人去验收，通常项目经理去验收会比较存在风险，比如不懂代码的项目经理如何去验收代码？
[/ol]
五、控制范围
偏差分析
偏差分析是一种确定实际绩效与基准的差异程度及原因的技术，可用于项目绩效测量结果来评估偏离范围基准的程度。用于控制项目偏离范围基准的原因和程度、决定是否需要采取纠正和预防措施。
范围控制是监督性工作，在干活的过程中，该干的活没干，不该干的活却做了，做着做着就跑偏了，所以这个阶段需要进行偏差分析。不断的去比对，现在实际做的工作是不是范围基准以内的工作，如果说与范围基准有误差，那么我们就该停下重新做调整。常见的IT类项目，范围不断地被改变，特别是业务部门对项目的交付物不是特别的想清楚，他们会对交付物不断的调整。如果业务部门提出的交付物与原交付物差别较大，那就需要重新去定义基准，并且重新计划，避免实际交付物与后期调整交付物存在结果、成本、资源等误差。
所以范围控制与范围核实并不完全一样，它们是互补状态，

参与人：核实客户必须参加，控制客户不必参与

时间点：核实在关键的阶段完成点，控制在项目执行全过程

内容：核实只关注最终交付成果，控制关注所有执行过程中输出

范围核实和控制范围是互补的，范围核实关注的是结果，控制范围关注的是过程。