1. RICE评分法概述：定义、核心四要素、适用场景
1.1 定义
RICE评分法是一种基于多维度的产品需求优先级量化排序模型，由产品管理社区提出并广泛验证。该方法将每个需求抽象为四个可量化因子——Reach（覆盖度）、Impact（影响力）、Confidence（信心度）和Effort（工作量），并通过统一的算术公式计算出优先级分数，帮助团队从“主观争论”转向“客观比较”。
核心公式： RICE Score = (Reach × Impact × Confidence) / Effort
1.2 核心四要素
| 要素 | 含义 | 典型评分范围 | 数据来源 |
|---|---|---|---|
| Reach | 该需求在单位周期内能触达的目标用户数（或交易笔数/会话数等） | 0.25 ~ 10（分段赋值） | 用户数据分析、市场调研、历史流量 |
| Impact | 需求上线后对核心业务指标（转化率、留存、收入等）的期望提升幅度 | 0.25 ~ 3（按高/中/低定性） | 实验经验、历史A/B测试、行业基准 |
| Confidence | 团队对 Reach 和 Impact 估算的把握程度，反映数据支撑强度 | 20% ~ 100%（或0.2~1.0） | 数据覆盖率、实验次数、领域专家判断 |
| Effort | 整个团队（含设计、开发、测试、运营）完成该需求所需的总人时或理想人天 | 以人月或人天为单位（正数，需归一化） | 技术方案评估、历史工时数据 |
实操贴士：建议为每个要素设计 离散等级表（如 Reach: 0.25/1/2/5/10），避免因连续数值导致评分波动过大。Confidence 不要直接使用百分比原始值，而是先按数据置信度分档（高=1.0，中=0.8，低=0.5），再与 Reach×Impact 的乘积相乘。
1.3 适用场景
RICE 评分法最适合以下三类产品决策上下文：
- 中期路线图规划（季度或半年）——需要对数十个候选需求进行通盘比较，排出建设顺序。
- 迭代排期争议调解——当多个业务方各自强调自身需求紧急时，用统一标尺降低向上博弈成本。
- 创新项目入池筛选——在零散创意中识别投入产出比最优的早期验证项。
注意：RICE 不适用于以下场景：
· 法律合规类需求（必须优先，无法量化替代）；
· 纯技术重构需求（通常 Impact 难以直接度量，需改用成本/风险模型）；
· 需跨季度建设的巨型需求（RICE 默认按一次性交付评估，若分阶段应拆分后独立评分）。
· 法律合规类需求（必须优先，无法量化替代）；
· 纯技术重构需求（通常 Impact 难以直接度量，需改用成本/风险模型）；
· 需跨季度建设的巨型需求（RICE 默认按一次性交付评估，若分阶段应拆分后独立评分）。
1.4 RICE 评分流程（SOP 步骤）
以下流程适用于每周或每双周的需求评审会，由产品经理主导、核心研发与测试参与。
| 步骤 | 操作内容 | 负责人 | 所需时间 |
|---|---|---|---|
| 1 | 准备候选需求列表（每项需包含一句话描述、预期用户受益描述） | 产品经理 | 30 min |
| 2 | 逐项评估 Reach：根据目标用户群规模赋分（查表或内插） | 产品经理 + 数据分析师 | 5 min/项 |
| 3 | 逐项评估 Impact：按高（3）、中（1.5）、低（0.5）定性 | 产品经理 + 业务方 | 3 min/项 |
| 4 | 逐项评估 Confidence：根据数据来源可靠性赋分（高=1.0，中=0.8，低=0.5） | 产品经理 + 数据团队 | 2 min/项 |
| 5 | 评估 Effort：由技术负责人汇总后端、前端、QA 工时并归一化 | 技术负责人 | 10 min/项 |
| 6 | 计算 RICE Score = (Reach × Impact × Confidence) / Effort，并按分数从高到低排列 | 产品经理 | 2 min/项 |
| 7 | 结果评审：团队对 Top 5 进行讨论，确认排序合理性 | 所有参会角色 | 15 min |
关键： Confidence 不应分配过细，建议只设三档；Effort 单位统一后需做一次通货膨胀处理（如全部换算为“人天”），否则会导致工作量差异被放大或缩小。
1.5 前置条件
- 已建立标准化的 需求池记录格式（至少包含需求标题、描述、提出方、预期收益承诺）。
- 团队已就 Reach/Impact/Confidence 的等级映射表达成共识（建议提前在一页纸看板上公示）。
- 至少完成过一次 培训演练（可在 1 小时内对 3~5 个需求进行模拟评分）。
1.6 输入输出物
| 类型 | 内容 | 格式要求 |
|---|---|---|
| 输入 | 候选需求列表（含需求 ID、描述、预期受益） | Excel 或在线多维表格 |
| 输入 | 用户规模数据（DAU/MAU 或同类指标） | SQL 查询结果或数据报表截图 |
| 输入 | 工时估算记录（来自技术可行性评估） | Jira / 飞书任务中的工时字段 |
| 输出 | RICE 优先级排序表（含各因子分值、总得分、排序序号） | 将输入表扩展 4 列，并锁定表头 |
| 输出 | 评分偏差记录（Confidence 低于 0.5 的需求需单独 flag） | 在排序表中增加“置信度不足”标注 |
1.7 责任边界
- 产品经理：负责发起评分会、组织讨论、维护等级映射表、输出最终排序表。
- 数据分析师：负责 Reach 数值的精确计算（含用户分层统计）及 Confidence 的数据来源佐证。
- 技术负责人：负责 Effort 估算（含前后端+测试）并签字确认。
- 业务方/运营：负责 Impact 定性打分，需在评审会上口头陈述理由。
1.8 记录材料
每次评分结束后需归档以下材料：
- 带有所有原始打分数据的 RICE 排序表（不可事后修改）。
- 评分会议纪要（含争议点及最终结论）。
- Confidence 低于 0.5 的需求的补数计划（例如：先做小规模 AB 测试再重新评分）。
1.9 异常处理
| 异常场景 | 处理方式 | 降级方案 |
|---|---|---|
| Reach 无直接数据（全新功能类） | 使用最小可覆盖用户量（如灰度 5% 的用户数）作为保守估值 | 先按 Reach=1 计算，待灰度数据出来后刷新 |
| Effort 估算差距大（前后端意见不统一） | 采用“三点估算”法（乐观/最可能/悲观），取加权平均值 | 取最大值作为 Effort，避免低估复杂度 |
| 多个需求得分极接近（差值 < 5%） | 引入“Weighted KANO”作为二级排序因子（见后续章节） | 由评审会投票二次排序 |
| Confidence 低于 0.3 | 将该需求标记为“实验性质”，不进入常规排期，放入专门创新队列 | 分配 20% 的迭代容量进行探索性开发 |
1.10 验收标准
- 输出表中所有需求的 RICE 分数计算完全正确（可用随机抽检 5 项人工复核）。
- 所有参与角色在评分表上签字或 im 确认，表示接受排序结果。
- 排序结果与业务直觉对比：Top 3 需求中至少有 2 个符合业务方“最想先做”的预期，否则需组织回溯会议优化等级映射表。
1.11 RICE 评分流程总图
重要提醒：本流程图仅为标准操作顺序。在实际评分中，Reach、Impact、Confidence 可并行评估以缩短会议时长；Effort 通常需在会后单独收集技术估算，再填入计算环节。切勿在会议现场让技术人员当场估算全部需求，以免干扰数据质量。