范围边界约定示例：一份可填写的范围说明书

范围边界约定要落到一份能签字、能对照验收的文档上。本文用一个“企业官网改版”的演示情景，给出一份填写完整的范围说明书示例，包含范围内交付物、范围外排除项、验收标准、假设与依赖、变更入口五类字段，并逐项解释填写理由，最后说明换项目时怎么改、哪些情形不能直接照搬。示例为演示用途，不对应真实客户案例。

要点总览（TL;DR）

• 范围边界约定示例的核心是一份范围说明书，把交付物、排除项、验收标准、假设与依赖、变更入口五类信息写在同一份文档里。
• 范围内条目写成可验收的对象并配编号，范围外条目具体到模块或系统，避免用“其他”兜底。
• 验收标准与交付物逐行对应，写明验收方式；假设与依赖单列，与排除项区分开。
• 迁移时按“替换表头—重写交付物—补排除项—配验收标准—列假设依赖—定变更入口”的顺序改，四类核心信息建议保留。
• 示例为演示情景，外包或联合交付需与合同条款对齐，范围频繁变动需配套变更管理流程。

示例目标：这份范围边界约定要解决什么问题

这份示例要回答一个具体问题：当项目组和需求方对“这次到底做什么”有分歧时，拿什么文档来对齐。范围边界约定的作用，是把四类信息写在同一页上——交付什么、不交付什么、按什么标准验收、想改从哪里进。四类信息缺一类，边界就会在执行中被重新解释。

示例设定如下：某企业启动官网改版，由内部项目组承接，需求方为市场部，计划周期为一个季度。项目组需要一份范围说明书，在启动会上与市场部确认，作为后续验收和变更的依据。这个情景是虚构的演示设定，用于展示字段如何填写，不代表任何真实客户的项目。

示例的假设条件包括：需求方为单一部门、交付物以页面和内容为主、不涉及与外部供应商的联合交付。示例不覆盖的内容包括：交付范围如何分解为工作包、任务如何拆解到人、变更申请提交后如何审批流转。这些属于范围分解和变更管理的范畴，本文只在边界处点到为止。

完整示例：官网改版项目的范围边界约定表

下表是填写完成的示例。表头记录文档身份，便于版本追溯；正文按“范围内—范围外—验收标准—假设与依赖—变更入口”的顺序排列。读者可以直接复制这张表的结构，替换项目名称与条目。

字段	填写内容
项目名称	企业官网改版（演示示例）
文档版本	V1.0
编制人	项目经理（示例角色）
确认人	市场部负责人（示例角色）
生效日期	项目启动会确认当日

范围内交付物清单

编号	交付物	说明
D1	首页	新版视觉与信息架构，含首屏、产品入口、新闻区
D2	产品介绍页（5个）	按现有产品线各一页，内容由市场部提供
D3	关于我们页	公司简介、发展历程、联系方式
D4	新闻列表页与详情页	列表支持分页，详情页沿用现有模板结构
D5	内容迁移	迁移现有官网已发布的新闻与产品文案，共约120篇，迁移后逐篇校对
D6	移动端适配	上述页面在手机与平板尺寸下的展示适配

范围外排除项清单

编号	排除项	说明
E1	后台内容管理系统重构	沿用现有后台，仅做必要的字段适配
E2	多语言站点	本期仅中文站，英文站另行立项
E3	在线商城与支付功能	不在本期交付物内
E4	历史内容中已下架文章的恢复	仅迁移当前线上可见内容
E5	品牌视觉规范制定	沿用市场部已确认的视觉规范

验收标准与交付物对应关系

交付物	验收标准	验收方式
D1 首页	设计稿经市场部书面确认；上线后各区块内容完整、链接可跳转	设计评审 + 上线检查
D2 产品介绍页	5个页面全部上线，文案与市场部提供版本一致	逐页对照核对
D3 关于我们页	公司简介、历程、联系方式三部分齐全，联系方式准确	逐项核对
D4 新闻页	列表分页正常，详情页可打开，样式与模板一致	抽样检查
D5 内容迁移	迁移篇数与清单一致，抽查无错字、无图片丢失	清单比对 + 抽样校对
D6 移动端适配	主流手机与平板尺寸下无横向滚动、无遮挡	设备实测

假设与依赖

• 市场部在产品介绍页开发启动前提供5个产品的定稿文案，延迟提供则对应页面顺延。
• 现有后台可支持新版页面所需的字段，如需改造字段，按变更处理。
• 视觉规范在市场部内部已确认，项目组不承担规范评审。
• 内容迁移依赖现有官网后台的导出权限，权限开通时间计入项目周期。

变更申请入口

• 提交方式：需求方以书面形式（邮件或需求单）提交变更申请，写明变更内容、原因和期望时间。
• 审批角色：项目经理评估影响后，由市场部负责人确认，双方确认后更新本文档版本号。
• 生效规则：未走变更入口的口头需求不纳入本期交付，可在下一版本评估。

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

交付物写成可验收的对象，而不是动作。“优化首页体验”无法判断是否完成，“首页上线且各区块链接可跳转”可以。示例中每个交付物都带编号和一句可核对的状态描述，验收时逐条对照即可。交付物颗粒度以“能被单独验收”为准，过粗会导致验收争议，过细会变成任务清单。

排除项要具体到模块或系统，避免用“其他”兜底。示例中的E1到E5分别指向后台、语言版本、商城功能、历史内容和视觉规范，每一项都是需求方可能提出、但本期明确不做的内容。写排除项时可以从两个来源找：启动会上被提到但决定不做的需求，以及同类项目中最容易被追加的功能。用“其他未尽事宜另行协商”收尾，等于把边界留空。

验收标准与交付物一一对应，是这张表能用于验收的关键。示例中D1到D6每条都有对应的标准和验收方式，标准写成可观察的结果，方式写明是评审、核对还是实测。验收标准与交付物分离书写，容易出现“标准很全但不知道对应哪个交付物”的情况，逐行对应可以避免。

假设与依赖单列，避免混入范围外。假设是“我们认为成立的前提”，依赖是“需要别人先完成的事”，两者都会影响交付，但性质不同于排除项。示例中“市场部延迟提供文案则页面顺延”属于假设被打破后的处理约定，写在这里比写在排除项里更准确。

变更入口写清提交方式与审批角色，让边界具备可执行性。示例规定书面提交、项目经理评估、需求方负责人确认、更新版本号四步。入口写清楚，口头需求就有了统一的处理路径；入口缺失，边界文档会在第一次追加需求时失效。

范围边界确认后，需要在协作工具中落地为可追踪的对象。以ONES为例，范围说明书可以作为项目内的文档保存并保留版本记录，D1到D6的交付物对应为工作项，验收标准写在对应工作项中，变更申请以需求单形式提交并关联原文档。这样文档中的边界与执行中的工作项保持同一份来源，验收时按工作项状态逐条核对。

可迁移规律：换一个项目怎么改这份示例

填写顺序建议先列交付物、再列排除项。交付物清单确定后，排除项才有对照对象——每一条排除项通常对应一个被讨论过但决定不做的需求。反过来先写排除项，容易写成泛泛的“不做与本期无关的功能”，失去约束力。

边界条目的判断标准可以统一为一句：这条内容能否被验收，或被明确拒绝。能验收的写进范围内并配验收标准；能被明确拒绝的写进范围外；两者都不属于的，说明还没想清楚，需要回到需求讨论。用这个标准逐条检查，可以筛掉“提升用户体验”“完善功能”这类无法判断的表述。

按项目类型调整字段取舍。以页面和内容交付为主的项目，交付物清单和验收标准是重点；涉及系统集成的项目，依赖项需要写得更细，包括接口提供方和时间点；外包或联合交付的项目，排除项和责任划分需要与合同条款对齐。字段可以增减，四类核心信息（交付、排除、验收、变更）建议保留。

替换步骤可以按以下顺序执行：

1. 替换表头的项目名称、编制人、确认人和生效日期。
2. 按本项目实际交付物重写D清单，每条配编号和可核对的状态描述。
3. 回顾启动会记录，把被提到但决定不做的需求逐条写入E清单。
4. 为每条交付物补一行验收标准和验收方式。
5. 列出假设与依赖，写明前提被打破时的处理约定。
6. 确认变更提交方式与审批角色，与需求方当面确认后定版。

范围边界与任务拆解、变更管理分工不同。范围边界回答“做不做”，任务拆解回答“怎么做、谁来做”，变更管理回答“改了之后怎么批”。本文示例只承担第一项，交付物清单可以直接作为任务拆解的输入，但拆解方法和审批流程需要另外的文档与流程承接。

适用边界：示例不能直接照搬的情形

本文示例为演示情景，不构成客户案例或实测结论。表中的项目名称、角色、篇数、页面数量均为说明字段用法而设定，读者替换时应以自己项目的实际数据为准，不应把示例中的数量当作经验值。

外包、多方联合交付等情形需要补充合同条款与责任划分。示例假设需求方为单一内部部门，当交付涉及外部供应商时，范围说明书中的排除项、验收标准和变更审批需要与合同中的工作说明书、验收条款保持一致，审批角色也要对应到合同约定的责任人。

范围频繁变动的项目需要配套变更管理流程。示例给出了变更入口，但没有展开审批流转、影响评估和版本对比的具体做法。当项目处于需求快速探索阶段时，仅靠一份边界文档不足以控制范围，需要配合变更流程和定期范围复核。

执行层的任务拆解不在本文范围。交付物清单可以向下拆分为任务，但拆分粒度、责任分配和进度安排属于计划管理的内容，本文不提供这部分方法。读者在完成边界约定后，可另行参考范围分解与任务组织的相关做法。

常见问题

范围边界约定和需求文档有什么区别，能不能合并成一份？

两者回答的问题不同。需求文档描述要做什么、做成什么样，范围边界约定回答这次做不做、按什么验收、想改从哪里进。实践中可以把范围边界作为需求文档的前置章节或独立附件，但建议保留独立的版本号和确认记录。合并成一份时，至少要让交付物清单、排除项和验收标准在文档结构上可单独定位，否则后续变更时难以判断改的是需求还是边界。

排除项写多少条合适，写少了会不会留下追加空间？

排除项的数量取决于项目被追加需求的风险点，没有统一标准。判断依据是：启动会或前期沟通中被提到、但决定本期不做的需求，都值得写一条；同类项目中最容易被追加的功能，也值得预先写入。示例中的五条排除项分别对应后台、语言版本、商城、历史内容和视觉规范，覆盖了需求方最可能提出的方向。如果排除项只写一两条笼统表述，追加需求时就缺少拒绝依据。

假设被打破时，示例里写“页面顺延”，实际项目中应该怎么处理？

示例中的“顺延”是一种处理约定的写法，实际项目中需要写得更具体：顺延多少、顺延是否影响整体交付日期、是否需要走变更入口。常见做法是把假设被打破的情形分成两类——影响交付时间的，按变更入口提交并重新确认日期；不影响交付物内容只影响排期的，由项目经理记录并在周报中同步。关键是假设条目旁边就写明打破后的处理方式，避免事后临时协商。

项目已经启动、边界没写清楚，还能补这份范围说明书吗？

可以补，但补的时机和方式需要调整。建议以当前已确认的交付物为基线，先写范围内清单和验收标准，再补排除项和变更入口，然后与需求方开一次短会确认。补写时容易出现的偏差是把已经做完的内容写成计划内交付物，这时应在文档中注明基线确认日期，并把补写前已完成的部分单独标注。补写后的文档同样需要版本号和确认人，否则后续变更仍然缺少对照基准。

范围边界确认后，在协作工具里怎么落地才能和文档保持一致？

常见做法是把范围说明书作为项目文档保存并保留版本记录，交付物清单中的每条对应一个工作项，验收标准写进对应工作项的描述或验收字段，变更申请以需求单形式提交并关联原文档。以ONES为例，文档可放在项目内的知识库中管理版本，工作项在项目里跟踪状态，验收时按工作项逐条核对。这样做的目的是让文档中的边界和执行中的对象来自同一份来源，避免文档改了一版而工作项没同步。