1. RICE评分法概述
RICE评分法由Intercom产品团队提出，是一种基于四维量化指标的优先级排序模型。本章作为课程开篇，将完整定义RICE四要素、公式与适用范围，并按照SOP框架逐一展开前置条件、操作步骤、输入输出物、责任边界、记录材料、异常处理及验收标准，为后续章节的实战案例打下统一的方法论基础。
1.1 适用场景
RICE评分法适用于以下产品决策场景，尤其适合原型阶段的功能范围筛选：
- 功能优先级排序：在产品待办列表（Backlog）中，从多个候选功能中筛选出高价值、低成本的原型范围。
- 版本规划：确定MVP（最小可行产品）或迭代版本应包含哪些功能。
- 资源分配争议：当开发、设计、测试资源有限时，用统一量化的评分结果辅助决策。
- 跨角色对齐：产品经理、设计师、工程师使用同一套评分标准，减少主观争论。
- 原型验证排期：在用户研究或可用性测试前，筛选出最值得投入原型资源的功能。
适用范围提示：RICE 最适合已有初步用户数据或行业经验的中后期产品；对于全新0→1产品，Confidence 系数往往较低，建议结合定性方法交叉验证。
1.2 前置条件
使用RICE评分法前，团队必须完成以下准备工作，并统一理解四要素的定义与公式。
1.2.1 四要素定义
| 要素 | 缩写 | 定义 | 评分范围 | 典型数据来源 |
|---|---|---|---|---|
| Reach | R | 每单位时间（通常为月）内，该功能预期能覆盖到的独立用户数。 | 整数，≥0 | DAU/MAU 数据、用户访谈样本量、行业基准 |
| Impact | I | 功能对目标用户的影响力程度，衡量用户行为或满意度的改变幅度。 | 1（最低）～5（最高） | 用户调研、历史A/B测试效果、专家评估 |
| Confidence | C | 团队对 Reach 和 Impact 预估的信心水平，反映数据支撑程度。 | 20% ～ 100% | 数据置信区间、样本量大小、过往经验复现率 |
| Effort | E | 完成该功能所需的总工作量，通常以“人月”或“人周”为单位。 | 正数，＞0 | 工程师估算、历史工时数据、原型复杂度评估 |
1.2.2 评分公式
RICE 综合得分计算公式为：
RICE Score = (Reach × Impact × Confidence) / Effort其中：
- Reach 取月活用户数（MAU）或预估触达人数，单位与 Effort 的时间周期需保持一致。
- Impact 使用 1–5 整数标度，避免小数带来的伪精度。
- Confidence 使用百分数（如 80% 记为 0.8），反映数据可信度。
- Effort 使用人月数，若团队使用人周需统一换算（1人月 ≈ 4人周）。
公式记忆口诀：“覆盖 × 影响 × 信心 ÷ effort”，得分越高优先级越高。Effort 在分母，意味着工作量对分数呈反向压制，避免高投入低产出功能虚高。
1.3 操作步骤
RICE 评分操作分为以下 6 个标准步骤，团队需逐项执行并记录数据：
- 定义功能清单：列出所有待评估的原型功能，每个功能以唯一 ID 标识。
- 估算 Reach：根据 MAU、目标用户池或历史曝光数据，填写每月的独立用户覆盖数。
- 评估 Impact：使用 1–5 分标度，结合用户痛点和业务目标打分。
- 评定 Confidence：根据数据支撑程度赋值百分比（20%/50%/80%/100%）。
- 计算 Effort：由开发团队估算人月数，精确到 0.5 人月。
- 计算并排序：代入公式求得 RICE 分数，按降序排列输出优先级列表。
操作禁忌：不要在步骤 2–5 中互相参考数值，避免“打分趋同”导致区分度失效。每个要素应独立评估后再汇总。
1.4 输入输出物
| 类型 | 名称 | 格式/载体 | 说明 |
|---|---|---|---|
| 输入物 | 功能待办列表 | Excel / 项目管理工具 | 包含功能名称、描述、提出人、提出日期 |
| 输入物 | 用户数据报告 | PDF / 数据看板 | DAU/MAU、留存率、功能使用率等 |
| 输出物 | RICE 评分排序表 | Excel / 在线表格 | 含四要素值、分数、优先级排名 |
| 输出物 | 原型范围决策报告 | PDF / 幻灯片 | 含评分依据、排序结果、入选功能清单 |
1.5 责任边界
- 产品经理：负责组织评分会议、定义功能清单、录入 Reach 和 Impact 初值，并对最终排序结果负责。
- 设计师：参与 Impact 评估，从用户体验视角提出调整建议。
- 开发工程师：独立估算 Effort，对工作量准确性负责。
- 数据分析师：提供 Reach 和 Confidence 所需的历史数据与置信区间。
- 决策者（总监/VP）：审核评分结果，对争议项行使最终裁决权。
责任隔离原则：Effort 估算者不参与 Impact 打分，避免工作量大小影响价值判断；Confidence 评定者需披露数据来源，接受团队质询。
1.6 记录材料
团队需维护以下记录材料，作为评分过程的可追溯依据：
- RICE 评分原始记录表：包含每个功能的四要素原始值、计算公式中间结果、最终分数。
- 评分会议纪要：记录争议点、数据来源引用、最终裁定理由。
- 版本历史：每次评分日期、参与人、功能列表版本号。
评分原始记录表示例（模板结构）：
| 功能ID | 功能名称 | Reach (月用户) | Impact (1-5) | Confidence (%) | Effort (人月) | RICE Score | 优先级排名 |
|--------|----------|----------------|--------------|----------------|---------------|------------|------------|
| F01 | 一键登录 | 12000 | 4 | 80 | 2.0 | 19200 | 1 |
| F02 | 智能搜索 | 8000 | 3 | 60 | 3.5 | 4114 | 3 |
| F03 | 消息推送 | 15000 | 2 | 50 | 1.5 | 10000 | 2 |1.7 异常处理
| 异常类型 | 典型表现 | 处理措施 |
|---|---|---|
| 数据缺失 | Reach 或 Confidence 无法从现有数据中获取 | 采用保守估算（如 Reach 取同类功能最小值，Confidence 默认 20%），并在记录中标注“低置信度” |
| 评分冲突 | 同一功能不同角色给出的 Impact 或 Effort 差异大于 2 分（或 2 倍） | 召开 15 分钟快速对齐会议，引用外部基准或历史类比数据消除分歧 |
| Effort 为 0 | 某功能被估算为“零工作量”（如仅配置开关） | 最小 Effort 值设为 0.5 人天，避免分母为零导致分数无穷大 |
| 分数极端偏高 | 某个功能 RICE Score 是第二名的 10 倍以上 | 重新核查 Reach 是否误用年数据代替月数据，Impact 是否超出 1–5 范围 |
异常上报规则：任何异常必须在评分记录表的“备注”列中写明原因与处理方式，不得私自调整分数掩盖异常。
1.8 验收标准
本章 RICE 评分法概述的落地效果，以下列验收标准衡量：
- 完整性：每个待评功能均已填写 Reach、Impact、Confidence、Effort 四项原始值，无缺失项。
- 一致性：同一团队内，Impact 1–5 分的定义理解一致（如“3分=中等影响，显著提升核心指标”）。
- 可复现：任意团队成员使用相同原始数据代入公式，得到的 RICE Score 完全一致。
- 区分度：评分结果中不存在超过 3 个功能并列相同分数的情况（若出现需重新校准 Confidence 或 Impact）。
- 可追溯：每项评分均能追溯到数据来源或评估依据，记录材料完整存档。
验收自查：在进入第 2 章实战案例前，请确保团队已完成一次模拟评分演练，并对照上述 5 条标准逐项自检通过。