项目范围说明书示例：一份可套用的完整范例

项目范围说明书要写清楚项目做什么、交付什么、按什么标准验收，以及哪些内容不在本次范围内。本文以虚构的“企业官网改版”项目为演示情景，给出一份字段齐全、可直接参照填写的范围说明书范例，逐项说明每个字段的写法依据，并总结换项目时如何替换内容、保留骨架。

要点总览（TL;DR）

• 项目范围说明书示例应覆盖六类字段：项目目标与成功标准、可交付成果、验收标准、范围边界与排除项、假设与制约、高层级需求。
• 本文以虚构的“企业官网改版”项目给出完整填写范例，每项成果配一条验收标准，排除项逐条列到功能名称。
• 换项目时保留字段骨架，按“一句话目标→可交付成果→验收标准”的顺序替换内容，成果与标准成对增删。
• 范围说明书只界定做什么与按什么标准验收；交付分解归WBS，任务排期归项目计划，变更审批归变更管理。
• 示例用于演示填写方法，实际使用以组织模板、评审与审批要求为准。

示例目标：这份范围说明书要解决什么问题

本文的示例情景设定为一家虚构的中型企业启动官网改版：现有官网信息架构陈旧，移动端体验差，市场部希望在上线后统一对外形象并支持内容自主维护。项目由内部项目组推进，设计、前端开发与内容运营分别由不同角色承担。该情景仅用于演示填写方法，不对应任何真实客户或真实项目。

这份示例要示范六类核心字段的完整写法：项目目标与成功标准、可交付成果清单、验收标准、范围边界与排除项、假设条件与制约因素、高层级需求。每个字段都给出可直接对照的填写内容，让读者看到一份“填完之后长什么样”的文档，而不只是字段名称清单。

读者可据此套用的场景包括：网站或系统改版类项目、内部信息化建设、市场活动落地、部门级交付项目等边界相对清晰、交付物可列举的项目。若项目涉及多阶段滚动交付或需求高度不确定，字段骨架仍可沿用，但目标与可交付成果需要按阶段拆分表述。

完整示例：企业官网改版项目范围说明书全文

以下为虚构项目的范围说明书填写范例，各字段前后对应，可直接作为格式参照。

一、项目目标与成功标准

项目目标：在 12 周内完成企业官网改版并上线，覆盖首页、产品中心、解决方案、关于我们、新闻动态五个一级栏目，实现移动端自适应，并将内容更新操作交由市场部人员自主完成。

成功标准：五个一级栏目全部上线且无阻断性缺陷；主流移动设备访问页面布局正常；市场部人员经一次培训后可独立发布一篇新闻稿；上线后一个月内无因范围遗漏导致的返工。

二、可交付成果清单

• 网站信息架构与栏目规划文档一份
• 五个一级栏目及下属页面的高保真视觉稿一套
• 前端页面开发与后台内容管理配置
• 内容迁移后的栏目内容与图片素材
• 市场部内容编辑操作手册一份及培训一次
• 上线部署与上线检查记录

三、验收标准

可交付成果	验收标准	验收方式
信息架构与栏目规划文档	五个一级栏目及二级页面层级完整，经市场部与项目组确认	文档评审签字
高保真视觉稿	覆盖全部一级栏目首页及典型内页，移动端与桌面端各一套	设计评审会通过
前端页面与后台配置	页面可正常访问，主流移动设备布局正常，无阻断性缺陷	测试清单逐项核对
内容迁移	原官网有效内容全部迁移，无失效链接	抽查页面与链接检查
操作手册与培训	手册覆盖发布、修改、下架操作；培训后市场部人员独立完成一次发布	现场操作验证

四、范围边界与排除项

范围内：五个一级栏目的规划、设计、开发、内容迁移、上线部署与内容编辑培训。

明确排除：多语言版本建设；会员注册与登录功能；在线支付与订单模块；第三方营销自动化工具对接；服务器与域名采购；上线后的日常内容运营。

五、假设条件与制约因素

假设条件：市场部能在设计启动前提供各栏目内容清单；现有品牌视觉规范可继续沿用；原官网内容可直接复用，无需重新撰写；内部评审人员能按约定时间反馈意见。

制约因素：上线时间受年度品牌发布节点约束，不可顺延；开发人力为两名前端工程师部分投入；预算仅覆盖设计与开发，不含外部内容撰写；服务器环境由公司 IT 部门统一提供，交付时间受其排期影响。

六、高层级需求

• 网站需支持桌面端与移动端自适应浏览
• 内容管理系统需支持非技术人员发布、修改、下架文章
• 页面加载需满足公司内部性能基线要求
• 需保留原官网有效内容的可访问路径或跳转
• 需提供栏目结构与页面清单，供后续运营参照

逐项解释：每个字段为什么这样写

目标与验收标准要形成对应关系。示例中“市场部人员可独立发布新闻稿”这一目标，在验收标准里落成了“培训后独立完成一次发布”的可核验动作。目标写得再具体，如果没有对应的验收动作，执行阶段就容易各说各话；反过来，验收标准若脱离目标，就会变成一堆与项目意图无关的检查项。

可交付成果的颗粒度控制在“可评审、可交接”的层级。示例把“视觉稿”写成“五个一级栏目及典型内页的一套”，既说明覆盖范围，又没有细到每个按钮的样式。颗粒度过粗会让验收无从下手，过细则把设计细节提前锁死，压缩执行阶段的合理调整空间。判断标准是：一项成果能否被单独评审、单独交接。

排除项的作用是防止范围蔓延。示例把多语言、会员、支付、营销工具对接逐条列出，原因是这些内容在官网改版讨论中经常被顺带提出。写排除项时宜具体到功能名称，避免只写“其他未提及内容不在范围内”这类笼统表述，后者在争议发生时缺乏约束力。

假设与制约的区别在于可控性。假设是“我们认为成立、但需要被验证”的前提，例如内容清单能按时提供；制约是“已经存在、项目无法改变”的限制，例如上线时间受品牌节点约束、人力只有部分投入。两者写混，会让风险识别失去焦点：假设失效需要触发确认和应对，制约则需要在计划中直接接受并留出缓冲。

可迁移规律：换一个项目怎么改

字段骨架保持不变，内容按项目替换。六类字段构成范围说明书的稳定结构，换项目时保留章节顺序，逐项替换具体表述即可。改写时先确定一句话目标，再从目标反推可交付成果，最后为每项成果配一条验收标准，这个顺序能减少字段之间的脱节。

可交付成果与验收标准采用配对写法。每列出一项成果，就在验收表中为它写一行，说明“达到什么状态算完成、由谁以什么方式确认”。示例中的六项成果与五行验收条目基本一一对应，读者替换内容时可按同样方式成对增删，避免出现有成果无标准、或有标准无对应成果的情况。

排除项与假设按“讨论中出现过的高频诉求”和“项目依赖的外部前提”两类替换。前者从过往同类项目的争议点中收集，后者从资源、时间、环境依赖中梳理。改写步骤可归纳为：

1. 用一句话写出项目目标，并列出两到三条可观察的成功标准
2. 按交付顺序列出可交付成果，每项控制在可单独评审的颗粒度
3. 为每项成果补一行验收标准与验收方式
4. 列出范围内事项，再逐条写出明确排除的功能或工作
5. 区分假设与制约，分别标注需要验证的前提和无法改变的限制
6. 补充高层级需求，确保与目标和成果不冲突

适用边界：哪些内容不写进范围说明书

范围说明书界定“做什么、交付什么、按什么标准验收”，交付范围分解归 WBS 与范围分解环节。示例中的“前端页面开发”是一项可交付成果，把它拆成页面清单、组件任务和工时估算，属于工作分解结构的工作，写进范围说明书会让文档过早进入执行细节。

执行阶段的任务拆解与人员分工同样不放在这里。谁在什么时间完成哪个任务、任务之间如何排期，属于项目计划与任务管理的内容。范围说明书只需说明成果与标准，任务层面的安排可在计划编制时展开。

范围变更的审批流程归变更管理。示例中的排除项为变更判断提供了依据，但变更如何提出、由谁审批、如何记录，属于变更控制流程的范畴，不在本文展开。

文档或流程	主要回答的问题	与范围说明书的关系
项目范围说明书	做什么、交付什么、按什么标准验收、哪些不做	本文示例的对象
WBS 与范围分解	交付成果如何逐层拆成工作包	以范围说明书为依据展开
项目计划与任务拆解	谁在何时完成哪些任务、如何排期	在执行层面承接分解结果
范围变更管理	范围调整如何提出、审批与记录	以范围边界为判断基准

示例本身也有局限。它演示的是字段写法与内容组织方式，不替代组织已有的文档模板、审批要求和合规规定。实际使用时，应以所在组织的模板为准，将本文示例作为填写参照；涉及评审签字、版本留存等要求，按组织流程执行。

范围说明书定稿后通常需要经过评审并留存版本。在 ONES 中，项目文档与实践经验可通过 ONES Wiki 沉淀，标准流程、评审节点和交付物模板也可沉淀为可复用资产，便于后续项目直接参照；范围说明书的评审与定稿状态可随文档一并管理，使后续的范围分解和变更判断有据可查。具体模板配置与评审流转方式以实际产品版本和组织配置为准。

常见问题

项目范围说明书和WBS应该先做哪个？

先定范围说明书，再做WBS。范围说明书明确项目目标、可交付成果和验收标准，WBS以此为依据把成果逐层拆成工作包。顺序反过来容易出现拆解完成后才发现某些成果未被确认、或验收标准缺失的情况。若项目已进入执行阶段才补范围说明书，可先用现有WBS反推成果清单，再补齐目标、验收标准与排除项。

排除项写多少条才够用？

排除项的数量取决于项目讨论中出现过多少容易被顺带提出的诉求，没有固定条数。判断标准是：某功能或工作一旦被提出，是否会引起范围争议。官网改版类项目通常把多语言、会员、支付、第三方工具对接逐条列出。写的时候具体到功能名称，避免用“其他未提及内容不在范围内”这类笼统表述，否则争议发生时缺乏约束力。

假设条件失效了怎么办？

假设是“认为成立但需要验证”的前提，一旦失效应触发确认和应对，而不是直接修改范围。例如示例中“市场部能按时提供内容清单”若未兑现，需要先评估对交付时间的影响，再决定是否调整计划或走变更流程。建议在范围说明书中为关键假设标注验证时点，把假设失效的处理纳入风险跟踪。

需求高度不确定的项目还能用这份示例吗？

可以沿用字段骨架，但目标和可交付成果需要按阶段拆分表述。需求不确定时，把整体目标改写为阶段性目标，每阶段列出该阶段的可交付成果与验收标准，排除项也按阶段更新。这样范围说明书仍能作为阶段验收和变更判断的依据，避免一次性锁定全部细节。

范围说明书定稿后如何留存和评审？

通常需要经过评审并留存版本，具体评审节点、签字要求和版本管理方式按组织流程执行。在 ONES 中，项目文档与实践经验可通过 ONES Wiki 沉淀，标准流程、评审节点和交付物模板也可沉淀为可复用资产，便于后续项目直接参照；范围说明书的评审与定稿状态可随文档一并管理。具体模板配置与评审流转方式以实际产品版本和组织配置为准。