什么是范围管理？

PMP里的范围管理，一句话讲就是： 先把项目“要做什么、不做什么”说清楚，再控制整个项目不要乱加、乱改、乱跑偏。 很多项目失败，不是因为技术做不出来，而是因为一开始范围没说清楚，过程中又不断加需求，最后时间、成本、质量全部失控。

一、什么是“范围”？

在 PMP 里，“范围”主要有两层意思：

1.产品范围

指这个产品、系统、功能本身要具备什么能力。

比如你要做一个“供应商管理系统”，产品范围可能包括：

• 供应商档案管理
• 供应商准入审批
• 合同信息管理
• 供应商评价
• 对接工商系统
• 数据统计报表

这些都是产品要有什么功能。

2. 项目范围

指为了交付这个产品，项目团队需要做哪些工作。 比如：

• 需求调研
• 原型设计
• 系统开发
• 测试
• 上线部署
• 用户培训
• 验收材料编写
• 项目总结

这些是为了把产品做出来，项目团队要完成的工作。

所以可以这样理解：

产品范围 = 交付物有什么功能
项目范围 = 为了交付这些功能，我们要做哪些工作

二、范围管理到底管什么？

范围管理不是简单地“管需求”，而是管这几件事：

1.明确项目边界

也就是告诉大家：

这个项目做什么？不做什么？

比如供应商管理系统：

本期做：

• 供应商基础信息管理
• 供应商准入流程
• 合同关联
• 工商信息查询

本期不做：

• 供应商付款结算
• 财务报销流程
• 自动招投标
• 第三方信用评分

这就叫边界清楚。

边界不清楚，就会出现一句很常见的话：

“这个功能也顺便做一下吧。”

项目就是这样一点点失控的。

2.把大目标拆成小工作

PMP 里有一个很重要的工具叫 WBS：工作分解结构。

它的作用是把一个大的项目，拆成可以管理、可以估算、可以分配、可以验收的小任务。

比如：

供应商管理系统项目

1. 项目管理
   1.1 项目计划
   1.2 周报管理
   1.3 风险管理
2. 需求分析
   2.1 供应商档案需求
   2.2 准入审批需求
   2.3 工商系统对接需求
3. 系统设计
   3.1 原型设计
   3.2 数据库设计
   3.3 接口设计
4. 开发实现
   4.1 供应商档案模块
   4.2 审批流程模块
   4.3 工商系统接口模块
5. 测试与上线
   5.1 功能测试
   5.2 用户验收
   5.3 生产上线

WBS 的核心价值是：

让项目从“一个模糊的大事情”，变成“一堆明确的小事情”。

3.防止范围蔓延

范围管理最重要的一个目的，就是防止 范围蔓延。

范围蔓延，也叫 Scope Creep。

意思是：

没有经过正式评估和批准，项目范围被不断扩大。

比如原本项目只做“供应商档案管理”，后来业务说：

• 能不能加一个合同审批？
• 能不能顺便做付款管理？
• 能不能再加一个供应商评分？
• 能不能对接财务系统？
• 能不能加移动端？

每个需求单独看都不大，但加起来项目就爆了。

范围蔓延的结果通常是：

• 项目延期
• 成本增加
• 团队加班
• 质量下降
• 验收困难
• 各方互相甩锅

所以 PMP 强调：

不是不能变更，而是变更必须走流程。

三、PMP 范围管理的主要过程

按照传统 PMP 知识体系，范围管理通常包括 6 个过程。

你可以先不用死记，先理解它们的逻辑。

1. 规划范围管理

这是第一步：先制定规则。

要说明：

• 需求怎么收集？
• 范围怎么定义？
• WBS 怎么拆？
• 范围怎么验收？
• 变更怎么处理？

它解决的是：

后面大家按照什么规则来管理范围？

2. 收集需求

这一阶段是从相关方那里了解需求。

比如：

• 领导想要什么？
• 业务部门想要什么？
• 使用人员痛点是什么？
• 运维部门有什么要求？
• 合规部门有什么要求？

常用方式包括：

• 访谈
• 会议
• 问卷
• 原型
• 竞品分析
• 业务流程梳理

这一阶段很关键，因为很多项目后期扯皮，都是因为前期需求没问清楚。

3. 定义范围

收集完需求后，要形成明确的范围说明。

也就是把项目到底交付什么写清楚。

通常要说明：

• 项目目标
• 交付物
• 验收标准
• 项目边界
• 除外责任
• 约束条件
• 假设条件

比如：

范围内：

• 建设供应商档案管理模块
• 支持供应商准入审批
• 支持供应商分类、评级、状态管理
• 支持对接工商系统查询企业基础信息

范围外：

• 不包含财务付款
• 不包含招投标管理
• 不包含供应商在线门户
• 不包含移动端 App

这个“范围外”非常重要，很多人写项目文档只写做什么，不写不做什么，后面就容易被无限加需求。

4. 创建 WBS

就是把项目范围进一步拆解。

PMP 里强调：

WBS 不是按组织架构拆，也不是按时间顺序拆，而是按交付物拆。

比如不要这样拆：

• 张三的工作
• 李四的工作
• 王五的工作

也不要只按时间拆：

• 第一周工作
• 第二周工作
• 第三周工作

更好的拆法是按交付物：

• 需求规格说明书
• 原型设计稿
• 数据库设计文档
• 供应商档案模块
• 审批流程模块
• 测试报告
• 上线方案
• 验收报告

这样才方便管理交付结果。

5. 确认范围

确认范围就是：

让客户、业务方、甲方或关键相关方正式验收已经完成的交付物。

注意，它不是测试。

测试主要是看质量是否合格。

确认范围主要是看：

这个交付物是不是符合当初约定的范围和验收标准？

比如供应商档案模块开发完成后，业务方确认：

• 字段是否齐全
• 查询是否满足要求
• 导入导出是否符合要求
• 权限是否正确
• 是否达到验收标准

确认通过，就代表这个交付物被正式接受。

6. 控制范围

控制范围就是在项目执行过程中，持续监控范围有没有变化。

重点是：

• 有没有新增需求？
• 有没有需求被偷偷扩大？
• 有没有交付物偏离原目标？
• 有没有未批准的变更？
• 变更是否影响工期、成本、质量？

比如业务临时说：

“能不能顺便加一个供应商黑名单自动预警？”

项目经理不能直接答应“可以”。

正确做法是：

1. 记录变更请求
2. 分析影响
3. 评估工期、成本、风险
4. 提交审批
5. 批准后纳入范围
6. 更新计划

这就是控制范围。

四、范围管理和需求管理有什么区别？

很多人会把范围管理和需求管理混在一起。

可以这样理解：

对比项	需求管理	范围管理
关注点	用户想要什么	项目承诺交付什么
重点	收集、分析、澄清需求	定义边界、控制变更、保证交付
输出	需求文档、用户故事、需求清单	范围说明书、WBS、验收标准
风险	需求不清楚	范围失控
典型问题	“业务到底要什么？”	“这个到底是不是本期要做？”

需求管理更偏“输入”，范围管理更偏“承诺与控制”。

五、范围管理为什么重要？

因为项目管理有三个核心约束：

• 范围
• 时间
• 成本

这三个是互相影响的。

如果范围变大，但时间和成本不变，那质量就会下降。

比如原计划：

• 做 10 个功能
• 3 个月完成
• 5 个人开发

后来变成：

• 做 18 个功能
• 还是 3 个月
• 还是 5 个人

结果通常就是：

• 加班
• 延期
• Bug 变多
• 验收困难
• 团队崩溃

所以范围管理的核心价值是：

保护项目目标，保护团队资源，也保护业务方的预期。

六、举个例子

假设你负责一个 App 下载 PDF 功能。

业务最开始的需求是：

H5 页面调用原生方法，下载 PDF 到共享目录，下载完成后调起手机 PDF 软件打开。

这个时候范围应该定义清楚。

范围内

• Android 提供 JSBridge 方法
• 支持 PDF 下载
• 保存到共享目录
• 下载完成后调起系统打开方式
• 处理下载失败提示
• 处理 Android 版本兼容
• 提供测试用例和联调说明

范围外

• 不支持 Word、Excel、图片等其他文件
• 不支持断点续传
• 不支持下载管理列表
• 不支持后台批量下载
• 不支持文件在线预览
• 不做云端存储

如果不写清楚，后面业务可能会说：

“既然 PDF 能下载，那 Word 也支持一下吧。”
“能不能做个下载列表？”
“能不能加个进度通知栏？”
“能不能下载后自动上传备份？”

这时候你就可以依据范围说明说：

这些属于新增范围，需要走变更评估。

这就是范围管理在实际工作中的价值。

七、范围管理的核心口诀

你可以这样记：

先定边界，再拆任务；
先讲清楚，再开始做；
变更可以，但不能偷偷变；
范围不控，项目必乱。

或者更简单：

做什么、不做什么、怎么拆、怎么验、怎么控。

八、项目经理在范围管理中要做什么？

项目经理不是自己决定所有范围，而是负责组织大家把范围说清楚，并控制它。

主要工作包括：

• 组织需求调研
• 明确项目目标和边界
• 输出范围说明书
• 组织 WBS 分解
• 明确验收标准
• 管理需求变更
• 防止范围蔓延
• 推动阶段性验收
• 维护相关方预期

项目经理最重要的能力不是“什么都答应”，而是：

让大家知道：新增东西可以谈，但必须评估代价。

九、你可以这样理解范围管理

范围管理本质上是在回答 5 个问题：

• 我们到底要交付什么？
• 哪些事情不属于本项目？
• 这些交付物怎么拆成可执行任务？
• 完成到什么程度才算验收通过？
• 如果中途要改，怎么评估和审批？

只要这 5 个问题讲清楚，项目就不容易乱。

十、总结

PMP 中的范围管理，是项目管理里非常核心的一块。

它不是单纯写需求文档，而是要把项目的目标、边界、交付物、工作内容、验收标准、变更规则全部管理起来。

最重要的是防止项目变成这样：

一开始只是做一个小功能，
后来变成一个大系统，
但时间没变、预算没变、人也没变。

所以范围管理的核心不是“拒绝需求”，而是：

让每一个新增需求都被看见、被评估、被批准、被管理。