项目范围定义要产出两份可确认的文件：范围说明书和WBS（工作分解结构）。项目经理主导，业务负责人确认需求，技术负责人评估可行性，关键用户参与评审。本文按“先回答哪些问题—写出范围说明书—拆出WBS—明确角色—示例—完成检查”的顺序展开，覆盖范围定义这一阶段，执行阶段的任务分派和范围变更审批不在本文重点。
要点总览（TL;DR）
- 范围定义要产出两份可确认的文件：范围说明书和WBS，完成标志是关键干系人书面确认，仅有初稿不算范围成立。
- 范围说明书按六步收敛：确认目标与约束、识别干系人、收集并分类需求、划定交付边界、编写验收标准、成稿评审，每步都有负责人和完成标志。
- WBS以交付物为导向分解，层级控制在三到四层，工作包用可估算、可分配、可验收三条标准检验粒度。
- 项目经理主导全过程，业务负责人确认交付边界与验收标准，技术负责人评估可行性，关键用户核对验收标准的可检验性。
- 收口前逐项核对七项检查：目标可追溯、交付物可验收、排除项明确、假设与依赖已记录、需求已分类、WBS粒度合适、干系人已确认。
范围定义先回答哪几个问题
范围定义是把项目目标翻译成可验收的交付边界。动手写文档之前，先确认四个问题都有明确答案，否则后面的WBS会建在模糊的假设上。
- 交付什么：项目结束时，哪些产品、系统、文档或服务必须交到用户手上，各自包含哪些内容。
- 不交付什么：哪些需求、功能、场景被明确排除在本期之外，避免后续“以为包含”的争议。
- 做到什么程度算完成：每个交付物的验收标准，包括功能范围、质量指标和验收方式。
- 由谁确认：谁有权认定范围成立，确认以什么形式留下记录。
这四个问题对应范围说明书的核心字段，也决定了WBS能拆到什么程度。范围定义与相邻工作有清晰边界：需求收集负责把干系人的期望挖出来，范围定义负责从中划定本期承诺的边界；任务拆解在执行阶段把工作包分派到人和时间；变更管理处理范围确认之后的新增或调整。范围定义阶段只做边界划定，不提前排期，也不处理变更审批。
范围定义的完成标志是：范围说明书与WBS获得关键干系人确认，确认记录可查。仅有文档初稿、没有确认动作，说明范围还没有真正成立。
从项目目标到范围说明书的操作步骤
范围说明书不是一次写成的，而是按“确认输入—收集分类需求—划定边界—写验收标准—成稿评审”的顺序逐步收敛。每一步都有输入、动作、输出和负责人。
| 步骤 | 输入 | 动作 | 输出 | 负责人 | 完成标志 |
|---|---|---|---|---|---|
| 1. 确认目标与约束 | 项目章程、业务目标、预算与时间约束 | 与业务负责人对齐项目要解决的业务问题和成功判据 | 目标与约束说明（可并入范围说明书背景部分） | 项目经理、业务负责人 | 业务目标有书面表述，双方认可 |
| 2. 识别干系人 | 组织架构、项目章程 | 列出受影响和能影响项目的角色，标注决策权与关注点 | 干系人清单 | 项目经理 | 关键干系人无遗漏，确认人明确 |
| 3. 收集并分类需求 | 访谈记录、现有系统文档、业务方材料 | 汇总需求，按必须、应该、可选分类，标注来源 | 需求清单（含优先级） | 业务负责人、关键用户 | 每条需求有来源和优先级 |
| 4. 划定交付边界 | 需求清单、目标与约束 | 确定本期纳入的交付物，把不做的内容写入排除项 | 交付物清单与排除项 | 项目经理、业务负责人 | 纳入与排除均有明确条目 |
| 5. 编写验收标准 | 交付物清单 | 为每个交付物写明完成判据和验收方式 | 验收标准 | 业务负责人、技术负责人 | 每条标准可被检验 |
| 6. 成稿与评审 | 以上全部输出 | 汇总为范围说明书初稿，组织评审并修订 | 范围说明书定稿 | 项目经理 | 评审意见闭环，确认记录留存 |
范围说明书的字段构成建议包含：项目背景与目标、交付物清单、验收标准、排除项、假设与依赖、关键干系人与确认人、版本与确认记录。其中排除项和假设最容易被省略，却恰恰是后续争议的高发区，写作时应逐条落到具体功能或场景，避免“其他相关功能不在范围内”这类笼统表述。
需求分类时，把“必须”项直接映射为交付物，“可选”项要么纳入本期并写明条件，要么放入排除项或后续版本，不要留在清单里悬而不决。技术负责人在这两步介入，评估需求的技术可行性和实现代价，对明显超出约束的需求提出调整建议。
把交付物拆成WBS的方法与粒度控制
WBS以交付物为导向分解，而不是按部门或按时间排列。做法是从范围说明书中的每个交付物出发，逐层回答“这个交付物由哪些组成部分构成”，直到最底层的工作包可以被估算、分配和验收。
分解层级通常控制在三到四层：第一层是项目整体，第二层是主要交付物或阶段，第三层是子交付物，第四层是工作包。层级过深会让管理成本超过收益，层级过浅则工作包过大、无法估算。判断工作包粒度是否合适，用三个标准检验：
- 可估算：负责人能给出工作量或工期区间，而不是“大概要一阵子”。
- 可分配：能明确落到一个角色或一个人，不需要多人共同承担同一工作包。
- 可验收：完成后有可检查的产出，能对照验收标准判断是否完成。
WBS与执行阶段的任务清单有衔接也有区别：WBS回答“要交付什么、由哪些部分组成”，任务清单回答“谁在什么时间做哪一步”。一个工作包在执行时可能拆成多条任务，但任务拆解属于排期和分派环节，不在范围定义阶段完成。范围定义阶段只需保证工作包边界清楚，让后续拆任务有稳定依据。
WBS字典为每个工作包补充说明，建议记录：工作包编号、名称、所属上层交付物、工作内容描述、验收标准、负责人、估算依据、依赖关系。字典的作用是让不同人看到同一个编号时理解一致，也便于后续变更时定位影响范围。
在协作工具中承载WBS时，可以把交付物和工作包建成项目计划中的层级条目，用依赖关系表达工作包之间的先后，用里程碑标记关键确认点。ONES的项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构，并可为任务设置前后置依赖、用里程碑标记重要时间点；范围说明书、需求清单与WBS可以在同一项目下关联管理，便于确认人对照查看。
角色分工与各环节交付物
范围定义涉及四类主要角色，各自在不同环节承担确认或评估职责。角色划分的关键是让“提需求的人”和“确认范围的人”明确，避免项目经理单方面定义范围。
| 角色 | 主要职责 | 参与的评审节点 | 确认动作 |
|---|---|---|---|
| 项目经理 | 组织范围定义全过程，汇总需求、起草范围说明书、组织WBS分解与评审 | 目标对齐、范围说明书评审、WBS评审 | 提交文档、记录评审意见与确认结果 |
| 业务负责人 | 确认业务目标，判定需求优先级，确认交付物与排除项符合业务预期 | 目标对齐、需求分类、范围说明书评审 | 书面确认交付边界与验收标准 |
| 技术负责人 | 评估需求的技术可行性、实现代价与依赖，参与WBS分解的技术合理性判断 | 需求分类、WBS评审 | 确认技术方案可行、工作包划分合理 |
| 关键用户 | 提供一线使用场景与需求细节，参与验收标准的可检验性讨论 | 需求收集、验收标准评审 | 确认验收标准符合实际使用 |
各环节交付物归属如下：范围说明书由项目经理起草、业务负责人确认；WBS及WBS字典由项目经理组织、技术负责人参与评审；验收标准由业务负责人主导编写、关键用户核对；确认记录由项目经理整理留存，记录确认人、确认时间、确认版本和遗留意见。确认记录是范围成立的凭证，口头同意应在评审后补成书面记录。
范围说明书与WBS定稿后，可以在ONES中把需求范围、交付物条目和确认状态放在同一项目下管理，评审意见和版本变化随文档留存，后续对照基线查看计划与执行的偏差时有据可查。这样范围定义的产出不只是几份文件，而是可追溯的确认链条。
示例：一个内部系统项目的范围定义过程
以下为演示情景，用于说明字段如何填写，不代表真实项目。
背景与目标：某公司计划建设内部报销系统，替代现有的线下审批流程。目标是让员工在线提交报销单、主管在线审批、财务批量导出付款数据，一期覆盖总部两个部门。
范围说明书关键字段示例：
- 交付物：报销单在线填报页面、两级审批流、财务导出功能、操作手册。
- 验收标准：报销单提交后主管可在系统内审批；审批通过的单据财务可导出为指定格式；操作手册覆盖全部角色操作；试点部门完成一轮真实报销。
- 排除项：不与外部银行系统直连；不含移动端应用；不含历史纸质单据补录；不含多币种报销。
- 假设与依赖：财务科目表由财务部在开发启动前提供；试点部门指定一名关键用户配合测试。
- 确认人：业务负责人（财务总监）、技术负责人（IT 经理）。
WBS分解片段示例：
- 1 报销系统一期
- 1.1 报销单填报功能
- 1.1.1 表单字段与校验规则
- 1.1.2 附件上传与存储
- 1.2 审批流
- 1.2.1 两级审批规则配置
- 1.2.2 审批通知与待办
- 1.3 财务导出
- 1.3.1 导出字段与格式定义
- 1.3.2 导出权限控制
- 1.4 操作手册与试点
- 1.1 报销单填报功能
每个工作包在WBS字典中补充验收标准和负责人，例如“1.3.1 导出字段与格式定义”的验收标准是“导出文件字段与财务提供的模板一致，抽样核对无缺列”，负责人为开发负责人。
示例中的取舍：业务方提出希望同时支持手机审批，评估后认为一期时间约束内无法保证质量，将其写入排除项并列入后续版本讨论；历史单据补录工作量大且不影响新流程运行，同样排除。把这两项明确写进排除项，比在会上口头说明更能减少后续争议。
范围定义的完成检查与常见遗漏
进入WBS细化排期或执行阶段之前，用下面这份清单逐项核对。全部通过，说明范围定义可以收口；有未通过项，先补齐再推进。
| 检查项 | 核验方式 | 通过标准 |
|---|---|---|
| 目标可追溯 | 对照项目章程与业务目标 | 每个交付物能说明支撑哪项业务目标 |
| 交付物可验收 | 逐条检查验收标准 | 每条标准有可观察的完成判据和验收方式 |
| 排除项明确 | 检查排除项条目 | 排除内容具体到功能或场景，无笼统表述 |
| 假设与依赖已记录 | 检查假设清单 | 外部依赖有责任方和时间要求 |
| 需求已分类 | 检查需求清单 | 必须、可选需求均有归属，无悬置项 |
| WBS粒度合适 | 抽查工作包 | 每个工作包可估算、可分配、可验收 |
| 干系人已确认 | 检查确认记录 | 关键确认人有书面确认，版本与时间可查 |
常见遗漏集中在四处：验收标准写成“满足业务需求”这类无法检验的表述；排除项缺失或过于笼统，导致执行中反复争论；需求收集后未分类，可选项被默认当成承诺；确认只发生在会议上，没有留下记录，人员变动后范围依据丢失。
检查未通过时，按遗漏类型分别处理：验收标准模糊的，回到业务负责人和关键用户处补充可检验判据；排除项缺失的，组织一次边界确认会，把争议项逐条落纸；需求未分类的，补做优先级判定并同步给提出方；确认无记录的，补签确认单或在协作工具中留下评审结论。补齐后重新核对清单，确认通过再进入下一阶段。
常见问题
范围说明书和需求清单是什么关系，能不能只写需求清单？
两者承担不同职责。需求清单记录干系人提出的期望，包含来源和优先级；范围说明书在此基础上划定本期承诺的边界，明确交付物、验收标准、排除项、假设与确认人。只写需求清单，团队知道“有人想要什么”，但不知道“本期承诺做到哪里、什么不做”，执行中容易出现范围蔓延。实际操作中，需求清单是范围说明书的输入，范围说明书是需求分类后的结论。
WBS要拆到多细才算合适？
用三条标准检验最底层工作包：负责人能给出工作量或工期区间；能落到一个角色或一个人；完成后有可检查的产出。三条都满足即可停止分解，不必追求统一层数。层级通常控制在三到四层，再往下拆管理成本会超过收益。需要提醒的是，工作包不等于执行任务，一个工作包在排期时可能拆成多条任务，那属于执行阶段的工作。
业务方在评审时临时提出新需求，应该怎么处理？
先判断它是否属于本期目标。属于本期且影响交付边界的，回到需求分类环节，明确优先级并评估对时间和代价的影响，由业务负责人决定纳入本期还是放入排除项或后续版本；不属于本期目标的，直接记入排除项或需求池。范围定义阶段不处理变更审批，范围确认之后的新增和调整走变更管理流程。关键是把结论落到书面，避免口头承诺留在会议记录之外。
范围定义需要开几次评审会，确认记录应该包含什么？
评审节点通常有三个：目标对齐、范围说明书评审、WBS评审，规模小的项目可以合并为一次，但确认动作不能省。确认记录建议包含确认人、确认时间、确认的文档版本和遗留意见，口头同意应在评审后补成书面记录。人员变动或后续出现争议时，这份记录是范围成立的凭证。在协作工具中留存评审结论和版本变化，可以让确认链条随时可查。
范围定义完成后，进入执行阶段前还需要做什么？
先按完成检查清单逐项核对，全部通过再推进。之后的工作属于执行阶段：把工作包拆成具体任务、分派到人、排出时间计划。范围定义阶段只保证边界清楚、工作包可估算可分配，不提前排期。如果检查中发现验收标准模糊或排除项缺失，先补齐再进入下一阶段，否则排期会建立在不确定的边界上。
