版本功能范围是一个版本承诺交付的功能集合及其边界，回答“这个版本做什么、不做什么、什么条件下调整”。它属于版本规划环节，与发布执行、上线准入和回滚处置分属不同管理阶段。本文聚焦范围的定义、边界与划定方法，不展开发布执行细节。
要点总览（TL;DR）
- 版本功能范围是一个版本承诺交付的功能集合及其边界，回答做什么、不做什么、什么条件下调整三个问题。
- 范围由需求池经筛选、优先级排序、依赖检查和容量核对收敛而成，产出应同时包含纳入项与明确的排除项。
- 范围变更可以发生，关键是设定触发条件、记录变更原因与影响，并由约定角色确认。
- 路线图管方向、需求池管候选、版本功能范围管承诺、发布计划管交付方式、迭代范围管短期执行，层级不同不能互相替代。
- 范围清单描述交付什么，任务清单描述如何分工完成，两者混用会让范围讨论陷入实现细节。
版本功能范围指什么
版本功能范围可以定义为：在某个版本中，团队明确承诺交付的功能条目集合，以及围绕这些条目划定的排除项和调整条件。这个定义包含两层含义。第一层是“集合”，即哪些功能被纳入本版本；第二层是“边界”，即哪些功能被明确排除，以及在什么条件下允许调整。两层合在一起，才构成一个可执行、可沟通的范围。
一个清晰的版本功能范围通常回答三个问题：
- 做什么：本版本要交付哪些功能条目，每个条目对应什么用户可见行为或业务结果。
- 不做什么：哪些候选需求被排除在本版本之外，排除的理由是什么，后续可能归入哪个版本或哪个方向。
- 什么条件下调整：范围变更由什么触发，谁来判断，变更如何记录和同步。
版本功能范围与版本目标、版本计划的关系需要区分清楚。版本目标描述这个版本要达成的业务意图或用户价值，例如“让新用户完成首次配置的路径缩短”。版本功能范围是把目标翻译成具体功能条目的结果，它承接目标，但不等于目标本身。版本计划则在范围基础上进一步安排时间、资源和交付节奏。换句话说，目标定方向，范围定内容，计划定节奏。三者顺序推进，范围处在承上启下的位置。
范围里包括什么，不包括什么
划定版本功能范围时，最容易出现的问题是把相邻环节的内容混进来，导致范围清单变成大杂烩。下面用一张对照表说明属于范围的内容和不属于本文重点的内容。
| 类别 | 内容 | 说明 |
|---|---|---|
| 属于范围 | 功能条目 | 本版本承诺交付的具体功能，通常对应需求条目或用户故事 |
| 属于范围 | 用户可见行为 | 功能交付后用户能感知到的操作、反馈或结果变化 |
| 属于范围 | 必要的配套改动 | 为支撑功能交付而必须同步完成的配置、数据、权限或界面调整 |
| 属于范围 | 明确的排除项 | 被有意排除的候选需求及排除理由 |
| 不属于本文重点 | 发布执行 | 构建、部署、灰度、发布节奏等归研发交付管理 |
| 不属于本文重点 | 上线准入 | 质量门禁、评审标准、准出条件归研发交付管理 |
| 不属于本文重点 | 回滚处置 | 发布后异常的回退方案与应急流程归研发交付管理 |
范围与排期、资源投入也需要区分。范围回答“交付什么”，排期回答“什么时候交付”，资源投入回答“投入多少人力和时间”。三者相互影响，但概念不同。范围确定后，排期和资源需要据此核对是否可行；如果排期或资源不足，调整的对象可能是范围，也可能是排期，这属于范围变更判定的一部分，而不是范围定义本身。
版本功能范围是怎么形成的
版本功能范围从需求池出发，经过筛选、排序、依赖检查和容量核对，最终收敛为一份范围清单。这个过程可以拆成输入、动作、产出和变更处理四个环节。
输入：需求池、版本目标、依赖与约束
需求池提供候选条目，是范围的原料。版本目标提供筛选依据，决定哪些需求与本次版本意图一致。依赖与约束包括技术依赖、外部接口、合规要求、团队容量等，它们决定哪些需求在本次版本中具备交付条件。
动作：筛选、排序、依赖检查、容量核对
- 筛选：按版本目标剔除明显不相关的需求，保留与目标一致或为达成目标所必需的条目。
- 优先级排序：在保留条目中按价值、紧迫性和成本排序，确定哪些进入承诺范围，哪些作为备选。
- 依赖检查：确认条目之间的先后依赖，避免把依赖未满足的功能放入本版本。
- 容量核对：用团队可用容量对照条目估算，判断范围是否超出可交付能力，必要时削减或拆分。
产出：版本范围清单及明确的排除项
产出物是一份范围清单，包含纳入的功能条目、每个条目的简要说明、对应的用户可见行为，以及明确的排除项和排除理由。排除项与纳入项同等重要，它让团队和干系人清楚边界在哪里，减少后续反复确认。
变更处理：范围调整的触发条件与记录方式
范围不是冻结不变的。常见触发条件包括：关键依赖出现阻塞、版本目标发生调整、出现影响交付的高优先级缺陷或合规要求。变更处理的关键是记录：谁提出、为什么调整、调整了哪些条目、对排期和资源有什么影响、由谁确认。记录方式可以是范围清单的变更日志，或在需求条目上标注版本归属的变更历史。这样在版本推进过程中，团队能追溯范围为什么变成现在这样。
在范围清单形成和变更记录这个环节，团队通常需要一个承载需求条目、版本归属和变更历史的协作空间。ONES 的需求管理与版本管理能力可以把需求条目归入指定版本，并保留条目状态和变更记录，便于在评审和交接时对照范围清单确认边界。具体字段和流程配置需结合团队实际使用方式设置。
容易混淆的几个相邻概念
版本功能范围经常与路线图、需求池、发布计划、迭代范围混用。它们处在不同层级，回答不同问题。下表按同一口径对比。
| 概念 | 回答的问题 | 时间粒度 | 与版本功能范围的关系 |
|---|---|---|---|
| 产品路线图 | 产品往哪个方向走，未来几个阶段重点是什么 | 季度或半年以上 | 路线图给方向，范围给具体交付集合；范围是路线图在某个版本上的落地 |
| 需求池 | 有哪些候选需求待评估和安排 | 持续积累 | 需求池是候选，范围是承诺；范围从需求池中筛选产生 |
| 发布计划 | 何时、以什么方式把版本交付出去 | 与版本周期对应 | 范围定做什么，发布计划定何时以何种方式交付 |
| 迭代范围 | 一个迭代内要完成哪些条目 | 通常一到四周 | 迭代范围是版本范围在时间上的切分，层级更低、粒度更细 |
这组概念的区别可以用一句话概括：路线图管方向，需求池管候选，版本功能范围管承诺，发布计划管交付方式，迭代范围管短期执行。它们相互衔接，但不能互相替代。把路线图当成范围，会导致承诺模糊；把需求池当成范围，会导致边界不清；把发布计划当成范围，会导致内容与节奏混淆。
一个具体例子与常见误解
下面用一个演示情景说明范围划定过程。某团队计划推出一个面向企业客户的账号管理版本，版本目标是“让管理员能够批量管理成员账号并控制访问权限”。以下为演示情景，不作为真实案例。
示例：纳入与排除
- 纳入：批量导入成员账号、按角色分配访问权限、成员状态启用与停用、操作记录查询。纳入理由是与版本目标直接相关，且依赖条件具备。
- 排除：单点登录对接、组织架构层级同步、自定义权限模板。排除理由是单点登录依赖外部身份服务排期，组织架构同步涉及上游数据改造，自定义权限模板超出本版本目标范围，三者均记录为后续候选。
- 变更条件：若批量导入依赖的接口在开发中发现问题，允许将批量导入拆分为“模板导入”先行交付，其余部分顺延，变更需记录并同步给相关干系人。
常见误解纠正
误解一：范围越大越好。范围大意味着承诺多，但交付能力和依赖条件有限。范围过大会导致每个条目都做不深，或者临近交付时被迫削减，反而损害可信度。合理的范围是与目标一致、容量可支撑、依赖可满足的集合。
误解二：范围一旦确定完全不能调整。范围需要稳定，但完全冻结不现实。关键是把调整变成有规则的动作：明确触发条件、记录变更原因、评估影响、由约定角色确认。有记录的调整比私下蔓延更可控。
误解三：范围清单等于任务清单。范围清单描述交付什么功能、用户能感知什么变化，任务清单描述团队如何分工完成。范围清单是承诺层面的产物，任务清单是执行层面的拆解。两者层级不同，混用会让范围讨论陷入实现细节，失去边界管理的意义。
常见问题
版本功能范围和版本目标是什么关系？
版本目标描述这个版本要达成的业务意图或用户价值，版本功能范围是把目标翻译成具体功能条目的结果。目标定方向，范围定内容。实践中常见的情况是目标写得清楚，但范围清单里的条目与目标关联不上，这时需要回到目标重新筛选，而不是在条目层面反复争论。
范围已经确定，中途有高优先级需求插进来怎么处理？
先判断它是否属于约定的变更触发条件，例如合规要求、影响交付的关键缺陷或版本目标调整。若符合，按变更流程记录提出人、调整原因、涉及的条目以及对排期和资源的影响，再由约定角色确认。若不符合触发条件，通常放入后续版本候选，并记录排除理由。把例外处理变成有规则的动作，比临时口头答应更可控。
范围清单需要写到多细？
范围清单停留在承诺层面即可：每个条目说明交付什么功能、用户能感知到什么变化、必要的配套改动有哪些。任务拆分、工时估算、人员分工属于执行层面，放在任务清单或迭代计划中处理。清单过细会让范围评审变成实现讨论，过粗则无法判断边界，通常以“干系人能据此判断某需求是否在本版本内”为标准。
团队容量不足时，应该削减范围还是延后排期？
两种调整都可行，取决于版本目标的刚性和外部约束。如果版本目标对应明确的时间窗口，例如合规截止或客户约定，通常优先削减范围，保留与目标最直接相关的条目；如果目标可以顺延，延后排期也是合理选择。无论选哪种，都要同步更新范围清单和排除项，避免范围与排期各自变化后对不上。
多个团队协作同一个版本时，范围怎么对齐？
先由各团队按统一口径提交本团队的范围条目与排除项，再在版本层面汇总核对依赖关系，确认跨团队的先后顺序和接口约定。汇总后的范围清单作为共同承诺，各团队的内部任务拆解可以不同，但条目归属和变更记录应保持一致，避免同一功能在不同团队清单里状态不一致。
