以下是《信息系统项目管理师教程》（第4版）关于项目范围管理的核心知识要点说明，结合考试重点与实践应用整理：
一、项目范围管理的定义与核心价值
1. 产品范围 vs 项目范围
- 产品范围：指产品、服务或成果的功能特性（如系统响应时间≤1秒），根据需求文件衡量完成情况。
- 项目范围：为交付产品范围而必须完成的工作（如开发、测试），根据范围基准（范围说明书+WBS+WBS词典）衡量完成情况。
- 区别 ： "产品范围看功能，项目范围看工作"
示例：开发"智慧医疗云平台"时，产品范围 是支持数据互通功能，项目范围是完成接口开发、测试等任务。
2. 范围管理的意义
- 防范围蔓延：避免未经控制的变更（如客户临时新增需求未走流程）。
- 防镀金：禁止团队自行添加多余功能（如程序员私自增加AI诊断模块）。
- 基准作用：范围基准是进度、成本、资源规划的基础。
二、项目范围管理的六大过程
1. 规划范围管理
- 定义：制定《范围管理计划》和《需求管理计划》，明确如何定义、确认及控制范围。
- 核心输出 ：
- 范围管理计划：规定范围说明书编制、WBS创建、验收流程及变更控制方法。
- 需求管理计划：需求优先级排序规则、跟踪矩阵配置方法（如需求状态字段设计）。
2. 收集需求
- 工具与技术 ：
- 焦点小组：预选干系人讨论需求（如卫健委、医院代表讨论医疗数据共享规则）。
- 原型法：通过可交互模型获取早期反馈（如政务系统界面原型）。
- 需求跟踪矩阵（RTM）：将需求与设计、测试关联，确保全程可追溯。
- 输出 ：
- 需求文件：分类记录业务需求（如"提升数据共享覆盖率至95%"）、干系人需求（如"支持医保移动支付"）、解决方案需求（功能/非功能）。
3. 定义范围
- 核心输出 ：项目范围说明书
七大要素口诀 ："目产边假约可"：- 项目目标：量化的成功标准（如"年故障时间≤4小时"）；
- 产品范围描述：细化功能（如"支持10个部门数据互通"）；
- 项目边界：明确包含/不包含内容（如"不包含硬件采购"）；
- 假设条件（如"团队具备信创开发经验"）；
- 制约因素（如"预算不可超856万元"）；
- 可交付成果（如"系统原型、培训材料"）；
- 验收标准（如"用户满意度≥90%"）。
4. 创建WBS
- 分解原则口诀 ："百八唯一，滚动独立"：
- 100%原则：WBS覆盖全部范围，无遗漏；
- 8/80原则：工作包耗时8~80小时；
- 唯一性原则：每个组件仅隶属一个父项；
- 滚动式规划：远期工作粗分解，近期细化。
- 输出 ：
- WBS词典：工作包描述、责任人、成本估算（如"数据清洗工作包：耗时40小时，成本2万元"）；
- 范围基准：范围说明书+WBS+WBS词典。
5. 确认范围
- 关键活动：由客户或发起人正式验收可交付成果（如签署《验收报告》）。
- 与质量控制的区别 ：
- 质量控制：检查可交付成果正确性（测试是否满足性能指标）；
- 确认范围：关注客户接受度（是否签字验收）。
6. 控制范围
- 核心任务 ：
- 偏差分析：对比实际范围与基准（如进度延误因新增需求未审批）；
- 管理变更：所有变更需经变更控制委员会（CCB）审批。
- 防范围蔓延：严禁未经评估直接答应客户新增需求。
三、高频考点与避坑要点
1. 范围蔓延 vs 镀金
- 范围蔓延：客户提出需求未走变更流程（如医院临时要求加功能，项目经理直接答应）；
- 镀金：团队自行添加功能（如开发人员觉得"刷脸登录"很酷，私自开发）。
2. 范围基准的权威性
- 组成 ：范围说明书+WBS+WBS词典，未经CCB批准不得修改；
- 考题陷阱 ： "详细进度计划属于范围基准" ❌（实际属于进度基准）。
3. 需求跟踪矩阵（RTM）的作用
- 确保需求→设计→开发→测试全程可追溯；
- 需求状态变更时评估影响范围（如"取消医保支付功能需删除相关接口代码"）。
四、总结：范围管理的核心逻辑
- 基准锚定：范围基准是项目执行的"宪法"，WBS是分解工作的核心工具；
- 变更管控：所有变更需通过整体变更控制流程（提交→评估→批准→更新基准）；
- 敏捷适应：需求不稳定时采用迭代式范围定义（如每2周确认一次需求）。
考试避坑口诀 ：
"签发要发起（章程），内容11项；
蔓延客户加，镀金自己防；
WBS百八则，基准三件套！"
更多案例及工具技术详见《信息系统项目管理师教程》第9章。