第2章：RICE模型前置条件 — 准备你的评分基座

2.1 适用场景

本章规则在以下典型场景中必须执行：

• 启动新一批需求排期：季度规划、版本规划启动时。
• 团队首次引入 RICE 模型：需要建立团队对标准和角色的共同记忆。
• 需求池长期未整理：存在大量过期、重复或模糊需求时。
• 评审人员发生变动：新成员加入评审团前必须完成标准对齐。

2.2 前置条件

执行本章流程前，必须保证以下物料和角色已就绪：

1. 产品路线图或季度 OKR 已对齐：确保待排序需求与当前战略目标一致。
2. 原始需求收集已完成：至少包含需求标题、描述、提出方、期望时间。
3. 核心评审团队已确认：产品经理、技术主管、业务方代表均已划定。

2.3 操作步骤

步骤 1：明确待排序需求列表

从需求池中提取本次待排序的全部需求，按统一格式整理。

• 动作：合并重复需求、识别依赖关系、剔除已过时需求。
• 格式要求：每条需求必须包含 需求 ID、标题、描述链接、提出方。
• 输出：一份清理后的《待排序需求清单》（不超过 20 条/批次为佳）。

步骤 2：统一评分标准

定义 RICE 四个维度的具体评分量表，确保团队共用同一把“尺子”。

步骤 3：确认评审角色与责任边界

使用 RACI 矩阵划分每个需求在 RICE 打分中的权责。

关键约束：每个需求必须有且只有一位 R（负责人） 和一位 A（审批人），责任不可重叠或缺失。

2.4 输入输出物

2.5 责任边界

• 产品经理 (PM)：对需求列表的完整性和格式负责；牵头制定标准草案。
• 技术主管 (Tech Lead)：对 Effort 维度的评分标准可行性负责。
• 产品负责人 (PO)：对前置条件是否能关闭拥有最终裁定权；在标准分歧时进行仲裁。
• 团队全员：需在评审角色矩阵上签字确认，未签字前不得启动打分。

2.6 记录材料

• 需求列表模板：建议使用结构化文档或项目管理系统（如 Jira、Notion）中的看板视图。
• RICE 标准定义卡：打印或置顶于协作文档，供打分期间随时对照。
• 评审角色确认签名表：形式可为电子签名或会议记录归档。

2.7 异常处理

2.8 验收标准

本章完成后，必须满足以下标准方可进入第 3 章 RICE 打分：

1. 需求列表完成度 100%：所有待排序需求均已完成字段标准化，无缺失、无重复。
2. 评分标准已归档并全员知晓：团队内任意成员可随时查询标准手册，无理解矛盾。
3. 角色矩阵已签署：每个需求的 R、A、I 角色已在团队内公示且获得责任人确认。
4. 异常已闭环：2.7 中识别的所有异常均已记录并执行了相应处理策略。