项目范围示例的价值在于让读者看到一份填好的范围说明书和WBS长什么样，再对照自己的项目改写。本文用虚构的“企业官网改版”情景，给出两份可直接套用结构的范例：一份项目范围说明书，一份对应的WBS分解表，并逐项解释字段填写理由与常见错误。范围文档与工作项在ONES中可由项目计划与知识库承载，便于后续确认范围基线并引用。
要点总览（TL;DR）
- 本文用虚构的“企业官网改版”情景，给出两份可直接套用结构的范例：一份项目范围说明书，一份与之一一对应的WBS分解表。
- 范围说明书覆盖目标、成功标准、交付物、范围包含与除外、验收条件、假设约束和审批角色；WBS按三级编码拆到工作包，每个工作包指定负责人和验收标准。
- 填写要点：目标写成可验证结果，除外事项单列且具体，工作包粒度以“一个负责人能独立交付可验收成果”为准，验收标准采用“交付物加验收方式”的写法。
- 换项目时按“写目标—反推交付物—定边界—写验收条件—建WBS—双向核对—确认基线”的顺序迁移，示例中的周期、角色和清单需按实际项目调整。
- 本文聚焦交付范围的界定与分解；执行任务拆解与人员组织、范围变更审批分别归相邻主题，不在本文展开。
示例要演示到什么程度
本示例的目标是展示一份完整、自洽、可直接对照填写的项目范围说明书与WBS分解表。读者看完后应能回答三个问题：范围说明书包含哪些字段、每个字段填成什么样算合格、这些字段如何落到WBS的工作包上。
情景设定为一家中型企业委托开发团队改版官方网站，项目周期约十周，预算与人员规模不在示例中展开。该情景为虚构示例，用于演示填写方法，不代表任何真实客户案例，也不附带实测数据或量化成效。
读者可获得的产出有两份：一是范围说明书范例，覆盖目标、交付物、边界、验收条件、假设约束与审批角色；二是与之一一对应的WBS分解表，覆盖层级编码、工作包名称、负责人与验收标准。两份范例配合S4的填写理由和S5的迁移步骤使用，效果最好。
完整示例：企业官网改版的范围说明书
下表是一份已填写的范围说明书范例。字段顺序按常见范围管理做法排列，读者可整体照搬结构，替换为自己的项目内容。
| 字段 | 填写内容（示例） |
|---|---|
| 项目名称 | 企业官网改版项目 |
| 项目目标 | 在十周内上线新版官网，实现三项可验证结果：首页与五个核心栏目页在主流浏览器与移动端正常访问；产品信息页支持后台自助更新；上线后旧站内容全部迁移且无死链。 |
| 成功标准 | 验收测试用例全部通过；内容迁移核对表完成率100%；上线后一周内无P1级故障。 |
| 交付物清单 | 1）信息架构与页面清单文档；2）视觉设计稿（首页加五个栏目页）；3）前端页面与后台内容管理模块；4）内容迁移核对表及迁移后的站点内容；5）上线部署说明与运维交接文档。 |
| 范围包含 | 官网信息架构梳理、页面设计与前端实现、内容管理后台的基础发布与编辑功能、旧站内容迁移、上线部署与交接。 |
| 范围除外 | 多语言站点、在线支付与会员系统、与第三方CRM的对接、旧站历史数据的归档策略设计、上线后的持续运营代管。 |
| 验收条件 | 每个交付物对应明确的验收方式：设计稿以评审签字为准；前端页面以验收测试用例通过为准；内容迁移以核对表逐项确认为准；部署交接以运维方书面接收为准。 |
| 假设与约束 | 假设：客户在每轮评审后三个工作日内反馈；旧站内容源文件可完整获取。约束：上线时间不得晚于合同约定日期；设计风格需符合客户品牌规范。 |
| 干系人与审批 | 客户方市场负责人（需求确认与验收）、开发方项目经理（范围与进度负责）、设计负责人（设计稿评审）、运维负责人（部署交接确认）。范围基线由客户方市场负责人与开发方项目经理共同确认。 |
这份说明书的重点在于“除外”一栏写得具体。多语言、支付、会员、CRM对接都是官网项目里容易被临时追加的内容，提前写进除外事项，后续讨论就有依据。验收条件与交付物逐条对应，避免出现“交付了但说不清是否合格”的情况。
完整示例：对应的WBS分解与工作包
WBS采用三级编码：第一级为项目，第二级为阶段或主要交付物，第三级为工作包。编码规则为“1.2.3”形式，层级数字对应分解深度，工作包是分配负责人和验收的最小单元。
| 编码 | 层级名称 | 对应交付物 | 负责人 | 验收标准 |
|---|---|---|---|---|
| 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 | 内容迁移 | 迁移后的站点内容与核对表 | 内容负责人 | 核对表完成率100%，无死链 |
| 1.4.1 | 旧站内容迁移执行 | 迁移内容 | 内容负责人 | 逐项核对确认 |
| 1.4.2 | 死链检查与修复 | 死链检查报告 | 内容负责人 | 检查报告显示无遗留死链 |
| 1.5 | 上线部署与交接 | 部署说明、运维交接文档 | 运维负责人 | 运维方书面接收 |
| 1.5.1 | 上线部署 | 已上线站点 | 运维负责人 | 上线检查清单全部完成 |
| 1.5.2 | 运维交接 | 交接文档与培训记录 | 运维负责人 | 运维方确认接收并完成培训 |
对应关系上，1.1对应范围说明书中的“信息架构与页面清单文档”，1.2对应“视觉设计稿”，1.3对应“前端页面与后台内容管理模块”，1.4对应“内容迁移核对表及迁移后的站点内容”，1.5对应“上线部署说明与运维交接文档”。范围说明书里的每一项交付物都能在WBS中找到落点，WBS中也不出现范围说明书之外的交付内容，两边互为校验。
逐项解释：每个字段为什么这样填
目标写成可验证结果，是为了让“做完了没有”有客观判断依据。示例中“主流浏览器与移动端正常访问”“支持后台自助更新”“无死链”都是可以检查的状态，比“提升品牌形象”这类描述更容易在验收时使用。目标一旦可验证，成功标准也就顺理成章地写成测试通过率、核对表完成率这类指标。
除外事项单列的作用是提前处理边界争议。官网项目常见的追加需求集中在多语言、支付、会员和外部系统对接，把这些写进除外栏，等于在项目开始时就把“这次不做”讲清楚，减少执行中反复确认的成本。
工作包粒度以“能分配给一个负责人、能用一句话说清验收标准”为宜。示例中1.4.1“旧站内容迁移执行”是一个工作包，如果再拆成按栏目逐个迁移，管理成本会超过收益；反过来，把1.3整个开发阶段当成一个工作包，又无法跟踪进度。粒度是否合适，可以用“负责人能否独立完成并交付可验收成果”来判断。
验收标准与交付物一一对应，写法上采用“交付物加验收方式”的结构，例如“设计稿以评审签字为准”。这样验收时不需要重新讨论标准，直接对照执行。
| 常见错误写法 | 问题 | 改进写法 |
|---|---|---|
| 目标：打造一流的官网体验 | 无法验证，验收时各说各话 | 目标：十周内上线，首页与五个栏目页在主流浏览器与移动端正常访问 |
| 范围除外：其他未提及事项 | 过于笼统，起不到边界作用 | 范围除外：多语言站点、在线支付、会员系统、CRM对接 |
| 工作包：完成开发 | 粒度过粗，无法分配与跟踪 | 工作包：前端页面实现、内容管理后台基础功能 |
| 验收标准：符合要求 | 没有可执行的判断依据 | 验收标准：验收测试用例全部通过 |
可迁移规律：换一个项目怎么套用
换项目时不必从零起草，按以下顺序操作即可把示例结构迁移过去。
- 先写目标，把目标改写成可验证的结果状态，明确时间、范围和判断方式。
- 从目标反推交付物，逐条问“要达成这个结果，必须交出哪些成果物”，形成交付物清单。
- 确定边界，把交付物之外但容易被误认为包含的内容写进除外事项，越具体越好。
- 为每项交付物写验收条件，采用“交付物加验收方式”的结构，确保验收时可执行。
- 按阶段或主要交付物建立WBS第二层，再向下拆到工作包，每个工作包指定负责人和验收标准。
- 核对范围说明书与WBS的对应关系，确保双向覆盖、无多余节点。
- 由关键干系人共同确认范围基线，后续讨论以基线为参照。
边界与除外事项的确定方法是：列出项目讨论中出现过的所有候选需求，逐条判断是否服务于当前目标，不服务的放入除外栏并注明原因。WBS分解遵循逐层细化原则，同一层级用同一维度划分，例如第二层统一按阶段划分，避免混用阶段和职能两种维度。范围基线确认后，后续的进度对比和变更讨论都以这份基线为起点。
在ONES中，这类范围文档可以放在知识库中作为项目资料留存，WBS则可用项目计划按交付物或阶段维度分解，并为任务设置前后置依赖与里程碑；范围基线确认后，可通过计划和里程碑基线对比执行偏差，追溯变更细节。这样范围说明书与WBS在同一项目下保持引用关系，交接和评审时有据可查。
适用边界：示例覆盖与不覆盖的内容
本示例适用于交付范围的界定与分解，即回答“这次交付什么、不交付什么、怎么拆成可管理的工作包”。范围说明书与WBS的结构、字段写法和对应关系是本文的核心内容。
执行层面的任务拆解与人员组织不在本文展开，那属于任务拆解与组织主题；范围批准之后的调整审批流程归项目变更管理主题，本文只说明基线确认，不涉及变更审批的具体流程。工具功能对比与选型推荐同样不在本文范围。
示例情景与真实项目存在差异：真实项目的干系人更多、约束更复杂，交付物数量和验收方式需要按实际情况调整；示例中的周期、角色和交付物清单仅用于演示填写方法，读者套用时应以自己项目的合同、规范和团队结构为准。
常见问题
范围说明书里的“除外事项”要写多细才算够用？
判断标准是：执行中一旦有人提出某项需求，团队能否直接对照除外栏给出明确答复。示例中把多语言站点、在线支付、会员系统、CRM对接逐项列出，就是为了让这些常见追加需求在项目开始时就有结论。如果只写“其他未提及事项”，除外栏起不到边界作用，讨论仍会回到原点。
写法上建议列出项目讨论中出现过、但本次不做的候选需求，并简要注明原因。除外事项与范围包含栏配合使用，两者合起来才构成完整的边界描述。
工作包拆到多细比较合适，拆得太细会有什么问题？
合适的粒度是“能分配给一个负责人，并能用一句话说清验收标准”。示例中“旧站内容迁移执行”作为一个工作包即可，再按栏目逐个拆分，管理成本会超过跟踪收益；反过来把整个开发阶段当成一个工作包，又无法判断进度。
拆得过细的典型表现是工作包数量膨胀、每个包只有几小时工作量，负责人频繁切换、汇报成本上升。可以用“负责人能否独立完成并交付可验收成果”作为判断依据，同时保持同一层级使用同一划分维度。
范围说明书和WBS都写好了，接下来怎么确认范围基线？
基线确认的前提是两份文档已经双向核对：范围说明书中的每项交付物都能在WBS中找到落点，WBS中也不出现范围说明书之外的交付内容。核对完成后，由关键干系人共同确认，示例中由客户方市场负责人与开发方项目经理共同确认。
基线确认后，后续的进度对比、变更讨论都以这份基线为参照。在ONES中，可通过项目计划和里程碑基线对比执行偏差，并追溯变更细节；变更审批的具体流程属于项目变更管理主题，本文不展开。
示例中的周期、角色和交付物清单能直接用到自己项目里吗？
不能直接照搬。示例设定为十周周期、中型企业官网改版，角色划分和交付物清单都服务于演示填写方法。真实项目的干系人更多、约束条件更复杂，交付物数量和验收方式需要按合同、行业规范和团队结构重新确定。
可以迁移的是结构和写法：字段顺序、目标的可验证写法、除外事项的单列方式、工作包与验收标准的对应关系。内容层面应以自己项目的实际情况为准，示例中的数字和角色仅作对照参考。
如果项目执行中确实出现了范围外的需求，应该怎么处理？
先对照范围说明书的除外栏和范围包含栏，判断该需求是否落在已确认的边界内。落在边界外的需求，需要走变更评估，判断对进度、资源和验收条件的影响，再决定是否纳入。这一审批流程属于项目变更管理主题，本文只说明基线确认与边界描述的作用。
提前把除外事项写具体，能减少这类讨论的频率；边界描述越清晰，变更评估时的判断依据越充分。
