第 9 章　项目范围管理

一、考情分析

二、学习目标

三、知识点精讲：范围管理基础

3.1 产品范围与项目范围

范围管理中的「范围」一词有两个必须严格区分的含义，这是本章一切概念的地基：

• 产品范围：某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据需求文件来衡量的——需求说清了产品要有什么功能、达到什么指标。
• 项目范围：包括产品范围在内，为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围的完成情况是根据项目管理计划来衡量的。

两者的关系可以概括为：产品范围是「做出来的东西本身要长什么样」，项目范围是「为了做出这个东西需要干的全部活」。项目范围通常包含产品范围（开发、测试等活动围绕产品功能展开），但还包括采购、培训、文档编制、项目收尾等与产品功能无直接对应关系的工作。

3.2 管理基础与新兴实践

教材强调，在项目环境中「范围」一词的使用要谨慎——讨论范围时应明确所指的是产品范围还是项目范围。范围管理的前四个过程属于规划过程组，后两个属于监控过程组，全部六个过程并非都在同一过程组，这一分布本身是选择题考点。

范围管理的趋势和新兴实践包括：①与商业分析师合作——商业分析师针对商业需求做研究和分析，识别并引导出产品需求，通过需求管理将商业需求与项目需求联系起来；②采用适应型方法，针对部分可交付成果采用敏捷模式，与业务代表合作定义、引导和确认需求，在短时间内快速迭代地确认需求并建立原型；③使用需求管理工具与知识库，借助信息化工具提升需求管理的效率与追溯性。这些实践反映的共同方向是：让需求的引导、澄清和确认更加贴近业务与用户，且持续进行而非一次性完成。

四、知识点精讲：规划范围管理与收集需求

4.1 规划范围管理（规划过程组）

规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。其主要作用是：在整个项目期间为如何管理范围提供指南和方向。它输出两份计划：范围管理计划——描述如何定义、制定、监督、控制和确认项目范围，是项目管理计划的组成部分；需求管理计划——描述将如何分析、记录和管理需求和需求优先级排序过程。

4.2 收集需求（规划过程组）

收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。其主要作用是为定义产品范围和项目范围奠定基础。需求将成为需求文件（描述各种单一需求如何满足项目相关的商业需求）与需求跟踪矩阵的来源。需求跟踪矩阵把每个需求与业务目标或项目目标联系起来，为管理需求变更、核实产品范围提供端到端的可追溯性——从需求源头到可交付成果的验收，逐条对应、层层可查。

4.3 收集需求的工具精讲与场景对照

收集需求的工具数量多、名称近，必须逐个理解并建立场景映射：

• 访谈：通过与干系人直接、一对一（或一对多）交谈来获得需求的正式或非正式方法。信任是访谈的基础，适用于干系人少、需求需要深挖细节的场景。
• 焦点小组：召集预先选定的干系人和主题专家，了解他们对所提议产品、服务或成果的期望和态度，由一位受过训练的主持人引导大家进行互动式讨论，在比一对一访谈更短的时间内获得比单独提问更丰富的信息。
• 引导式研讨会：把主要干系人召集在一起定义产品需求，是快速定义跨职能需求并协调干系人需求差异的重要技术。两种典型形态：质量功能部署（Quality Function Deployment, QFD）——把用户需求（客户声音）转化为技术需求、确定设计参数，使用质量屋矩阵展开分析；联合应用开发（Joint Application Development, JAD）——把用户与开发团队召集在一起共同定义软件需求，注重快速、共识式地确定需求。引导式研讨会能比单项活动更快地发现和解决多干系人之间的矛盾。
• 群体创新技术：①头脑风暴——短时间内产生大量创意，重视数量、欢迎自由发挥；②名义小组技术——通过头脑风暴产生创意，再由小组成员按重要性对创意进行排序，用「投票」把群体意见收敛为优先次序；③思维导图——把从头脑风暴中获得的创意整合成一张反映创意间共性与差异的图；④亲和图——把大量创意按亲和性（自然关系）分类归组，发现问题本质；⑤多标准决策分析——借助决策矩阵，用系统方法建立评分权重，对多方案进行评估与排序。
• 群体决策技术：为达成群体结论而对多个方案进行评估的方法——①一致同意：所有人都同意某方案；②大多数原则：超过半数的成员支持（常与举手表决等形式结合）；③相对多数原则：得票最多的方案胜出，即便未过半数，适合选项较多且需要快速收敛时；④独裁：由一个人为群体做出决策。
• 问卷调查：适用于干系人多、分布广、需要快速完成调查的场景，受众多时比访谈经济高效。
• 标杆对照：将实际或计划的做法与其他可比组织的做法进行比较，识别最佳实践、形成改进意见，为需求提供参照系。
• 原型法：在实际制造产品之前先造出产品的实用模型（如界面原型），征求干系人的早期反馈，经历「模型 → 反馈 → 修正 → 再反馈」的循环渐进地明确需求。
• 系统交互图：展示业务系统（过程、设备、计算机系统等）与其他人与系统之间如何交互的范围模型，帮助看清系统边界，明确哪些在范围内、哪些不在。
• 文件分析：分析现有文档（商业计划、流程文档、政策文件、旧系统文档等）来识别相关需求。
• 观察和交谈：直接看用户在工作环境中如何实际操作（「跟着用户上班」），适合用户说不清自己需求的场景。

五、知识点精讲：定义范围与创建 WBS

5.1 定义范围（规划过程组）

定义范围是制定项目和产品详细范围描述的过程。其主要作用是描述产品、服务或成果的边界和验收标准。详细的项目范围说明书对成功完成项目至关重要：它明确标注哪些工作属于项目范围（做）、哪些工作不在范围内（不做），并附可交付成果的验收标准——「不做什么」与「做什么」同样重要，因为排除项能有效管理干系人的预期。项目范围说明书的内容通常包括：产品范围描述、可交付成果、验收标准、项目除外责任（排除项）等。

5.2 创建 WBS（规划过程组）——本章核心

创建 WBS（Work Breakdown Structure，工作分解结构）是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。其主要作用是为所要交付的内容提供架构。WBS 是以可交付成果为导向的工作层级分解，最低层的组成部分称为工作包，可以对其安排进度、估算成本、分配责任、实施监控。

5.2.1 WBS 的层次与表现形式

WBS 自上而下逐层细化：最高层是项目整体（或可交付成果集合），中间层是可交付成果的逐级细分，最底层是工作包。在较大型项目中，工作包之上还可设「规划包」，其内容在滚动式规划的后续阶段再分解为工作包。WBS 词典伴随每个 WBS 组件编制，为工作包提供详细说明。WBS 的常见表现形式有两种：分层的树状结构（自上而下的树形图，直观、适合向管理层展示，大型项目画布空间有限）与表格形式／列表形式（以缩进编号表示层级，便于编制与计算机处理）。无论哪种形式，分解逻辑必须一致。

5.2.2 分解的原则与注意事项

分解就是把项目可交付成果划分为更小、更便于管理的组成部分，直到工作包层。开展分解时必须遵循以下原则：

• 100% 原则：WBS 必须覆盖项目的全部工作，包含且仅包含完成项目所必需的全部工作——下层之和恰好等于上层，既不能遗漏（少做）也不能越界（多做）。WBS 是为可交付成果而做，不包括不产生交付物的纯管理活动外的内容时应特别谨慎，确保「该干的都在、不该干的都不在」。
• 面向可交付成果：分解的第一层可以按项目生命周期阶段划分（需求、设计、开发、测试、部署），也可以按主要可交付成果划分，但必须自上而下保持同一逻辑，不得在同一层混用不同分解逻辑。
• 工作包粒度适中：工作包过大则无法有效控制，过细则管理成本过高，粒度以「能安排进度、估算成本、明确责任、便于监控」为准。
• 滚动式规划：近期要完成的工作分解到工作包层面，远期工作在高层级上暂列（如规划包），随着信息明朗再逐步细化——这不是偷懒，而是承认「渐进明细」的客观规律。
• 注意事项：分解完成后应检查：每项工作是否有人负责（可分配）、能否估算工期与成本、是否便于跟踪验收；WBS 不是进度计划（不体现时间顺序），也不是组织分解结构（不体现部门归属），更不是采购清单。把不同性质的结构混为一谈是分解的常见错误。

5.2.3 WBS 词典

WBS 词典是针对每个 WBS 组件（包括工作包）编制的详细说明文件，描述的内容通常包括：账户编码标识号、工作描述、负责组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、合同信息、技术参考文献等。可以说「WBS 告诉你有哪些活，WBS 词典告诉你每项活的来龙去脉」——没有 WBS 词典的 WBS 只是一个骨架，难以支撑成本、进度、责任等管理活动。

5.2.4 范围基准

创建 WBS 过程最重要的输出是范围基准，它是项目管理计划中三大基准之一，由三部分构成：

六、知识点精讲：确认范围与控制范围

6.1 确认范围（监控过程组）

确认范围是正式验收已完成的项目可交付成果的过程。其主要作用是：使验收过程具有客观性；通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。请注意「正式」二字——确认范围是一种正式验收行为，通常由客户或发起人执行，他们对照验收标准检查可交付成果，做出接受、拒收或附条件接受的决定。

三个关键细节：输入中的「核实的可交付成果」来自质量控制过程——质量检查在先，正式验收在后，这是确认范围与控制质量时点关系的基础；工具「检查」是指开展测量、审查与确认等活动，以判断工作和可交付成果是否符合要求及产品验收标准，也可以称为审查、审计或巡检；输出中若可交付成果未通过验收，应提出变更请求（通常是缺陷补救类），返工后再次提交验收。「正式验收」意味着验收结论要有书面记录并经客户或发起人签字确认，成为后续结束项目或阶段的依据——它是合同与商业层面的里程碑，而不只是技术层面的通过。

6.2 控制范围（监控过程组）

控制范围是监督项目和产品的范围状态、管理范围基准变更的过程。其主要作用是在整个项目期间保持对范围基准的维护。其核心工作包括：确保所有范围变更都通过实施整体变更控制过程进行处理；防止未获批准的变更进入产品或项目范围；维护范围基准中各项内容的完整性；管理实际与计划的差异。控制范围应当与其他控制过程（控制进度、控制成本等）紧密结合，偏差分析是其核心工具。

偏差分析把实际完成的工作与范围基准比较，识别偏离及偏离程度；趋势分析观察偏差随时间的变化方向，判断范围是否在被持续侵蚀。一旦发现范围偏差（多做了、少做了、做偏了），处理方式不是悄悄修正，而是通过变更请求进入整体变更控制流程裁决——这正是控制范围与整合管理「实施整体变更控制」的天然接口，也是案例分析的联合命题点。

七、知识点精讲：三大高频易混点辨析

7.1 确认范围 vs 控制质量

这是本章辨析题的第一主角，三个维度一次记牢：

两句话锚定记忆：「质量先核实，范围后验收」「质量看正确，范围看接收」。一个必须警惕的反例是：通过质量检查的可交付成果未必能通过确认范围——技术正确不等于客户满意（客户还可能基于商业判断拒收或附条件接收）；反之，确认范围不能替代控制质量，验收不能掩盖内在质量缺陷。

7.2 范围蔓延 vs 镀金

7.3 范围基准的组成

范围基准 = 项目范围说明书 + WBS + WBS 词典。命题人的三种考法：①缺项判断——「范围基准包括范围说明书和 WBS」是错句，漏了 WBS 词典；②张冠李戴——把需求文件、需求跟踪矩阵塞进范围基准（它们是项目文件，不是基准组件）；③归属混淆——把 WBS 词典说成项目文件（它是创建 WBS 过程输出范围基准的组成部分）。基准作为项目管理计划的组件，其任何修改都必须经过实施整体变更控制批准。

八、典型案例分析

案例一：验收会上的翻脸

背景：某企业的 ERP 定制项目进入验收阶段。项目组提交了全部可交付成果，内部测试报告显示功能全部通过、缺陷已清零。但在客户组织的验收会上，客户方业务负责人只粗看演示，就以「界面操作习惯与我们的业务流程不符」为由拒收其中两个模块，并表示「当初需求就是这么说的，你们没理解到位」。项目经理拿出需求文件逐条比对，发现需求文件只笼统写了「支持报销管理」，并未约定具体的审批流转级数与界面形式。

问题描述：请分析该项目的范围管理存在哪些问题，并提出改进措施。

问题诊断（分点）：

1. 收集需求阶段工具选择不当：报销这类强业务流程需求，应采用访谈、观察和交谈、引导式研讨会甚至原型法深入引导，仅靠笼统的书面收集导致需求颗粒度不足；
2. 需求文件编写质量缺陷：「支持报销管理」这类表述不可验证、不可度量，未达到可作为验收依据的要求；
3. 确认范围机制缺失或流于形式：没有在里程碑点分批与客户做正式验收，把全部验收压力堆积到末期，失去了中途纠偏的机会；
4. 缺少需求跟踪矩阵：无法向客户展示「需求条目 → 设计 → 实现」的对应关系，验收争议时说不清双方当初的约定；
5. 混淆了控制质量与确认范围：项目组以「内部测试通过」自证合格，忽视了确认范围必须由客户或发起人对照验收标准正式进行。

改进措施（分点）：

1. 对争议模块重新开展需求引导：与业务负责人访谈并现场观察实际报销操作，用原型法快速确认界面与流程，将「报销管理」细化为可验证的具体需求条目；
2. 建立需求跟踪矩阵，逐条追溯需求来源与实现状态，作为后续验收的共同依据；
3. 对争议内容走整体变更控制流程：若业务负责人提出的流转级数、界面形式超出原需求范围，应记录变更请求、评估影响并提交审批，而不是免费返工；
4. 今后的项目按里程碑分批执行确认范围，每批验收书面留痕，避免末期集中爆发；
5. 在范围说明书中预先写明验收标准与除外责任，明确「不做什么」，管理客户预期。

命题落点：本题同时命中「收集需求工具」「确认范围」「需求跟踪矩阵」「变更控制」四个考点，是范围管理案例题的典型复合结构，答题时按「需求质量 → 验收流程 → 变更处置」三条线索分点展开。

案例二：被「顺手」蚕食的项目

背景：某门户系统项目进行到第四个月。项目经理复盘时发现：程序员小李觉得某页面「不够炫」，自作主张加了三套动画效果；客户方的信息科科员陆续提出六七个「顺手改一下」的小需求，团队都直接改了没记录；市场部经理在例会上说「再加个数据大屏就更完美了」，项目经理碍于情面答应「我们想想办法」。项目预算已消耗 65%，进度却只完成 45%。

问题描述：请指出案例中违反范围管理原则的现象，并说明项目经理应如何处理。

问题诊断（分点）：

1. 小李自加动画效果属于镀金：团队主动交付超出范围基准的内容，未经客户要求、未走变更控制；
2. 信息科科员「顺手改一下」的需求被直接实施，属于范围蔓延：未经变更控制流程的、由客户方发起的范围扩大，且变更请求未记录、未评估、未审批；
3. 市场部经理的大屏诉求被口头回应，未转化为正式变更请求，同样存在范围失控风险；
4. 控制范围过程缺位：没有开展偏差分析，直至预算与进度严重失衡才复盘；
5. 项目经理缺乏「范围基准受控」的纪律意识，变更管理流程形同虚设。

处理措施（分点）：

1. 对照范围基准全面清点已发生的范围偏差，评估已实施镀金与蔓延内容的成本、进度与风险影响；
2. 小李的动画效果：确认其不在范围基准内，原则上撤销或补走变更流程由 CCB 决定去留；
3. 客户的全部「顺手需求」：补记变更请求，统一纳入变更日志，逐项评估影响后提交变更控制委员会审批，批准的纳入计划实施、否决的书面回复；
4. 数据大屏诉求：记入变更日志走整体变更控制，若涉及合同金额与工期调整，与客户商务协商；
5. 向客户与发起人报告当前偏差，若需重新基线，按批准的变更更新范围基准与项目管理计划。

命题落点：本题的「三段情节」分别对应镀金、范围蔓延、口头变更三个独立考点，命题人常将其混编在一个案例中要求逐一定性——答题先定性质、再给流程，条理即分数。

九、考点速记卡