第2章 案例拆解第一步：从业务目标倒推，识别待评估的功能或改进点清单

任何功能评估的起点都不是“这个功能看起来不错”，而是业务目标需要什么。RICE 评分要评估的功能或改进点，必须能回溯到一个具体的业务目标，否则评分结果无法指导决策。本章聚焦第一步：从北极星目标出发，沿用户链路与业务链路反向拆解，最终输出一份与目标强关联的待评估功能/改进点清单。

2.1 核心逻辑：从北极星目标到功能候选

倒推路径遵循“目标 → 行为链路 → 场景痛点 → 功能假设”的逐层收敛逻辑。以某在线教育 App 为例，业务目标是提升课程完成率，拆解流程如下表：

2.2 用户场景与业务问题识别

业务目标拆解后，需要将指标断层映射为具体用户场景。场景描述要包含人物、时机、行为、障碍四要素。

• 场景 1：职场新人小张，晚上 10 点打开课程，学 15 分钟被工作消息打断，之后忘记回来，连续 3 天未登录。
• 场景 2：学员小李完成第 2 章后遇到难题，无答疑入口，卡顿 2 天后放弃继续学习。
• 场景 3：用户小王希望快速通过考试，但课程进度条不显示预估完成时间，无法做学习计划，中途流失。

每个场景对应一个业务问题：

2.3 用户访谈：验证场景假设与挖掘深层痛点

场景清单是假设，必须通过用户访谈验证是否真实存在。访谈结构围绕业务目标倒推设计，避免开放式闲聊。

访谈提纲模板（半结构化）：
1. 筛选条件：近 7 天报名但未完成第 3 章的用户
2. 核心问题：
   - 你通常在什么时间学习？每次学多久？
   - 最近一次中断学习的原因是什么？（追问：当时发生了什么？）
   - 如果有一个功能能帮你坚持学完，你希望它是什么？
3. 验证假设：
   - “是否有过想学但被其他事情打断，之后没再回来的经历？”
   - “遇到难题时，你尝试过哪些方式解决？效果如何？”
4. 优先级判断：
   - 如果只能选一个功能帮你完成课程，你选哪个？为什么？

每完成 5～8 场访谈，对场景假设做一次置信度修正。验证通过率 > 70% 的场景进入需求拆解环节，否则回退重新识别场景。

2.4 需求拆解：从用户问题到功能方案

将验证后的场景痛点转化为可评估的功能方案。拆解遵循“痛点 → 需求 → 功能 → 验收指标”四层结构。

同一痛点可产生多个功能候选，全部纳入待评估清单，后续用 RICE 打分筛选。

2.5 方案表达与指标验证

每个功能候选需用统一模板表达，确保后续 RICE 评分时有足够信息支撑判断。

【功能方案模板】
功能名称：智能学习提醒
痛点关联：场景 1 — 学习连续性差，中断后无召回
用户故事：作为忙碌的职场学员，我希望在中断学习后及时收到提醒，以便快速回到课程继续学习，避免遗忘。
预期行为变化：用户收到提醒 → 点击进入 App → 继续上次学习位置
核心指标：
  - 提醒点击率（目标 ≥ 30%）
  - 提醒后 24h 内回访率（目标 ≥ 50%）
  - 被提醒用户的跟学留存率提升（相对提升 ≥ 15%）
验收标准：
  - 提醒发送成功率 ≥ 99%
  - 点击到继续学习的转化率 ≥ 80%
  - 上线 2 周内跟学留存率正向波动，统计显著

指标验证的底线是可量化、可观测、可归因。无法设置验收标准的功能候选暂不进入 RICE 清单，需补充数据埋点方案后再评审。

2.6 交付物：待评估功能/改进点清单模板

本章最终产出是一份结构化的功能候选清单，用于第 3 章开始进行 RICE 打分。清单字段如下：

至此，案例拆解的第一步完成。这份清单将作为第 3 章 RICE 评分的输入，每个功能候选都会在 Reach、Impact、Confidence、Effort 四个维度上进行量化评估。