1. RICE 框架总览：四要素定义、权重逻辑、适用场景与常见误区
RICE 是产品需求优先级排序中最实用的量化模型之一。它将每个需求拆解为 Reach（触达人数）、Impact（影响程度）、Confidence（信心指数）、Effort（投入成本）四个维度，通过公式 RICE Score = (Reach × Impact × Confidence) / Effort 得出可横向对比的优先级分数。本章从用户场景与业务问题出发，讲透每项要素的衡量逻辑及常见陷阱。
1.1 四要素定义与衡量基准
| 要素 | 定义 | 典型衡量单位 / 经验值 | 对应业务问题 |
|---|---|---|---|
| Reach | 在一个时间窗口内（通常为 3 个月），该功能预计能触达的用户数 | 活跃用户数 / 独立访客数 | 有多少人会用？对用户池拉动有多大？ |
| Impact | 该功能对单个用户目标的达成贡献度 | 3（大规模）、2（高）、1（中）、0.5（低） | 用完后用户留存/转化是否会显著提升？ |
| Confidence | 你对 Reach 和 Impact 估算的把握程度 | 100%（有数据/实验）、80%（有强证据）、50%（有弱证据）、20%（猜测） | 你现在有多少用户访谈数据或数据指标支撑这个判断？ |
| Effort | 整个团队（产品、设计、开发、测试）需要投入的人·月数 | 人·月 或 人·周 | 这件事值不值得团队花这么多工期去做？ |
👤 访谈对齐建议： 在用户访谈中单独询问“你每周/每月做这个操作的频率”可直接校准 Reach；通过“如果去掉这个功能你会不会觉得很难受”来侧面判断 Impact。不要仅看日活总量，要关注目标用户群。
1.2 权重逻辑：乘法结构带来的排序效果
RICE 的乘法结构天然放大了“高影响 + 有信心 + 低投入”的需求，同时压制了“不确定、长周期”的提议。权重本身不人为分配系数，而是靠四个维度的乘积和除法形成排序斜率。
- 高 Reach × 高 Impact → 分数大幅提升：用于核心功能优化，例如支付链路成功率。
- 低 Confidence 自动拉低分数：即使 Reach 和 Impact 很高，若只是猜测，分数会比有数据支撑的方案低一个量级。
- Effort 在分母上做除法：两个方案分数相同时，更小的 Effort 将胜出，避免长周期项目长期占据队列顶部。
⚙️ 方案表达示例：
需求 A：Reach=5000, Impact=2, Confidence=80%, Effort=3 → 分数 = (5000×2×0.8)/3 ≈ 2667
需求 B：Reach=2000, Impact=3, Confidence=50%, Effort=2 → 分数 = (2000×3×0.5)/2 = 1500
→ 需求 A 优先，尽管 A 的 Impact 更低，但 Reach 和 Confidence 更高。
需求 A：Reach=5000, Impact=2, Confidence=80%, Effort=3 → 分数 = (5000×2×0.8)/3 ≈ 2667
需求 B：Reach=2000, Impact=3, Confidence=50%, Effort=2 → 分数 = (2000×3×0.5)/2 = 1500
→ 需求 A 优先，尽管 A 的 Impact 更低，但 Reach 和 Confidence 更高。
1.3 适用场景
RICE 最适合 已有一定用户基数 的产品阶段，此时 Reach 和 Effort 可被相对精确估算。若处于 0-1 探索期，Confidence 普遍偏低，建议结合用户故事映射先定性验证假设，再套用 RICE。
- 适合：B2C 增长功能排序、SaaS 后台功能迭代、跨功能组件的资源争夺。
- 不适合：纯创新/探索型需求（缺少数据基准）、政治因素或战略必须项（不可替代）。
1.4 常见误区
⚠️ 误区 1：把“用户数量”直接当成 Reach
Reach 必须是 真实会在该场景下操作的用户，而不是产品总用户数。例如“让所有注册用户都能导出报告”的 Reach ≠ 总注册数，而应是每月至少导出一次的实际用户数。
⚠️ 误区 2：Impact 数值凭感觉拍脑袋
使用 Impact 标准量表时，需要结合用户访谈或历史实验数据来校准。如果团队对“3 分”的理解差异很大，应通过用户故事映射中的具体场景达成共识。
⚠️ 误区 3：Effort 只估算开发时间
Effort 必须包含设计、测试、上线验证、文档、AB 实验配置的完整链条。遗漏任意环节都会导致分数虚高，最终排期失控。
Reach 必须是 真实会在该场景下操作的用户，而不是产品总用户数。例如“让所有注册用户都能导出报告”的 Reach ≠ 总注册数，而应是每月至少导出一次的实际用户数。
⚠️ 误区 2：Impact 数值凭感觉拍脑袋
使用 Impact 标准量表时，需要结合用户访谈或历史实验数据来校准。如果团队对“3 分”的理解差异很大，应通过用户故事映射中的具体场景达成共识。
⚠️ 误区 3：Effort 只估算开发时间
Effort 必须包含设计、测试、上线验证、文档、AB 实验配置的完整链条。遗漏任意环节都会导致分数虚高，最终排期失控。