第3章 RICE模型适用场景判断
核心结论：RICE模型最适合用户增长、产品功能评估、小团队敏捷迭代三类场景。在这些场景下，RICE的高效计算和可量化特性能够直接驱动优先级决策；若不满足前置条件，应换用KANO或MoSCoW模型。
3.1 适用场景
| 场景 | 典型例子 | RICE优势 |
|---|---|---|
| 用户增长 | 注册转化优化、推荐机制AB测试、渠道投放策略 | Reach与Effect强相关，可快速计算增长倍数 |
| 产品功能评估 | 新功能灰度上线、功能模块砍留、性能改进 | 分层打分（R/C/E）统一量化，支持跨功能对比 |
| 小团队敏捷迭代 | 2周sprint backlog梳理、MVP需求排序 | 计算简单（单表即可），无需复杂共识会议 |
场景边界：RICE不适用于战略投资判断、长期ROI分析、用户情感深度调研。这些场景应优先考虑KANO（情感）或MoSCoW（战略强制）。
3.2 前置条件
- 数据可获取：Reach（触达人数）、Effect（转化或行为影响）、Confidence（置信度）三项指标必须能通过现有埋点、实验或历史数据估算。
- 团队认知统一：所有参与者理解“量化打分”概念，接受分数代替主观讨论。
- 迭代周期短：需求待办项不超过50条，且每条可在1～2个迭代内交付。
- 无强依赖：需求之间不存在必须按固定顺序交付的硬性依赖（否则需配合MoSCoW解耦）。
3.3 操作步骤（判断是否适用RICE）
- 审查需求池：列出当前待评估的所有需求项（≤50条）。
- 数据自检：对每一条需求，能否给出Reach（日/周/月触达）、Effect（0.25～3）、Confidence（20%～100%）的大致数值？若≥80%的需求可估算 → 进入下一步；否则 → 考虑KANO或MoSCoW。
- 场景匹配：当前问题属于用户增长、功能评估或敏捷迭代中的至少一类？是 → 继续；否 → 换模型。
- 团队节奏检查：团队是否能在一周内完成打分并达成共识？是 → 可选RICE；否 → 改用轻量MoSCoW。
- 输出决策：通过以上4步，标记“RICE适用”或“建议其他模型”。
3.4 输入输出物
| 类别 | 具体物 | 格式/示例 |
|---|---|---|
| 输入 | 待评估需求清单 | 可导出为Excel或Jira列表 |
| 输入 | 数据源（埋点、实验、运营报表） | 用户数、转化率、置信区间 |
| 输出 | 适用性判断结果 | “RICE适用”或“建议KANO/MoSCoW”及原因 |
| 输出 | 需求打分表（若适用） | 包含R、I、C、E四个字段的评分记录 |
3.5 责任边界
- 产品经理（PM）：提供需求池并保证每项描述清晰；主导数据估算。
- 数据分析师（DA）：协助提取Reach、Effect指标；计算Confidence。
- 开发负责人：评估Effort（人天）；确认迭代可行性。
- Scrum Master：组织快速打分会议（≤30min）；监督避免“伪量化”。
3.6 记录材料
- 适用性检查表（示例片段）：
需求ID | Reach可估算? | Effect可估算? | 场景匹配? | 团队节奏? | 结果 PM-101 | 是 | 是 | 用户增长 | 是 | 适用 PM-102 | 否 | 是 | 功能评估 | 是 | 建议KANO PM-103 | 是 | 否 | 战略投资 | 否 | 建议MoSCoW - RICE评分草稿（仅当适用时生成）：包含每项需求的R/I/C/E值及最终分数。
3.7 异常处理
| 异常现象 | 处理方案 |
|---|---|
| Confidence难以估算 | 采用后拉原则：取团队中位数或经验值，标注“低置信度”备忘 |
| 需求条数＞50 | 先按MoSCoW粗筛为Must/Should/Won’t，仅对Should层内需求使用RICE |
| 存在硬依赖导致排序无效 | 将依赖链打包为一个“Epic”并用同一个RICE score表示 |
| 部分需求无任何数据支撑 | 标记为“数据缺失”，暂时排除，待补充数据后单独评估 |
3.8 验收标准
- 已输出本章适用的 适用性决策树（见下方SVG图），且团队全员理解分支逻辑。
- 对于任意给定需求，可通过上述5步骤在 15分钟内 判断是否该用RICE。
- 记录材料（检查表+打分草稿）存档至项目文档库，可供后续复盘追溯。
- 异常处理清单覆盖团队已知的95%以上数据问题。
提示：上述决策树可直接打印为A4海报贴在团队白板上，每次需求梳理前快速走一遍，避免模型选错导致打分混乱。