💡 核心公式：
RICE 分数 = (Reach × Impact × Confidence) / Effort
分数越高，优先级越高。此分值仅用于相对排序，并非绝对价值衡量。
#### 1.2 四要素定义
| 要素 | 英文 | 定义与核心问题 | 典型单位 / 度量方式 |
| :--- | :--- | :--- | :--- |
| R | Reach | 在特定时间窗口内（通常是每季度），该功能预计能触达多少用户？ | 用户数 / 事件数 / 会话数 |
| I | Impact | 该功能对用户成功或核心业务指标的提升效果如何？ | 数值型（如转化率提升%）或（1~3档) |
| C | Confidence | 你对 Reach 和 Impact 的估算有多大把握？是否有数据或研究支撑？ | 百分比（20%~100%）或(低/中/高) |
| E | Effort | 整个团队（产品、设计、研发、测试、部署）完成该项目所需的总人周/人月是多少？ | 人·周（Person-Weeks） |
- **Reach**：通常以“季度内独立用户数”计。若上线后预计影响1000名用户，则 Reach = 1000。
- **Impact**：避免使用模糊的“大/中/小”。建议锚定具体业务指标，如“提升注册转化率5%”。若只能定性，建议设档位：3倍=“巨大”，1倍=“高”，0.5倍=“中”，0.25倍=“低”。
- **Confidence**：严格区分数据驱动与主观判断。
- 100%：有明确 A/B 测试或历史数据支撑。
- 80%：有用户调研、原型测试或强相关数据推导。
- 50%：仅凭个人经验或坊间传闻。
- 20%：纯粹的“猜测”。
- **Effort**：包含所有相关人员的工作量。一个6人团队开发3周，Effort = 6 × 3 = 18 人周。
RICE 分数 = (Reach × Impact × Confidence) / Effort
分数越高，优先级越高。此分值仅用于相对排序，并非绝对价值衡量。
⚠️ 常见误区：忽略 Effort 的团队协同成本（如沟通、代码审查、上线沟通会），导致 Effort 被严重低估，使得大项目“看起来”比实际上更优先。
#### 1.3 适用场景与前置条件
**适用场景**
| 场景类型 | 说明 | 示例 |
| :--- | :--- | :--- |
| 功能提案排序 | 多个新功能等待排期，需统一打分排序。 | 支付模块、用户画像、消息推送分别得45、30、60分，优先做60分的消息推送。 |
| 增量优化决策 | 对已有功能进行性能/体验优化，判断 ROI。 | 优化支付成功率 vs. 优化页面加载速度，选 RICE 分数高的。 |
| 产品路线图规划 | 季度或年度规划时，筛选并分配资源。 | 将高优先级的项目放入路线图前半部分。 |
| 需求池清理 | 大量积压需求需批量评估并剔除低价值项。 | 评分低于特定阈值（如10分）的需求被标注为“不优先”或冻结。 |
**前置条件**
在尝试使用 RICE 框架之前，团队需满足以下条件，否则框架会沦为形式主义：
1. **有可用于估算 Reach/Impact 的基础数据**：如 GA/友盟/自建的站内用户统计、业务指标看板。若完全无历史数据，Confidence 普遍低于50%，结果仅供参考。
2. **团队可对 Effort 进行粗略估算**：开发团队愿意给出人周、人月级别的估算，而非“这个嘛，看情况……”式的模糊承诺。
3. **所有参与者理解评分含义**：正式打分前需进行5~10分钟共识对齐，避免有人把“信心度”全部填成100%，而有人只填20%。
4. **决策边界清晰**：该评分结果仅是“推荐顺序”，并非最终执行命令。仍需结合战略目标、外部约束（如合作伙伴要求、合规期限）做最终判断。
✅ 前置条件检查清单
#### 1.4 操作步骤（第一章节预演）
本章仅进行框架认知。具体打分步骤将在第2~5章详细展开。以下为宏观流程：
1. **填写要素**：对每一个待办项，填写 Reach、Impact、Confidence、Effort。
2. **计算分数**：应用公式 (R × I × C) / E。
3. **排序**：按照分数从高到低排列。
4. **决策裁决**：结合战略/风险/机会窗口，对排序结果做人工调整。
#### 1.5 输入输出物 & 责任边界
- **输入物**：
- 产品需求池清单（Excel/ Trello / Jira）
- 历史用户行为数据报告（PDF 或 BI 系统截图）
- 团队交付能力评估（上季度项目准时交付率、团队容量）
- **输出物**：
- RICE 评分表（带公式的表格，推荐 Google Sheets / Airtable）
- 优先级排序结果（前 5 项进入待开发列）
- **责任边界**：
- **产品经理**：提供 Reach/Impact 估算及 Confidence 评估，组织评审。
- **技术负责人**：提供 Effort 估算。
- **数据/分析师**：提供 Reach/Impact 定量参考数据。
- **决策者/VP**：基于 RICE 排序结果进行最终确认或否决。
#### 1.6 RICE 四要素关系流程图
#### 1.7 记录材料
- **RICE 评分模板表**：建议建立包含以下列的表格（每行一个功能项）。
| 功能名称 | Reach (用户数) | Impact (倍数) | Confidence (%) | Effort (人周) | RICE 分数 | 优先级 |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| 示例：支付优化 | 5000 | 2 | 80 | 4 | 2000 | 高 |
| 示例：注册流程 | 10000 | 3 | 50 | 8 | 1875 | 中 |
| 示例：性能优化 | 2000 | 1 | 70 | 2 | 700 | 低 |
- **打分记录存档路径**：`/Shared Drive/RICE_Scores/Q4_2024/`
#### 1.8 异常处理
- **现象**：有团队成员对所有 Confidence 都填 80%~100%，导致评分趋同。
- **处理**：团队评审时强制要求：若无 A/B 测试或用户访谈数据支撑，Confidence 最高 50%。上线前指定数据负责人提供对标参考值。
- **现象**：Effort 估算出现“好高骛远”（都估得太小）或“过度悲观”（都估得太大）。
- **处理**：基于上季度同类型项目的实际人周偏差值，对估算进行校准。例如，上季度平均实际耗时是估算的1.3倍，则本次 Effort 需乘以1.3的膨胀系数。
- **现象**：排序后，某个“战略级”功能排名靠后，但老板坚持必须上。
- **处理**：在最终决策时允许保留“例外通道”，但需记录该理由（如“业务合规要求Q2必须上线支付分”、“与某大厂合作框架协议强制包含此功能”）。RICE结果留存备查，作为复盘时评估置信度偏差的参考。
#### 1.9 验收标准
第1章学习完成后，应能：
1. 准确复述 RICE 四要素及其含义。
2. 能够识别一个需求项是否适合用 RICE 进行优先级排序（判断适用场景）。
3. 能够列举出使用 RICE 前必须满足的3个前置条件。
4. 能够说明 RICE 得分中 Confidence 置信度的不同档位依据。
- 是否有数据源：用户数、转化率、留存率等核心指标的统计口径和近3个月数据可用。
- 是否有估算能力：技术团队是否能在1小时内给出“粗略人周”估算？
- 是否有评审小组：产品、设计、开发负责人是否每周有固定时间段参与优先级评审？
- 是否有决策容忍度：高层是否接受“数据驱动”的顺序，而非“谁喊得响谁先做”？