范围边界约定要回答四个问题：做什么、不做什么、谁确认、怎么算完成。本文用一份虚构的“客户门户改版”项目，演示如何把答案填进一份可复用的范围说明书，并逐项解释字段填法，帮助读者对照自己的项目完成初稿与评审定稿。
要点总览（TL;DR）
- 范围边界约定用“范围内、范围外、待定、验收口径”四类字段回答做什么、不做什么、谁确认、怎么算完成，示例以虚构的客户门户改版项目演示填写过程。
- 范围内条目写到交付物粒度，范围外条目同时写排除理由与替代归属，待定项标注确认人和确认时点，验收口径与范围条目一一对应。
- 待定项与范围外条目的区别在于事项是否已决：已排除的写替代归属，未决的限期给出结论，逾期按本期不做处理并移入范围外。
- 迁移到自己的项目时按交付物—活动—排除项三层组织条目，内部系统、对外交付、运维支持三类项目的字段取舍各有侧重。
- 示例为虚构情景，合同型交付的边界措辞需与合同文本一致；范围边界约定是任务拆解与变更审批的输入，不能替代它们。
示例目标：这份范围边界约定要解决什么问题
本文的演示情景设定为：某公司计划对现有客户门户进行一次改版，涉及前端页面重构、部分后台接口调整和上线支持。该情景为虚构示例，仅用于说明填写方法，不代表任何真实客户或项目。示例要产出的结果，是一份可以直接进入评审的范围说明书初稿，评审通过后作为后续任务拆解和验收引用的依据。
这份文档需要回答四类问题。第一，做什么：本次改版包含哪些交付物、活动和覆盖范围。第二，不做什么：哪些功能、系统和配合工作明确排除在外。第三，谁确认：每条待定内容由谁在什么时点给出结论。第四，怎么算完成：每条范围条目对应什么验收口径，验收时不看什么。
判断定稿的标准可以归纳为三条，逐条核对即可：
- 每条范围内条目都能被至少一条验收口径引用，不存在“写了但无法验收”的条目。
- 每条范围外条目都写明了排除理由和替代归属，读者能判断该事项由谁承接。
- 每条待定项都有确认人和确认时点，评审结束时没有“无人负责的空白项”。
达到这三条，文档就可以作为范围基线使用；未达到时，先补齐再评审，避免会上反复讨论同一处空白。
完整示例：客户门户改版项目的范围边界约定
项目背景与目标一句话描述：在两个月内完成客户门户的页面改版与核心接口适配，使现有注册客户能在新界面上完成登录、订单查询和资料修改三类操作。以下为填写完成的示例内容。
范围内条目
| 编号 | 类型 | 条目内容 | 责任方 |
|---|---|---|---|
| IN-01 | 交付物 | 新版门户首页、登录页、订单查询页、资料修改页共四个页面的设计与前端实现 | 前端组 |
| IN-02 | 交付物 | 订单查询与资料修改所依赖的两个后台接口的适配改造 | 后端组 |
| IN-03 | 活动 | 面向现有注册客户的灰度发布与上线后一周内的缺陷修复 | 前端组、测试组 |
| IN-04 | 覆盖范围 | 桌面端浏览器；用户角色为已注册的普通客户 | 产品负责人 |
范围外条目
| 编号 | 排除内容 | 排除理由 | 替代归属 |
|---|---|---|---|
| OUT-01 | 移动端页面适配 | 本期资源集中在桌面端，移动端另行立项 | 由移动端改版项目承接，时间待定 |
| OUT-02 | 新客户注册流程改造 | 注册流程涉及风控系统，不在本次改版目标内 | 由风控系统改造项目承接 |
| OUT-03 | 历史订单数据清洗 | 数据问题由数据团队统一处理 | 由数据治理季度计划承接 |
| OUT-04 | 上线后的长期运维值守 | 本期只覆盖上线后一周的缺陷修复 | 移交运维组按既有值班制度执行 |
待定项清单
| 编号 | 待定内容 | 影响 | 确认人 | 确认时点 |
|---|---|---|---|---|
| TBD-01 | 订单查询页是否需要支持按时间区间筛选 | 影响接口参数设计与前端交互 | 产品负责人 | 需求评审会当天 |
| TBD-02 | 灰度发布的比例与观察周期 | 影响上线排期与测试投入 | 技术负责人 | 上线前一周的发布评审 |
验收口径
| 对应条目 | 完成定义 | 不纳入验收的内容 |
|---|---|---|
| IN-01 | 四个页面按设计稿实现，通过测试组的功能用例 | 视觉细节的像素级比对不作为验收条件 |
| IN-02 | 两个接口在测试环境返回结果与旧接口一致，异常场景有明确返回 | 接口性能压测不在本期验收范围 |
| IN-03 | 灰度客户可正常完成三类操作，一周内无阻断级缺陷 | 非阻断级体验优化不阻塞验收 |
| IN-04 | 桌面端主流浏览器各完成一轮回归 | 移动端浏览器不在本轮回归范围 |
责任方与交接边界
产品负责人对范围条目和待定项的最终结论负责；前端组与后端组分别对各自交付物负责；测试组对验收用例的执行结果负责。上线一周后，缺陷修复工作连同已知问题清单移交运维组，移交以清单签收为完成标志。跨组交接只认清单，口头确认不计入交接完成。
逐项解释：每个字段为什么这样填
范围内条目写到交付物粒度，是因为“完成门户改版”这类表述无法被验收引用。示例中 IN-01 明确到四个页面，测试组可以直接据此设计用例，评审时也能判断工作量是否被低估。写成口号式条目，常见后果是执行阶段对“改到什么程度算完”反复争论。
范围外条目要同时写排除理由和替代归属。只写“移动端不做”，读者无法判断这是本期不做还是永远不做；补上“由移动端改版项目承接”，边界就从一句否定变成了责任交接。示例中 OUT-01 至 OUT-04 都遵循这一结构，评审时可以逐条确认替代方是否知情。
待定项与范围外条目的区别在于事项是否已决。范围外是已经决定排除，待定项是尚未决定、但必须在某个时点给出结论。示例中 TBD-01 若最终决定不做筛选，应移入范围外并补替代归属；若决定做，则移入范围内并补验收口径。待定项长期滞留，说明确认机制没有生效。
验收口径与范围条目保持一一对应，是这份文档能被引用的关键。示例中每条 IN 条目都有对应行，且写明“不纳入验收的内容”，避免验收阶段被追加未约定的期望。对应关系缺失时，验收往往退化为凭印象判断。
责任方字段的作用是让每个条目有唯一对接人。示例按交付物归属到组，按结论归属到角色，避免出现“大家一起负责”的条目。跨团队扯皮多发生在责任方写成部门名称却没有具体角色的条目上，填写时把决策角色和交付角色分开写，争议会明显减少。
可迁移规律：换一个项目怎么套用
条目组织可以沿用三层结构：先列交付物，再列围绕交付物的活动，最后列排除项。交付物回答“做出什么”，活动回答“为此做什么”，排除项回答“不碰什么”。三层顺序稳定后，不同项目的文档结构可以保持一致，评审时也便于对照。
待定项需要控制数量并设置升级机制。建议初稿阶段待定项不超过五条，每条都指定确认人和时点；评审时仍未闭环的条目，升级到项目负责人处限期给出结论，逾期未决的按“本期不做”处理并移入范围外。这样待定项不会无限累积，范围基线也能按时冻结。
不同项目类型的字段取舍有所差异：
- 内部系统项目：范围外条目可以简写，重点放在交付物粒度和验收口径，因为内部需求方通常在场，沟通成本低。
- 对外交付项目：范围外条目和替代归属要写得更细，验收口径尽量引用可测量的完成定义，减少交付争议。
- 运维支持类工作：范围内以服务内容和响应边界为主，验收口径侧重可用性与响应时限，交付物条目相应减少。
评审会的做法可以直接沿用：逐条过范围内和范围外条目，每读到一条待定项当场指定确认人和时点，会议结束前复核三条定稿标准。评审记录与文档版本一并留存，后续变更以版本对比的方式追溯。
范围说明书定稿后，条目状态和评审结论需要有承载的地方。ONES 支持在项目下管理需求范围与研发任务，并可用「项目计划」按交付物或阶段创建工作分解结构；将范围条目转为工作项、把评审结论记录在文档中，可以让“已定稿”和“执行中”的状态保持对应。采用瀑布方式管理的团队，还可以通过基线对比查看计划与执行的偏差，追溯变更细节。具体功能范围以实际部署与套餐为准。
适用边界：示例不能直接照搬的地方
本文情景为虚构示例，其中的项目背景、条目内容和确认安排均为演示填写方法而设，不代表任何真实客户或项目，也不构成对成效的承诺。读者应替换为自己项目的实际交付物与角色。
合同型交付与内部项目的边界写法差异明显。合同型交付中，范围外条目往往对应合同条款和计价，措辞需要与合同文本一致，替代归属要写明商务处理方式；内部项目的范围外条目更多是协调安排，措辞可以更简洁。直接照搬示例中“另行立项”这类表述到合同场景，可能引发解释分歧。
范围边界约定与任务拆解、变更审批分工不同。本文只处理“边界写什么、谁来确认”，交付范围的详细分解结构、执行阶段的任务拆解与人员组织、变更审批流程与变更单设计，都需要另行处理。范围说明书是这些工作的输入，不能替代它们。
边界约定需要随变更同步更新。当待定项得出结论、范围外事项被重新纳入、或验收口径调整时，应更新文档版本并重新走一次评审确认；只改任务不改文档，会让范围基线逐渐失效，验收时又回到口头约定。建议把“范围文档更新”作为变更处理的固定动作之一。
常见问题
待定项在评审会上仍然没有结论，应该怎么处理？
评审会上逐条过待定项，当场指定确认人和确认时点。到约定时点仍未闭环的条目，升级到项目负责人处限期给出结论；逾期未决的，按“本期不做”处理并移入范围外，同时补上替代归属。这样处理可以避免待定项长期滞留，让范围基线按时冻结。
范围外条目只写“本期不做”可以吗？
建议补上排除理由和替代归属。只写“本期不做”，读者无法判断这是本期不做还是永远不做，也无法知道该事项由谁承接。写成“移动端适配由移动端改版项目承接，时间待定”，边界就从一句否定变成了责任交接，评审时可以逐条确认替代方是否知情。
合同型交付项目套用这份示例时，哪些地方需要调整？
合同型交付中，范围外条目往往对应合同条款和计价，措辞需要与合同文本一致，替代归属要写明商务处理方式。示例中“另行立项”这类内部协调式表述，直接搬到合同场景可能引发解释分歧。验收口径也建议尽量引用合同中可测量的完成定义。
范围说明书定稿后，条目状态和评审结论放在哪里管理？
定稿后需要让“已定稿”和“执行中”的状态保持对应。ONES 支持在项目下管理需求范围与研发任务，并可用「项目计划」按交付物或阶段创建工作分解结构；将范围条目转为工作项、把评审结论记录在文档中，便于后续对照。采用瀑布方式管理的团队还可以通过基线对比查看计划与执行的偏差，追溯变更细节。具体功能范围以实际部署与套餐为准。
范围边界约定和任务拆解、变更审批是什么关系？
范围边界约定处理“边界写什么、谁来确认”，是后续工作的输入。交付范围的详细分解结构、执行阶段的任务拆解与人员组织、变更审批流程与变更单设计，都需要另行处理。当待定项得出结论、范围外事项被重新纳入或验收口径调整时，应更新文档版本并重新评审确认，把“范围文档更新”作为变更处理的固定动作之一。
