第2章 RICE 框架总览：四要素含义、适用场景、前置条件、输入输出物

2.1 适用场景

RICE 框架适合以下四类典型决策环境，团队可根据当前成熟度判断是否启用：

• 需求 Backlog 定期排序：每迭代或每月对积压需求做统一量化评分，消除主观拍脑袋。
• 产品路线图规划：在季度/年度规划中，用 RICE 分数对齐资源投入与业务目标。
• 跨团队资源竞备：多个业务方同时提出需求时，用统一标尺减少博弈成本。
• 版本发布范围裁剪：上线窗口紧张时，按 RICE 排序决定“做哪些、砍哪些”。

2.2 前置条件

在正式启用 RICE 评分前，团队必须完成以下四项准备：

1. 需求列表已结构化：每个需求有唯一 ID、标题、简述及关联 Epic/Story 层级。
2. 基础数据源就绪：至少具备用户量级、历史版本使用率、调研样本量等定量或半定量数据。
3. 评分角色明确：已指定 PO、BA、技术代表、数据支持人各一名，避免一人包办。
4. 评分规则共识：团队对 Reach 的“人数区间”、Impact 的“1-5 分定义”、Confidence 的“% 档位”达成书面约定。

2.3 操作步骤：RICE 四要素详解与评分流程

RICE 评分本质上是一个四步量化 + 一步计算的流水线。以下按执行顺序拆解每个要素的含义与操作要点。

Step 1 — Reach（触达）

含义：在给定时间窗口内，该需求预计影响到的独立用户/客户数。通常以“人数/月”或“人数/季度”计。

Step 2 — Impact（影响）

含义：该需求对用户/业务带来的改变程度。建议使用 1-5 分制，并给出每个分数的行为锚定。

Step 3 — Confidence（信心）

含义：对 Reach 和 Impact 评分的可靠程度。数值越低，说明数据支撑越薄弱，最终分数可能失真。

Step 4 — Effort（努力）

含义：开发该需求所需的总人·天（或人·月），包含设计、开发、测试、部署全链路。

Step 5 — 计算 RICE Score

将以上四个值代入公式：

RICE Score = (Reach × Impact × Confidence) / Effort

示例：
功能 A：Reach = 500 人/月，Impact = 3，Confidence = 80%，Effort = 20 人·天
RICE Score = (500 × 3 × 0.8) / 20 = 60

功能 B：Reach = 2000 人/月，Impact = 2，Confidence = 50%，Effort = 30 人·天
RICE Score = (2000 × 2 × 0.5) / 30 ≈ 66.7

排序结论：功能 B（66.7）> 功能 A（60），建议优先启动功能 B。

2.4 输入输出物

2.5 责任边界

2.6 记录材料

每次 RICE 评审必须留存以下三份材料，作为可追溯的决策档案：

1. RICE 评分原始表（电子版）：包含每个需求的四要素分数、计算过程、评分人签名或缩写。
2. 评分依据备忘录：对 Confidence 低于 80% 的需求，必须附上数据来源或推断逻辑的文字说明。
3. 排序结果确认单：PO、Tech Lead、数据分析师三方签字（或邮件确认），表示对排序无异议。

2.7 异常处理

2.8 验收标准

本章 RICE 框架总览落地是否合格，以下六条必须全部满足：

1. 完整性：所有需求均已填写 Reach、Impact、Confidence、Effort 四项数值，无空缺项。
2. 可追溯性：每个 Confidence ≤ 80% 的需求都附有书面依据说明。
3. 一致性：同一场评审会中，不同角色对相同需求打分的波动范围不超过 20%（按 RICE Score 计算）。
4. 共识性：排序结果经 PO、Tech Lead、数据分析师三方确认，无未关闭的争议。
5. 时效性：从评分会议开始到输出排序列表，总耗时不超过 4 小时（按 15 个需求计算）。
6. 归档性：所有记录材料已按 2.6 节要求保存至指定位置。