项目范围说明书模板以一张可直接复制的空白表为核心，覆盖项目与产品范围描述、可交付成果、验收标准、除外责任、假设与制约、范围变更入口等字段。填写时先写清“做什么、交付什么、凭什么验收”，再补“不做什么”和变更路径，最后让发起人、项目经理与主要干系人确认基线。下文给出空白表、逐字段写法、必填与选填规则、一份完整示例，以及模板随项目演进的维护方法。
要点总览（TL;DR）
- 模板以一张可复制的空白表为核心，按基本信息、目标与范围描述、可交付成果与验收标准、除外责任、假设与制约、变更与签字六个区域组织，从上往下逐区填写。
- 填写顺序是先写清做什么、交付什么、凭什么验收，再补不做什么和变更路径，最后由发起人、项目经理与主要干系人确认基线。
- 项目名称、版本、编制人、审批人、项目目标、项目范围描述、可交付成果、验收标准与签字为必填；产品范围描述、验收方式、假设与制约可按项目情况选填，留空需标注原因。
- 模板可按项目规模裁剪：小型短周期项目保留六项核心字段，跨部门或合同约束强的项目强化制约因素与变更入口。
- 基线批准后每次范围变化都要递增版本号并更新修订记录，同步通知范围分解与计划排期的责任人。
可复制空白模板：项目范围说明书表格
下面这张表可以整段复制到 Word、在线文档或表格工具中，按行填写即可。表格分为六个区域：基本信息、项目目标与范围描述、可交付成果与验收标准、除外责任、假设条件与制约因素、范围变更与确认签字。区域顺序对应填写顺序，建议从上往下逐区完成。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 一、基本信息 | 项目名称 | |
| 文档版本 | V . （如 V1.0） | |
| 编制人 / 日期 | ||
| 审批人 / 审批日期 | ||
| 项目发起人 | ||
| 二、项目目标与范围描述 | 项目目标 | |
| 产品范围描述 | ||
| 项目范围描述（做什么） | ||
| 三、可交付成果与验收标准 | 可交付成果清单 | |
| 验收标准 | ||
| 验收方式与责任人 | ||
| 四、除外责任 | 明确不包含的内容 | |
| 五、假设条件与制约因素 | 假设条件 | |
| 制约因素 | ||
| 六、范围变更与确认签字 | 范围变更入口 | |
| 干系人确认 | 姓名 / 角色 / 日期 | |
| 签字 | 发起人： 项目经理： 主要干系人： |
复制时保留“区域”列作为填写指引，正式归档版本可以删除该列，只保留字段名与内容两列。可交付成果清单和验收标准建议在表格内用编号分行，例如“D1、D2”，便于后续与范围分解逐项对应。
字段说明：每个格子该写什么
模板能否被独立填写，取决于每个字段是否有明确的写法要求。下表逐字段说明含义与写法，重点区分“描述性字段”和“可核验字段”：前者写清边界，后者写到能被第三方判断是否达成。
| 字段 | 含义 | 写法要求 |
|---|---|---|
| 项目名称 | 本说明书对应的项目标识 | 与立项文件、合同或项目管理系统中的名称保持一致，避免简称混用 |
| 文档版本 | 说明书的修订版本 | 首次基线用 V1.0；每次批准后的修改递增次版本号，并在修订记录中注明原因 |
| 编制人 / 日期 | 文档起草责任人与完成日期 | 写具体人名，不写部门代称；日期写到日 |
| 审批人 / 审批日期 | 批准该范围基线的人 | 通常为项目发起人或其授权人；审批日期是基线生效时间 |
| 项目发起人 | 为项目提供资源与决策支持的角色 | 写姓名与职务，便于变更时找到决策人 |
| 项目目标 | 项目要达成的业务结果 | 写结果而非活动，尽量带衡量口径，如“上线后覆盖 3 个业务部门” |
| 产品范围描述 | 产品、系统或服务本身的特征与功能 | 描述交付物“是什么”，可用功能清单或特性概述 |
| 项目范围描述 | 为交付产品所需完成的工作 | 按“做什么”逐条列出主要工作包或阶段，动词开头 |
| 可交付成果清单 | 项目需要产出的有形或可验证结果 | 逐项编号，每项写清名称与完成形态，如“需求规格说明书（评审通过版）” |
| 验收标准 | 判断可交付成果是否合格的依据 | 写到可度量：数量、比例、通过条件、检查方式；避免“满足要求”这类无法判断的表述 |
| 验收方式与责任人 | 由谁、以什么方式验收 | 写评审会、测试报告、现场检查等方式及对应责任人 |
| 除外责任 | 明确不属于本项目范围的内容 | 逐条写“不包含……”，针对容易被误认为在范围内的相邻工作 |
| 假设条件 | 编制范围时默认成立、但尚未验证的前提 | 写“假设……成立”，并注明假设不成立时的影响 |
| 制约因素 | 限制项目选择空间的既定条件 | 写预算上限、强制节点、指定技术路线、合规要求等 |
| 范围变更入口 | 范围需要调整时走什么路径 | 写变更申请的提交对象、评审形式与批准人，指向具体流程或表单 |
| 干系人确认与签字 | 范围基线获得认可的记录 | 逐人记录姓名、角色、确认日期；签字表示认可当前版本为基线 |
范围描述与可交付成果两个字段容易写混：范围描述回答“团队要做哪些工作”，可交付成果回答“做完后交出什么”。前者用工作包或阶段组织，后者用编号清单组织，两者应能互相对应，每一项可交付成果都能在范围描述中找到支撑工作。
验收标准字段建议采用“对象＋条件＋判定方式”的结构。例如“接口联调完成，核心接口成功率不低于约定阈值，以测试报告为准”，比“系统运行稳定”更容易在验收会上形成一致判断。除外责任字段则要针对项目边界上最易产生分歧的相邻工作来写，例如“本次不包含历史数据迁移”“不包含第三方系统改造”。
必填与选填：哪些字段不能空
模板字段并非每份项目都要全部填满，但有几类字段缺失会直接影响范围基线是否成立。判断标准是：该字段缺失后，是否会导致范围无法界定、验收无法判断或变更无法追溯。下表给出必填与选填的对照。
| 字段 | 必填 / 选填 | 理由与适用条件 |
|---|---|---|
| 项目名称、文档版本、编制人 / 日期 | 必填 | 文档身份与追溯的基础，任何项目都不可缺 |
| 审批人 / 审批日期、项目发起人 | 必填 | 没有批准人，范围基线不成立 |
| 项目目标 | 必填 | 范围取舍的判断依据 |
| 项目范围描述 | 必填 | 说明书的核心内容 |
| 可交付成果清单 | 必填 | 验收与后续分解的对象 |
| 验收标准 | 必填 | 缺少则无法判断交付是否完成 |
| 除外责任 | 建议必填 | 边界争议多的项目必须写；内部小项目至少写一条最易混淆的排除项 |
| 产品范围描述 | 选填 | 交付物为软件、系统等有明确产品形态时填写；纯服务或内部改进项目可并入项目范围描述 |
| 验收方式与责任人 | 选填 | 验收流程已在合同或质量计划中约定时可引用，不重复展开 |
| 假设条件 | 选填 | 存在未验证前提时填写；前提均已确认的项目可写“无” |
| 制约因素 | 选填 | 有预算、节点、技术或合规硬约束时填写 |
| 范围变更入口 | 建议必填 | 项目周期超过一个交付阶段时应写明；一次性短任务可引用组织统一变更流程 |
| 干系人确认与签字 | 必填 | 基线确认的记录，至少包含发起人与项目经理 |
留空处理遵循两条规则：一是选填字段确实不适用时，写“不适用”并简述原因，不留空白格，避免读者误以为遗漏；二是必填字段在基线批准前不得为空，若信息暂缺，写“待确认”并注明责任人与确认时限，在批准前补齐。不同项目类型下的取舍可以这样把握：研发或交付类项目重点填产品范围描述与验收标准；内部改进类项目重点填项目目标与除外责任；合同约束强的项目重点填制约因素与变更入口。
填写示例：一份填好的范围说明书
以下示例为演示情景，用于说明字段之间的对应关系，非真实客户案例。示例项目为某企业“客户服务工单系统升级”，采用表格模板填写。
| 字段 | 填写内容 |
|---|---|
| 项目名称 | 客户服务工单系统升级项目 |
| 文档版本 | V1.0 |
| 编制人 / 日期 | 张明（项目经理）/ 2025-03-10 |
| 审批人 / 审批日期 | 李华（运营总监）/ 2025-03-14 |
| 项目发起人 | 李华，运营总监 |
| 项目目标 | 将工单平均首次响应时间从现状缩短至约定目标，并在升级后覆盖客服一线与二线两个团队 |
| 产品范围描述 | 升级后的工单系统包含工单创建与分派、优先级规则、服务时限提醒、知识库关联四项功能 |
| 项目范围描述（做什么） | 1. 梳理现有工单流程与分派规则；2. 完成系统配置与规则开发；3. 迁移在用工单模板；4. 组织一线与二线客服培训；5. 试运行与上线切换 |
| 可交付成果清单 | D1 流程与规则说明文档（评审通过版）；D2 升级后的工单系统（试运行通过）；D3 工单模板迁移清单；D4 培训记录与操作手册；D5 上线切换方案与上线报告 |
| 验收标准 | D1 经客服负责人评审签字；D2 试运行期间工单分派规则按配置执行，抽检样本全部符合规则；D3 在用模板全部完成迁移并经抽样核对；D4 一线与二线客服参训覆盖率与考核通过率达标；D5 上线后连续运行观察期内无阻断性故障 |
| 验收方式与责任人 | 评审会（客服负责人）、试运行抽检（项目经理与客服主管）、上线评审（发起人） |
| 除外责任 | 不包含历史工单数据清洗；不包含与第三方呼叫中心系统的接口改造；不包含客服绩效考核规则调整 |
| 假设条件 | 假设现有工单数据可在升级前完成备份；假设客服团队在培训期可安排脱产时间。若假设不成立，上线时间相应顺延并提交变更 |
| 制约因素 | 上线时间不得晚于业务旺季前；系统须部署在现有合规环境内；预算不超过已批准额度 |
| 范围变更入口 | 新增或删减可交付成果须提交范围变更申请，由发起人审批；审批通过后更新本说明书版本 |
| 干系人确认 | 李华（发起人）2025-03-14；张明（项目经理）2025-03-14；王芳（客服负责人）2025-03-13 |
| 签字 | 发起人：李华 项目经理：张明 主要干系人：王芳 |
这份示例体现了三个填写要点：可交付成果用 D1—D5 编号，验收标准逐项对应，读者能直接看出每项成果如何判定完成；除外责任针对最容易被误认为在范围内的三项相邻工作；假设条件写明了不成立时的处理方式，使假设成为可跟踪的事项而非空话。
调整与维护：模板如何随项目演进
模板拿到后需要按项目情况裁剪，并在基线批准后持续维护。裁剪的原则是保留能支撑范围界定、验收判断和变更追溯的字段，合并或省略重复表达的部分；维护的原则是每次范围变化都留下版本痕迹，使说明书始终与项目实际一致。
按项目规模裁剪字段
- 小型、周期短的项目：保留基本信息、项目目标、项目范围描述、可交付成果、验收标准、签字六项；除外责任至少写一条；假设与制约可合并为一栏。
- 中型交付项目：使用完整模板，产品范围描述与项目范围描述分列，验收方式与责任人单独填写。
- 跨部门或合同约束强的项目：在完整模板基础上强化制约因素与变更入口，验收标准写到可抽检、可复核的程度。
版本号与修订记录维护
首次批准的版本记为 V1.0，作为范围基线。此后每次经批准的修改递增次版本号，如 V1.1、V1.2；范围发生结构性调整时递增主版本号，如 V2.0。修订记录至少包含版本号、修订日期、修订人、修订内容和批准人，附在说明书末尾或独立成表。修订记录与正文版本号必须一致，避免出现正文已改、记录未更新的情况。
范围变更批准后如何更新说明书
- 确认变更申请已获批准，记录批准人与批准日期。
- 修改受影响的字段：可交付成果清单、验收标准、除外责任或制约因素，逐项对应变更内容。
- 更新文档版本号，在修订记录中写明变更来源与影响范围。
- 将更新后的说明书重新提交发起人与主要干系人确认，形成新的基线。
- 同步通知范围分解与计划排期的责任人，使工作分解与验收安排跟随新基线调整。
范围说明书与范围分解、变更管理之间有明确的分工边界：说明书界定“做什么、交付什么、凭什么验收”，范围分解把已确认的范围拆成可执行的工作包，变更管理负责变更申请的提出、评审与批准。说明书本身不展开工作包拆解方法，也不设计审批流程，只记录变更入口指向哪里，以及在变更批准后如何更新自身。
当项目在协作平台中管理时，说明书的版本维护可以与文档和工作项联动。ONES Wiki 支持使用页面模板库一键创建制式化文档，并记录所有页面版本、支持随时查看与回滚，适合承载范围说明书这类需要保留基线和修订痕迹的文档；页面组可关联项目，使范围文档与需求、任务互相对应。在采用瀑布管理方式的场景中，ONES 瀑布项目管理方案支持设置项目计划和里程碑基线、对比计划与执行的偏差，并通过版本对比追溯变更细节，可用于范围基线批准后的偏差跟踪。具体可用能力以实际开通的版本与配置为准。
常见问题
项目范围说明书和范围分解（WBS）是什么关系，先做哪一个？
先有范围说明书，再做范围分解。说明书界定“做什么、交付什么、凭什么验收”，是范围分解的输入；范围分解把已确认的范围拆成可执行、可分配的工作包。实际操作中，说明书的可交付成果清单用编号（如 D1、D2）列出，范围分解时逐项展开，两者能一一对应，后续验收和变更追溯也更清楚。工作包拆解的具体方法不在本文展开，可参考范围分解相关主题。
项目已经启动，但范围说明书还没签字，可以边做边补吗？
可以补，但要限定范围和时限。建议在基线批准前，对暂缺的必填字段写“待确认”，注明责任人与确认时限，并在第一个交付阶段结束前完成签字。补写期间如果出现新增需求，先记录到变更入口，不直接进入执行，避免范围在无基线状态下持续扩大。签字确认的记录至少包含发起人与项目经理。
除外责任写多少条合适，写少了会有什么问题？
条数没有统一标准，判断依据是项目边界上哪些相邻工作最容易被误认为在范围内。常见做法是逐条写“不包含……”，针对历史数据迁移、第三方系统改造、相邻团队职责这类高频争议点。内部小项目至少写一条最易混淆的排除项；跨部门或合同约束强的项目应把边界相关事项写全。除外责任写得具体，验收会上对“这算不算项目范围”的分歧会明显减少。
范围变更批准后，说明书要改哪些地方，版本号怎么定？
先确认变更申请已获批准并记录批准人与日期，再修改受影响的字段，通常涉及可交付成果清单、验收标准、除外责任或制约因素。版本号方面，首次基线为 V1.0，此后经批准的修改递增次版本号（V1.1、V1.2），范围发生结构性调整时递增主版本号（V2.0）。修订记录写明版本号、日期、修订人、修订内容和批准人，并与正文版本号保持一致。更新后重新提交发起人与主要干系人确认，形成新基线。
用协作平台管理范围说明书，版本和评审记录怎么留痕？
可以把说明书放在支持页面模板与版本管理的文档工具中。ONES Wiki 支持使用页面模板库一键创建制式化文档，并记录所有页面版本、支持随时查看与回滚，适合承载需要保留基线和修订痕迹的范围说明书；页面组可关联项目，使范围文档与需求、任务互相对应。采用瀑布管理方式时，ONES 瀑布项目管理方案支持设置项目计划和里程碑基线、对比计划与执行的偏差，并通过版本对比追溯变更细节。具体可用能力以实际开通的版本与配置为准。
