第1章 RICE模型概述与MVP范围界定场景
适用场景
RICE模型适用于以下MVP（最小可行产品）范围界定场景：
- 产品团队需要在多个候选功能中决定哪些进入首个发布版本。
- 资源有限（开发时间、人力、预算）且需要最大化早期市场验证效果。
- 功能需求来源多样（用户反馈、竞品分析、内部提案），需要客观量化排序。
- 团队处于产品早期阶段，缺乏历史数据时仍可依赖信心度维度做出合理估计。
前置条件
- 已明确产品目标和关键业务指标（如用户增长率、转化率）。
- 已完成初步的需求收集与梳理，形成候选功能列表。
- 团队对每个候选功能的覆盖人数、影响力、信心度、开发工作量有可量化的估算依据（如用户调研数据、技术方案评审、历史工时记录）。
- 至少一名产品经理负责组织评分会议，并确保评分一致性。
模型四个维度
| 维度 | 英文 | 含义 | 典型度量 |
|---|---|---|---|
| 覆盖人数 | Reach | 在特定时间窗口内，该功能预计能触达的用户数量 | 月活跃用户数（MAU）、潜在体验人数 |
| 影响力 | Impact | 该功能对关键目标的转化效果（如提升留存、转化率） | 转化率提升百分点、用户满意度得分 |
| 信心度 | Confidence | 团队对覆盖人数和影响力估算的肯定程度 | 百分比（如80%表示比较肯定） |
| 开发工作量 | Effort | 完成该功能所需的人·月或故事点总和 | 人·天、故事点（Story Points） |
核心价值
- 量化决策：将主观判断转化为可比较的数字，减少“老板拍板”式决策。
- 平衡效率与影响：通过（R × I × C）/ E公式，优先推进高覆盖、高影响、高信心、低工作量的功能。
- 尽早暴露风险：信心度维度强制团队审视数据支撑的充分性，避免盲目投入。
- 跨团队对齐：统一的评分框架让开发、设计、市场人员在同一语言下讨论优先级。
公式示例：RICE Score = (Reach × Impact × Confidence) / Effort
例如：功能A：Reach=5000, Impact=3, Confidence=80%, Effort=10 → 得分=(5000×3×0.8)/10=1200
例如：功能A：Reach=5000, Impact=3, Confidence=80%, Effort=10 → 得分=(5000×3×0.8)/10=1200
与其他优先级模型的区别
| 模型 | 核心变量 | 特点 | 与RICE的主要差异 |
|---|---|---|---|
| MoSCoW | Must / Should / Could / Won't | 依靠小组协商定性分类 | 缺乏量化权重，无法处理大型功能列表的精细排序 |
| Kano | 满意度 vs 功能实现程度 | 分类（基本型、期望型、兴奋型） | 偏向用户情感分类，未考虑开发成本和覆盖用户量 |
| 加权评分（WSJF） | 延迟成本 / 工作规模 | 常用于SAFe框架 | 需要计算延迟成本（较复杂），RICE更轻量且适合初创团队 |
| ICE | Impact / Confidence / Ease | 与RICE类似，但缺少Reach | 忽略用户覆盖面，可能误判对整体业务的实际影响 |
操作步骤（RICE评分流程）
- 整理候选功能列表：确保每个功能有清晰描述和验收标准。
- 估算 Reach：基于用户基数或场景频率给出数字（如：预计每月触达2000位新用户）。
- 估算 Impact：通常采用1/2/3或1~10分制（3=重大影响，1=轻微影响）。
- 评估 Confidence：团队投票给出百分比（如80%表示有高可信数据支持）。
- 估算 Effort：由开发团队估算人·天或故事点。
- 计算 RICE 得分：使用公式
R = (Reach × Impact × Confidence) / Effort，并按得分从高到低排序。 - 讨论调整：检查异常高分或低分功能，确认估算合理性。
- 确定MVP队列：选取排名靠前的功能进入第一个迭代。
输入与输出物
| 输入物 | 输出物 |
|---|---|
| 候选功能列表（含描述） | RICE评分排序表（含各维度数值与最终得分） |
| 用户规模数据（如MAU） | 优先级队列（按得分降序） |
| 历史转化率/调研结果 | MVP范围界定提案（建议包含的前3～5个功能） |
责任边界
- 产品经理：组织评分会议、确保维度含义统一、维护评分记录。
- 开发团队：提供Effort估算（故事点/人·天）。
- 设计师/用户研究员：协助提供Reach和Impact的数据支撑。
- 利益相关方：对最终得分和排序进行确认，不直接干预评分过程。
异常处理
- 数据缺失：若Reach或Impact无法估算，可将Confidence设为较低值（如30%），并标记为“需补充调研”。
- 分歧较大：团队对某功能维度严重不一致时，暂停评分，先做针对性用户测试或技术预研。
- 得分相等：优先选择Confidence更高（数据支撑更足）的功能，或综合业务策略决定。
- Effort超预期：若开发工作量远大于常规，需拆分为子功能后再重新评分。
验收标准
- 所有候选功能均已填入RICE评分矩阵。
- 得分计算无算术错误，且与公式一致。
- 评分过程文档化（含各维度估算依据和参与者）。
- 输出明确的MVP范围列表（通常不多于5个功能）。
- 利益相关方对列表无重大异议（或已完成协商调整）。
最佳实践：首次使用RICE时，可先选3～5个代表性功能进行试评分，让团队熟悉维度定义和估算尺度，再铺开到全部候选功能。