第1章 RICE方法概述与MVP迭代节奏核心概念
本章作为整个课程的入口，帮助团队建立统一的RICE评分语言和MVP节奏认知。在进入后续30章的具体SOP操作前，必须确保所有角色对RICE四维定义、MVP核心原则以及迭代节奏的基本概念达成一致。
1.1 适用场景
- 产品待办列表（Backlog）中需求数量超过团队交付能力，需要量化优先级时。
- 启动一个新的产品/功能MVP迭代周期，需要确定首次选入迭代的范围。
- 多角色（产品、开发、设计、测试）对需求优先级存在分歧，需要客观标尺对齐。
- 现有迭代节奏混乱、周期间隔随意，需要建立固定节奏的反馈循环。
1.2 前置条件
- 已有明确的产品愿景与用户画像（至少完成初始版本）。
- 产品待办列表已按User Story或Feature粒度拆分，且每个条目包含可估算的业务价值描述。
- 团队已定义迭代周期单位（如1周/2周/1月），并达成基本共识。
1.3 操作步骤
- 识别RICE四维
对每个待办需求，依次评估其Reach（触达用户数）、Impact（对核心指标的影响）、Confidence（证据强度）、Effort（开发工作量）。 - 应用MVP核心原则
根据RICE总分排序，选择最高分且Effort可接受的需求作为候选MVP。牢记“最小可行”意味着只做验证假设所必需的功能，不做镀金。 - 设定迭代节奏
确定一个时间盒（Timebox），将选中的MVP放入迭代计划，并设定固定周期（如每两周一次）。在该周期内完成开发、测试、验证、回顾，形成构建-测量-学习闭环。
1.4 输入输出物
| 输入 | 输出 |
|---|---|
| 产品待办列表（未排序） | RICE评分后的优先级排序列表 |
| 用户故事/功能描述 | MVP迭代计划（含周期、目标、交付物） |
| 团队历史速率（Velocity）数据 | 迭代节奏日历（固定周期间隔） |
1.5 责任边界
| 角色 | 职责 |
|---|---|
| 产品经理 | 负责Reach与Impact的评分，维护RICE分数一致性 |
| 开发团队（技术Lead） | 负责Effort估算，提供技术可行性意见 |
| 用户研究员/数据分析师 | 负责Confidence数据来源（用户调研、A/B测试、历史数据） |
| Scrum Master/迭代经理 | 确保迭代节奏按时启动和关闭，组织回顾 |
1.6 记录材料
- RICE评分卡（电子表格或专用工具）：记录每个需求四个维度的分值及总分。
- 迭代节奏看板（物理白板或数字工具）：展示当前迭代的MVP范围与进度。
- RICE评分指南：包含各维度的评分标尺（1-10分制）与参考案例。
1.7 异常处理
异常：两个需求RICE总分相同，无法选出唯一MVP。
处理：优先比较 Impact × Confidence 乘积，取更高者；若仍相同，由产品经理决策并记录理由。
处理：优先比较 Impact × Confidence 乘积，取更高者；若仍相同，由产品经理决策并记录理由。
异常：迭代周期太短，无法完成选中的MVP。
处理：缩小MVP范围（进一步拆分用户故事），或延长迭代周期（需团队同意）。
处理：缩小MVP范围（进一步拆分用户故事），或延长迭代周期（需团队同意）。
异常：Confidence评分出现极端分歧（有人打1分，有人打10分）。
处理：组织15分钟快速讨论，寻找原始证据或约定统一置信区间（如只允许1、5、10三档）。
处理：组织15分钟快速讨论，寻找原始证据或约定统一置信区间（如只允许1、5、10三档）。
1.8 验收标准
- 团队成员能口述RICE四个维度的全称及含义，无概念混淆。
- 在5分钟内对一个虚构需求完成独立RICE评分，且得分逻辑可解释。
- 产品待办列表中至少80%的需求已完成RICE评分，并生成了优先级排序。
- 团队已确认迭代周期长度，并在看板上贴出最近3个迭代的时间边界。
图1：RICE评分模型结构图 —— 展示四个维度如何汇聚到优先级决策
💡 团队练习：拿出当前产品待办列表中任意3个需求，按上述四维分别打分，然后使用公式计算总分。核对内部评分是否一致，讨论Confidence证据的具体来源。