项目范围管理（需求、WBS 与确认范围）

两个"范围"别混

类型	定义	回答的问题
产品范围	产品、服务或成果的特征和功能	产品要有什么功能、什么性能
项目范围	为交付产品所必须完成的工作	项目团队要干哪些活

产品范围没定义清楚，项目范围一定失控；项目范围没圈住，产品范围再清楚也交付不了。

六个过程

过程	过程组	输出
规划范围管理	规划	范围管理计划、需求管理计划
收集需求	规划	需求文件、需求跟踪矩阵
定义范围	规划	项目范围说明书
创建 WBS	规划	范围基准（WBS + WBS 字典）
确认范围	监控	验收的可交付成果、变更请求
控制范围	监控	工作绩效信息、变更请求

收集需求：把"想要"变成"可验证"

常用工具：

• 访谈：一对一，适合高层级需求；
• 焦点小组：同角色群体，挖深层需求；
• 引导式研讨会：跨职能一起定义需求（JAD、QFD）；
• 问卷：大范围、快速收集；
• 标杆对照：看竞品/行业最佳；
• 观察/原型：用户说不清时，看他怎么做、给他一个样品；
• 上下文图：画系统与外部实体的边界；
• 亲和图/思维导图：把杂乱需求归类。

输出两份关键文件：

• 需求文件：每个需求要有编号、描述、来源、优先级、验收标准、假设与约束；
• 需求跟踪矩阵（RTM）：需求 → 设计 → 开发 → 测试 → 验收，一路可追。RTM 是防"需求漏做"和"范围蔓延"的利器。

定义范围：范围说明书

项目范围说明书至少包含：

• 产品范围描述；
• 主要可交付成果；
• 验收标准（可测量）；
• 除外责任（Exclusions）——明确不做什么，比写做什么更能防扯皮；
• 假设条件与制约因素。

制造业 NPI 项目里，"除外责任"尤其重要：模具费谁出、认证费谁承担、客户提供哪些来料、试产良率谁负责，写清楚比事后开会强。

创建 WBS：100% 规则

WBS（工作分解结构）是把项目范围逐层拆到工作包的层级结构。核心规则：

1. 100% 规则：下一层所有工作包之和 = 上一层 100%，不能多也不能少；
2. 面向交付物：按可交付成果拆，不按部门拆；
3. 工作包可估算、可分配、可验收：一般 8～80 小时，最多不超过一个报告周期；
4. WBS 字典：每个工作包写清范围、验收标准、责任人、估算、依赖。

几个概念：

• 控制账户（Control Account）：管理层面的节点，用来挂进度、成本、范围绩效；
• 规划包（Planning Package）：知道要做什么但还没细拆，属于滚动式规划；
• 工作包：最底层，直接派活；
• 滚动式规划：近期细、远期粗，随项目推进逐步细化。

WBS 不是组织架构图，也不是进度计划。WBS 只回答"做什么"，进度计划回答"什么时候做、谁做"。

确认范围 vs 控制质量

这两个过程经常被混：

过程	目的	谁做	依据
控制质量	可交付成果对不对（符合规格）	团队/质量	质量指标、检查
确认范围	可交付成果被不被接受（符合需求）	客户/发起人	范围说明书、验收标准

顺序通常是：先控制质量（内部检查合格），再确认范围（客户验收）。内部检验合格但客户不认，说明需求没对齐；客户认了但内部有缺陷，说明质量门没守住。

控制范围：防蔓延，也防镀金

• 范围蔓延（Scope Creep）：未经批准的范围增加，通常是"顺便加一点"积累出来的；
• 镀金（Gold Plating）：团队主动加了客户没要求的功能，看似好心，实则增加成本与风险。

控制手段：

1. 所有范围变更走整体变更控制；
2. 用 RTM 检查每条需求是否都有交付和验证；
3. 定期对照范围基准做偏差分析；
4. 验收标准写可测量的，不写"满足客户要求"。

制造业场景：NPI 范围怎么圈

• 产品范围：功能、性能、外观、可靠性、法规认证；
• 项目范围：DFM、样件、模具、治具、试产、PPAP、量产导入；
• 除外责任：客户来料、客户认证费用、产品设计归属、售后责任；
• 验收标准：样件合格率、Cmk/Ppk、PPAP 批准、试产良率、节拍达标。

范围说明书 + WBS + RTM 三件套做完，项目才具备"可计划、可报价、可验收"的基础。

关联条目

• PMBOK 知识体系总览
• WBS 与项目进度计划
• 项目整合管理
• 进度管理
• 样品阶段、设计冻结与设计认可