第2章 确认适用场景：产品阶段、团队规模、数据基础、决策频率

RICE 评分法并非万能银弹，它的有效性与团队当前所处的产品阶段、团队规模、数据成熟度以及决策节奏密切相关。在正式使用 RICE 给功能排序前，必须先确认这四个维度是否落在 RICE 的“舒适区”。如果场景错配，评分结果会误导优先级，甚至拖慢交付节奏。

适用场景对照表

前置条件

• 产品路线图（Roadmap）中已有候选功能 backlog，且 backlog 条目数 ≥ 5。
• 团队已确认当前产品生命周期（通过阶段检查清单：用户量级、留存曲线、变现模式）。
• 数据可用性清单：列出每个候选功能可获得的关键指标（如 DAU、转化率、用户操作日志）。
• 决策日历：明确本次排序是用于周迭代还是季度规划。

操作步骤

1. 判定产品阶段：对照“探索期 / 成长期 / 成熟期 / 衰退期”特征，至少收集近 3 个月的用户增长率和留存率数据。
2. 评估团队规模：统计参与功能评审的核心成员数（PM、开发、设计、QA）。3~20 人视为适中。
3. 检查数据基础等级：将每个候选功能对应的数据源标记为 A（埋点充分）、B（有部分日志）、C（零数据）。若超过 60% 为 C 级，则考虑降级。
4. 确定决策频率：根据公司发布周期填写“周/双周 / 月 / 季度”。频率越高越适合 RICE。
5. 匹配兼容性：参照上表，若全部命中舒适区，继续使用完整 RICE；若有 2 项以上落在谨慎区，建议改用 ICE 或使用定性权重校准。

输入输出物

责任边界

• 产品经理：主导产品阶段判断、召集团队评估、输出场景确认卡片。
• 数据工程师 / 分析师：提供每个功能的数据等级评估，标注缺失指标。
• 技术负责人：确认团队实际参与人数与能力分布。

记录材料

统一使用《场景确认卡片》模板记录，包含 4 个维度的评估结果和最终建议。模板简化示例：

# 场景确认卡片（结构示例）

| 维度       | 评估结果        | 兼容性 |
|------------|----------------|--------|
| 产品阶段   | 成长期（月活50k）| ✔ 舒适 |
| 团队规模   | 8人（PM+3Dev+...）| ✔ 舒适 |
| 数据基础   | 70% A级，30% B级 | ✔ 舒适 |
| 决策频率   | 双周迭代        | ✔ 舒适 |
| 总结论     | 建议完整 RICE    |        |

异常处理

• 场景冲突：例如产品阶段为“探索期”但团队规模大、数据基础丰富。此时优先以产品阶段为准，调低 Reach 和 Confidence 的权重，加大 Impact 话语权。
• 数据基础过差：超过 60% 功能为 C 级时，暂停 RICE，先完成一轮最小可用数据采集（埋点或手动日志），或改用 ICE 定性评分。
• 团队中途扩/缩编：若团队人数在评分过程中变化超过 30%，需重新评估 Effort 估算的准确性，并更新场景卡片。

验收标准

• 场景确认卡片中 4 个维度均有明确评级（不能有“待定”）。
• 至少有两名跨角色成员（如 PM + 技术负责人）签字确认卡片内容。
• 卡片中明确注明了因场景差异而调整的 RICE 权重系数（如有）。