编写项目范围说明书，先锁定项目目标与可交付成果，再逐项写清范围边界、验收标准、假设与制约、依赖与除外责任，最后经发起人和关键干系人评审签字形成基线。核心做法是用“目标—可交付成果—验收标准”三列对齐，用“范围内/范围外”两栏划清边界，用假设与制约记录前提，并说明后续调整走变更管理入口。本文按文档编写任务展开，范围分解与变更审批细节留给相邻主题。
要点总览（TL;DR）
- 范围说明书按七块骨架编写：项目目标、可交付成果、验收标准、范围边界与排除项、假设与制约、高层级需求、里程碑与审批，每块对应固定输入来源。
- 编写顺序是目标→可交付成果→验收标准→范围边界→假设与制约→评审定基线，前一项决定后一项，写完一步再进入下一步。
- 项目经理主笔整合，业务负责人提供需求与验收口径，技术负责人确认可行性与依赖，发起人和关键干系人评审批准基线。
- 评审重点检查目标可衡量、验收标准可判定、排除项具体、假设标注影响；通过后编号存档，后续范围调整转入变更管理。
- 定稿前用完成检查清单逐项核对，目标、验收标准、排除项、批准记录、版本位置属于阻断项，未解决不进入基线。
先定结构：范围说明书要写哪几块
范围说明书的作用是让项目团队和干系人对“做什么、做到什么程度、不做什么”形成同一份可引用的文字。动笔前先定章节骨架，比边写边想更省返工。一份可直接套用的骨架通常包含七块：项目目标、可交付成果、验收标准、范围边界（含排除项）、假设与制约、高层级需求、里程碑与审批。每块回答一个具体问题，输入来源也相对固定。
| 章节 | 回答的问题 | 主要输入来源 |
|---|---|---|
| 项目目标 | 项目要达成什么结果，用什么指标判断达成 | 项目章程、业务立项材料 |
| 可交付成果 | 项目结束时交付哪些可被接收的成果 | 章程、需求清单、干系人访谈 |
| 验收标准 | 每项成果由谁、依据什么、达到什么条件算通过 | 业务负责人确认的验收口径、质量要求 |
| 范围边界与排除项 | 哪些业务对象和功能在项目内，哪些明确不做 | 需求清单、干系人访谈、合同或任务书 |
| 假设与制约 | 编写和推进所依赖的前提、外部限制是什么 | 章程、资源与合规要求、技术负责人意见 |
| 高层级需求 | 支撑目标的主要需求类别和优先级 | 需求清单、用户访谈记录 |
| 里程碑与审批 | 哪些时间点需要评审或决策确认 | 项目计划草案、治理安排 |
这份骨架只解决“写什么”。可交付成果如何继续拆成工作包，属于范围分解环节；范围确定后如何审批调整，属于变更管理环节。范围说明书本身承担的是定义与确认，把这两件事写进文档时只需说明衔接入口，不必展开方法。
编写步骤：从目标到验收标准逐项落地
按顺序编写能减少前后矛盾：目标决定可交付成果，可交付成果决定验收标准，边界和假设再约束前面三项。每一步都应有明确输入、动作、输出和完成标志，写完一步再进入下一步。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提取目标与高层级需求 | 项目章程、立项材料、需求清单 | 把章程中的目的转写为可衡量的目标陈述，归纳主要需求类别 | 目标段落、高层级需求清单 | 每个目标都有指标、时间范围或可观察结果 |
| 2. 列可交付成果并配验收标准 | 需求清单、业务负责人意见 | 逐项列出可被接收的成果，为每项写明验收人、验收依据和通过条件 | 可交付成果清单及验收标准 | 每项成果都能找到唯一验收人和可判定条件 |
| 3. 写范围边界 | 需求清单、干系人访谈 | 分“范围内/范围外”两栏填写，排除项具体到业务对象或功能 | 范围边界段落 | 排除项没有“暂不考虑”这类模糊表述 |
| 4. 记录假设、制约与外部依赖 | 章程、技术负责人意见、资源安排 | 逐条写前提条件、限制因素和外部依赖，并标注影响 | 假设与制约清单 | 每条假设都写明“若不成立会影响什么” |
| 5. 评审、修订并形成基线 | 完整草稿、评审意见 | 组织评审会，逐条处理意见，确认批准人和版本号 | 基线版本范围说明书 | 批准人确认、版本标识和存放位置明确 |
第一步常见的偏差是把章程原文照抄成目标。可衡量的目标陈述应包含对象、结果和判断口径，例如把“提升客户满意度”改写为“上线后三个月内，客户服务工单平均首次响应时间从当前水平降至约定目标值”。具体数值来自项目实际约定，编写时向业务负责人确认，不自行设定。
第二步的关键是验收标准与可交付成果一一对应。一项成果配多条标准时，要写清是全部满足还是满足其一。验收人写角色而非泛称，验收依据写可查阅的文件、测试结果或业务确认记录。第三步的排除项最容易写空，判断方法是问一句“如果干系人提出这项需求，我们是否要启动变更”，答案是“要”的，就应明确列入范围外。
角色分工与各环节交付物
范围说明书写完却无人认账，通常不是文字问题，而是角色和确认动作没有落到人。编写阶段需要四类角色参与，各自提供不同输入，并在评审环节留下确认记录。
| 角色 | 职责 | 交付物 | 参与时点 |
|---|---|---|---|
| 项目经理 | 主笔与整合，负责目标、边界、假设与制约成文，组织评审 | 范围说明书草稿与修订稿、评审记录 | 编写全过程 |
| 业务负责人/产品负责人 | 提供需求范围与验收口径，确认排除项是否符合业务预期 | 需求清单确认、验收标准意见 | 步骤1至3，评审会 |
| 技术负责人 | 确认可交付成果的技术可行性，说明外部依赖和技术制约 | 可行性意见、依赖清单 | 步骤2和4，评审会 |
| 发起人与关键干系人 | 评审目标与范围边界，批准基线 | 评审意见、批准确认 | 评审与基线确认 |
签字确认方式按团队治理习惯确定，可以是评审会纪要中的逐项确认，也可以是文档审批记录。无论采用哪种形式，都要能回答三个问题：谁批准了这版范围、批准的是哪个版本、批准时间是什么时候。项目经理负责把这些记录与文档放在同一处，避免后续引用时找不到依据。
在工具承载上，ONES 瀑布项目管理解决方案支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，也支持用里程碑标记重要时间点、事件或决策点。范围说明书定稿后，可交付成果可以对应到计划中的交付物条目，阶段审批点可以对应里程碑，使文档中的范围定义与计划执行保持同一套对象。需求范围、研发任务也可在项目下统一管理，便于编写时核对需求清单与范围边界是否一致。
示例：一份范围说明书的关键段落怎么写
以下为演示情景，用于示范写法，不代表真实项目。假设某企业要建设内部合同管理系统，范围说明书的关键段落可以这样写。
目标段落示例：“在项目验收后两个月内，实现合同起草、审批、归档全流程线上办理；合同平均审批周期由现行人工流转水平下降至双方约定的目标值；合同台账可按合同类型、签约主体和到期时间查询。”目标包含对象、结果和时间范围，判断口径可在验收时核对。
可交付成果与验收标准示例：
| 可交付成果 | 验收人 | 验收依据 | 通过条件 |
|---|---|---|---|
| 合同起草与审批功能 | 法务负责人 | 需求确认单、测试报告 | 约定审批场景全部跑通，审批记录可追溯 |
| 合同台账与到期提醒 | 合同管理员 | 业务验收记录 | 台账字段完整，提醒按约定提前天数触发 |
| 历史合同数据迁移结果 | 业务负责人 | 迁移核对清单 | 抽样核对一致率达到双方约定标准 |
范围内/范围外示例：范围内写“合同起草、审批、归档、台账查询、到期提醒”；范围外写“电子签章对接、与财务系统的付款联动、供应商门户”。排除项写到具体业务对象，干系人看到后能判断是否需要另行立项或走变更。
假设与制约示例：“假设法务部在需求确认后两周内完成审批流程定稿；若延迟，审批功能开发将顺延。”“制约：系统需部署在企业现有云环境内，迁移窗口由运维部门统一安排。”每条假设都带影响说明，评审时才能判断风险。
从示例可以提炼三条写法规律：目标写结果和判断口径，不写努力方向；验收标准写人和依据，不写“满足业务需要”；排除项写具体对象，不写“其他事项”。
评审与基线：让范围说明书真正生效
草稿写完只完成一半，评审和基线确认才让文档具备被引用的效力。评审会不必逐字通读，重点检查四类问题：目标是否可衡量、验收标准是否可判定、排除项是否明确、假设是否有依据并标注影响。每类问题指定对应角色回应，业务口径由业务负责人确认，技术可行性由技术负责人确认。
评审通过后形成基线版本，需要做三件事：给版本编号并注明批准日期；把文档存放在团队约定的唯一位置，后续引用以该版本为准；记录批准人和评审意见处理结果。基线之后的范围调整转入变更管理，本文只说明入口：任何新增或删减范围外事项的请求，都应提交变更申请，说明影响并由批准人决策，不在原文档上直接改写。
范围说明书与后续范围分解的衔接关系是：说明书定义可交付成果和边界，范围分解把可交付成果继续拆成可管理的工作包，两者保持同一套成果名称和编号，避免计划里出现说明书未定义的内容。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过版本对比追溯变更细节；范围说明书确认的可交付成果进入计划后，可借助这一机制观察执行是否偏离已确认范围。
完成检查：范围说明书是否可交付
定稿前用下面这份清单逐项核对。标注为阻断项的问题未解决时，文档不宜进入基线。
| 检查项 | 通过标准 | 是否阻断 |
|---|---|---|
| 目标可衡量 | 每个目标有指标、时间范围或可观察结果 | 是 |
| 可交付成果有验收标准 | 每项成果都写明验收人、验收依据和通过条件 | 是 |
| 排除项具体 | 范围外事项写到业务对象或功能，无“暂不考虑”类表述 | 是 |
| 假设与制约标注影响 | 每条假设说明不成立时的影响，制约注明来源 | 否，但需在评审中说明 |
| 评审与批准记录完整 | 批准人、批准版本、批准时间可查 | 是 |
| 版本与存放位置明确 | 版本号唯一，存放位置为团队约定位置 | 是 |
| 与需求清单一致 | 范围内事项能对应需求清单条目，无未确认需求混入 | 否，需在评审中澄清 |
清单全部通过后，范围说明书即可作为基线交付，后续范围分解、计划编制和变更判断都以这一版为参照。若评审中发现目标或验收标准存在争议，先回到对应步骤补充确认，再重新提交评审，避免带着未决问题进入基线。
常见问题
范围说明书和项目章程内容重叠，编写时怎么区分？
章程解决“为什么做、谁授权做”，范围说明书解决“做什么、做到什么程度、不做什么”。编写时从章程提取项目目的和高层级需求，转写为可衡量的目标陈述，再往下展开可交付成果和验收标准。章程中的授权信息、发起人职责不必重复抄入范围说明书，引用章程版本即可。
如果章程本身目标写得笼统，先在范围说明书的目标段落里补齐指标和判断口径，并向业务负责人确认，避免把模糊表述继续往下传递。
干系人在评审时提出新增需求，应该当场写进范围说明书吗？
评审阶段的新增需求先判断是否属于已定义范围。属于范围内且原需求清单已覆盖的，补充说明即可；超出范围边界的，记录为变更请求，转入变更管理评估影响，不在评审会上直接改写基线草稿。
这样处理的好处是范围说明书保持可追溯：哪些内容在基线内、哪些通过变更进入，后续计划编制和验收都有明确依据。评审纪要中应写明该请求的处理去向和责任人。
项目周期短、团队规模小，范围说明书可以简化吗？
可以按项目实际调整详略，但四类内容建议保留：目标及判断口径、可交付成果与验收人、范围外事项、关键假设。周期短的项目可以把章节合并成一页文档，验收标准写成简表，排除项列三五条具体对象。
简化的是篇幅和格式，保留的是可判定性。目标仍要能回答“怎么算达成”，验收标准仍要能回答“谁依据什么确认通过”，否则文档在验收和变更判断时无法被引用。
范围说明书定稿后，执行中发现漏了一项必要工作，怎么处理？
先判断该工作是否在已确认的范围边界内。属于范围内但描述不完整的，按文档修订流程补充说明并记录修订原因；属于范围外事项的，提交变更申请，说明对进度、资源和验收的影响，由批准人决策后再更新基线。
两种情况的共同要求是留下记录：修订或变更都要对应到版本号，避免执行内容与基线文档脱节。后续范围分解和计划调整以更新后的版本为参照。
范围说明书里的验收标准写到什么颗粒度合适？
颗粒度以“验收人能独立判断通过与否”为准。每项可交付成果至少写明验收人角色、验收依据（需求确认单、测试报告、业务验收记录等）和通过条件；一项成果有多条标准时，注明是全部满足还是满足其一。
不必写到具体测试用例级别，那属于测试计划的内容。范围说明书的验收标准承担的是确认口径，后续测试和验收执行可以在此基础上细化。
