第2章 前置条件与参与角色

2.1 适用场景

RICE 方法适用于产品团队在 需求池膨胀、资源受限、截止日期明确 时，从大量候选功能中筛选出 MVP 功能集。典型场景包括：

• 新产品从 0 到 1 的 MVP 版本规划；
• 已有产品进入新市场或新用户群时的功能优先级重排；
• 季度或月度迭代中，面对 50+ 个候选功能需要快速收敛。

若团队处于“所有功能都做”或“完全凭直觉排序”的状态，则本方法最能发挥价值。

2.2 前置条件：基础知识清单

以下四项基础认知是顺畅执行 RICE 评分的必要前提。团队可对照自检，缺失项需在课程开始前补齐。

2.3 操作步骤：前置准备流程

在正式开始 RICE 评分之前，按照以下 4 个步骤完成准备。每一步的输出物将直接用于后续章节。

1. 知识补齐（30 分钟）： 对照 2.2 表格，完成自评并补齐短板。
2. 角色确认（15 分钟）： 从 PM、设计师、开发中明确本次评分的 固定评分小组，并指定一名记录员。
3. 输入物整理（45 分钟）： 将待评功能从需求池中导出为“用户故事列表”和“功能列表”两种格式（见 2.5 节）。
4. 模板与工具准备（10 分钟）： 下载 RICE 评分表模板、设置共享文档权限。

2.4 参与角色与责任边界

RICE 评分需要三个角色组成 核心评分小组，每个角色拥有明确的输入责任和决策边界。

2.5 输入物与输出物

明确的输入物是 RICE 评分公正性的基础。本章要求团队准备以下两份材料：

输入物一：用户故事列表

每个功能以 用户故事 格式描述，确保团队对“为谁做、做什么、为何做”达成共识。

[
  {
    "id": "US-001",
    "as_a": "注册用户",
    "i_want": "使用微信一键登录",
    "so_that": "无需记住密码，10秒内完成注册"
  },
  {
    "id": "US-002",
    "as_a": "内容创作者",
    "i_want": "在发布文章时添加标签分类",
    "so_that": "读者能按主题检索内容"
  }
]

输入物二：功能列表（含结构化描述）

在用户故事基础上，补充估算所需的元数据字段。

[
  {
    "feature_id": "F-001",
    "title": "微信一键登录",
    "user_story_id": "US-001",
    "target_users": "全部新注册用户",
    "expected_daily_users": 1200,
    "known_risks": "微信SDK兼容性待验证"
  },
  {
    "feature_id": "F-002",
    "title": "文章标签分类",
    "user_story_id": "US-002",
    "target_users": "内容创作者群体",
    "expected_daily_users": 450,
    "known_risks": "标签管理后台需要额外开发"
  }
]

2.6 记录材料

为保障评分过程可追溯，需提前准备以下记录材料：

2.7 异常处理

在准备阶段可能遇到的典型异常及对应处理方案：

2.8 验收标准

本章完成时，团队应逐条确认以下验收项。全部通过后方可进入第 3 章 RICE 正式评分。

• ✅ 每位评分成员已完成基础知识自评，且无 ❌ 项；
• ✅ PM / 设计师 / 开发 三个角色均已指定具体人员，并在协作平台公示；
• ✅ 用户故事列表和功能列表已整理为结构化 JSON 格式，字段完整；
• ✅ RICE 评分主表模板已创建，并设置好 Reach / Impact / Confidence / Effort 列；
• ✅ 所有候选功能均已标记 [就绪] 或 [待补充]，无遗漏；
• ✅ 异常处理清单已知会全体评分成员，并明确升级路径。