界定产品范围的核心动作，是把“产品要做什么”写成一份可判定的功能特性清单：每条特性说明目标用户、触发条件、输入输出、验收口径和明确不包含的内容，再逐条映射到需求、设计、开发、测试、上线等工作项，形成双向可追溯的范围基线。清单字段和追溯规则先定下来，工具只是承载手段；ONES可用于在项目下维护需求范围、拆解工作项并设置计划基线，帮助团队把这份清单落到日常协作中。
要点总览（TL;DR）
- 产品范围以功能特性为基本单元，每条特性写清目标用户、触发条件、输入输出、验收口径和不包含内容，让第三方能独立判断做没做。
- 功能特性边界用“包含/不包含”成对描述，把容易混淆的相邻能力明确排除，减少执行中被相近需求带偏。
- 把每条特性逐条拆成需求、设计、开发、测试、上线工作项并标注特性编号，形成双向追溯，反向检查剔除孤立工作项。
- 范围基线经产品负责人、项目经理、开发与测试代表评审确认后冻结并记录版本，作为后续变更比对的统一依据。
- 进入执行前用完成检查清单核对验收口径、追溯完整性和边界外需求去向，检查不通过按问题类型退回处理。
先定产品范围：功能特性清单怎么写
产品范围回答的是“产品要具备什么能力”，基本单元是功能特性，而非页面、模块或开发任务。一条特性写得好不好，判断标准很直接：一个不参与讨论的第三方读完，能独立判断这项能力做了还是没做。达不到这个标准，说明描述还停留在方向层面，需要继续拆。
编写时先取业务目标和用户场景作为输入，逐个场景识别产品需要提供的能力，再按统一字段逐条填写。字段不必多，但每项都要填实，空缺的字段往往就是后续争议的来源。
| 字段 | 填写要求 | 常见问题 |
|---|---|---|
| 特性名称 | 用动宾结构描述能力，如“支持按项目导出范围清单” | 写成模块名，看不出具体能力 |
| 目标用户 | 写明角色及使用场景，如“项目经理在周会前整理范围” | 只写“所有用户” |
| 触发条件 | 说明什么情况下该能力被使用 | 缺失，导致验收时无法复现 |
| 输入 | 用户提供或系统已有的数据、操作 | 输入来源不明 |
| 输出 | 可观察的结果，如生成的清单、状态变化 | 只写“完成处理” |
| 验收口径 | 可检验的通过条件，尽量带数量或状态 | 写成“体验良好” |
| 不包含内容 | 与本特性相近但本期不做的事项 | 整条留空 |
边界建议用“包含/不包含”成对描述。只写正向功能，执行中很容易被相近需求带偏；把容易混淆的相邻能力明确排除，评审和开发时才有共同参照。例如“包含按项目导出范围清单；不包含跨项目汇总导出”，一句话就划清了本期与后续的界线。
这一步的完成标志是：清单中每条特性都能被第三方独立判定，验收口径可检验，不包含项已写明。达到这个状态，产品范围才算初步界定完成。
把功能特性映射到项目工作范围
产品范围说明交付什么，项目工作范围说明为交付这些特性需要做哪些事，包括需求细化、设计、开发、测试、上线准备等活动集合。两者衔接的方式是逐条映射：每条特性拆出一组工作项，每个工作项标注所属特性编号。
操作上分三步。第一步，给功能特性清单统一编号，如F-01、F-02，编号在后续所有文档中保持不变。第二步，针对每条特性列出交付所需的工作项，按需求、设计、开发、测试、上线分类，工作项描述到可分配、可估算的程度。第三步，把特性编号与工作项编号填入追溯表，形成正向对应。
| 特性编号 | 特性名称 | 工作项编号 | 工作项类型 | 负责人 | 状态 |
|---|---|---|---|---|---|
| F-01 | 按项目导出范围清单 | T-01 | 需求细化 | 产品负责人 | 已完成 |
| F-01 | 按项目导出范围清单 | T-02 | 接口设计 | 开发代表 | 进行中 |
| F-01 | 按项目导出范围清单 | T-03 | 功能开发 | 开发代表 | 待开始 |
| F-01 | 按项目导出范围清单 | T-04 | 导出结果校验测试 | 测试代表 | 待开始 |
正向映射完成后必须做反向检查：逐个工作项回指特性编号。指不回任何特性的工作项，要么是遗漏登记的范围，要么是超出边界的额外工作，应进入待定清单，由产品负责人和项目经理判断是补入基线还是剔除。同时检查每条特性是否至少有一个开发类和测试类工作项覆盖，避免出现“写了特性但没人做”或“做了但没验证”的情况。
完成标志是追溯表无孤立工作项、无未覆盖特性。此时产品范围与项目工作范围使用同一套编号和口径，后续任何一方调整都能快速定位影响面。
角色分工与各阶段交付物
范围界定涉及三类角色，职责按产物划分，交接点清晰，避免出现“大家都参与、没人负责”的局面。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 产品负责人 | 编写功能特性清单，守住包含与不包含边界，解释特性意图 | 功能特性清单（含编号、验收口径、不包含项） | 映射启动前交付给项目经理 |
| 项目经理 | 组织特性到工作项的映射，维护追溯表，组织基线评审与冻结 | 特性—工作项追溯表、范围基线版本记录 | 评审通过后向团队发布基线 |
| 开发代表 | 从可实现角度评审特性描述与验收口径，补充技术约束 | 评审意见、技术可行性说明 | 基线评审会上提交 |
| 测试代表 | 从可验证角度评审验收口径，确认每条特性可设计测试用例 | 验收口径修订建议、用例覆盖说明 | 基线评审会上提交 |
评审确认是范围基线成立的关键节点。产品负责人、项目经理、开发与测试代表共同确认清单内容、追溯完整性和验收口径后，基线冻结并记录版本，作为后续需求讨论和变更比对的统一依据。冻结之后新增或调整的内容走变更记录，与基线区分开，保证任何时候都能回答“当前基线是什么、改过什么”。
在工具层面，ONES瀑布项目管理解决方案支持在项目下管理需求范围、研发任务，并可用项目计划按目标、交付物或项目阶段分解工作，适合承载特性清单与工作项的对应关系；测试用例也可与需求、任务关联，让验收口径在测试环节有落点。团队仍需先确定字段与编号规则，再决定在工具中如何配置。
示例：一个功能特性如何落到工作范围
以下为演示情景，用于说明填写与映射过程，不代表真实项目数据。
特性描述（F-01）：支持项目经理按单个项目导出范围清单。目标用户为项目经理，使用场景是周会前整理当前范围。触发条件为项目经理在项目详情页选择“导出范围清单”。输入为项目内已确认的功能特性清单及状态。输出为一份包含特性编号、名称、验收口径、当前状态的清单文件。验收口径为：导出内容与项目内清单一致，字段完整率100%，单次导出在10秒内完成。不包含：跨项目汇总导出、自定义导出模板、定时自动导出。
拆出的工作项：
- T-01 需求细化：明确导出字段范围与权限规则，产出需求说明。
- T-02 接口设计：设计清单查询与文件生成接口，产出设计文档。
- T-03 功能开发：实现导出入口、字段组装与文件下载。
- T-04 测试：验证字段完整率、内容一致性及导出耗时，关联F-01的验收口径设计用例。
- T-05 上线准备：更新使用说明，通知项目经理群体。
追溯关系：F-01对应T-01至T-05，五个工作项均标注特性编号F-01；反向检查时每个工作项都能回指F-01，无孤立项。
边界外需求的识别：讨论中出现“顺便支持跨项目汇总导出”的提议。对照F-01的不包含项，该提议属于明确排除的内容，登记到待定需求清单，注明提出人、场景和期望时间，由产品负责人评估是否进入下一期范围，本期基线不做调整。这样处理既保留了需求线索，也避免本期范围在执行中被悄悄扩大。
完成检查：范围基线是否可用
进入执行前，用以下清单逐项核对。全部通过，说明产品范围与工作范围已界定清楚，可以作为后续比对依据。
- 每条功能特性都有编号、目标用户、触发条件、输入输出和可检验的验收口径。
- 每条特性都写明了不包含内容，相近能力已用“包含/不包含”成对描述。
- 每个工作项都能追溯到某条特性编号，追溯表中无孤立工作项。
- 每条特性至少有一个开发类和一个测试类工作项覆盖，无未覆盖特性。
- 范围基线已经产品负责人、项目经理、开发与测试代表评审确认，并有版本记录。
- 边界外需求已登记到待定清单，记录了提出人、场景和去向。
检查不通过时按问题类型处理：验收口径不可检验的，退回产品负责人补充；出现孤立工作项的，由项目经理组织判断补入基线或剔除；特性无工作项覆盖的，补齐映射后再评审；基线未评审或版本记录缺失的，暂缓发布基线，完成评审和记录后重新冻结。处理完成后重新走一遍检查，确认无遗留问题再进入执行阶段。
常见问题
功能特性清单写到什么颗粒度才算够？
判断标准是第三方可独立判定：一个没有参与讨论的人读完这条特性，能判断这项能力做了还是没做。如果描述里只有方向性表述，比如“优化导出体验”，说明颗粒度还不够，需要补上目标用户、触发条件、输入输出和可检验的验收口径。
颗粒度也不宜过细到页面元素或按钮级别，那属于设计阶段的工作。功能特性描述的是产品要具备的能力，页面和交互在后续设计工作项中细化。
产品范围已经评审冻结，执行中又出现相近需求，怎么处理？
先对照该特性或相关特性的“不包含”项。如果提议已被明确排除，登记到待定需求清单，记录提出人、场景和期望时间，由产品负责人评估是否进入下一期，本期基线不做调整。如果提议确实属于遗漏的范围内容，走变更记录，与当前基线区分开，保留“基线是什么、改过什么”的可追溯记录。
处理的关键是把新需求与基线比对后再决定去向，避免在执行中直接口头扩大范围。
产品范围与项目工作范围的追溯表需要维护到什么程度？
至少保证两点：每个工作项都能回指某条特性编号，每条特性都有开发类和测试类工作项覆盖。追溯表随工作项状态更新而更新，特性编号在需求、设计、开发、测试各环节保持一致，不因文档版本变化而重新编号。
团队规模较小、特性数量不多时，一张表格即可维护；特性数量多、跨团队协作时，可借助项目管理平台承载关联关系，但编号规则和字段口径仍需团队先统一。
开发或测试代表在基线评审时提出验收口径无法验证，应该怎么衔接？
这类意见应在评审会上直接退回产品负责人补充，而不是带着模糊口径冻结基线。测试代表可以从“能否据此设计测试用例”的角度判断，开发代表从“能否据此估算和实现”的角度判断，两者意见都指向同一条特性时，说明该特性的验收口径需要重写。
修订后的特性重新提交评审，确认可检验后再纳入基线冻结，避免执行阶段才发现无法验收。
范围基线冻结后，工具中如何承载特性清单与工作项的对应关系？
ONES 瀑布项目管理解决方案支持在项目下管理需求范围、研发任务，并可用项目计划按目标、交付物或项目阶段分解工作；测试用例也可与需求、任务关联，让验收口径在测试环节有落点。团队可以把特性清单作为需求范围维护，把拆出的工作项挂在对应特性下，借助关联关系保持追溯。
工具配置前先确定字段与编号规则，具体版本与套餐对上述能力的支持范围需另行确认。
