确定版本功能范围，是把“想做”的候选需求收敛为“这一版承诺做”的功能集合的决策过程。操作路径是：建立统一候选池并补齐价值、成本、依赖信息，用事先约定的标准排序，按容量与依赖裁剪成草案，经跨角色评审确认边界，最后冻结范围并设定变更入口。本文只讨论“本版做什么”，发布执行、准入评审与回滚不在范围内。
要点总览（TL;DR）
- 范围确定是把候选需求收敛为本版承诺交付的功能集合，终点是一份含“做”与“不做”的范围清单，发布执行与回滚不在本文范围。
- 筛选前先统一四条准入口径：用户价值可说明、成本可估算、依赖可识别、责任人有归属，避免评审时逐条重定标准。
- 排序用用户价值、战略契合、成本与风险、依赖前置四个标准，权重与打分理由事先约定并留痕，输出候选集而非最终范围。
- 裁剪要结合人力、时间与外部依赖估算容量，前置未就绪的功能延后，形成本版做、下版做、暂不做三档草案。
- 评审确认边界与例外后冻结范围，并明确变更的提出人、评估人和决策人，以是否影响版本目标与交付节奏作为判断标准。
先定判断口径：什么样的功能才算进入本版范围
范围确定的终点，是一份本版承诺交付的功能集合。判断某个功能能否进入这个集合，需要在筛选开始前统一四条口径，让所有候选在同一标尺下比较。
- 用户价值可说明：能指出服务哪类用户、解决什么具体问题、预期带来什么可观察的变化，例如减少某环节操作步骤、缩短某类请求的处理时间。
- 成本可估算：研发能给出粗略的人力和时间量级，允许有区间，但不能是“说不清”。
- 依赖可识别：知道该功能依赖哪些前置功能、外部系统、数据或合规审批，以及这些依赖当前是否就绪。
- 责任人有归属：有明确的产品负责人跟进该功能，后续的验收口径也有人对结果负责。
这四条口径的价值在于把争论从“这个功能重要不重要”转为“它是否满足准入条件、满足到什么程度”。口径应在排序前由产品负责人牵头确认并书面留痕，避免评审会上逐条重新定义标准。一份可复用的口径清单，通常就是这四条加上团队自己的补充项，例如是否涉及数据迁移、是否影响现有客户合同承诺。
第一步：建立需求候选池并补齐三类信息
候选池的作用是让所有可能进入本版的需求出现在同一张表里，而不是散落在聊天记录、邮件和各个人的记忆中。候选来源通常包括四类：用户反馈与客服工单、产品数据洞察、销售与客户诉求、技术债与合规要求。四类来源的诉求性质不同，但进入候选池后使用同一套字段描述。
每个候选需要补齐三类信息：
- 价值描述：目标用户、使用场景、预期结果，尽量写成可验证的表述。
- 粗略成本：研发给出的量级估算，注明估算人和估算依据。
- 依赖关系：前置功能、外部系统、数据准备、审批事项，以及依赖的当前状态。
字段缺失的候选标注“待补”，不进入排序环节。这条规则看似严格，实际是保护决策质量：用不完整信息排序，得到的顺序在评审时必然被推翻。补齐动作由产品负责人组织，研发负责成本与依赖评估，业务方负责价值场景的补充说明。完成标志是候选池中每个进入排序的条目三类字段齐全，待补条目单独列出并注明补齐期限。
当候选条目较多、来源分散时，可以用ONES的需求管理承载候选池：把反馈、诉求和技术债统一录入为需求工作项，用自定义字段记录价值描述、成本估算和依赖关系，让后续排序在同一数据基础上进行。
第二步：用统一标准排序并筛出候选集
排序的目的是把候选池收敛为一个可讨论的候选集，而不是直接定出最终范围。建议使用四个标准，并对每个标准事先约定权重和打分规则：
| 标准 | 判断内容 | 打分参考 |
|---|---|---|
| 用户价值 | 覆盖用户规模、问题严重程度、可观察的改善 | 1–5分，附一句理由 |
| 战略契合 | 与版本目标、年度方向的一致性 | 1–5分，说明对应哪项目标 |
| 成本与风险 | 人力投入、技术不确定性、合规风险 | 按成本高低反向计分 |
| 依赖前置 | 前置项是否就绪，未就绪是否可在本版内解决 | 就绪、可解决、不可解决三档 |
打分与权重需要事先约定并留痕，包括谁打分、分歧如何合并。常见做法是产品负责人给出价值与战略分，研发负责人给出成本与依赖分，分歧超过一定分差时由双方当面说明理由后取共识值。输出物是带评分与排序理由的候选集，通常取排序前若干名进入下一环节，具体数量按团队容量预估确定。排序结果要保留理由字段，因为评审时被问到的往往不是分数，而是“为什么它排在前面”。
第三步：按容量与依赖裁剪成范围草案
候选集是按价值排出的顺序，范围草案则要回答“这一版装得下多少”。容量估算的口径包括三项：可用人力（扣除支持、会议和休假后的实际投入）、版本周期内的时间、外部依赖的到位时间。三项中任何一项被低估，范围都会在执行中被动缩水。
裁剪时按排序从高到低装入，同时检查依赖链：前置项未就绪的功能延后，即使它的单项评分很高；两个功能共享同一前置项时，优先装入能带动更多后续项的那个。裁剪结果划分为三档：
- 本版做：容量内、依赖就绪、责任明确的功能。
- 下版做：价值成立但本版容量不足或前置未就绪的功能，注明预计版本。
- 暂不做：价值不成立、成本明显超出收益或与版本目标无关的功能，注明原因，避免反复回到讨论桌。
完成标志是一份含三档划分的版本范围草案，每个“本版做”条目都有成本估算和依赖状态，“下版做”和“暂不做”都有归类和理由。这份草案是评审的讨论底稿，不是最终承诺。
第四步：跨角色评审确认边界与例外
评审的作用是把草案中的假设摆到台面上，由各角色确认自己能否承接。参与角色通常包括产品、研发、测试、业务或客户代表。产品负责人主持并说明范围逻辑，研发确认成本与依赖判断，测试确认验收口径是否可执行，业务代表确认客户承诺与范围边界是否冲突。
评审需要确认三类内容：范围边界，即本版明确做什么、不做什么；验收口径，即每个功能的完成标准由谁认定；例外项与风险，即哪些条目因特殊原因被放入或拿出，风险如何处置。例外项必须记录理由与责任人，例如某客户合同承诺的功能优先级被上调，需要写明合同依据、提出人和跟进人。
评审结论应形成书面记录，包含确认后的范围、未达成一致的事项及处理方式。完成标志是所有参与角色对范围边界无异议，或异议已转为记录在案的例外项。
第五步：冻结范围并设定变更入口
冻结不是宣布范围不可改变，而是把改变纳入受控流程。冻结的输出包括三份内容：范围清单，逐条列出本版交付的功能及验收口径；版本目标，用一两句话说明这一版要达成的业务结果；不做清单，列出本版明确排除的功能及原因。三份内容一起发布给相关角色，作为后续判断变更的依据。
变更入口需要明确三个问题：谁可以提出变更，通常包括产品、业务代表和研发负责人；谁负责评估，一般由产品负责人评估价值与目标影响，研发负责人评估成本与节奏影响；谁做决策，由版本负责人或产品负责人最终拍板。变更判断围绕两个问题：是否影响版本目标，是否影响交付节奏。影响目标或节奏的变更需要重新走裁剪与评审，不影响的可在版本内消化并记录。
在ONES中，可以把冻结的范围清单与版本关联，需求工作项的状态和版本归属形成可追溯的记录；变更申请作为独立工作项提交，保留提出人、评估意见和决策结论，避免变更只发生在口头沟通中。
角色分工与各环节交付物
范围确定涉及多个角色，职责与决策权的区分需要在启动前说清。下表按环节汇总输入、输出与责任角色。
| 环节 | 主要责任角色 | 输入 | 输出 |
|---|---|---|---|
| 统一口径 | 产品负责人（决策） | 版本目标、历史争议点 | 范围准入口径清单 |
| 建候选池 | 产品负责人组织，研发与业务补充 | 反馈、数据、销售诉求、技术债与合规要求 | 字段齐全的候选池 |
| 排序筛选 | 产品负责人与研发负责人共同打分 | 候选池、权重规则 | 带评分与理由的候选集 |
| 裁剪草案 | 产品负责人主导，研发提供容量与依赖判断 | 候选集、容量估算 | 三档划分的范围草案 |
| 评审确认 | 产品、研发、测试、业务代表共同参与 | 范围草案、验收口径 | 评审结论与例外项记录 |
| 冻结与变更 | 版本负责人决策，产品负责人维护入口 | 评审结论、变更申请 | 冻结清单与变更流程说明 |
决策权与建议权要分开：范围口径、最终范围和变更决策由产品负责人或版本负责人拍板；研发对成本和依赖的判断具有专业权威，测试对验收口径的可行性有否决建议权，业务代表提供客户承诺信息但不直接决定范围。建议权用于影响决策，决策权用于结束争论，两者混用会让评审会反复失焦。
示例：一个版本的范围确定过程
以下为演示情景，用于说明方法如何落地，不代表真实项目数据。
某内部协作工具的下一版本目标定为“让新客户在首次使用中完成核心配置”。候选池收集到八条需求：批量导入成员、配置模板库、操作引导、权限预设、移动端适配、报表导出、消息通知优化、单点登录对接。补齐信息后，报表导出因价值描述模糊被标注待补，暂不进入排序。
排序阶段，操作引导与配置模板库在用户价值和战略契合上得分最高；单点登录对接成本高且依赖外部身份系统排期，依赖前置一栏标为不可解决；移动端适配价值成立但成本超出本版容量。裁剪时，本版装入操作引导、配置模板库、权限预设和批量导入成员，其中批量导入是权限预设的前置项，优先保留。单点登录对接与移动端适配归入下版做，报表导出与消息通知优化归入暂不做并注明原因。
评审会上，业务代表提出某客户合同要求本版包含单点登录对接，经确认该承诺签署时间晚于版本目标确定时间，作为例外项记录：理由为合同承诺，责任人为业务代表，处理方式为评估是否以简化方案在本版提供基础对接。最终冻结的范围清单包含四项功能，不做清单列出单点登录完整对接、移动端适配、报表导出和消息通知优化，版本目标保持不变。
完成检查：范围确定是否到位
范围确定工作结束时，用以下清单逐项核对，全部满足才视为完成：
- 范围清单同时包含“本版做”和“不做”两部分，不做部分有原因说明。
- 每个进入本版的功能都有价值描述、成本估算和依赖说明，三项齐全。
- 排序标准、权重和打分理由已留痕，评审时能解释排序结果。
- 范围草案有三档划分，下版做和暂不做的条目有归类和预计处理方式。
- 评审结论已书面记录，例外项有理由和责任人。
- 变更入口明确：谁提出、谁评估、谁决策，判断标准是是否影响版本目标与交付节奏。
- 每个本版功能都有责任人和可执行的验收口径。
清单中任何一项缺失，都意味着范围在后续执行中可能被重新讨论。补齐这些项的成本远低于版本中途返工的成本。
常见问题
候选池里的需求信息补不齐，是否可以先排序、边做边补？
不建议先排序。用不完整信息排出的顺序，在评审时往往被推翻，反而增加一轮返工。更稳妥的做法是把字段缺失的条目标注“待补”，单独列出并注明补齐期限，由产品负责人组织研发补成本与依赖、业务方补价值场景，补齐后再进入排序。如果版本周期紧、必须提前决策，可以只对价值明确且成本量级清楚的条目先排序，其余条目明确排除在本版讨论之外，避免用模糊信息占位。
排序打分出现分歧时，怎么处理才不至于让评审会失焦？
分歧通常来自打分依据不同，而不是标准本身有问题。可以在排序前约定分歧处理规则：产品负责人给出价值与战略分，研发负责人给出成本与依赖分，分差超过约定阈值时由双方当面说明理由后取共识值，并把理由写进记录。评审会上只讨论记录中理由不充分或信息有变化的条目，其余按排序结果处理。这样评审的焦点落在例外和新增信息上，而不是重新打一遍分。
范围冻结后，客户合同或监管要求带来必须插入的需求，怎么处理？
这类需求走变更入口，不直接改动已冻结清单。由提出人提交变更申请，产品负责人评估对版本目标的影响，研发负责人评估对交付节奏的影响，版本负责人决策。若必须在本版承接，需要同步决定拿出哪项已排功能，保持容量平衡，并把调整结果更新到范围清单和不做清单中。合同承诺、监管要求等依据要写入变更记录，明确责任人和跟进方式，避免同类诉求反复以口头方式进入。
团队规模小、角色兼任时，这套流程可以简化到什么程度？
可以合并环节，但不能省略判断依据。小团队常见做法是把候选池、排序和裁剪放在一次会议内完成，由兼任产品与业务角色的人给出价值判断，研发给出成本与依赖判断，当场形成三档草案；评审确认与冻结合并为一次书面确认，参与人签字或留言确认即可。需要保留的是：每个进入本版的功能有价值、成本、依赖三项说明，不做清单有原因，变更入口有人负责。简化的是会议次数和文档形式，不是决策依据本身。
范围确定完成后，如何判断后续执行中范围是否失控？
可以看三个信号：本版新增功能是否都走了变更入口并有决策记录；已排功能的成本估算是否被大幅突破而范围未相应调整；不做清单中的条目是否反复回到讨论中。出现前两种情况，说明变更判断标准执行不严，需要回到冻结清单核对目标影响；出现第三种情况，说明不做原因记录不够具体，应补充归类依据。定期对照冻结清单与当前实际范围，差异项逐条说明来源，比事后追责更能及时发现问题。
