5 项目范围管理

项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。

项目范围管理过程包括：

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

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

5.3 定义范围 — 制定项目和产品详细描述的过程。

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

5.5 确认范围 — 正式验收已完成的项目可交付成果的过程。

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

范围的含义：

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

在项目范围管理过程中，收集、记录和管理相关方需求。项目范围管理的发展趋势和新兴实践包括（但不限于）注重与商业分析专业人士的合作，以便：

• 确定问题并识别商业需要；
• 识别并推荐能够满足这些需要的可行解决方案；
• 收集、记录并管理相关方需求，以满足商业和项目目标；
• 推动项目集或项目的产品、服务或最终成果的成功应用 。

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

裁剪时需要考虑的因素

因为每个项目都是独特的，所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括（但不限于）：

• 知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系？为了在未来项目中重复使用需求，项目经理应建立哪些指南？
• 确认和控制。组织是否拥有正式或非正式的与确认和控制相关的政策、程序和指南？
• 开发方法。组织是否采用敏捷方法管理项目？开发方法属于迭代型还是增量型？是否采用预测型方法？混合型方法是否有效？
• 需求的稳定性。项目中是否存在需求不稳定的领域？是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确？
• 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南

在敏捷或适应型环境中需要考虑的因素

对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过发布多个版本来明确需求。这样一来，范围会在在整个项目期间被定义和再定义。在敏捷方法中，把需求列入未完项。

5.1 规划范围管理

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。本过程的主要作用是，在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。

规划范围管理：输入、工具与技术和输出

规划范围管理：数据流向图

5.1.1 规划范围管理：输入

规划范围管理的输入包括：

• 项目章程
• 项目管理计划
  • 质量管理计划
  • 项目生命周期描述
  • 开发方法
• 事业环境因素
  • 组织文化
  • 基础设施
  • 人事管理制度
  • 市场条件
• 组织过程资产
  • 政策和程序
  • 历史信息和经验教训知识库

5.1.2 规划范围管理：工具与技术

规划范围管理需要的工具与技术包括：

• 专家判断
  • 以往类似项目
  • 特定行业、学科和应用领域的信息
• 数据分析
• 会议

5.1.3 规划范围管理：输出

规划范围管理的输出包括：

• 范围管理计划
  • 制定项目范围说明书
  • 根据详细项目范围说明书创建WBS
  • 确定如何审批和维护范围基准
  • 正式验收已完成的项目可交付成果
• 需求管理计划
  • 如何规划、跟踪和报告各种需求活动；
  • 配置管理活动，例如如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及如何变更审批权限；
  • 需求优先级排序过程；
  • 测量指标及使用这些指标的理由；
  • 反映哪些需求属性将被列入跟踪矩阵的跟踪结构。

5.2 收集需求

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

收集需求：输入、工具与技术和输出

收集需求：数据流向图

5.2.1 收集需求：输入

收集需求的需求包括：

• 项目章程
• 项目管理计划
  • 范围管理计划
  • 需求管理计划
  • 相关方参与计划
• 项目文件
  • 假设日志
  • 经验教训登记册
  • 相关方登记册
• 商业文件
• 协议
• 事业环境因素
  • 组织文化
  • 基础设施
  • 人事管理制度
  • 市场条件
• 组织过程资产
  • 政策和程序
  • 包含以往项目信息的历史信息和经验教训知识库

5.2.2 收集需求：工具与技术

收集需求需要的工具与技术包括：

• 专家判断
  • 商业分析
  • 需求获取
  • 需求分析
  • 需求文件
  • 以往类似项目的项目需求
  • 图解技术
  • 引导
  • 冲突管理
• 数据收集
  • 头脑风暴
  • 访谈
  • 焦点小组
  • 问卷调查
  • 标杆对照
• 数据分析
  • 协议
  • 商业计划
  • 业务流程或接口文档
  • 业务规则库
  • 现行流程
  • 市场文献
  • 问题日志
  • 政策和程序
  • 法规文件
  • 建议邀请书
  • 用例
• 决策
  • 投票
  • 独裁型决策执行
  • 多标准决策分析
• 数据表现
  • 亲和图：用来对大量创意进行分组的技术，以便进一步审查和分析
  • 思维导图：把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性和差异，激发新创意
• 人际关系与团队技能
  • 名义小组技术，名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式，由四个步骤组成：
    • 向小组提出一个问题或难题。每个人在沉思后写出自己的想法。
    • 主持人在活动挂图上记录所有人的想法。
    • 集体讨论各个想法，直到全体成员清晰理解。
    • 个人私下投票决出各种想法的优先排序，通常采用 5 分制，1 分最低，5 分最高。为减少想法数量、集中关注想法，可进行数轮投票。每轮投票后，都将清点选票，选出得分靠前的那些想法。
  • 观察和交谈
  • 引导，引导与主题研讨会结合使用，把主要相关方召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调相关方的需求差异。因为具有群体互动的特点，有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于相关方达成一致意见。此外，与分别召开会议相比，研讨会能够更早发现并更快解决问题。适合采用引导技能的情境包括（但不限于）：
    • 联合应用设计或开发 (JAD)。JAD 会议适用于软件开发行业。这种研讨会注重把业务主题专家和开发团队集中在一起，以收集需求和改进软件开发过程。
    • 质量功能展开 (QFD)。制造行业则采用 QFD 这种引导技能来帮助确定新产品的关键特征。QFD从收集客户需要（又称“客户声音”）开始，然后客观地对这些需要进行分类和排序，并为实现这些需要而设定目标。
    • 用户故事。用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。用户故事描述哪个相关方将从功能中受益（角色），他需要实现什么（目标），以及他期望获得什么利益（动机）。
• 系统交互图，系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。

• 原型法，原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的实物，它使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

5.2.3 收集需求：输出

收集需求的输出包括：

• 需求文件
  • 业务需求
  • 相关方需求
  • 解决方案需求
    • 功能需求
    • 非功能需求
  • 过渡和就绪需求
  • 项目需求
  • 质量需求
• 需求跟踪矩阵：需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。
  • 业务需要、机会、目的和目标；
  • 项目目标；
  • 项目范围和 WBS 可交付成果；
  • 产品设计；
  • 产品开发；
  • 测试策略和测试场景；
  • 高层级需求到详细需求。
    
    需求跟踪矩阵示例

5.3 定义范围

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

定义范围：输入、工具与技术和输出

定义范围：数据流向图

5.3.1 定义范围：输入

定义范围的输入包括：

• 项目章程
• 项目管理计划
• 项目文件
  • 假设日志
  • 需求文件
  • 风险登记册
• 事业环境因素
  • 组织文化
  • 基础设施
  • 人事管理制度
  • 市场条件
• 组织过程资产
  • 用于制定项目范围说明书的政策、程序和模板
  • 以往项目的项目档案
  • 以往阶段或项目的经验教训

5.3.2 定义范围：工具与技术

定义范围需要的工具与技术包括：

• 专家判断
• 数据分析
• 决策
• 人际关系与团队技能
• 产品分析
  • 产品分解
  • 需求分析
  • 系统分析
  • 系统工程
  • 价值分析
  • 价值工程

5.3.3 定义范围：输出

定义范围的输出包括：

• 项目范围说明书：项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
  • 产品范围描述
  • 可交付成果
  • 验收标准
  • 项目的除外责任：识别排除在项目之外的内容
• 项目文件更新
  • 假设日志
  • 需求文件
  • 需求跟踪矩阵
  • 相关方登记册

5.4 创建WBS

创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程的主要作用是，为所要交付的内容提供架构，它仅开展一次或仅在项目的预定义点开展。

WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。

创建 WBS：输入、工具与技术和输出

创建 WBS：数据流向图

5.4.1 创建WBS：输入

创建WBS的输入包括：

• 项目管理计划
• 项目文件
  • 项目范围说明书
  • 需求文件
• 事业环境因素
• 组织过程资产
  • 用于创建WBS的政策、程序和模板
  • 以往项目的项目档案
  • 以往项目的经验教训

5.4.2 创建WBS：工具与技术

创建WBS需要的工具和技术包括：

• 专家判断
• 分解：分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。分解的程度取决于所需的控制程度，以实现对项目的高效管理；工作包的详细程度则因项目规模和复杂程度而异。
  • 识别和分析可交付成果及相关工作；
  • 确定 WBS 的结构和编排方法；
  • 自上而下逐层细化分解；
  • 为 WBS 组成部分制定和分配标识编码；
  • 核实可交付成果分解的程度是否恰当。

WBS示例

5.4.3 创建WBS：输出

创建WBS的输出包括：

• 范围基准
  • 项目范围说明书
  • WBS
  • 工作包：WBS 的最低层级是带有独特标识号的工作包。这些标识号为进行成本、进度和资源信息的逐层汇总提供了层级结构，构成账户编码。每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效。控制账户拥有两个或更多工作包，但每个工作包只与一个控制账户关联。
  • 规划包：一个控制账户可以包含一个或多个规划包，其是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。
  • WBS词典
• 项目文件更新
  • 假设日志
  • 需求文件

5.5 确认范围

确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。

确认范围：输入、工具与技术和输出

确认范围：数据流向图

5.5.1 确认范围：输入

确认范围的输入包括：

• 项目管理计划
  • 范围管理计划
  • 需求管理计划
  • 范围基准
• 项目文件
  • 经验教训登记册
  • 质量报告
  • 需求文件
  • 需求跟踪矩阵
• 核实的可交付成果
• 工作绩效数据

5.5.2 确认范围：工具与技术

确认范围需要的工具与技术包括：

• 检查
• 决策

5.5.3 确认范围：输出

确认范围的输出包括：

• 验收的可交付成果
• 工作绩效信息
• 变更请求
• 项目文件更新

5.6 控制范围

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

控制范围：输入、工具与技术和输出

控制范围：数据流向图

5.6.1 控制范围：输入

控制范围的输入包括：

• 项目管理计划
  • 范围管理计划
  • 需求管理计划
  • 变更管理计划
  • 配置管理计划
  • 范围基准
  • 绩效测量基准
• 项目文件
  • 经验教训登记册
  • 需求文件
  • 需求跟踪矩阵
• 工作绩效数据
• 组织过程资产
  • 现有的、正式和非正式的，与范围控制相关的政策、程序和指南
  • 可用的监督和报告的方法和模板

5.6.2 控制范围：工具与技术

控制范围需要的工具与技术包括：

• 数据分析
  • 偏差分析
  • 趋势分析

5.6.3 控制范围：输出

控制范围的输出包括：

• 工作绩效信息
• 变更请求
• 项目管理计划更新
  • 范围管理计划
  • 范围基准
  • 进度基准
  • 成本基准
  • 绩效测量基准
• 项目文件更新
  • 经验教训登记册
  • 需求文件
  • 需求跟踪矩阵