第2章 适用场景判断：哪些项目需用 RICE+KANO 组合
2.1 适用场景
RICE+KANO 组合并非万能模板，它解决的是 「商业价值 × 用户满意度」交叉排序 的典型难题。以下场景强烈建议使用该组合：
- 跨维度优先级争议 —— 业务方强调 ROI，用户研究员坚持满意度，双方难以对齐时，组合模型提供统一量化框架。
- 需同时评估商业回报与用户情感 —— 例如新功能既能带来收入增长，又可能影响 NPS 评分，需要两个维度联合排序。
- 资源严重受限，需精准分配 —— 研发人力、预算或时间窗口只有 1 个 sprint，必须选出「高商业价值 + 高用户满意度」的少数关键需求。
- 产品进入成熟/精细化运营期 —— 基础功能已完善，需从大量「锦上添花」型需求中筛选出最能撬动用户留存与付费的点。
- 需求池超过 50 条，人工排序失效 —— 依靠经验或投票已无法达成共识，需要结构化模型辅助决策。
💡 判断口诀：「有争议、要兼顾、资源紧、需求多」—— 满足任意两条即应考虑组合模型。
2.2 不适用场景
在以下场景中强行使用 RICE+KANO 反而增加成本、降低效率，应选择更轻量的方法：
| 场景类型 | 典型例子 | 推荐替代方案 |
|---|---|---|
| 纯技术架构选型 | 数据库迁移、框架升级、CI/CD 工具替换 | 技术决策矩阵（Trade-off Matrix） |
| 紧急 Bug / 安全漏洞 | 线上崩溃、数据泄露、支付失败 | 紧急通道直接修复，无需模型排序 |
| 合规/法律强制需求 | GDPR 整改、实名认证、隐私协议更新 | 强制纳入，排序权重设为最高 |
| 资源极度充裕，可并行开发 | 大厂成熟产品线，团队规模 > 50 人且产能富余 | 简单优先级标签（P0/P1/P2）即可 |
| 需求池 < 10 条且无争议 | 小型内部工具、MVP 验证期 | 团队投票 + 用户访谈 |
⚠️ 常见误区：不要将 RICE+KANO 用于「个人日常任务排序」或「非功能型需求（如品牌定位、管理流程）」，模型的数据维度与这些场景不匹配。
2.3 前置条件
执行适用性判断前，必须确认以下条件已满足，否则决策树结果可能失真：
- 功能需求列表已结构化 —— 每条需求有唯一 ID、简要描述、提出方、关联 Epic。
- 团队具备模型基础认知 —— 至少 PO、Scrum Master、技术负责人了解 RICE 四要素（Reach, Impact, Confidence, Effort）和 KANO 五分类（必备、期望、兴奋、无差异、反向）。
- 已有初步数据采集渠道 —— 用户调研配额、埋点事件定义、历史工时数据可用。
- 组织决策层授权使用模型排序结果 —— 避免模型算完却被「拍脑袋」推翻。
2.4 操作步骤：决策树判断流程
按下述 4 个判断步骤依次执行，每步输出「是/否」并走向对应分支，最终得出是否使用 RICE+KANO 组合的结论。
步骤 1：检查需求列表完整性
- 判断依据：是否有 ≥80% 的需求已明确描述并录入需求池？
- 是 → 进入步骤 2。
- 否 → 暂停判断，先完成需求收集与结构化（输出《完整需求清单》），再重新执行步骤 1。
步骤 2：判断是否需要「商业价值 + 用户满意度」双重评估
- 判断依据：本次排序结果是否同时影响收入指标（ARPU、转化率）和体验指标（NPS、CSAT、留存）？
- 是 → 进入步骤 3。
- 否 → 直接输出结论「建议使用单一模型」（如仅关注商业价值用 RICE，仅关注满意度用 KANO）。
步骤 3：排除紧急 Bug 与合规强制需求
- 判断依据：需求池中是否包含「必须在本迭代修复/上线」的紧急 Bug 或法律合规项？
- 是 → 将这些需求标记为「紧急通道」，移出排序池；剩余需求进入步骤 4。
- 否 → 所有需求直接进入步骤 4。
步骤 4：评估资源约束程度
- 判断依据：可用资源（人力、时间、预算）能否覆盖需求池中前 30% 需求的同时开发？
- 是 → 输出结论「建议使用单一模型」（资源充裕，无需精细排序）。
- 否 → 输出结论「适合使用 RICE+KANO 组合」。
—— 资源有限且需同时权衡商业与体验，正是组合模型的最佳发力点。
2.5 输入输出物
| 阶段 | 输入物 | 输出物 | 格式要求 |
|---|---|---|---|
| 步骤 1 | 原始需求收集记录 | 结构化需求清单（含 ID、描述、提出方、Epic） | Excel / Airtable |
| 步骤 2 | 业务目标文档、用户体验目标文档 | 双重评估必要性结论（是/否） | 决策日志 |
| 步骤 3 | 当前迭代 Backlog、Bug 列表、合规清单 | 紧急通道需求标记列表 | Jira 标签 / 看板列 |
| 步骤 4 | 团队产能数据（Velocity）、预算剩余 | 资源约束评估结果 + 最终模型建议 | 决策树输出卡片 |
2.6 责任分工
| 角色 | 职责 | 关键产出 |
|---|---|---|
| 产品负责人 (PO) | 发起判断流程，确认业务目标与资源约束，签署最终结论 | 决策日志、模型使用授权 |
| 需求分析师 (BA) | 整理需求列表，执行决策树步骤，记录分支选择理由 | 结构化需求清单、决策树输出卡片 |
| 技术负责人 | 提供 Effort 估算（RICE 维度），确认紧急 Bug 标记 | 工时估算表、紧急通道标记 |
| 用户研究员 | 提供用户满意度数据来源，协助判断是否需要双重评估 | 用户目标文档、满意度数据可用性评估 |
2.7 常见异常及处理措施
| 异常现象 | 可能原因 | 处理措施 |
|---|---|---|
| 需求列表长期不完整，反复卡在步骤 1 | 需求采集流程缺失，或干系人配合度低 | 启动「需求补全工作坊」，设定截止日期；PO 对未按时提交的需求暂不纳入排序 |
| 业务方与用户研究员对「双重评估」意见不一 | 缺乏量化证据证明两个维度都会受显著影响 | 引用历史数据或竞品案例做「影响面预估」；若仍无法达成一致，按「是」处理（保守使用组合模型） |
| 紧急 Bug 和合规需求占比 > 40% | 迭代规划节奏过紧，或合规工作积压 | 将这些需求移出排序池后，若剩余需求 < 10 条，直接走单一模型；同时向管理层反馈资源瓶颈 |
| 资源约束判断结论与团队感受明显矛盾 | 产能数据不准确或资源计算口径不一致 | 回顾最近 3 个迭代的 Velocity 中位数，统一按「人天」计算；如有疑义，以 PO 最终裁定为准 |
2.8 验收标准
完成本章学习与实践后，应能达成以下验收项（用于课程结业或团队内部评审）：
- 决策树走通率 100% —— 任意给定一个需求池，能按 4 个步骤走完并输出明确结论（不卡在任一步骤）。
- 场景分类准确率 ≥ 90% —— 随机抽取 10 个真实项目场景，正确识别「适用」「不适用」且理由充分。
- 异常场景有预案 —— 针对 2.7 节列出的 4 类异常，能口述或书面给出处理措施，无需查阅资料。
- 输出物完整且格式合规 —— 提交的决策树输出卡片包含：需求列表快照、每一步的「是/否」选择及依据、最终模型建议、签字确认人。
✅ 本章核心交付：一张填写完整的「RICE+KANO 组合适用性决策树输出卡片」，包含 4 步判断结论与责任人签字。