3. RICE 范围定义：需求/功能单位、颗粒度规范、排除清单
RICE 评分的起点不是原始需求列表，而是经过统一裁剪的功能单位。本章定义什么是“一个可评分的功能单位”，设定颗粒度标准，并明确哪些内容不应进入评分流程。范围定义的质量直接决定 RICE 排序的可比性与可信度。
3.1 适用场景
- 团队首次引入 RICE 框架，需要统一评分对象的粒度口径。
- 现有需求列表包含不同粒度的混合项（史诗、特性、任务混杂），需要标准化。
- 评分结果出现争议，回溯发现因功能单位边界模糊导致分数不可比。
- 需将 RICE 评分嵌入需求管理流程（Jira / TAPD / 飞书项目）前的初始化准备。
3.2 前置条件
- 已建立原始需求池（至少包含需求标题、一句话描述、来源）。
- 团队已确定使用 RICE 作为选型框架（即已完成第 2 章框架选型决策）。
- 产品经理与技术负责人均已参与范围定义评审。
- 已有或可参照的需求分层规范（Epic / Feature / Story / Task 分级）。
3.3 操作步骤
核心原则：一个功能单位应满足“独立可交付、可估算、可测试、面向用户或业务价值”。
以下四步完成从原始需求到标准化功能单位的转换。
以下四步完成从原始需求到标准化功能单位的转换。
- 列出现有需求清单
从产品路线图、用户反馈池、技术债登记表、合规需求列表中汇总所有待评估条目，形成原始需求池 V1。 - 按颗粒度规范拆解或合并
对照下表将每个需求映射到标准层级。跨版本的大型史诗拆解为特性/用户故事；过细的开发任务合并为用户故事；保持同一批次内颗粒度一致。 - 应用排除清单过滤
将属于排除类别的条目移出评分池，归档至排除清单日志。排除项不再进入 RICE 评分，但保留追溯记录。 - 评审与确认功能单位清单
产品经理 + 技术负责人 + 相关干系人共同评审。每个功能单位需有唯一 ID、名称、描述、粒度层级。通过后冻结为功能单位清单 V1。
3.4 输入输出物
| 方向 | 名称 | 说明 | 格式 / 载体 |
|---|---|---|---|
| 输入 | 原始需求池 V1 | 未经裁剪的需求条目集合，可含不同粒度 | Excel / 需求管理工具列表 |
| 输入 | 产品战略目标文档 | 用于判断需求是否与当前战略对齐 | Confluence / 飞书文档 |
| 输出 | 功能单位清单 V1 | 标准化后的可评分功能单位，含 ID、名称、描述、粒度 | JSON / 表格 / Jira Epic Link |
| 输出 | 颗粒度规范文档 | 团队统一的分层标准与示例 | Markdown / 在线文档 |
| 输出 | 排除清单日志 | 被排除的条目及排除原因，供日后回溯 | Excel / 需求工具标签 |
功能单位清单 JSON 模板示例：
[
{
"id": "FUNC-001",
"name": "社交账号一键登录",
"description": "支持微信、Google、Apple ID 一键注册/登录",
"granularity": "feature",
"epic": "用户增长与注册体验",
"status": "approved"
},
{
"id": "FUNC-002",
"name": "登录异常告警",
"description": "连续 5 次登录失败触发管理员通知",
"granularity": "story",
"epic": "账户安全体系",
"status": "approved"
}
]3.5 责任边界
| 角色 | 职责 | 决策权 |
|---|---|---|
| 产品经理 | 定义功能单位、维护排除清单、组织评审 | 对颗粒度分层和范围边界有一票否决权 |
| 技术负责人 | 确认拆解后的功能单位在技术上可行且可独立交付 | 对技术不可行的功能单位可打回重新拆解 |
| 需求提出方 / 业务方 | 提供原始需求背景，确认排除项无遗漏 | 申诉排除决定，但最终由产品经理裁定 |
| 团队全体 | 参与功能单位清单评审，提出边界模糊项 | 集体评议，共识后冻结清单 |
3.6 记录材料
- 颗粒度对照表：团队约定的四级粒度（Epic / Feature / Story / Task）及每个层级的正例与反例。
- 排除清单检查表：逐一核对每项原始需求是否命中排除类别（技术债务、内部工具、合规强制、已承诺交付、依赖前置）。
- 功能单位清单模板：包含 ID、名称、描述、粒度、所属史诗、状态（草稿 / 已确认 / 已排除）的标准化模板。
3.7 异常处理
| 异常情形 | 处理方式 |
|---|---|
| 功能单位颗粒度过大（跨版本史诗） | 要求拆解为多个特性或用户故事，每个可独立评分；拆解后重新进入评审 |
| 功能单位颗粒度过小（开发子任务） | 合并为上层用户故事，确保每个单位包含完整价值闭环 |
| 需求边界模糊，无法归类 | 召开 30 分钟边界澄清会，由产品经理与提出方确定范围；仍模糊的暂缓纳入 |
| 排除清单中发现需紧急处理的需求 | 标记为“例外紧急项”，走快速通道评审，进入下一批次评分 |
| 原始需求遗漏关键条目 | 补充后进入下一轮范围定义，不强制塞入当前批次 |
常见陷阱：不要将“技术方案”作为功能单位。例如“引入 Redis 缓存”应表达为“降低首页加载时间至 1s 以内”的功能单位。RICE 评分面向用户价值，而非技术实现。
3.8 验收标准
- 每个功能单位均满足独立可交付、可估算、可测试、面向用户或业务价值四项条件。
- 同一批次内所有功能单位的颗粒度处于同一层级（全部为 Feature 或全部为 Story），不得混合跨层级评分。
- 排除清单日志完整记录每项排除条目的原始编号、名称、排除原因、决策人。
- 功能单位清单已通过产品经理 + 技术负责人双签确认，状态标记为
approved。 - 清单已同步至团队统一的需求管理工具，并关联对应 RICE 评分字段。