1. RICE 对齐概述
RICE 对齐是产品团队在需求优先级决策中，基于触达（Reach）、影响（Impact）、信心（Confidence）、投入（Effort）四要素建立统一评分标准，使产品经理、设计师、开发三方对需求优先级达成共识的协作框架。本章定义 RICE 对齐的核心概念、适用场景和团队分工，为后续章节的评分操作和争议处理奠定基础。
适用场景
| 场景 |
说明 |
典型示例 |
| 跨职能优先级对齐 |
PM、设计、开发对需求优先级存在分歧，需要统一标准 |
版本规划会议、季度路线图评审 |
| 资源有限决策 |
人力或时间资源受限，需从多个需求中选出最优投入方向 |
季度资源分配、冲刺规划 |
| 数据驱动评估 |
需要量化指标辅助决策，减少主观判断偏差 |
功能上线后效果评估、需求池筛选 |
前置条件
- 团队已收集待评估的需求列表（至少 3～5 项）
- 产品经理、设计师、开发对 RICE 框架有基本认知
- 已有明确的评估目标（如确定下个迭代的 3 个核心需求）
- 准备好统一的评分模板或记录工具
RICE 四要素定义
| 要素 |
英文 |
定义 |
评估维度 |
| 触达 |
Reach |
功能在特定时间内能触达的用户数量或比例 |
用户量、使用频次、覆盖范围 |
| 影响 |
Impact |
对用户或业务产生的预期影响程度 |
转化率、满意度、业务收益 |
| 信心 |
Confidence |
对触达和影响评估的信心程度 |
数据来源可靠性、经验验证 |
| 投入 |
Effort |
实现该功能所需的开发/设计总投入 |
人天、复杂度、依赖项 |
要点：四要素的评分范围建议统一为 1～5 分（整数），便于横向比较。后续章节会给出各要素的评分锚点示例。
操作步骤
- 组建对齐团队 — 确认参与角色：产品经理（主持）、设计师、开发代表，至少 3 人。
- 定义要素标准 — 团队共同确认 Reach、Impact、Confidence、Effort 的评分范围和参考锚点（如 1～5 分）。
- 设定对齐目标 — 明确本次对齐要达成的共识（例如：确定下个迭代的 3 个需求）。
- 识别适用场景 — 从需求池中筛选出需要 RICE 评分的需求，排除明显不适用项。
- 分配角色责任 — 各角色明确在评分中的职责边界（详见责任边界表）。
输入 / 输出物
| 类型 |
内容 |
来源 / 去向 |
| 输入 |
需求列表、产品路线图、历史评分数据（如有） |
产品经理整理提供 |
| 输出 |
RICE 评分表（含四要素分值）、对齐会议纪要 |
团队共享文档 / Wiki |
责任边界
| 角色 |
核心责任 |
评分侧重 |
| 产品经理 |
定义 RICE 标准，组织对齐会议，汇总评分结果 |
Reach（市场触达）、Impact（业务价值） |
| 设计师 |
评估用户体验维度的影响与信心 |
Impact（体验提升）、Confidence（用户验证） |
| 开发工程师 |
评估技术实现难度、工时与风险 |
Effort（人天/复杂度）、Confidence（技术可行性） |
记录材料
- RICE 评分模板 — Excel 或在线表格，包含需求名称、四要素分值、总分、备注列。
- 对齐会议记录模板 — 包含日期、参与角色、评分结果、争议点、最终共识。
- 历史评分库 — 已评需求的归档，用于后续参考和信心校准。
实践建议：首次实施 RICE 对齐时，建议先用 3～5 个简单需求做演练，让团队熟悉评分节奏后再处理复杂度高的需求。
异常处理
| 异常场景 |
处理方式 |
| 团队对 RICE 要素理解不一致 |
由 PM 统一解读定义，给出 1～2 个示例需求作为参考 |
| 数据缺失无法评分 |
标记为“低信心”，设定默认值（如 2 分），后续补充数据后再调整 |
| 同一需求各角色评分差异过大（分差 ≥ 3） |
进入“争议讨论”环节，各自陈述依据，重新评分或取平均 |
| 角色缺席导致评分不完整 |
缺席角色提前给出书面评分，或委托同职能代表参与 |
验收标准
- 所有待评估需求已完成 RICE 四要素评分，并记录在统一模板中。
- 产品经理、设计师、开发三方对评分标准理解一致，无原则性分歧。
- 对齐会议形成可追溯的书面纪要，包含评分结果和争议处理记录。
- 各角色已确认自己的责任边界，并承诺在后续迭代中按此标准执行。
注意：RICE 对齐不是一次性活动。当市场环境、用户数据或团队能力发生变化时，应及时复盘并调整评分标准，保持框架的时效性。