2. 优先级决策的四种经典框架：MoSCoW、Kano、WSJF、RICE 适用场景
2.1 适用场景（何时使用框架）
当需求 backlog 不断膨胀、利益相关方意见严重分歧，或交付时间与质量之间存在明显冲突时，就需要引入结构化优先级框架来替代“拍脑袋”决策。不同的框架适用于不同的业务上下文的“游戏规则”。
2.2 前置条件（启动框架的基础）
- 明确的产品战略目标与迭代/发布周期。
- 经过初步澄清的功能列表（Epic / User Story）。
- 关键利益相关方（PO、业务负责人、开发代表）的参与承诺。
- 基础的量化数据（用户量、转化率、开发工时估算能力）。
2.3 四种框架结构对比（操作步骤与输入输出物）
以下按照 SOP 格式，逐一拆解 MoSCoW、Kano、WSJF、RICE 的适用情境与操作流程。首先通过决策逻辑图找到当前项目的主要约束条件。
2.3.1 MoSCoW 模型
| SOP 环节 | 说明 |
|---|---|
| 适用场景 | 交付时间线绝对固定，范围可协商。常见于季度版本发布、政府项目。 |
| 前置条件 | 用户故事已拆分并验收；利益相关者已组织；交付日期已定。 |
| 操作步骤 | 1. 集体评审所有故事。2. 按 Must / Should / Could / Won't 归类。3. 检查 Must 占比是否不超过 60%。4. 责任方签字确认。 |
| 输入输出物 | 输入：用户故事列表。输出：带 MoSCoW 标签的 Backlog。 |
| 责任边界 | PO 主导分类；SM 把控时间盒；开发团队评估技术可行性。 |
| 记录材料 | 需求优先级定级确认表。 |
| 异常处理 | 所有项均为 Must → 强制要求 PO 重新排序并删减 20% 条目。 |
| 验收标准 | 团队与业务方对分类无异议；迭代计划可覆盖所有 Must 项。 |
2.3.2 Kano 模型
| SOP 环节 | 说明 |
|---|---|
| 适用场景 | 评估功能对用户满意度的影响，寻找兴奋点。适用于 0-1 创新或满意度优化。 |
| 前置条件 | 用户画像清晰；已定义功能假设列表；具备调研工具（如问卷平台）。 |
| 操作步骤 | 1. 设计 Kano 双向问卷。2. 投放给目标用户。3. 根据 Better-Worse 系数归类（基本型、期望型、兴奋型、无差异型）。4. 排期优先顺序：兴奋型 > 期望型 > 基本型。 |
| 输入输出物 | 输入：功能假设。输出：Kano 分类矩阵。 |
| 责任边界 | PM 设计问卷；用户体验设计师分析结果；PO 进行排期决策。 |
| 记录材料 | Kano 问卷原始数据、Better-Worse 散点图。 |
| 异常处理 | 结果矛盾（如某功能同时为基本与兴奋）→ 需通过用户访谈定性确认。 |
| 验收标准 | 团队明确区分“必备项” |