1. 理解RICE评分框架：四维度定义、权重作用、核心价值
本章定位：RICE是产品团队在MVP阶段筛选功能/需求的经典量化工具。掌握四维度含义、权重计算逻辑及框架设计初衷，是后续所有实战操作的理论基础。
适用场景
- 团队有多个功能候选，需要依据数据而非直觉排序MVP范围
- 产品经理、项目经理、创业团队在资源有限时做优先级决策
- 需求评审会、迭代规划会、Sprint开始前对候选功能进行量化评估
- 希望统一团队对“价值”和“成本”的认知语言，避免主观争论
前置条件
| 条件项 | 说明 |
|---|---|
| 基础知识 | 理解MVP（最小可行产品）概念，熟悉功能列表管理（如Backlog） |
| 数据准备 | 至少对候选功能有粗略的用户量、开发日、信心依据（历史数据或调研） |
| 工具状态 | 无需特定软件，可使用电子表格或白板；本章提供理论框架 |
| 组织角色 | 至少一位具备产品决策权的PM参与，建议包含开发TL、设计师共同学习 |
操作步骤（理解框架的核心流程）
- 认识四维度：分别掌握Reach、Impact、Confidence、Effort的量化定义与单位
- 理解权重作用：通过
RICE Score = (Reach × Impact × Confidence) / Effort理解乘除关系——Reach、Impact、Confidence是乘积放大，Effort是分母衰减 - 把握核心价值：将主观判断转化为可重复、可比较的数值，消除“功能之争”，聚焦“用户价值与开发成本的最优比”
权重作用速记：Reach和Impact决定了“总收益”，Confidence是“我们对收益的把握程度”，Effort是“完成它要花多少人力天数”。RICE不是数学真理，而是一种决策共识工具。
输入/输出物
| 输入物 | 输出物 |
|---|---|
| 候选功能列表（至少3个以上） 用户行为数据/估算 团队经验与历史记录 | RICE四维度理解笔记 框架应用原则备忘录 （本章不产生具体评分，只产出认知框架） |
责任边界
- 产品经理：主导框架导入，解释四维度含义，确保团队对定义理解一致
- 开发/设计：配合提供Effort估算依据，指出Confidence中技术风险点
- 决策负责人：确认权重使用策略（如是否要加自定义权重？本章不涉及，但需知晓默认权重为1:1:1:1）
记录材料
建议创建一份RICE共性知识文档，包含：
- 四维度官方定义（来自Intercom原始RICE框架）
- 团队自定义的单位换算表（例如Reach采用“月活跃用户数”，Impact采用“类别：1/2/3倍”等）
- 本章的
RICE Score公式与避坑指引
# RICE Score 标准公式（供参考）
RICE_Score = (Reach * Impact * Confidence) / Effort
# 示例（假设一个功能）
Reach = 2000 (用户/月)
Impact = 2 (分类系数：2表示“显著提升核心指标”)
Confidence = 0.8 (80%把握)
Effort = 5 (人天)
# Score = (2000 * 2 * 0.8) / 5 = 640异常处理
- 问题：四维度数值范围不统一 → 统一采用1-10或1-5整数标度，或像Impact使用
0.5/1/2/3乘数，避免混用 - 问题：Confidence无法量化 → 用
1（完全信息）、0.5（部分信息）、0.1（纯猜测）三个档位 - 问题：团队对Impact和Reach的“重要性”争执 → 确认RICE采用乘法而非加法，两者同等重要；若仍无法达成，可引入加权系数（但超出本章范围）
验收标准
- 能用一句话分别解释四维度含义（例如：Reach = 功能影响多少独立用户）
- 能写出正确公式并说明为什么Effort是分母
- 能识别出RICE不适合“定性优先”或“高层战略必须”的场景
- 完成一份本章的框架学习自检清单，包含维度、权重、核心价值三项
初始常见误解：RICE不是“打分越高功能越重要就一定要做”——它只反映“每单位成本带来的预期用户价值”。战略功能（如登录注册）可能RICE得分低但必须做，RICE应在“可选功能池”中使用。