1. RICE 方法总览

1.1 适用场景

RICE 方法适用于需要对产品需求或特性进行优先级排序的场景，尤其是当团队资源有限、多个候选需求并存时。典型场景包括：

• 季度/迭代规划：从需求池中筛选出最高价值的特性交付。
• MVP 定义：确定最核心的功能集合。
• 跨团队协作排序：统一不同角色的优先级判断标准。
• 需求评审跟进：为评审会议提供定量依据，减少主观争论。

1.2 前置条件

在应用 RICE 方法前，团队应具备以下条件：

• 已建立结构化的需求池（如 Jira、Notion 或 Excel）。
• 每个需求具备可量化的基础数据（用户数、影响力评估、信心度自评、开发工作量估算）。
• 团队已对齐 RICE 的四个维度的定义与评分标准（本章后续详细说明）。
• 存在至少一名负责维护评分结果的 RICE 评分员（通常由产品经理担任）。

1.3 整体流程（四步走）

RICE 方法的执行包含四个连续步骤，以下表格概括了每个步骤的目标与产出。

1.4 输入与输出物

• 输入物：
  • 需求描述列表（含 ID、标题、简述）
  • 每个需求的 Reach（受影响的用户量或事件数）
  • 每个需求的 Impact（按预设量级打分：0.25 / 0.5 / 1 / 2 / 3）
  • 每个需求的 Confidence（百分比：20% / 50% / 80% / 100%）
  • 每个需求的 Effort（人月或人天，整数）
• 输出物：
  • RICE 评分排序表（可导出为 CSV）
  • 优先级等级标识（P0 ~ P3）
  • 评分日志（含调整记录）

1.5 责任边界

1.6 记录材料

每一次 RICE 评分过程必须生成以下记录：

• 主记录文件： 包含所有需求的四个维度原始值、计算得分、排序结果。
• 变更日志： 记录校准环节中任何数值的修改，以及修改原因和操作人。
• 会议纪要： 如果通过会议讨论校准，需留存关键讨论点与结论。

示例记录片段（仅展示格式，非真实数据）：

需求ID, Reach, Impact, Confidence, Effort, RICE, 优先级
REQ-101, 8000, 3, 0.8, 4, 4800, P0
REQ-102, 2000, 1, 0.5, 2, 500, P2
REQ-103, 500, 2, 0.2, 1, 200, P3

1.7 异常处理

1.8 验收标准

完成 RICE 方法总览章节后，检查以下要点：

• 团队所有成员能说出 RICE 四个维度的英文全称及含义。
• 至少有 1 个已填充的 RICE 评分示例（非空表）。
• 评分记录满足“输入 - 计算 - 输出”的闭环，且包含异常处理说明。
• 责任边界表已归档并知会相关角色。

1.9 RICE 方法全景流程（内联 SVG）

1.10 关键概念速查

以下定义有助于团队快速对齐评分标准：

• Reach（用户触及量）：需求上线后，在固定周期内（如一个月）预计影响的用户数量或独立事件数。
• Impact（影响力）：该需求对核心指标（转化率、留存、收入等）的贡献程度。建议使用量级：0.25（极低）、0.5（低）、1（中）、2（高）、3（极高）。
• Confidence（信心度）：对 Reach、Impact 及 Effort 估算的综合信心。建议取值：20%（猜测）、50%（有数据支撑）、80%（已验证）、100%（历史数据确凿）。
• Effort（工作量）：研发、设计、测试等全部人力投入的总人月数或人天数，需包含非开发任务。