确定项目范围，核心是把“要交付什么、不交付什么、凭什么算完成”写成可核对的三类文件：范围说明书、WBS交付物分解、范围确认与变更规则。做法是先锁定项目目标与干系人期望，界定边界与排除项，再按交付物逐层分解到可估算、可验收的工作包，最后通过评审确认基线，并把后续调整交给变更流程。本文按这一顺序给出可直接填写的字段、分解步骤、角色分工与完成检查清单。
要点总览（TL;DR）
- 先写范围说明书，把项目目标、交付物清单、边界与排除项、验收条件、假设与约束五类信息写实，排除项要具体到对象。
- WBS以交付物为上层节点逐层分解，工作包需具备负责人、验收标准、估算依据，能独立估算和验收即可停止分解。
- 范围说明书由项目经理起草、业务与技术负责人评审、发起人确认；确认记录要能追溯到具体人员和版本，基线建立后交付物清单、边界与工作包划分受控。
- 范围蔓延靠早期信号识别：清单外新成果、验收标准临时加码、工作量明显超出估算；处置动作是记录、影响评估、移交变更管理。
- 收口时按范围说明书、WBS、确认记录、变更移交四类产物逐项核对，未通过项作为阻断项补做后再进入下一阶段。
先定边界：范围说明书要写清哪几项
范围说明书的作用，是让项目组和干系人对“这次做到哪里”形成同一份文字依据。它不需要写成长篇文档，但必须把目标、交付物、边界、验收条件、假设与约束五类信息写实。填写顺序建议从项目目标开始，再列交付物，然后划边界与排除项，最后补验收条件、假设与约束——因为排除项往往是在列交付物时才暴露出来的。
| 字段 | 填写要点 | 常见问题 |
|---|---|---|
| 项目目标 | 写清项目要解决的业务问题、目标对象和期望结果，用可判断的表述 | 写成“提升系统能力”这类无法判断是否达成的口号 |
| 交付物清单 | 逐项列出项目结束时需要移交的成果，包括文档、系统、培训材料等 | 把过程活动（如“开展调研”）当成交付物 |
| 边界与排除项 | 明确本次覆盖的业务范围、系统范围、组织范围，并单列“本次不做”的事项 | 只写“包含什么”，不写“不包含什么” |
| 验收条件 | 每个主要交付物的验收标准、验收方式和验收人 | 验收标准写成“符合要求”，没有可核对的依据 |
| 假设与约束 | 列出范围成立所依赖的前提，以及预算、时间、法规、技术等限制 | 假设不写，后期条件变化时无法追溯责任 |
边界描述要具体到对象和动作。含糊表述如“支持部分报表功能”，可修正为“交付销售、库存两类报表的查询与导出；财务类报表不在本次范围”。排除项同样要写具体，例如“不包含历史数据迁移”“不包含移动端适配”。排除项写得越明确，后续争议越少。
需要区分交付范围与执行任务拆解：范围说明书回答“交付什么成果”，属于本文的处理对象；至于由哪个小组、用什么工序去完成，属于任务拆解与组织安排，在WBS工作包确定后再展开，不写进范围说明书的交付物清单。
按交付物分解WBS：从成果到工作包的步骤
WBS的上层节点应当对应交付物，而不是部门或动作。按部门分解会让同一成果被切散在多个分支里，按动作分解则容易漏掉成果。以交付物为导向，分解过程可以按以下步骤推进：
- 把范围说明书中的交付物清单作为WBS第一层，逐项确认无遗漏、无重复。
- 对每个交付物向下分解为子交付物或主要组成部分，形成第二、第三层。
- 继续分解到工作包：能够独立估算工作量、指派一名负责人、写出验收标准的最小单元。
- 为每个工作包补充负责人、验收标准、估算依据三项要素。
- 组织交付物负责人逐层核对，确认下层之和覆盖上层，没有范围外内容混入。
| 工作包要素 | 要求 | 判断示例 |
|---|---|---|
| 负责人 | 一名明确的负责人，对工作包结果负责 | “由后端组负责”不合格，应落到具体角色或人员 |
| 验收标准 | 可观察、可核对的完成条件 | “接口文档完成并通过评审”优于“文档写好” |
| 估算依据 | 工作量或工期估算所依据的信息 | 参考同类工作包的历史数据、技术方案或专家判断 |
分解到什么程度停止，常用两条判断标准：一是工作包可以独立估算和分配，不需要再拆；二是工作包的完成状态可以被验收人直接判断。若一个工作包仍需要多人分别交付不同成果，或验收时说不清“做到什么算完成”，说明还需要继续分解。粒度过细同样有代价，会增加管理成本，通常以能支撑估算和跟踪为准，不必拆到单个操作步骤。
WBS确定后，工作包之间的先后依赖和关键节点可以一并标注，便于后续排期。在ONES中，可以使用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，并为任务设置前后置依赖、用里程碑标记重要时间点或决策点，使交付物分解结果与进度安排对应起来。
角色与交付物分工：谁写、谁审、谁确认
范围由单方拍定，是后续扯皮的主要来源。范围确定过程需要把撰写、评审、确认三类动作分到不同角色，并明确每个环节的产出物。
| 角色 | 主要动作 | 产出物 |
|---|---|---|
| 发起人 | 明确项目目标与业务优先级，对边界争议做最终裁定，确认范围基线 | 目标说明、范围确认签署 |
| 项目经理 | 组织范围说明书编写与WBS分解，汇总干系人期望，安排评审，维护范围文件版本 | 范围说明书、WBS、评审记录 |
| 业务负责人 | 提出业务需求与验收标准，确认交付物是否满足业务使用要求 | 需求说明、验收条件 |
| 技术负责人 | 评估交付物的技术可行性，识别技术约束与依赖，参与工作包估算 | 技术约束说明、估算依据 |
干系人期望的收集由项目经理牵头，业务负责人和技术负责人分别从业务与技术角度补充，冲突事项提交发起人裁定。范围说明书由项目经理起草、业务与技术负责人评审、发起人确认；WBS由项目经理组织分解，各交付物负责人核对覆盖性；确认记录在评审通过后形成，作为基线依据。三份产出物之间存在先后关系：范围说明书是WBS的输入，WBS是确认评审的主要材料，确认记录则固定评审结论。
范围确认与基线：评审通过后怎么固定
范围确认与内部评审不是一回事。内部评审是项目组对范围说明书和WBS的技术性检查，关注分解是否完整、估算是否合理；范围确认是发起人和业务负责人对“交付什么、不交付什么、凭什么算完成”的正式认可，关注的是承诺。两者可以安排在同一次会议，但确认动作要单独完成并留痕。
确认记录建议包含以下内容：确认的范围文件名称与版本、确认的交付物清单、明确的排除项、验收条件、参与确认的人员与角色、确认日期、遗留问题及处理约定。签署方式可以是会议纪要附签字、电子审批记录或书面确认单，关键是能够追溯到具体人员和具体版本。
基线建立后，受控内容包括：交付物清单及其验收条件、范围边界与排除项、WBS的工作包划分与负责人。这些内容发生调整，需要走变更流程；工作包内部的执行细节、任务排序等，属于日常执行管理，不必每次变更都升级处理。在ONES中，可以设置项目计划和里程碑基线，对比计划与执行的偏差，并通过版本对比追溯变更细节，让范围基线在项目推进中保持可查。
范围蔓延怎么控：识别、记录与移交变更
范围蔓延通常不是一次大变更造成的，而是若干“顺手做一下”累积起来的。早期识别可以关注几个信号：交付物清单外出现新的成果要求；验收标准在执行中被临时放宽或加码；工作包负责人反映工作量明显超出估算且无对应变更记录；会议纪要中频繁出现“顺便也支持一下”的表述。
发现信号后，处置动作分三步：
- 记录：把新增需求写入范围变动登记，写明提出人、提出时间、涉及的业务或系统对象、期望完成时间。
- 影响评估：由项目经理组织技术负责人评估对工作量、进度、成本和其他交付物的影响，业务负责人确认业务价值与优先级。
- 移交：将登记与评估结果提交项目变更管理，由变更流程决定是否批准、如何调整基线。本文的处理到此为止，审批决策与基线调整归项目变更管理。
范围变动登记建议保留字段：编号、提出人、需求描述、关联交付物、影响评估结论、移交日期、变更处理结果回填。登记表的价值在于让每一次范围调整都有出处，避免口头承诺变成默认范围。ONES在需求、基线、版本和变更之间建立统一管理对象，可支撑需求变更影响分析与交付结果回溯，适合把变动登记与后续变更处理放在同一条链路上。
示例：一个交付项目的范围确定全过程
以下为演示情景，用于说明步骤如何衔接，不指向真实客户或项目数据。
某企业需要建设一套内部合同管理系统。范围说明书中的项目目标写为“实现合同起草、审批、归档的线上化，覆盖法务部与采购部日常合同类型”。交付物清单包括：合同模板库、线上审批流程、归档查询功能、管理员操作手册、上线培训。排除项明确为：不包含电子签章对接、不包含历史纸质合同扫描录入、不包含与财务系统的付款联动。验收条件按交付物逐项写明，例如审批流程的验收标准为“三类合同各完成一次端到端审批并留存记录”。假设与约束中写明“法务部在项目期内指定一名对接人配合评审”。
WBS第一层对应上述五项交付物。以“线上审批流程”为例，向下分解为流程配置、审批节点权限、通知提醒三个子交付物，再分解到工作包，例如“配置三类合同的审批节点”作为一个工作包，负责人为实施顾问，验收标准为“三类合同审批路径与确认的流程图一致”，估算依据为同类项目的流程配置工作量。
项目执行到中期，采购部提出希望增加“合同到期自动提醒”功能。项目经理将其登记为范围变动，评估结论为需要新增定时任务开发与测试，影响进度约一周。该事项连同评估结果移交变更管理，由变更流程决定是否纳入本期。整个过程留下了从识别、记录、评估到移交的完整记录，范围基线在变更批准前保持不变。
完成检查：范围确定做到什么程度算完成
范围确定工作是否收口，可以按四类产物逐项核对。下表列出检查项、通过标准与责任人，未通过的项目应作为阻断项处理，补做后再进入下一阶段。
| 产物 | 检查项 | 通过标准 | 责任人 |
|---|---|---|---|
| 范围说明书 | 目标、交付物、边界与排除项、验收条件、假设与约束五类字段齐全 | 每项交付物有对应验收条件，排除项具体可读 | 项目经理 |
| WBS | 上层节点对应交付物，工作包具备负责人、验收标准、估算依据 | 下层覆盖上层，无范围外内容，工作包可独立估算与验收 | 项目经理与交付物负责人 |
| 确认记录 | 确认人员、版本、日期、遗留问题齐全 | 发起人与业务负责人完成确认，记录可追溯到具体版本 | 发起人 |
| 变更移交 | 变动登记字段完整，影响评估结论明确 | 每条变动均有移交记录，基线调整有对应变更处理结果 | 项目经理 |
未通过时的补做动作：范围说明书缺排除项，回到交付物清单逐项追问“这次不做哪些相关事项”；WBS工作包缺验收标准，由交付物负责人补充可观察的完成条件；确认记录缺签署，重新组织确认并补齐；变动登记缺影响评估，暂停纳入执行，先完成评估再移交。四类产物全部通过后，范围确定工作即可视为完成，后续调整统一进入变更管理。
常见问题
范围说明书里“排除项”写多少才够用？
排除项的数量没有固定标准，判断依据是它与交付物清单的对应关系。做法是对每个主要交付物追问一次“这次不做哪些相关事项”，把容易产生误解的相邻内容单列出来，例如不包含历史数据迁移、不包含移动端适配、不包含与某系统的对接。排除项写到具体对象和动作即可，不必穷举所有无关事项。范围说明书评审时，业务负责人和技术负责人各补充一轮，通常就能覆盖主要争议点。
WBS分解到工作包后，还需要再拆成具体任务吗？
需要，但两类工作分开管理。WBS工作包回答“交付什么、由谁负责、凭什么算完成”，是范围基线的一部分；把工作包继续拆成执行任务、安排人员与工序，属于任务拆解与组织的工作，在WBS确定后展开。工作包内部的执行细节和任务排序变化，通常按日常执行管理处理，不必每次都走变更流程；涉及交付物清单、验收条件或工作包划分的调整，才需要进入变更管理。
范围确认会议和内部评审可以合并开吗？
可以安排在同一次会议，但两个动作要分开完成并分别留痕。内部评审由项目组检查范围说明书和WBS的完整性、估算合理性；范围确认由发起人和业务负责人对交付物清单、排除项和验收条件作出正式认可。合并开会时，建议先完成技术性评审并记录修改意见，修改定稿后再进行确认环节，确认记录写明所确认的文件名称与版本，避免用评审意见代替确认结论。
项目进行中业务方口头提出新增需求，项目经理应该先做什么？
先登记，再评估，然后移交。把提出人、提出时间、需求描述、关联交付物和期望完成时间写入范围变动登记，同时向提出方说明该事项需要经过影响评估和变更流程，基线在批准前保持不变。随后组织技术负责人评估工作量、进度和成本影响，业务负责人确认业务价值与优先级，评估结果连同登记一并提交项目变更管理。审批决策和基线调整由变更流程处理，项目经理负责回填处理结果。
范围基线建立后，哪些调整需要走变更，哪些可以直接处理？
受控内容发生调整需要走变更流程，包括交付物清单及其验收条件、范围边界与排除项、WBS的工作包划分与负责人。工作包内部的执行细节、任务先后顺序、人员临时调配等，属于日常执行管理，由项目经理在授权范围内处理并做好记录。判断不清时，可以看调整是否改变了对发起人和业务负责人的交付承诺：改变了承诺就走变更，只影响执行方式则按日常管理处理。
