第3章 需求优先级排序矩阵：Kano模型、MoSCoW方法、价值-复杂度四象限
核心目标：通过三种互补的优先级排序工具，将原始用户需求转换为分级、可量化的硬件开发路线图输入。本章提供从“需求收集”到“排定交付批次”的标准操作流程。
适用场景
- 产品团队已收集超过20条用户需求，需要确定首次硬件迭代（V1.0）的必做与选做项。
- 多项目并行时，需要快速识别高价值、低复杂度的“低挂果实”需求。
- 需求方、研发、项目经理对优先级争议较大，需要结构化决策依据。
前置条件
- 已完成用户需求清单（至少包含需求ID、原始描述、来源角色）。
- 产品经理具备基本的用户调研数据（如满意度问卷、竞品对标报告）。
- 参与排序的干系人（产品、研发、测试、市场）已对齐评分标准（见下表）。
| 评分维度 | 定义 | 示例 |
|---|---|---|
| 用户价值 | 需求被满足后用户满意度提升程度 | 续航增加50% → 高价值；按钮颜色 → 低价值 |
| 技术复杂度 | 实现该需求所需的研发周期、风险及资源 | 新增传感器模块 → 高复杂度；修改固件参数 → 低复杂度 |
| 业务紧迫度 | 不实现该需求对市场窗口或合规的影响 | 法规要求安全认证 → 极高紧迫度 |
操作步骤
步骤1：Kano模型分类（用户满意属性）
将每条需求按照“具备时的满意度”和“缺失时的不满意度”分为五类：
- 基本型（M）：必须满足，缺失则用户强烈不满。
- 期望型（O）：与满意度正相关，满足越多越满意。
- 兴奋型（A）：用户未预期，但提供后惊喜，缺失无影响。
- 无差异型（I）：有无不影响满意度。
- 反向型（R）：提供后反而降低满意度。
操作技巧：设计双项选择题问卷（正向/反向），通过Kano评估表自动归入对应类别。硬件场景下建议先以小组专家评估法替代大规模问卷，降低周期成本。
步骤2：MoSCoW方法（交付优先级）
在Kano分类基础上，结合业务目标将需求标记为四个等级：
- Must have（必须有）：基本型需求 + 法规/底线要求。
- Should have（应该有）：期望型中价值高的需求。
- Could have（可以有）：兴奋型 / 低价值期望型。
- Won't have（本次不做）：无差异型 / 反向型 / 复杂度极高的备选。
步骤3：价值-复杂度四象限（最终排序）
将Must、Should类需求放入四象限矩阵，X轴为技术复杂度（低→高），Y轴为用户价值（高→低）：
- 第一象限（高价值-低复杂度）：优先实现，首批交付。
- 第二象限（高价值-高复杂度）：规划为第二批次或迭代。
- 第三象限（低价值-低复杂度）：可延后或作为锦上添花。
- 第四象限（低价值-高复杂度）：坚决砍掉或放至远期。
常见偏差：研发容易将高复杂度需求误判为“高价值”，可以用市场数据和竞品对标拉回评审；运营容易将低价值需求误标为“Must have”，需回归Kano基本型定义。
输入输出物
| 阶段 | 输入物 | 输出物 |
|---|---|---|
| Kano分类 | 需求清单（含原始描述）、用户调研数据 | Kano类别标签（M/O/A/I/R） |
| MoSCoW分级 | Kano分类结果、路线图约束（时间/资源） | MoSCoW标签（Must/Should/Could/Won't） |
| 四象限排序 | Must+Should需求、复杂度/价值评分表 | 最终Roadmap节点清单（含批次归属） |
责任边界
- 产品经理：主导Kano分类与四象限排序，输出最终优先级清单。
- 研发负责人：提供技术复杂度评分及实现可行性风险。
- 市场/销售：提供用户价值与竞品对标数据。
- 项目经理：依据最终清单制定迭代计划，并监控异常偏离。
记录材料
- Kano分类工作底稿（含每项需求的分类理由）
- MoSCoW评审会议纪要（记录争议点与最终裁决）
- 价值-复杂度四象限气泡图（可使用Excel或Miro导出）
- 优先级排序最终审批单（需产品总监签字）
异常处理
| 异常场景 | 处理措施 |
|---|---|
| 某需求Kano分类争议大（如一半人认为基本型，一半认为兴奋型） | 追加用户调研样本（至少30份有效问卷），或按“保守原则”归为基本型。 |
| MoSCoW中Must需求超过资源容量50% | 触发Red Flag机制：必须与产品委员会协商砍掉部分Should/Could需求，或调整路线图时间轴。 |
| 四象限中所有需求都集中在高复杂度区域 | 组织架构层面成立预研项目组，将部分高复杂度需求拆分为“技术预研”任务，不占用交付节点。 |
| 市场/研发对价值评分分歧超过2档 | 强制以“外部客户付费意愿”作为最终评判标准，必要时安排客户访谈。 |
验收标准
- 每条需求已打上Kano类别标签，且标签有效（M/O/A/I/R无遗漏）。
- MoSCoW分级结果中 Must + Should 需求数量不超过团队交付能力的120%（预留缓冲）。
- 价值-复杂度四象限图已生成，并标注了首批交付节点的需求ID。
- 干系人（产品、研发、测试、市场）在最终优先级清单上签字确认，无“未解决的争议项”。
流程SOP提示：优先级排序并非一次性活动，硬件Roadmap每季度应重新执行一次上述步骤（尤其当市场环境或技术方案发生重大变化时）。