项目范围管理

PMP第5章项目范围管理，项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。确认范围是正式验收已完成的项目可交付成果的过程。

项目范围管理

定义

项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。确认范围是正式验收已完成的项目可交付成果的过程。

主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。

产品范围

完成情况是根据产品需求来衡量的

某项产品、服务或成果所具有的特征和功能。

项目范围

为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。

项目范围的完成情况是根据项目管理计划来衡量的

预测型生命周期范围说明

中在项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理

确认范围在每个可交付成果生成时或者在阶段审查点开展，而控制范围则是一个持续性的过程。

经过批准的项目范围说明书、工作分解结构WBS和相应的WBS词典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更

适应型项目范围说明

整体范围分解为一系列拟实现的需求和拟执行的工作（有时称为产品未完项），在每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建 WBS

每次迭代中，都会重复开展两个过程：确认范围和控制范围。

使用未完项（包括产品需求和用户故事）反映当前需求

补充说明：“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或、能力。 需求将成为工作分解结构（WBS）的基础，也将成为成本、进度、质量和采购规划的基础。

需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现和维持效益。

剪裁需要考虑的因素

知识和需求管理。

确认和控制。

开发方法。

需求的稳定性。

治理。

计划

5.1规划范围管理

定义

要作用是，在整个项目期间对如何管理范围提供指南和方向。

为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程

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

输入

项目章程

项目管理计划

质量管理计划

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

项生命周期描述

义了项目从开始到完成所经历的一系列阶段

开发方法

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

事业环境因素

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

组织过程资产

工具与技术

专家判断

数据分析

于评估收集需求、详述项目和产品范围、创造产品、确认范围和控制范围的各种方法。

会议

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

输出

范围管理计划

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

制定项目范围说明书；

根据详细项目范围说明书创建WBS

确定如何审批和维护范围基准；

正式验收已完成的项目可交付成果。

*需求管理计划

定义：项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。有些组织称之为“商业分析计划”

如何规划、跟踪和报告各种需求活动

配置管理活动，例如，如何启动变更，如何分析其影响以及变更审批权限

需求优先级排序过程；

测量指标及使用这些指标的理由；

反映哪些需求属性将被列入跟踪矩阵的跟踪结构。

5.2收集需求

定义：为实现项目目标而确定、记录并管理相关方的需要和需求的过程。作用是，为定义产品范围和项目范围奠定基础，且仅开展一次或仅在项目的预定义点开展。

输入

项目章程

项目管理计划

范围管理计划。

需求管理计划。

相关方参与计划。

项目文件

商业计划

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

协议

事业环境因素

组织过程资产

*工具与技术

专家判断

商业分析；需求获取；需求分析；需求文件；以往类似项目的项目需求；图解技术；引导冲突管理。

*数据收集

头脑风暴

访谈

访谈是通过与相关方直接交谈，来获取信息的正式或非正式的方法。

访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。

经常是“一对一”谈话，但也可以包括多个访谈者和/或多个被访者

访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息。

焦点小组

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

由一位受过训练的主持人引导大家进行互动式讨论。

问卷调查

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

标杆对照见

标杆对照所采用的可比组织可以是内部的，也可以是外部的

数据分析

*决策

投票

集体决策

独裁型决策制定

多标准决策分析

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

*数据表现

亲和图

用来对大量创意分组的技术，以便进一步审查和分析

思维导图

*人际关系与团队技能

名义小组技术

通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。

向集体提出一个问题或难题。每个人在沉思后写出自己的想法。

主持人在活动挂图上记录所有人的想法

集体讨论各个想法，直到全体成员达成一个明确的共识。

个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高

观察和交谈

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

当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节。

观察，也称为“工作跟随”，通常由旁站观察者观察业务专家如何执行工作，但也可以由“参与观察者”来观察，通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。

引导

引导与主题研讨会结合使用，把主要相关方召集在一起定义产品需求。

用于快速定义跨职能需求并协调相关方的需求差异。

因为具有群体互动的特点，有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于相关方达成一致意见

引导情景

联合应用设计或开发(JAD)，以收集需求和改进软件开发过程。

质量功能展开(QFD)，制造行业则采用QFD这种引导技能来帮助确定新产品的关键特征。客户需求又称“客户声音”，客观地对这些需要进行分类和排序，并为实现这些需要而设定目标。

用户故事。用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。用户故事描述哪个相关方将从功能中受益（角色），他需要实现什么（目标），以及他期望获得什么利（动机

*系统交互法

系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式

系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。

*原型法

定义：在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期馈。

括微缩产品、计算机生成的二维和三维模型、实体模型或模拟

原型是有形的实物，它使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。

原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。

经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。

故事板

是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。

故事板用于各种行业的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。

在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

输出

*需求文件

定义：描述各种单一需求将如何满足与项目相关的业务需求

始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。

只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。

需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件

需求分为不同的种类，如业务解决方案和技术解决方案。前者是相关方的需要，后者是指如何实现这些需要。

需求的类别

业务需求：整个组织的高层级需要

相关方需求

解决方案需求

功能需求。

功能需求描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互

非功能需求。

非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等

过渡和就绪需求

这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。

项目需求

项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等

质量需求

用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等

*需求矩阵跟踪法

产品需求从其来源连接到能满足需求的可交成果的一种表格。

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

需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。

最后，需求跟踪矩阵还为管理产品范围变更提供了框架。

类别

业务需要、机会、目的和目标；项目目标；项目范围和WBS可交付成果；产品设计；产品开发；测试策略和测试场景；高层级需求到详细需求

应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。

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

为确保相关方满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。其中列有相关的需求属性。

5.3定义范围

定义：制定项目和产品详细描述的过程。

定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细的项目范围说明书，对项目成功至关重要

应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项范围说明书

随着对项目信息的更多了解，应该更加详细具体地定义和描述项目范围。

需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。

随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。

输入

项目章程

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

项目管理计划

项目管理计划组件包括（但不限于）范围管理计划，其中记录了如何定义、确认和控制项目范围。

项目文件

假设日志。需求文件。风险登记册。

事业环境因素

组织过程资产

工具与技术

专家判断

数据分析

决策

人际关系与团队技能

*产品分析

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

每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度

产品分析技术：

产品分解；需求分析；系统分析；系统工程；价值分析；价值工程。

输出

*项目范围说明书

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

它记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果

还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。

项目范围说明书使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作并为评价变更请求或额外工作是否超过项目边界提供基准。

项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度

内容

产品范围描述。可交付成果。验收标准。项目的除外责任。

虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细

项目文件更新

5.4创建WBS

将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。工作包

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

WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。

最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制

在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果而不是活动本身

分解程度取决于所需的控制程度，已实现对项目的高校管理，工作包的详细程度因项目规模和复杂程度而异

输入

项目管理计划

项目文件

项目范围说明书。需求文件。

事业环境因素

项目所在行业的WBS标准，这些标准可以作为创建WBS的外部参考资料

组织过程资产

工具与技术

专家判断

分解

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术

识别和分析可交付成果及相关工作；确定WBS的结构和编排方法；自上而下逐层细化分解；为WBS组成部分制定和分配标识编码；核实可交付成果分解的程度是否恰当

创建 WBS 的方法

上而下分解方法、自下而上验证使用组织特定的指南和使用 WBS模板

以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层，

以主要可交付成果作为分解的第二层，

纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同WBS

输出

范围基准

项目范围说明书、工作包、WBS、规划包

WBS词典

是针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件。WBS 词典对 WBS 提供支持，其中大部分信息由其他过程创建，然后在后期添加到词典中。

项目文件更新

控制

确认范围

正式验收已完成的项目可交付成果的过程。本过程应根据需要在整个项目期间定期开展

输入

项目管理计划

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

项目文件

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

核实的可交付成果

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

工作绩效数据

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

工具与技术

检查

来判断工作和可交付成果是否符合需求和产品验收标准；检查有时也被称为审查、产品审查和巡检等

决策

输出

*验收的可交付成果

符合验收标准的可交付成果应该由客户或发起人正式签字批准。

工作绩效信息

更新请求

项目文件更新

控制范围

监督项目和产品的范围状态，管理范围基准变更的过程

要作用是，在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。

输入

项目管理计划

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

项目文件

工作绩效数据

组织过程资产

工具与技术

数据分析

偏差分析。趋势分析。

确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作

输出

工作绩效信息

变更请求

项目管理计划更新

项目文件更新

如果已经验收完毕，出现bug，需要改进，如果客户增加需求，不接受改进，放到下一个阶段

厉害的PM用专家判断，小白用分解

输入需求文件是为了校对