项目范围定义要解决的是“这次到底交付什么、做到什么程度算完成”。它把需求、边界和验收条件写成可确认的范围说明书，并经评审批准，作为后续分解与变更判断的依据。本文覆盖从需求收集到范围批准的完整动作，交付步骤表、字段表、角色分工和检查清单；范围分解、任务拆解与变更审批不在本文展开。
要点总览（TL;DR）
- 项目范围定义的核心产出是经干系人确认并批准的范围说明书，写清可交付成果、验收标准、排除项、假设与约束。
- 操作按五步推进：收集需求与约束、界定交付边界、编写范围说明书、评审与修订、批准并建立基线，每步都有明确完成标志。
- 范围说明书按字段填写：目标可观察、可交付成果能对应验收标准、排除项具体到易误解对象、假设带影响说明、约束注明来源。
- 项目经理组织过程，业务方确认验收标准，技术负责人评估可行性与约束，批准人对范围基线负责并留下可查记录。
- 完成与否看三点：字段完整可检验、评审意见逐条闭环、批准证据与基线版本可查，之后才能进入范围分解。
项目范围定义要产出什么：核心答案与操作步骤
范围定义的核心产出是一份经干系人确认的范围说明书。它至少写清四件事：项目要交付的成果、成果的验收条件、明确排除在本次之外的内容、以及成立所依赖的假设与约束。范围说明书获得批准后，才具备作为后续工作分解和变更判断依据的资格。
从需求收集到范围批准，可以拆成五个步骤。每一步都需要明确输入、动作、输出和完成标志，避免“收集了需求但没人确认”“写了文档但没人批准”这类悬空状态。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 收集需求与约束 | 业务目标、用户诉求、合同或立项材料、现有系统与资源条件 | 访谈业务方与关键用户，整理需求条目；记录时间、预算、合规、技术等约束 | 需求清单与约束清单 | 需求条目有提出人和来源，约束有明确出处 |
| 2. 界定交付边界 | 需求清单、约束清单 | 区分本次交付与后续交付，识别明显不在范围内的内容，形成排除项初稿 | 可交付成果清单与排除项初稿 | 每项需求都有归属判断：纳入、排除或待定 |
| 3. 编写范围说明书 | 可交付成果清单、排除项初稿、验收要求 | 按字段逐项填写目标、可交付成果、验收标准、排除项、假设与约束 | 范围说明书初稿 | 字段无空缺，可交付成果可被验收标准检验 |
| 4. 评审与修订 | 范围说明书初稿 | 组织业务方、技术负责人评审，处理歧义与冲突，记录修订意见 | 评审记录与修订后的范围说明书 | 评审意见逐条有处理结论 |
| 5. 批准与基线 | 修订后的范围说明书、评审记录 | 由有权限的负责人批准，确定范围基线并通知相关干系人 | 批准记录与范围基线 | 批准人、批准时间、基线版本可查 |
五个步骤中，第2步最容易被跳过。团队常把需求清单直接当成范围，结果执行中才发现有些需求属于下一期、有些依赖外部系统尚未就绪。把排除项和假设显式写出来，比事后解释更省成本。
范围说明书和需求条目需要在协作工具中承载、评审和留痕时，ONES 瀑布项目管理解决方案支持在项目下管理需求范围、研发任务等内容，并基于 PMI、CMMI 理论覆盖从立项到收尾的瀑布项目管理全过程，将需求管理、研发管理、测试管理和资源管理流程连接起来。范围说明书批准后进入工作分解环节时，ONES 支持用「项目计划」创建工作分解结构（WBS），按目标、交付物或项目阶段等维度分解计划和工作；具体分解方法属于范围分解主题，此处仅作衔接说明。
范围说明书怎么写：字段与填写要求
范围说明书不需要长篇大论，但每个字段都要写到能被检验的程度。以下字段表可直接作为填写模板使用。
| 字段 | 填写要求 | 常见问题 |
|---|---|---|
| 项目目标 | 用一到三句话说明项目要解决的业务问题和期望结果，结果尽量可观察 | 写成口号，无法判断是否达成 |
| 可交付成果 | 逐项列出本次要交付的成果，每项写清形态（系统功能、文档、报告、培训等）和范围粒度 | 粒度不一，有的写到模块，有的写到按钮 |
| 验收标准 | 与可交付成果一一对应，写清由谁、依据什么、达到什么条件算通过 | 只写“满足业务需求”，无法执行验收 |
| 排除项 | 明确列出本次不做但容易被误认为在范围内的内容，必要时注明计划归属 | 省略不写，执行中反复扯皮 |
| 假设条件 | 记录范围成立所依赖的前提，写明假设不成立时的影响 | 把假设当事实，风险暴露过晚 |
| 约束条件 | 记录时间、预算、技术、合规等硬性限制及其来源 | 只写“时间紧”，没有具体节点 |
可交付成果的描述粒度以“能对应一条验收标准”为准。如果一项成果找不到对应的验收方式，说明它要么太笼统，要么还不具备纳入本次范围的条件。验收标准建议写成“由谁在什么条件下确认什么结果”，例如“由业务负责人在测试环境完成核心流程走查并签字确认”，比“功能可用”更可执行。
排除项的写法要具体到容易被误解的对象。写“不含报表功能”不如写“不含管理驾驶舱报表，本期仅提供固定格式的月度汇总导出”。假设条件则要带上影响说明，例如“假设现有用户数据可在两周内完成清洗迁移；若延迟，验收时间相应顺延”。约束条件注明来源，便于评审时判断能否调整。
谁负责哪一步：角色分工与交付物
范围定义不是项目经理一个人的文档工作。业务方决定要什么，技术负责人判断能不能做、代价多大，干系人确认边界是否可接受，项目经理负责组织过程并保证文档完整。角色不清时，最常见的后果是范围说明书由项目经理单方起草，评审时无人真正确认。
| 角色 | 主要职责 | 交付物 | 确认动作 |
|---|---|---|---|
| 项目经理 | 组织需求收集与评审，起草和维护范围说明书，跟踪评审意见闭环 | 范围说明书初稿与修订稿、评审记录 | 确认字段完整、意见已处理 |
| 业务方 | 提出并澄清业务需求，确认可交付成果与验收标准符合业务预期 | 需求清单、验收标准确认意见 | 对验收标准签字或书面确认 |
| 技术负责人 | 评估技术可行性、依赖与约束，识别技术层面的排除项 | 技术约束说明、可行性评估意见 | 确认约束与假设已记录 |
| 关键干系人 | 从使用、运维、合规等角度评审边界，提出排除项补充 | 评审意见 | 参与评审并反馈结论 |
| 批准人 | 对范围基线负责，批准范围说明书 | 批准记录 | 签署批准并确定基线版本 |
范围批准的责任归属需要事先明确。通常由项目发起人或其授权的业务负责人批准，项目经理负责提交完整材料，不自行代替批准。批准动作应留下可查记录：批准人、批准时间、批准的版本。范围基线确定后，后续任何范围调整都进入变更管理流程，本文不展开审批细节。
当范围说明书、需求条目和评审记录需要在同一处沉淀时，ONES 的项目与需求管理能力可以把需求范围、研发任务放在项目下统一管理，便于评审意见与版本对应。范围基线确定后，ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过对比版本细节追溯变更细节，为范围基线的后续对照提供依据；具体操作以实际版本为准。
示例：一个交付项目的范围定义过程
以下为演示情景，用于说明范围定义各步骤如何落地，不代表真实项目。
某制造企业计划上线一套设备巡检管理系统，由内部研发团队承接，计划周期三个月。立项时业务方提出“把巡检、报修、备件管理都做进去”，技术负责人指出备件管理依赖尚未上线的库存系统。若直接按口头需求开工，很可能在第二个月才发现备件模块无法交付。
第一步收集需求与约束：项目经理访谈巡检主管和一线班组长，整理出巡检计划、巡检记录、异常上报、报修工单四组需求；约束清单记录三条：三个月内上线、需通过信息安全评审、库存系统尚未就绪。
第二步界定边界：四组需求中，巡检计划、巡检记录、异常上报纳入本期；报修工单纳入本期但只做提交与流转，不含备件领用；备件管理列入排除项，注明依赖库存系统上线后另行立项。技术负责人补充一条假设：移动端使用现有企业微信入口，不单独开发 App。
第三步编写范围说明书：可交付成果写为“巡检计划配置功能、移动端巡检记录填报、异常上报与通知、报修工单提交与流转、管理员操作手册、一线人员培训两场”。验收标准逐项对应，例如巡检记录填报的验收标准为“巡检员在测试环境完成一次完整巡检填报，主管可在后台查看记录并导出”。
第四步评审：评审会上业务方提出异常上报需要支持图片附件，技术负责人确认可行并纳入本期；信息安全同事提出记录留存期限要求，写入约束条件。评审意见共五条，逐条记录处理结论，其中一条“备件管理能否先做简易版”经讨论维持排除，理由是库存数据不可用会导致功能无法验收。
第五步批准：业务负责人在修订后的范围说明书上签署批准，项目经理将批准版本定为范围基线，并把排除项与假设同步给巡检主管和研发团队。后续若有人提出备件相关需求，按变更流程评估，不在本期直接插入。
完成检查：范围定义是否到位
范围定义是否完成，不看文档页数，而看三件事：字段是否完整且可检验、干系人是否真正确认、基线是否建立并能衔接后续工作。以下清单可逐项核对。
| 检查项 | 通过标准 |
|---|---|
| 目标可观察 | 项目目标能对应到可判断是否达成的结果描述 |
| 可交付成果完整 | 每项成果有形态描述，且能对应至少一条验收标准 |
| 验收标准可执行 | 写明确认人、确认条件和确认方式 |
| 排除项具体 | 列出容易被误认为在范围内的内容，必要时注明归属 |
| 假设与约束有出处 | 每条假设写明不成立时的影响，每条约束注明来源 |
| 评审意见闭环 | 评审意见逐条有处理结论，无悬空条目 |
| 批准证据可查 | 批准人、批准时间、批准版本均有记录 |
| 基线已建立 | 范围基线版本确定，并已通知相关干系人 |
| 后续衔接明确 | 范围分解的输入已就绪，变更走变更管理流程 |
清单中“评审意见闭环”和“批准证据可查”两项最容易被形式化处理。建议在评审记录中保留意见原文与处理结论的对应关系，批准记录与范围说明书版本号绑定。范围基线建立后，后续计划与执行出现偏差时，可对照基线判断是执行问题还是范围发生了变化。ONES 支持设置项目计划和里程碑基线并对比计划与执行的偏差，可作为基线对照的承载方式之一，具体功能以实际版本为准。
完成以上检查，范围定义即具备进入下一阶段的条件：以批准的范围说明书为输入开展范围分解，把可交付成果逐层拆到可估算、可分配的工作包。分解方法与变更审批分别属于范围分解和项目变更管理主题，此处不再展开。
常见问题
需求一直收不齐，范围定义能不能先做起来？
可以先启动，但要区分两种情形。若缺失的是次要需求，可先按已确认的核心需求编写范围说明书，并在假设条件中写明“某类需求待补充，补充后需重新评审验收标准”，同时设定补充截止时间。若缺失的是决定交付边界的关键需求，例如核心业务流程尚未确认，此时写出的范围说明书无法通过验收标准检验，建议先完成关键需求澄清再进入编写环节。无论哪种情形，未确认的内容都应显式记录，避免在执行中被当作已定范围。
范围说明书批准后，业务方又提出新需求怎么办？
批准后的范围说明书即为范围基线，新增需求不再直接插入本期执行，而是进入变更管理流程评估。实际操作中，项目经理可以先判断该需求是否落在已写明的排除项内：若属于排除项，直接引用原文说明本期不做及计划归属；若属于范围外的新内容，提交变更评估，说明对时间、资源和验收的影响，由批准人决定是否调整基线。把排除项写具体，能显著减少这类反复沟通的成本。
小项目也需要写完整的范围说明书吗？
字段可以精简，但关键判断不能省。小项目至少写清三件事：本次交付什么、什么算验收通过、什么明确不做。目标、假设与约束可以合并成简短说明，排除项仍建议保留，因为小项目往往靠口头约定推进，边界模糊时返工代价更明显。评审与批准环节可以简化形式，例如由业务负责人在文档中书面确认，但批准人、时间和版本仍应留下记录，便于后续对照。
范围定义和范围分解的先后关系怎么把握？
范围定义在前，范围分解在后。范围定义确定交付什么、验收条件是什么，范围分解则把已批准的可交付成果逐层拆到可估算、可分配的工作包。若在范围说明书尚未批准时就开始分解，容易出现拆到一半发现边界变化、工作包全部重做的情况。判断是否可以进入分解，可看范围说明书是否已批准、基线版本是否确定、可交付成果是否每项都有对应验收标准。分解的具体方法属于另一主题，此处不展开。
范围定义过程中，评审意见分歧较大时如何处理？
先把分歧归类：属于事实判断的（如技术是否可行、依赖是否就绪），由技术负责人给出评估依据；属于业务取舍的（如某功能本期做不做），由业务方与批准人决定优先级。每类分歧都应在评审记录中保留意见原文与处理结论的对应关系，不能只写“已讨论”。暂时无法达成一致的条目，可标记为待定并设定决策时限，同时评估其对验收标准的影响。带着未闭环的重大分歧进入批准环节，会让基线本身失去约束力。
