第 3 章 用户故事与 RICE 打分：将用户故事转化为可对比的优先级序列
本章交付产出
在本章结束时，你将产出一份可对比的用户故事优先级序列。该序列以 RICE 综合得分为排序依据，直接决定原型范围包含哪些用户故事、先做哪个后做哪个，以及哪些故事需要推迟或拆分。
- 决策产出：按 RICE 得分降序排列的用户故事优先级列表（含 Reach、Impact、Confidence、Effort 四项明细）
- 关键模板：RICE 评分表、用户故事优先级矩阵
- 验收标准：得分≥8 的用户故事必须进入本轮原型范围，得分位于 5–7.9 的视资源弹性纳入，得分＜5 的推迟到下个迭代
⚡ 核心原则：用户故事是需求的原子单位，RICE 打分将定性故事转化为定量排名，避免“谁声音大谁优先”的主观决策。
3.1 业务问题：用户故事堆积，如何确定优先级？
在实际产品迭代中，团队往往同时面对 20–30 个用户故事，每个故事看起来都有价值。缺乏量化标准导致反复开会争论、开发资源被低价值故事占用、高价值故事被推迟。仅靠“直觉排序”或“业务方催得急”来做范围取舍，会使原型偏离核心用户路径。
⚠️ 常见陷阱：不要用“故事点数”替代 RICE 评分。故事点数是开发复杂度估算，不是价值判断。RICE 从用户触达、影响、信心、成本四个维度独立打分，避免复杂度绑架优先级。
3.2 用户访谈与需求拆解：从原始诉求到可评分故事
在进入 RICE 打分前，必须确保用户故事已经过需求拆解，具备可度量、可验证的边界。以下是一个典型转化过程：
| 用户访谈原始诉求 | 拆解后的用户故事 | 可度量指标 |
|---|---|---|
| “找历史订单太慢了，经常翻好几页” | 作为买家，我希望在订单列表页支持按时间范围筛选，以便在 10 秒内找到近 3 个月的订单。 | 筛选后查询耗时 ≤ 10 秒；月活买家使用率 ≥ 60% |
| “提交工单后不知道进展到哪了” | 作为用户，我希望在工单详情页看到状态流转时间线，以便实时了解处理进度。 | 工单页面停留时长降低 30%；客服咨询量下降 15% |
| “想批量导出报表但每次只能选一个月” | 作为运营，我希望能选择多个月份批量导出销售报表，以便在 1 次操作内完成季度数据汇总。 | 导出操作次数减少 60%；单次导出数据量支持 12 个月 |
💡 拆解要点：每个用户故事只包含一个用户角色、一个功能诉求、一个可度量结果。如果故事包含“同时…并且…”，说明需要继续拆解。
3.3 RICE 模型四维打分步骤
RICE 模型由 Intercom 提出，包含四个评分维度：Reach（触达）、Impact（影响）、Confidence（信心）、Effort（成本）。每个维度采用 1–10 分制，最终得分 = (R × I × C) / E。
步骤 1：Reach（触达用户数）
评估该用户故事在一个时间周期内（通常为 1 个月）能触达到多少用户。触达不等同于功能使用人数，而是接触到该功能的用户量。
| 得分 | 触达标准（月） | 典型场景 |
|---|---|---|
| 10 | ≥ 100,000 用户 | 登录页改版、全局导航优化 |
| 7–9 | 10,000 – 99,999 用户 | 核心功能流程优化 |
| 4–6 | 1,000 – 9,999 用户 | 特定角色功能、二级页面 |
| 1–3 | ＜ 1,000 用户 | 管理后台、低频设置项 |
步骤 2：Impact（影响程度）
该故事对用户核心目标的改善程度。影响度聚焦于“完成目标的效果”，不依赖触达人数。
| 得分 | 影响描述 | 典型表现 |
|---|---|---|
| 10 | 颠覆性提升 | 任务完成率提升 ≥ 50% |
| 6–9 | 显著改善 | 完成率提升 20%–49% |
| 3–5 | 中等改善 | 完成率提升 5%–19% |
| 1–2 | 微小改善 | 完成率提升 < 5% |
步骤 3：Confidence（信心指数）
你对 Reach 和 Impact 评分有多大把握。信心不足时，分数应直接降低。
| 得分 | 信心依据 | 数据支撑 |
|---|---|---|
| 10 | 已有 A/B 测试或历史数据验证 | 定量实验数据 |
| 6–9 | 用户访谈 + 可用性测试数据 | 定性 + 小样本定量 |
| 3–5 | 仅凭用户访谈或行业经验推断 | 无定量数据 |
| 1–2 | 纯粹直觉或团队猜测 | 无任何依据 |
步骤 4：Effort（开发成本）
包含设计、开发、测试、部署在内的全流程人天成本。Effort 是唯一的分母，成本越高得分越低。
| 得分 | 成本范围（人天） | 典型故事规模 |
|---|---|---|
| 1 | ＞ 30 人天 | 跨系统重构、新模块开发 |
| 3–4 | 11–30 人天 | 中等复杂度新功能 |
| 5–7 | 4–10 人天 | 常规功能迭代 |
| 8–10 | ≤ 3 人天 | 小优化、文案调整 |
📐 评分对照表使用建议：在每个维度打分时，先找到最匹配的行，再根据实际情况微调 ±1 分。避免打出 0 分或超过 10 分；如果某个维度完全不适用，该故事应暂缓进入 RICE 流程。
3.4 综合得分计算与优先级序列生成
RICE 综合得分公式：
RICE Score = (Reach × Impact × Confidence) / Effort以下是一个包含 5 个用户故事的 RICE 评分实战案例：
| 用户故事 ID | 用户故事简述 | R | I | C | E | RICE 得分 | 优先级排名 |
|---|---|---|---|---|---|---|---|
| US-001 | 订单列表支持按时间筛选 | 8 | 9 | 8 | 4 | 144.0 | 1 |
| US-002 | 工单详情页展示状态时间线 | 6 | 7 | 7 | 5 | 58.8 | 2 |
| US-003 | 批量导出多个月份报表 | 4 | 6 | 5 | 3 | 40.0 | 3 |
| US-004 | 个人中心头像裁剪功能 | 3 | 2 | 9 | 8 | 6.75 | 4 |
| US-005 | 深色模式一键切换 | 2 | 1 | 3 | 6 | 1.0 | 5 |
⚠️ 关键规则：当两个用户故事的 RICE 得分差距小于 5% 时，需要引入置信度加权—— Confidence 更高的故事应排在前面。不要仅凭小数点后两位做绝对排序。
3.5 用户故事→RICE 优先级序列流程图
下图展示了从用户故事进入 RICE 漏斗到生成可对比优先级序列的完整路径：
🗺️ 流程图解读：用户故事经过拆解验证后，进入四维独立评分通道；Effort 作为分母直接参与计算，最终输出降序排列的优先级序列。每次迭代重新评分，避免“一次排序用一年”的静态决策。
3.6 验收标准与决策规则
优先级序列生成后，团队需按以下规则完成原型范围决策：
| RICE 得分区间 | 原型范围决策 | 行动要求 |
|---|---|---|
| ≥ 30.0 | 强制纳入本轮原型 | 立即进入设计与开发编排 |
| 10.0 – 29.9 | 建议纳入 | 与业务方确认资源后纳入 |
| 5.0 – 9.9 | 弹性纳入 | 视人力余量决定，可做简化版本 |
| ＜ 5.0 | 推迟到下个迭代 | 记录到产品 Backlog 并标注 RICE 得分 |
✅ 验收标准：最终的原型范围清单必须满足以下条件—— (1) 所有包含的用户故事 RICE 得分均 ≥ 5；(2) 排序前 3 的故事已全部纳入；(3) 没有任何故事得分低于 5 却意外出现在本轮原型中。
3.7 交付物模板：RICE 评分表
使用以下空白模板对新的用户故事进行 RICE 打分。推荐在 Confluence 或 Notion 中建表，每次迭代更新一次。
## RICE 评分表（迭代：2025-Q2-迭代2）
| 用户故事 ID | 用户故事简述 | Reach (1-10) | Impact (1-10) | Confidence (1-10) | Effort (1-10) | RICE 得分 | 优先级排名 | 决策 |
|------------|------------|-------------|--------------|------------------|--------------|----------|----------|------|
| US-001 | | | | | | | | |
| US-002 | | | | | | | | |
| US-003 | | | | | | | | |
### 评分依据备注
- US-001 Reach 依据：________
- US-002 Impact 依据：________
- US-003 Confidence 依据：________
⚠️ 使用提醒：不要跳过“评分依据备注”部分。当后续迭代需要回溯优先级决策时，备注中的依据是避免重复争议的唯一凭证。如果 Confidence 得分低于 5，必须在该字段中写明“为什么信心不足”。
3.8 本章小结与回顾清单
- ✅ 用户故事已经过需求拆解，具备可度量边界
- ✅ 对每个故事完成了 Reach、Impact、Confidence、Effort 四维打分
- ✅ RICE 综合得分已计算并填入评分表
- ✅ 按得分降序排列生成了优先级序列
- ✅ 根据得分区间完成了原型范围决策
- ✅ 评分依据和备注已记录，可供后续回溯
📘 下章预告：第 4 章将讲解如何将本章生成的优先级序列映射到原型功能结构图，并产出第一个版本的原型范围边界文档。