第1章 RICE模型概述与适用场景
1.1 定义
RICE 模型是一种用于需求优先级排序的量化评估框架，由四个核心维度组成：
| 维度 | 英文 | 定义 | 典型问题 |
|---|---|---|---|
| 触达 | Reach | 一个周期内该功能/Agent 会影响到多少用户/Agent实例数量 | 有多少用户会在确定时间内体验到？ |
| 影响 | Impact | 该需求对用户或业务目标的改变程度（通常 1×, 2×, 3×） | 这个功能能多大幅度的提升关键指标？ |
| 信心 | Confidence | 你对 Reach 和 Impact 估计的确定性（通常 20%, 50%, 80%, 100%） | 我们有多确信数据/假设是准确的？ |
| 努力 | Effort | 实现该需求所需的总人-天或故事点（团队规模） | 需要多少开发/产品/设计资源？ |
分数公式：RICE Score = (Reach × Impact × Confidence) / Effort。分数越高的需求优先级越高。
Agent 场景扩展： 在 Agent 需求中，“触达”可理解为 Agent 实例被调用的次数或影响的对话轮次；“影响”评估对任务完成率、响应准确度的提升；“信心”反映测试数据或专家判断的可信度；“努力”包括 prompt 设计、工具集成、回测等工时。
1.2 适用场景
- 产品路线图规划：在多个 Agent 功能候选列表中决定先开发哪个。
- Sprint 积压梳理：对即将排期的 Agent 需求进行客观排序，避免“最强声音优先”。
- 跨团队资源调配：当多个 Agent 项目共享人力时，用分数衡量投入产出比。
- 版本发布决策：判断哪些 Agent 能力必须进入本轮发布，哪些可延迟。
- 假设验证闭环：在 A/B 测试前用 RICE 预估，事后对比实际数据修正未来评估。
1.3 不适用场景
| 场景类型 | 原因 | 替代方法 |
|---|---|---|
| 合规/法务需求（必须做） | 优先级由外部强制，无需排序 | 直接标记为“强制” |
| 严重 Bug / 安全漏洞 | 紧急程度压倒优先级 | 使用 Severity × Urgency 矩阵 |
| 无量化数据的早期概念 | 四个维度都无法估计，分数无效 | 先用 ICE（Impact × Confidence × Ease） |
| 单一人决策的小团队 | 模型 overhead 大于收益 | 简单票选或 MoSCoW |
注意： RICE 模型假设每个维度的评分是独立且可量化的。如果 Agent 需求高度耦合（例如一个功能依赖另一个功能的完成），应先将需求拆分为独立子项，否则分数会失真。
1.4 前置条件
- 已采集并整理 Agent 需求列表（至少包含功能描述、预期用户/实例范围、粗略实现方案）。
- 组建 评分小组（产品经理 + 技术负责人 + 至少一名业务方代表）。
- 确定 评分标度：例如 Reach 的“月活跃用户数分段”或“调用频次分段”；Impact 的“关键指标提升百分比区间”；Confidence 的“证据等级”；Effort 的“人天/故事点”。
- 准备 历史数据参考（如有相似 Agent 功能的埋点或实验数据）。
1.5 操作步骤
- 准备需求卡片：每个需求写在一张卡片（或 JIRA/Notion 条目）上，包含描述、预期用户场景、关联数据源。
- 独立评分：每位成员分别对 Reach / Impact / Confidence 打分（Effort 由技术负责人统一评估）。
- 汇总与讨论：计算每个需求四个维度的平均分，形成初始 RICE 分数；分数差值超过 30% 的维度进行讨论协商，达成共识后修正。
- 排序并切分优先级：按分数从高到低排列，根据发布周期或 Sprint 容量选择“必须做”、“应该做”、“可做可不做”。
- 更新记录：将最终评分、排序、讨论纪要保存至共享文档。
1.6 输入输出物
| 类型 | 名称 | 内容/格式 |
|---|---|---|
| 输入 | Agent 需求清单 | 结构：ID, 需求标题, 描述, 关联功能模块, 提出人, 提出日期 |
| 输出 | RICE 评分排序表 | Excel/Google Sheets，包含：需求ID, Reach, Impact, Confidence, Effort, RICE分数, 排序名次, 状态(待定/已采纳/搁置) |
| 输出 | 争议处理记录 | 标记出哪些需求经过重新评分，以及最终决议理由 |
1.7 责任边界
- 产品经理：负责需求卡片编写、组织评分会议、记录最终结果；对 Reach 和 Impact 的最终得分拥有裁决权（但需解释）。
- 技术负责人：评估 Effort 人天，判断技术可行性与依赖。
- 业务方/运营：提供用户反馈、业务指标趋势数据，协助 Confidence 评分。
- 所有人：对评分过程中的偏见保持警惕，遇到利益冲突需主动回避。
1.8 记录材料
模板示例（RICE评分记录表）：
| 需求ID | 需求标题 | Reach (1-10) | Impact (1-10) | Confidence (%) | Effort (人天) | RICE分数 | 排名 | 备注 |
|--------|--------------------|--------------|---------------|----------------|---------------|----------|------|--------------|
| A-001 | 多轮对话记忆增强 | 8 | 3 | 80 | 15 | 12.8 | 1 | 数据支撑强 |
| A-002 | 自动工具调度优化 | 5 | 4 | 50 | 12 | 8.33 | 2 | 信心较低 |
| A-003 | 用户情绪识别 | 3 | 2 | 30 | 20 | 0.9 | 3 | 缺乏训练数据 |建议使用在线协作表格，并保留每次评分的快照（版本历史）。
1.9 异常处理
| 异常现象 | 可能原因 | 处理方案 |
|---|---|---|
| 所有需求分数极低（<1） | Effort 被高估 或 Confidence 设得太严 | 重新校准标度，检查是否有“基准需求”作为锚点 |
| 某一维度评分差异超过50% | 成员对需求的理解不一 | 先统一需求描述，再匿名投票，取中位数 |
| 计算后发现得分相等无法区分 | 区分度不够 | 增加二级指标：战略对齐度、风险系数；或启用 Break-Tie 投票 |
| 急需上线但评分排后 | 模型未考虑紧急度 | 在定稿阶段单独标记“紧急例外”，记录原因后放入下一轮 |
1.10 验收标准
- 所有当前待评审的 Agent 需求已完成 RICE 评分，生成排序表。
- 排序表中每个需求均有明确的 Reach、Impact、Confidence、Effort 原始值（非空）。
- 争议记录中标注出至少 3 条需求（或全部需求）经过讨论后的修改细节。
- 产品经理与技术负责人共同签字确认排序结果（可使用电子签或会议结论）。
- 记录材料已存档至团队共享目录，SOP 文档版本与评分记录版本一致。