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

内容导航：

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

项目范围管理包括哪些内容

项目管理体系包含哪些内容

PMP|十大知识体系（二）项目范围管理

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

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

项目管理铁三角

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

举个例子：

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

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

范围管理

范围管理是我们十大知识领域中靠前需要先思考先管起来。

为什么要管范围？

项目范围不好控制，项目的范围会经常变化，所以很多人经常会抱怨“计划赶不上变化”。在实际工作中常会见到公司的产品还处于研发中，但是市场、用户、资源等各个因素都时时发生变化，甚至会出现产品上市后，产品现用户与当初设立的目标用户不同，这些因素的变化都会导致项目定位、需求、方向等要素变化。当然项目管理不只是单纯告诉你“计划赶不上变化”这回事。

那么是不是不做计划，就不会出边“计划赶不上变化”的局面。

明白的人都清楚越是计划赶不上变化的情况下，越是要加强计划的制定，应当认清楚不做计划风险越大。那么做计划的前提基础，要先提明确项目范围，项目过程中哪些活该干，哪些不该干。如果从一开始连项目中什么该做什么不该做都搞不清楚，那么这个项目做成功的概率是非常小的。

所以项目范围管理的重要性，是在于我们在给我们的工作内容圈定范围，以保证我们的工作人员与项目相关的人，都在做这个范围内的事情，保证相关人员都在做范围内的事情，避免干了半天都在做不关项目的活，既浪费大家时间、还浪费公司资源。

项目管理的特点是目标导向非常强的一种管理模式，它本来就是临时性，就是为了短期临时去完成一个目标，只有当我们把所有的关注和资源全新投入到这个目标相关事情上面才能最快最好完成这个目标，不要去做与目标无关的其他事情。

一、收集需求

那么需求是从哪里来的？

常见的需求来源：

公司内部（老板/其他部门）产品经理（策划/挖掘）外部（用户/客户）

在实际工作中，根据项目章程和项目干系人的分析，我们会发现老板、相关监管部门，不同的职能部门的需求占大部分。

所以在收集需求过程中我们需要去收集所有干系人的需求，然后从这些需求里面其分析哪些需求是可行的哪些需求是不可行的，这是圈定项目范围的第一步。

常用的收集需求方式，定性到定量的一个过程：

最常见的四种数据分析方法有用户访谈、问卷调查、数据分析、可用性测试，本文主要讲解项目管理体系，暂不详细分析每种收集需求方法。

二、定义范围

当我们把需求收集工作做好后，接下来就要去定义项目范围，定义项目范围是为了保证什么该做什么不该做。

定义范围的时候，我们需要对前一步收集来的需求进行分析，哪些需求是我们现在该做、能做、哪些不能做或者后期在做，白纸黑字的记录下来，我们知道需求并不能证明我们最后工作量，其实需求解决的问题是我们最后要交付哪些东西。跟所有干系人确定需求列表后，就能很好的定义项目范围哪些工作我们该做，哪些工作我们不该做。

在定义项目范围过程中，我们要先把我们要交付的产品弄清楚。

产品结构-产品分解

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

对于一个IT类的项目，更要定义清楚范围，讲清楚产品产出与交付是什么。

产出一个系统具体是指什么？如CRM系统，那什么叫CRM系统，系统背后是一个集合。

当把CRM系统交付进行分解，可能会有软件、硬件、用户说明书、培训课件教程。不同企业的CRM系统还会出现不一样，有的里面有销售运营报表、有的有用户清单、等。所以每个点都能逐层进行分解，才不会落东西。实际中，我曾经遇到过，运营活动快上线了，才说没有预热；产品上线了才发现缺少产品日志等等。

所以前期的产品分解，分解的越清晰越不会落下东西。因此一开始如果不能定义好要交付的产品，后期会造成很大麻烦。

有了项目分解后，要与定义一份项目范围说明书：

项目范围描述（我们要交付哪些产品）产品验收标准（验收标准与验收人）项目可交付成果项目的除外责任（有哪些情况下，某些东西做错不负责任，如有些假设条件出现不可控的情况，负责人不担责）项目制约因素

制约因素是受制于既定行为或不行为的状态、特性或感觉。可以是来自项目内部或外部的，会影响项目或过程绩效的限制因素。制约因素是已经客观存在的，往往对项目的范围、成本、进度、时间、资源等方面起限制与约束作用。

例如，施加于项目进度的、会影响进度活动时间安排的任何限制或约束，都属于进度制约因素，一般表现为固定的强制日期。如果项目是根据合同实施的，那么合同条款通常也是制约因素。

就像我国汽车售后市场规模已接近9676亿元，但是与整车市场的快速成长不相配，还在一定程度上制约了中国汽车行业的发展，制约因素如下：市场整体质量不高、市场集中度不高、服务水平较低、行业统计数据不到位，同时外资企业扩张较快。这就是项目制约因素。

项目假设条件

是一个将来概念，就是事情还没有发生，到底会出现什么情况谁都不知道。但是在项目管理中，你要对你现在的项目作出假设，假设会出现什么事情影响你的项目，然后提前作出准备，减低不必要的损失。就比如一个户外活动定在周六，结果周六出现暴风雨天气，那么其实在项目开展前就要准备好顶棚之类的东西。

三、创建WBS（核心）1.创建工作分解结构–WBS。

我们在定义范围的时候，前期理清要交付的东西，然后明白我们需要干什么活，通过工作分解方式去了解我们要干什么活。

分解结构WBS，不止是项目管理，在其他领域都可以使用，当大家发现一件事非常难干不知道怎么做的时候，往往是因为大家将杂乱无章并且把无关的事情与核心工作揉在一起而导致事情难做。当大家没有理清工作顺序、思路时候，它把原来叫一个活进行分开分开，越分解对工作内容越清楚，当把工作分解到一定大小时候，就能将工作落实到负责这工作的人身上。通过拆分成不同层面、不同颗粒度，我们就能更好的把工作关起来。所以不用分解结构工作，是很难将项目管理起来的。

2.什么是WBS？ 面向可交付成果的对项目工作的层次化分解。定义项目整个范围，范围内的颗粒度越细越好，这样的话不会再产生超出范围外的需求。将项目工作分解为较小的，易于管理的多项工作。管理的难度通常取决于要管理这个工作的复杂程度，拆成越小，越好管理。好比一个人管理一大堆事和一个人管理一两件事，后者肯定是比较好管理。每分解下一层代表对项目更详细的定义。分解得越细，对项目越了解。就像对某个需求，进行逐层分析，才能想到很多涉及到该需求的其他功能没有想到。所以分解得越细能帮我们再次去分析用户需求对实现需求的理解。

3.常见分解维度

按阶段分解：先把项目工作按照生命周期划分成不同的阶段，再分解每个阶段要做的事情。

如打算迭代一款社交产品V4.0版本的开发工作，收集需求阶段>详细设计阶段>构建开发阶段>整合措施阶段。每个阶段下，都有需要完成的工作。好处：可以看到哪些交付物是属于这个阶段该完成的，有利于阶段性的管控。

按成果分解：他的第一层不是以阶段维度，而是不同类型的交付物。然后为了完成某类交付物，我需要去完成哪些分解后的交付物。如我们去分解产品兼容设备，我们可以划分基础兼容设备、特殊兼容设备，细化层次的兼容设备。好处：保证了我们不会落下交付物，应为我们第一层分解的就是交付物类型。

4.工作包

当进行WBS时候，我们把所有东西都分解到最底层的时候，会形成一种概念——工作包，也叫工作细目。

定义工作包的目的，是为了找到合适的人去承担完成这个工作包这一部分的职责。

什么时候称为分到底了，我们可以监控进度、估算成本和资源，那就可以打包成为一个工作包。并找到一个合适的人与承担的时候，那么这个东西就可以称为一个工作包。

5.WBS分解

WBS分解-最基本远侧

100%划分原则，项目中所有工作都要进行WBS划分，所有项目工作都在WBS中提现，如后期发现有遗漏，那就没有100%划分了，就算超出项目范围外。分解到工作包水平的时候，必须要有人去承担职责，由责任人来自己决定完成工作所需要的资源等。每一层的分解不能只有一个，常见一个分解成多个才算分解，一个分解一个并不算分解。要描述合格交付物的状态，特别是产品工作包后，要清楚描述工作包的状态，让责任人能清晰理解工作包的状态。

WBS-最佳实践性质的原则

基于可交付物和期望的状态（期望的状态指：开发阶段的状态、测试阶段的状态…）来进行分解。重点描述产出而不是动作。产出指WBS分解出来的每一要素最好是名词，不是动作。当我们进行WBS分解时候，每一层分解出来的要素都要是名词，如合同、说明书，合同的上传功能，合同审批的功能；动作：创建合同上传功能，创建合同审批的功能，创建一个业务流程的儿描述。为什么要重视产出，应为我们做项目重点要的是输出物，而不是动作，动作是输出物的过程，如打印照片，照片是输出物，打印是动作。有些项目经理分解出来大量的动作，如分析XX需求，开发XX软件等等，所有动作都在，但是把交付物都落下了。我们做项目重要的是动作后能得出产出。所以对于WBS分解也是一样，WBS我们定义的是一个范围，如果我们定义的是一个个产出物，那么其实我们定义的目标是当我们得到某个产出才算完成。每层分解不要超过9个，超过9个难以控制，建议3-7个。每个要素只能指定一个负责人，尤其是在我们国家，指定给多个人那基本就是没制定人。由负责人去分配给一些配合人员。一担落到几个人身上，几个人都会觉得不是自己的事情。每层级别尽量做到100%分解完，再分解下一层，常见的错误分解完一层后，抓住一个点深入分解下去，接着再分解其它层，这样容易出现，一条线分解完后，再分解另一条线同层级的维度会出现不同。

6.WBS表达形式-层次结构图和锯齿列表 图形式表达：非常直观，让大家一下就能看出层次之间关系，但是占地大。锯齿形列表方式：通常不直观，但是能在一张纸里面显示出来。

7.WBS词典

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

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

分解代码：一个项目的WBS可能分解出成千上百的项不同任务，这时候如果不编码会造成混乱。同时编码也能帮助我们标识每个分解出来的任务关系。工作描述：分解出来的工作描述，如做某个功能的开发，这个开发主要实现什么功能，包括开发语言是什么？负不负责测试？等负责组织：每个分解出来的任务指派给相关负责人与负责部门。里程碑清单：标识几个关键的里程碑，这样我们才能知道任务进行到什么阶段，进展是快还是慢。进度活动：进度需要有一个描述。所需资源：所需要有哪些资源。成本估算：时间成本、开发成本、金钱成本等质量要求：什么程度算完成，测试到什么程度算通过等验收标准：每个工作完成后，谁去验收、用什么方式去验收。参考文献：有些活动需要参考不同文档，需要写出参考哪些文档。合同信息：有些项目需要外包，还需要签署相关合同。

通过WBS分解后的任务活动，如果没有这些注解和解释，很容易产生各种注解和误会，不同的人对活动的注解理解是不一样的，所以产出WBS词典，保证每个人对注解的理解是一致的。

四、核实范围

需求说明书+范围说明书+WBS+WBS词典=项目范围基准（基线）

通常项目正式实施之前，需要把基线定义出来，这个基线定义项目需要完成哪些工作才算完成。将来进行项目评价与绩效考核时候，会将产出项目与定义的基线、WBS词典做对比得出偏差有多大。偏差越大则代表项目已经偏离范围。核实产品是否在范围内，首先要通过【需求跟踪矩阵】去保持客户联系，确定产品范围有没变，确保【需求文档】最新后，用它去核实“确认过质量的产品”【确认的可交付成果】的范围，核实没有问题就可以验收这个产品；如果有问题就要提交一个变更请求。注意在核实和控制过程还是用需求文件，而没有用范围说明书，因为相对需求文件，范围说明书比较粗略。实际企业中，前期工作没搞这么复杂，只是把项目过程中关键任务关键活动列出来，做个计划，但是这样的计划是不准确的。因为通常意义上，我们做计划前需要把WBS分解到最底层并且找到合适的责任人。最怕的是没将项目WBS分解清楚并且任务责任人也没找着，就开始做计划，这样会导致计划执行不下去，且过程中会一直调整，造成这样的情况就是因为一开始计划就没做清楚。计划没做清楚还会导致部门/成员合作之间容易产生误会，比如，销售部门的理解和运营部门的理解都是不一样的，我们常说“一千个人眼里就有一千个哈姆雷特”就是在这个道理。所以为了避免过程中需求一直被调整，计划不断被调整，项目一开始WBS就要分解到最底层，分解清楚，而且每一个分解出来的工作包或者元素能有一个准确的定义，并且整个团队能对此达成共识，这个项目范围就不会容易被改变。当项目进行实施阶段，项目经理需要检查实际工作范围与实际产出的结果是否与范围基准一致。这时候需要进行范围核实，范围核实是正式验收项目已完成的可交付成果的过程。这个过程中项目经理要做的是组织合适的人去验收，通常项目经理去验收会比较存在风险，比如不懂代码的项目经理如何去验收代码？

五、控制范围偏差分析

偏差分析是一种确定实际绩效与基准的差异程度及原因的技术，可用于项目绩效测量结果来评估偏离范围基准的程度。用于控制项目偏离范围基准的原因和程度、决定是否需要采取纠正和预防措施。

范围控制是监督性工作，在干活的过程中，该干的活没干，不该干的活却做了，做着做着就跑偏了，所以这个阶段需要进行偏差分析。不断的去比对，现在实际做的工作是不是范围基准以内的工作，如果说与范围基准有误差，那么我们就该停下重新做调整。常见的IT类项目，范围不断地被改变，特别是业务部门对项目的交付物不是特别的想清楚，他们会对交付物不断的调整。如果业务部门提出的交付物与原交付物差别较大，那就需要重新去定义基准，并且重新计划，避免实际交付物与后期调整交付物存在结果、成本、资源等误差。

所以范围控制与范围核实并不完全一样，它们是互补状态，

参与人：核实客户必须参加，控制客户不必参与时间点：核实在关键的阶段完成点，控制在项目执行全过程内容：核实只关注最终交付成果，控制关注所有执行过程中输出

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

本文由 @阿信 原创发布于人人都是产品经理。未经许可，禁止转载。

一、项目范围管理包括哪些内容

项目范围是指完成项目所需的所有项目工作。管理这项工作对于项目成功至关重要。在管理范围时，确定任务的优先级至关重要，这样你才能有效地规划和分配资源。

为了管理范围，项目经理需要：
-使用范围管理计划来明确定义将要完成的项目活动
-与所有利益相关者共享范围管理计划，让每个人都在同一个页面上
-使用变更单来避免范围蔓延并跟踪对项目范围所做的所有变更
-管理干系人的期望以维持项目范围
-使用任务管理工具和技术来跟踪范围内的所有项目活动

项目经理采取的这些范围管理行动都是必不可少的，因为每项任务所需的时间对最终产品的成本和质量至关重要。这会对进度和成本产生很大影响，尤其是在项目规模很大的情况下。

8Manage PM项目管理软件具有任务管理功能，可以轻松分配、排序和优先处理你的任务。通过这种方式，你可以将所有关键项目任务委派给合适的人员，从而防止可怕的范围蔓延。此外，通过提供文件共享和任务评论，团队可实现任务级别的协作。

二、项目管理体系包含哪些内容

第一，项目范围管理。这主要是为了实现项目的目标，对项目的工作内容进行控制的管理过程宴培。主要工作包括了范围的界定，范围的规划，范围的调整等。
第二，项目时间管理扒链。是为了确保项目最终的按时完成的一系列管理过程。所包括的工作内容比较多，例如具体活动界定，活动排序，时间估计，进度安排及时间控制等各项工作。
第三，项目成本管理。是为了保证完成项目的实际成本、费用不超过预算成本、费用的管理过程。
第四，项目质量管理。这是为了达到用户所期待的质量，从而要完成的工作，质量规划、质量控制等都是要做的。
第五，项目人力资源管理。保证所有参与项目的人能够最有效的发挥自己的实力完春祥孙成管理措施。组织的规划、团队建设、人员招聘等都是项目人力资源管理所负责的。
除了以上提到的五点，8Manage PM项目管理系统还包含项目沟通管理、项目风险管理、项目采购管理、项目集成管理、项目干系人管理等，这些都是项目管理所包括的内容。

三、PMP|十大知识体系（二）项目范围管理

项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。做且只做范围内的工作，避免画蛇添足。

项目范围管理过程包括：规划范围管理，收集需求，定义范围，创建WBS，确认范围，控制范围六个过程，下面将对每个过程做重点阐述。

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。这一过程解决的是整个项目期间对如何管理范围提供指导性文件。

在项目环境中，“范围”有两种含义：

（1）产品范围：某项产品、服务或成果所具有的特征和功能。

（2）项目范围：为交付产品、服务或成果所必须完成的工作。

1-2-1 输入

（1）项目章程

记录项目目的、项目概述、假设条件、制约因素，以及项目意图实现的高层级需求。

（2）项目管理计划

  质量管理计划 ：在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。

项目生命周期描述： 项目生命周期定义了项目从开始到完成所经历的一系列阶段。

开发方法： 开发方法定义了项目是采用瀑布式、迭代型、适应型、敏捷型还是混合型开发方法。

（3）事业环境因素

组织文化；基础设施；人事管理制度；市场条件。

（4）组织过程资产

政策和程序；历史信息和经验教训知识库。

1-2-2 工具与技术

（1）专家判断

需给出判断意见的主题：以往类似项目；特定行业、学科和应用领域的信息。

（2）数据分析

用于评估收集需求、详述项目和产品范围、创造产品、确认范围和控制范围的各种方法。比如常用的数据分析技术备选方案分析。

（3）会议

参会者可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方、范围管理各过程的负责人，以及其他必要人员。

1-2-3 输出

（1）范围管理计划

范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。

范围管理计划的内容包括：制定项目范围说明书；根据详细项目范围说明书创建 WBS；确定如何审批和维护范围基准；正式验收已完成的项目可交付成果。

（2）需求管理计划

需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。

需求管理计划的主要内容包括：如何跟踪，规划和报告各种需求活动；配置管理如何启动变更，如何分析影响，如何追溯，跟踪报告，如何变更审批权限等活动；需求优先级排序；测量指标及应用这些指标的理由；反映哪些需求属性将被列入跟踪矩阵的跟踪结构等。

收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。

解决的是需要什么的问题。

2-2-1 输入

（1）项目章程

重点关注的是项目章程里面记录的项目概述以及将用于制定详细需求的高层级需求。

（2）项目管理计划

范围管理计划 ：范围管理计划包含如何定义和制定项目范围的信息。

需求管理计划 ：需求管理计划包含如何收集、分析和记录项目需求的信息。

相关方参与计划 ：从相关方参与计划中了解相关方的沟通需求和参与程度，以便评估并适应相关方对需求活动的参与程度。

（3）项目文件

假设日志： 有关产品、项目、环境、相关方以及会影响需求的其他因素的假设条件。

经验教训登记册 ：有效的需求收集技术，尤其针对使用迭代型或适应型产品开发方法的项目。

相关方登记册： 用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望。

（4）商业文件

会影响收集需求过程的商业文件是商业论证，它描述了为满足业务需要而应该达到的必要、期望及可选标准。

（5）协议

协议包含的项目和产品需求部分。

（6）事业环境因素

能够影响收集需求过程的事业环境因素包括：组织文化，基础设施，人事管理制度，市场条件。

（7）组织过程资产

能够影响收集需求过程的组织过程资产包括：政策和程序；包含以往项目信息的历史信息和经验教训知识库。

2-2-2 工具与技术

（1）专家判断

针对以下方面给出专家意见：商业分析，需求获取，需求分析，需求文件，以往类似项目的项目需求，图解技术，引导，冲突管理。

（2）数据收集

头脑风暴： 用于产生和收集对项目需求和产品需求的创意技术。

访谈： 与相关方直接交谈，目的是识别和定义所需产品可交付成果的特征和功能，甚至可能获取到机密信息。

焦点小组： 召集预定的相关方和主题专家，一起研讨，目的是了解他们对所讨论产品，服务或成果的期望和态度。

问卷调查： 问卷调查方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。

标杆对照： 将实际或计划的产品，过程和实践，与其他组织的进行比较，可比组织可以是内部也可以是外部。

（3）数据分析

用于本过程的数据分析主要是文件分析，文件分析包括审核和评估任何相关的文件信息，以识别和获取需求。

（4）决策

适用于手机需求过程的决策技术包括：

投票： 本技术用于生成，归类和排序产品需求，结果包括一致同意（每个人），大多数同意（超过50%）和相对多数同意

独裁型决策制定： 由一个人负责为整个集体制定决策。

多标准决策分析： 借助决策矩阵，用系统分析方法建立诸如风险水平，不确定性和价值收益等多种标准，以对众多创意进行评估和排序。

（5）数据表现

亲和图： 对大量技术进行分组，以便进一步审查和分析。

思维导图： 头脑风暴结果的呈现，用于反映创意间的共性和差异，激发新创意。

（6）人际关系与团队技能

名义小组技术 ：一种结构化的头脑风暴形式，有四个步骤：向集体提出问题，每个人写出想法；主持人记录所有人想法；集体讨论想法达成明确的共识；私下投票决出各种想法的优先排序，得分高者胜出。

观察和交谈 ：直接察看个人在各自的环境中如何执行工作（或任务）和实施流程。

引导 ：把主要相关方召集在一起定义产品需求，有效引导参与者积极参与给出意见。适合引导的场景包括联合应用设计或开发 (JAD)、质量功能展开 (QFD)、用户故事

（7）系统交互图

对产品范围的可视化绘制，显示业务系统（过程，设备，计算机系统等）及其与人和其他系统（行动者）之间的交互方式。展示了业务系统的输入，输入提供者，业务系统的输出和输出接收者。

（8）原型法

原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。

2-2-3 输出

（1)需求文件

需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。

需求分类包括：业务需求、相关方需求、解决方案需求（功能需求/非功能需求）、过渡和就绪需求、项目需求、质量需求

（2）需求跟踪矩阵

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。

可应用于整个项目生命周期中跟踪需求。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期等。

3-1 定义

定义范围是制定项目和产品详细描述的过程，本过程的主要作用是，描述产品、服务或成果的边界和验收标准，解决的是需要做什么的问题。

本质是从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。

3-2 重点描述

3-2-1 输入

（1）项目章程

项目章程中包含对项目的高层级描述、产品特征和审批要求。

（2）项目管理计划

项目管理计划中的范围管理计划记录了如何定义、确认和控制项目范围。

（3）项目文件

假设日志： 有关产品、项目、环境、相关方以及会影响项目和产品范围的假设条件和制约因素。

需求文件： 应纳入范围的需求。

风险登记册： 可能影响项目范围的应对策略，例如缩小或改变项目和产品范围，以规避或缓解风险。

（4）事业环境因素

 组织文化；基础设施；人事管理制度；市场条件。

（5）组织过程资产

用于制定项目范围说明书的政策、程序和模板；以往项目的项目档案；以往阶段或项目的经验教训。

3-2-2 工具与技术

（1）专家判断

（2）数据分析

此过程中常用备选方案分析，备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法。

（3）决策

常用的是多标准决策分析，多标准决策分析是一种借助决策矩阵来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。

（4）人际关系与团队技能

通过引导使关键相关方就项目可交付成果以及项目和产品边界达成跨职能的共识。

（5）产品分析

产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。

产品分析技术包括产品分解，需求分析，系统分析，系统工程，价值分析，价值工程。

3-2-3 输出

（1）项目范围说明书

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。包括：

  产品范围描述： 逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。

可交付成果 ：为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或

服务能力 ：可交付成果也包括各种辅助成果，如项目管理报告和文件。

  验收标准 ：可交付成果通过验收前必须满足的一系列条件。

项目的除外责任 ：识别排除在项目之外的内容。

（2）项目文件更新

可在本过程更新的文件包括：假设日志，需求文件，需求跟踪矩阵，相关方登记册。

4-1 定义

创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程解决的是怎么做的问题。

4-2 重点描述

4-2-1 输入

（1）项目管理计划

项目管理计划中的范围管理计划定义了如何根据项目范围说明书创建 WBS。

（2）项目文件

项目范围说明书：需要实施的工作及不包含在项目中的工作。

需求文件：各种单一需求如何满足项目的业务需要。

（3）事业环境因素

会影响创建 WBS 过程的事业环境因素包括（但不限于）项目所在行业的 WBS 标准，这些标准可以作为创建 WBS 的外部参考资料。

（4）组织过程资产

能够影响创建 WBS 过程的组织过程资产包括（但不限于）：用于创建 WBS 的政策、程序和模板；以往项目的项目档案；以往项目的经验教训

4-2-2 工具与技术

（1）专家判断

（2）分解

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。

4-2-3 输出

（1）范围基准

范围基准是经过批准的范围说明书、WBS 和相应的 WBS 词典。

项目范围说明书 ：包括对项目范围、主要可交付成果、假设条件和制约因素的描述

WBS： 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。

工作包： WBS 的最低层级是带有独特标识号的工作包。每个工作包都是控制账户的一部分。

规划包： 一个控制账户可以包含一个或多个规划包，其是一种低于控制账户而高于工作包的工

作分解结构组件，工作内容已知，但详细的进度活动未知。

WBS词典： 针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。

（2）项目文件更新

可在本过程更新的项目文件包括假设日志和需求文件。

确认范围是正式验收已完成的项目可交付成果的过程。解决的是验收问题。

5-2-1 输入

（1）项目管理计划

范围管理计划、需求管理计划、范围基准

（2）项目文件

经验教训登记册、质量报告、需求文件、需求跟踪矩阵

（3）核实的可交付成果

核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。

（4）工作绩效数据

包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。

5-2-2 工具与技术

（1）检查

检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。

（2）决策

可用于本过程的决策技术包括（但不限于）投票。

5-2-3 输出

（1）验收的可交付成果

符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。

（2）工作绩效信息

包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来并传递给相关方。

（3）变更请求

对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展缺陷补救。

（4）项目文件更新

本过程可更新的项目文件包括：经验教训登记册，需求文件，需求跟踪矩阵

控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程的主要作用是，在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。

6-2-1 输入

（1）项目管理计划

包括范围管理计划、需求管理计划、变更管理计划、配置管理计划、范围基准、绩效测量基准

（2）项目文件

经验教训登记册，需求文件、需求跟踪矩阵

（3）工作绩效数据

包括收到的变更请求的数量、接受的变更请求的数量，或者核实、确认和完成的可交付成果的数量。

（4）组织过程资产

能够影响控制范围过程的组织过程资产包括（但不限于）：现有的、正式和非正式的，与范围控制相关的政策、程序和指南；可用的监督和报告的方法与模板。

6-2-2 工具与技术

（1）数据分析

偏差分析： 偏差分析用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。

趋势分析： 趋势分析旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。

6-2-3 输出

（1）工作绩效信息

本过程产生的工作绩效信息是有关项目和产品范围实施情况（对照范围基准）的、相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。

（2）变更请求

分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。变更请求需要经过实施整体变更控制过程的审查和处理。

（3）项目管理计划更新

范围管理计划

范围基准：在针对范围、范围说明书、WBS 或 WBS 词典的变更获得批准后，需要对范围基准做出相应的变更。

进度基准：在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应的变更。

成本基准：在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。

绩效测量基准：在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。

（4）项目文件更新

本过程可更新的项目文件包括：经验教训登记册，需求文件，需求跟踪矩阵