第3章 需求优先级排序：Kano模型、MoSCoW方法、价值评估矩阵
3.1 业务问题：需求堆积与资源有限
IoT 产品经理在完成一轮用户访谈后，常常面对 50～80 条原始需求，而开发团队下个迭代的实际产能只能覆盖 30%～40%。缺少科学的优先级排序方法，会导致三种典型问题：
- 团队在低价值需求上浪费人力——例如为 0.1% 的用户定制硬件接口；
- 关键用户场景被延迟——设备离线告警这类基本型需求被当做普通功能排期；
- 产品上市节奏失控——干系人反复拉扯，需求列表每周都在变化。
本章的三种方法（Kano 模型、MoSCoW 方法、价值评估矩阵）可以组合成一个完整的决策框架，帮助产品经理从“什么都要做”转变为“先做什么、怎么做、为什么做”。
IoT 场景提示： 智能硬件领域需求优先级排序的难点在于“硬件改版成本极高、OTA 能力有限”。一旦选错优先级，退回周期可能长达 3～6 个月。
3.2 用户访谈中的需求分类预判
在用户访谈阶段，产品经理可以通过“功能-满意度”假设性问题提前判断需求类型，为后续 Kano 模型分析积累原始数据。以下是一组访谈问题模板：
问题模板（Kano 模型探测）：
1. 如果设备支持【功能 X】，您会觉得非常满意、理所当然、无所谓、勉强接受还是非常不满？
2. 如果设备不支持【功能 X】，您会觉得非常满意、理所当然、无所谓、勉强接受还是非常不满？
选项对照：
非常满意 → 5分 当然满意 → 4分 无所谓 → 3分
勉强接受 → 2分 非常不满 → 1分通过对同一功能的正反两个问题得分组合，可以初步判断需求属于基本型（必须做）、期望型（做得越好越满意）还是兴奋型（超出预期）。
| 功能示例 | 正向回答（有） | 反向回答（无） | 初步分类 |
|---|---|---|---|
| 设备在线状态推送 | 4 – 当然满意 | 1 – 非常不满 | 基本型 |
| App 远程开关响应 < 1 s | 5 – 非常满意 | 2 – 勉强接受 | 期望型 |
| 设备自动识别用户习惯 | 5 – 非常满意 | 4 – 当然满意 | 兴奋型 |
3.3 Kano 模型：从用户场景出发的需求分类
Kano 模型由东京理工大学教授狩野纪昭提出，将需求分为三个核心类别，每个类别对应不同的产品策略：
| 需求类型 | 用户满意度曲线 | IoT 典型场景 | 优先级策略 |
|---|---|---|---|
| 基本型（Must-be） | 不满足 → 极度不满；满足 → 中性 | 设备在线率 ≥ 99.9%、数据不丢包 | 必须满足，否则产品无法上市 |
| 期望型（One-dimensional） | 线性关系：满足越多，满意度越高 | App 控制响应时间、固件 OTA 速度 | 投入越多越好，形成竞争壁垒 |
| 兴奋型（Attractive） | 不满足 → 中性；满足 → 惊喜 | 设备自诊断、自修复、AI 场景推荐 | 选择性投入，打造差异化亮点 |
常见误区： 产品经理容易把“用户抱怨最多的功能”当作兴奋型需求来投入。实际上，抱怨多往往是基本型需求未被满足，正确的做法是先补齐基本型，再规划期望型和兴奋型。
3.4 MoSCoW 方法：干系人共识对齐
MoSCoW 方法帮助产品经理在干系人之间快速达成优先级共识，将需求分为四组：
| 分组 | 含义 | IoT 需求示例 | 占需求总量建议 |
|---|---|---|---|
| M – Must | 本次交付必须实现，否则产品不可用 | 设备入网配置、基础数据上报 | ≤ 40% |
| S – Should | 非常重要，但可以通过变通方案临时替代 | 多用户权限管理 | ≤ 30% |
| C – Could | 有价值，但非核心场景，资源充足时再做 | 语音控制集成 | ≤ 20% |
| W – Won't | 明确本次不做，放入后续迭代或产品路线图 | AI 预测性维护 | ≥ 10% |
实操建议： 在优先级评审会上，让每位干系人用彩色便签对需求进行 MoSCoW 分组，然后对齐差异部分。如果 Must 组超过 40%，说明范围需要进一步裁剪。
3.5 价值评估矩阵：量化决策
价值评估矩阵从商业价值和实现成本两个维度对需求进行打分，将需求放入四个象限：
| 象限 | 商业价值 | 实现成本 | 优先级决策 |
|---|---|---|---|
| 第一象限 | 高 | 低 | 优先做（Quick Win） |
| 第二象限 | 高 | 高 | 规划做（战略投资） |
| 第三象限 | 低 | 低 | 可选做（锦上添花） |
| 第四象限 | 低 | 高 | 放弃做（避免浪费） |
为了减少主观偏差，可以使用加权评分公式进行量化：
优先级得分 = 商业价值 × 0.6 + 用户满意度影响 × 0.4
商业价值 = 收入影响(1-5) × 0.5 + 战略匹配(1-5) × 0.3 + 市场竞争力(1-5) × 0.2
实现成本 = 开发人天 + 硬件改版成本(人天折算) + 测试人天
最终排序 = 优先级得分 / 实现成本 × 100
案例： 某智能门锁产品有两个待办需求——(A) 远程临时密码生成 和 (B) 指纹识别速度优化。通过价值评估矩阵计算后，A 的最终排序得分为 82，B 为 45，产品经理决定将 A 放入 Must 组，B 放入 Should 组。
3.6 三方法协同：完整优先级决策框架
三种方法不是孤立的，而是形成一条从用户价值分类 → 干系人共识 → 量化评分的完整决策链：
具体执行步骤：
- 第一步： 使用 Kano 模型对需求进行用户满意度分类，识别出“基本型”“期望型”“兴奋型”；
- 第二步： 在干系人评审中使用 MoSCoW 方法对需求分组，确保 Must 组不超过 40%；
- 第三步： 对 Must 和 Should 组内的需求进行价值评估矩阵量化打分，输出最终排序列表。
3.7 指标验证与验收标准
优先级排序是否有效，需要通过以下指标和验收标准进行验证：
| 验证维度 | 关键指标 | 验收标准 |
|---|---|---|
| 覆盖率 | 需求优先级覆盖率 | 已排序需求数量 ÷ 总需求数量 ≥ 95% |
| 共识度 | 干系人优先级评分标准差 | 标准差 ≤ 1.2（5 分制） |
| 准确性 | 迭代结束后需求废弃率 | 已实现需求中，被判定为“不必要”的比例 ≤ 10% |
| 满意度 | 干系人对排序结果的满意度评分 | 平均分 ≥ 4.0 / 5.0 |
验收检查清单：
- 每个需求都已标注 Kano 类别、MoSCoW 分组和价值评估得分；
- Must 组需求总量 ≤ 40%；
- 优先级排序结果已通过产品委员会评审并签字确认；
- 排序结果已同步至项目排期工具（如 Jira / 禅道）。
3.8 交付物模板：需求优先级清单
以下模板可作为 PRD 附录中的标准交付物，确保每一条需求都有明确的优先级依据：
| 需求 ID | 需求描述 | 用户场景 | Kano 分类 | MoSCoW 分组 | 商业价值 (1-5) | 实现成本 (人天) | 优先级得分 | 最终排序 |
|---|---|---|---|---|---|---|---|---|
| REQ-001 | 设备离线告警推送 | 用户不在家时设备断网 | 基本型 | Must | 5 | 8 | 82 | 1 |
| REQ-002 | App 远程控制响应 < 1s | 用户远程开关设备 | 期望型 | Must | 4 | 12 | 60 | 2 |
| REQ-003 | 多用户权限管理 | 家庭多成员使用 | 期望型 | Should | 4 | 15 | 48 | 3 |
| REQ-004 | 语音控制集成 | 用户通过音箱控制设备 | 兴奋型 | Could | 3 | 10 | 42 | 4 |
| REQ-005 | AI 预测性维护 | 设备自诊断并提前告警 | 兴奋型 | Won't | 3 | 40 | 15 | 5 |
模板使用说明：
- 优先级得分 = (商业价值 × 0.6 + 用户满意度影响 × 0.4) / 实现成本 × 100；
- 最终排序 按优先级得分从高到低排列，用于指导迭代排期；
- 该模板应在每次迭代开始前更新，并作为 PRD 评审的必备附件。