RICE四维拆解：Reach、Impact、Confidence、Effort 定义
本章节聚焦 RICE 模型四个核心维度的标准化定义，确保团队在量化评分前对每个维度的内涵、衡量方式和评分基准达成统一认知。准确的维度定义是后续评分可靠性的基石，也是跨职能协作的“共同语言”。
适用场景
- 团队首次引入 RICE 模型进行需求优先级评分，需要建立统一的维度理解
- 现有评分体系存在维度定义模糊、评分口径不一致的问题，需要重新校准
- 跨职能团队（产品、技术、设计、运营）协作评审前，需对齐各维度认知
- 产品需求池中批量功能/需求的初步筛选与排序，需要标准化定义框架
- 季度/版本迭代规划前的集中需求评估会议，需提前统一评分语言
前置条件
- 已完成产品待办需求（Product Backlog）的初步梳理，形成待评估清单
- 团队核心成员（产品经理、技术负责人、数据分析师）已了解 RICE 模型的基本概念
- 已明确评估的时间窗口（如月度活跃周期、季度规划周期）
- 已确定评估范围（全部需求或特定分类需求），避免范围漂移
- 具备维度的基础数据支撑（如用户量级数据、历史工时数据、转化率基线）
操作步骤
步骤一：定义 Reach（覆盖范围）
Reach 衡量在特定时间窗口内，受该功能/需求影响的独立用户数量。评估的是“广度”而非“深度”。
- 核心问题：该功能在评估周期内能触达多少独立用户？
- 衡量指标：独立用户数（UV）、日活跃用户（DAU）、月活跃用户（MAU）、目标用户群规模
- 评分参考（1-10 分）：1-2 分（极小众，如 <1% 用户）、3-4 分（小众，1%-5%）、5-6 分（中等，5%-15%）、7-8 分（大众，15%-30%）、9-10 分（广泛，>30%）
- 注意事项：只计算“直接触达”的用户量，不叠加“间接受益”用户；需与时间窗口绑定声明
步骤二：定义 Impact（影响程度）
Impact 衡量功能/需求对用户行为或业务指标产生的影响深度。评估的是“强度”而非“广度”。
- 核心问题：该功能对用户或业务的核心指标提升有多大？
- 衡量指标：转化率提升、留存率提升、客单价提升、NPS 提升、任务完成率提升
- 评分参考（1-10 分）：1-2 分（微小影响，<1% 提升）、3-4 分（轻度影响，1%-5%）、5-6 分（中度影响，5%-15%）、7-8 分（显著影响，15%-30%）、9-10 分（颠覆性影响，>30%）
- 注意事项：优先评估“直接影响”，间接影响可做辅助说明但不计入核心评分；需与基线数据对比
步骤三：定义 Confidence（置信度）
Confidence 衡量团队对 Reach 和 Impact 评估结果的信心程度。反映的是“证据强度”而非“主观意愿”。
- 核心问题：我们有多大把握确定 Reach 和 Impact 的评估是准确的？
- 衡量依据：数据支撑程度（如 A/B 测试、用户调研、历史数据）、经验匹配度、外部验证结论
- 评分参考（1-10 分）：1-2 分（纯推测，无数据）、3-4 分（弱佐证，有间接数据）、5-6 分（中等，有部分直接数据）、7-8 分（强证据，有直接数据或实验结论）、9-10 分（高置信度，有权威验证或大规模数据）
- 注意事项：避免“过度自信”与“过度保守”，依据客观证据而非主观感觉；Confidence 应独立于 Reach 和 Impact 的数值大小
步骤四：定义 Effort（投入成本）
Effort 衡量完成该功能/需求所需的总资源投入。在 RICE 公式中为分母，评分越高代表成本越高。
- 核心问题：完成该功能需要投入多少人力、时间和资源？
- 衡量指标：人天 / 人月、开发工时、依赖资源数量、跨团队协作成本、维护成本
- 评分参考（1-10 分，注意方向：分值越高成本越高）：1-2 分（极小投入，<2 人天）、3-4 分（小投入，2-5 人天）、5-6 分（中等，5-15 人天）、7-8 分（大投入，15-30 人天）、9-10 分（极大投入，>30 人天或跨季度）
- 注意事项：需包含开发、测试、部署、文档、沟通全链路成本；注意 Effort 是成本分，在公式中做分母，高 Effort 会降低 RICE 总分
维度定义校准建议：团队在首次定义四维时，建议选取 3-5 个典型需求进行“预评分”演练，通过讨论对齐每个维度的评分尺度，避免后续出现系统性偏差。预评分结果不计入最终决策，仅用于校准标准。
维度定义总览
| 维度 | 英文 | 核心定义 | 典型指标 | 评分方向 |
|---|---|---|---|---|
| 覆盖范围 | Reach | 特定时间内影响的独立用户数 | UV / DAU / MAU / 目标用户群占比 | 越高越好（分子） |
| 影响程度 | Impact | 对用户行为或业务指标的影响深度 | 转化率 / 留存率 / NPS / 客单价提升 | 越高越好（分子） |
| 置信度 | Confidence | 对 Reach 和 Impact 评估结果的信心程度 | 数据支撑度 / 验证成熟度 / 经验匹配度 | 越高越好（分子） |
| 投入成本 | Effort | 完成功能所需的总资源投入 | 人天 / 工时 / 跨团队依赖数 / 维护成本 | 越低越好（分母） |
输入输出物
| 类型 | 名称 | 内容说明 | 责任方 |
|---|---|---|---|
| 输入 | 产品需求列表 | 待评估的功能/需求清单，包含需求编号、名称、概述 | 产品经理 |
| 输入 | 用户数据与业务基线 | 月度活跃用户量、转化率基线、历史工时数据等 | 数据分析师 |
| 输出 | RICE 四维定义标准文档 | 包含各维度定义、核心指标、评分对照表、使用规范 | 产品负责人 |
| 输出 | 维度预评分校准记录 | 3-5 个典型需求的预评分结果与讨论纪要 | 产品经理 + 团队 |
责任边界
| 角色 | 职责范围 | 关键交付 |
|---|---|---|
| 产品经理 | 主导 Reach 与 Impact 的定义与评分，输出需求背景与用户场景 | Reach 评分表、Impact 评分表 |
| 技术负责人 | 主导 Effort 的定义与评估，提供开发工时及资源依赖清单 | Effort 评分表、技术依赖清单 |
| 数据分析师 | 提供 Confidence 所需的数据支撑，审核 Reach/Impact 的数据合理性 | 数据可信度评估报告、Confidence 建议值 |
| 产品负责人 | 审核四维定义的合理性与一致性，裁定跨角色争议 | 维度定义终审签批、争议裁决记录 |
记录材料
- RICE 四维定义标准卡（一页纸）—— 每个维度的定义、核心指标、评分示例、常见误区
- 维度评分对照表 —— 1-10 分各档位的详细描述与参考案例
- 预评分校准纪要 —— 记录预评分讨论中暴露的分歧与最终校准结论
- 维度定义问答清单 —— 团队在定义过程中常见的模糊问题及其官方回答
异常处理
| 异常情况 | 处理方式 | 升级路径 |
|---|---|---|
| 维度定义存在跨角色争议 | 召开 30 分钟专项对齐会，由产品负责人主持，以数据事实为裁决依据 | 产品负责人终审 |
| 数据不足无法定义 Confidence | 标记为“低置信度”，按保守评分（≤3 分）处理，同步启动数据采集计划 | 数据分析师补充数据后复审 |
| Effort 评估范围不明确 | 使用“最小可行路径”原则，先评估核心路径成本，后续迭代补充 | 技术负责人确认范围边界 |
| 需求跨模块/跨团队依赖复杂 | 拆分为独立子需求分别评分，最终按加权或最高原则合并 | 产品负责人拆分决策 |
| 评分尺度与历史项目不一致 | 回溯历史 5 个已评分项目的维度分，进行一致性校准回归 | 数据分析师 + 产品经理联合校准 |
验收标准
- 每个维度均有清晰、无歧义的书面定义，并附有至少 2 个典型示例
- 四维的评分对照表（1-10 分）已填写完整，每档均有可量化的衡量锚点
- 团队核心成员（产品、技术、数据）对四维定义达成书面确认，无遗留争议
- 已完成 3-5 个典型需求的预评分校准，校准记录归档可追溯
- 定义标准文档已发布至团队知识库，所有评估参与者可随时查阅