第1章 RICE评分法概述与MVP范围定义

适用场景

RICE评分法适用于产品团队在需求积压（Backlog）中确定先做哪个功能、哪个需求应纳入首次发布（MVP）范围的决策场景。典型适用场景包括：

• 从零启动新产品，需要从数十个想法中筛选出最小可行版本。
• 现有产品进入新阶段，资源有限，需对齐下一迭代的交付边界。
• 跨职能团队（产品、设计、开发）对需求优先级存在分歧，需要一个可复用的量化对齐工具。
• 向管理层或投资人解释“为什么这个功能先做、那个功能后做”时，提供可追溯的评分依据。

前置条件

学习本章并能在后续章节中完成RICE评分实操，需满足以下前置条件：

1. 基础产品术语：了解用户故事、史诗故事、需求优先级、发布计划等基本概念。
2. 数据可用性：至少对所评估的功能/需求有粗略的用户覆盖估算、开发人日估算，以及定性或定量的影响判断。
3. 工具就绪：准备一个可编辑的电子表格（如Excel、Google Sheets）或协作文档，用于记录RICE评分表。
4. 团队共识：确认至少一名产品负责人和一名技术负责人参与评分过程，以保证 Impact 和 Effort 的评估有双向输入。

操作步骤：理解 RICE 四要素与 MVP 范围

本章为概念认知步骤，不涉及具体计算。请按以下顺序完成对核心概念的构建：

1. 理解 Reach（触达人数）：估算在特定时间窗口内（通常为季度），该功能会影响到多少独立用户。单位为人/季度。
2. 理解 Impact（影响程度）：衡量该功能对核心指标（留存、转化、NPS等）的拉动强度。通常采用 0.25/0.5/1.0/3.0 的离散倍率。
3. 理解 Confidence（信心指数）：对 Reach 和 Impact 估算的确信程度。20%（猜测）→ 50%（低确信）→ 80%（中确信）→ 100%（高确信）。
4. 理解 Effort（投入成本）：该功能所需的总人月（或人天），包含设计、开发、测试、部署全链路。
5. 理解 MVP 范围：MVP 不是“最少功能的产品”，而是“能验证核心假设的最小发布单元”。RICE 评分最高的功能组合构成 MVP 的候选集。

输入输出物

责任边界

记录材料

本章需留存以下记录材料，作为后续章节评分的基础档案：

• RICE 四要素定义卡（纸质或电子）：用一页纸记录 Reach / Impact / Confidence / Effort 在本团队中的具体量纲和取值规则。
• 候选功能清单（原始版）：记录所有待评功能的唯一编号、名称、描述、提出人、提出日期。
• MVP 范围概念确认纪要：团队对 “MVP 不是最小功能集，而是最小验证集” 达成共识的会议纪要。

异常处理

验收标准

完成本章学习后，需满足以下验收标准方可进入第2章：

1. 团队全员能独立说出 RICE 四个要素的全称及含义，无歧义。
2. 已产出 “RICE 四要素定义卡” 并由产品经理和技术负责人共同签署。
3. 候选功能清单已整理完毕，每个功能至少包含名称和一句话描述。
4. MVP 范围概念已在团队内达成一致：MVP 是“验证核心假设的最小发布单元”，而非“功能数量最少”。

本章知识框架：RICE 与 MVP 范围的关系

下图展示了 RICE 四要素如何汇聚成评分，并最终指向 MVP 范围的确定逻辑。第2章起将围绕每个要素的取值细节展开。