2. RICE四要素定义与量化标准

2.1 适用场景

本章适用于以下典型场景：

• MVP 需求筛选：从大量候选需求中筛选出最小可行版本必须包含的功能，需要统一、可量化的优先级评估框架。
• 跨角色对齐：产品经理、开发、设计、运营对需求价值认知存在分歧时，使用 RICE 评分建立客观对话基础。
• 向干系人展示决策依据：需要向上级或业务方解释“为什么做 A 而不做 B”时，RICE 评分提供可追溯的量化证据。
• 版本节奏规划：在同一个 MVP 迭代周期内，对多个候选功能进行热力图排序，确定本轮「必做/应做/可不做」清单。

2.2 前置条件

在开始 RICE 四要素评分之前，团队必须完成以下准备工作：

• 已产出结构化的 需求列表（至少包含功能名称、目标用户、预期收益描述）。
• 具备基础的 用户行为数据 或 行业对标估算（如 DAU/MAU、转化率、留存率）。
• 团队对产品的 核心北极星指标 达成共识（例如“周活跃用户数”或“首单转化率”）。
• 指定一名 评分协调人（通常为产品经理），负责组织评分会议并记录结果。

2.3 操作步骤——四要素详解

RICE 模型由四个维度组成：Reach（覆盖范围）、Impact（影响程度）、Confidence（信心指数）、Effort（投入成本）。每个维度采用 1–10 分制量化，最终通过公式 (R × I × C) / E 计算出优先级总分。

2.3.1 Reach（覆盖范围）—— 定义与量化

定义：在指定时间周期（通常为 MVP 迭代的 2–4 周）内，该功能预计会影响多少用户。衡量的是「广度」而非「深度」。

2.3.2 Impact（影响程度）—— 定义与量化

定义：该功能对产品的核心北极星指标的提升强度。衡量的是「深度」—— 每个受影响用户的行为改变幅度。

2.3.3 Confidence（信心指数）—— 定义与量化

定义：团队对 Reach 和 Impact 两项估算的「确信程度」。数据来源越扎实，Confidence 越高。

2.3.4 Effort（投入成本）—— 定义与量化

定义：完成该功能所需的全部工作量，包含设计、开发、测试、部署。以「人·天」或「人·周」为统一单位。

2.4 输入输出物

2.5 责任边界

• 产品经理（评分协调人）：组织评分会议，确保每项需求都有 R/I/C/E 四维评分，最终汇总形成优先级排序。
• 数据分析师：提供 Reach 和 Impact 所需的定量数据，并对 Confidence 在 5 分以上的需求给出数据来源标注。
• 技术负责人：主导 Effort 评分，输出工作量估算，并注明技术风险项（如第三方依赖、历史债务影响）。
• 业务/运营代表：提供用户反馈和业务场景输入，辅助 Impact 评分的「业务价值」判断。

2.6 记录材料

每次 RICE 评分需保留以下材料，供后续复盘或回溯：

• RICE 评分原始表（包含每项需求的四维分数、计算过程、评分人）。
• 评分会议纪要（记录争议点、数据来源、临时假设）。
• 刻度校准记录（首次评分时，团队共同确认的刻度参考案例）。

推荐使用以下 JSON 结构持久化存储每条需求的评分记录：

{
  "feature_id": "F2024-031",
  "feature_name": "微信登录接入",
  "score_r": 7,
  "score_i": 8,
  "score_c": 6,
  "score_e": 4,
  "rice_score": 84.0,
  "scored_by": "张明（PM）",
  "data_source": "2024Q3 用户调研 N=1200",
  "controversy_note": "技术评估 Effort 原为 6，经拆解为两期后降至 4"
}

2.7 异常处理

2.8 验收标准

本章节（RICE 四要素定义与量化标准）的掌握情况可通过以下清单验收：

• ✅ 能独立说出 R、I、C、E 四个维度的中文名称与核心定义。
• ✅ 能根据给出的场景描述，为每个维度在 1–10 分内给出合理的评分并说明理由。
• ✅ 能正确计算 RICE 总分：(R × I × C) / E，并解释为什么 Effort 是分母。
• ✅ 能识别 Confidence ≤ 3 时模型发出的「先验证再开发」信号。
• ✅ 能在实际项目中输出一份包含四维评分和总分排序的 RICE 矩阵。