1.1 课程全景与KANO模型基础
适用场景
KANO 模型适用于以下场景中的需求优先级排序与用户满意度影响分析：
- 产品功能规划：大量候选需求需要筛选，确定“做哪些、先做谁”
- 用户细分调研：不同用户群体对同一功能的接受程度差异显著
- 存量功能优化：已有功能体验不佳，判断属于“必备属性”缺失还是“魅力属性”不足
- 竞品功能对标：对比竞品功能包中哪些是“基本款”、哪些是“加分项”
- 版本迭代定级：敏捷开发中决定当前迭代的 MVP 边界
前置条件
- 已完成用户角色定义与典型场景梳理
- 具备至少一种结构化访谈方法基础（如行为事件访谈 BEI 或深度访谈）
- 待分类功能列表已形成初版，条目颗粒度一致（无过粗或过细条目）
- 团队至少 1 人掌握 KANO 分类矩阵的判别规则
操作步骤
步骤1 - 定义需求池
将待评估功能整理为功能条目清单，每条只描述一个单维度能力。例如：
需求池示例条目标
─────────────────────
F001：支持微信扫码登录
F002：项目看板支持拖动排序
F003：日志自动归档至云端
F004：多人实时协同编辑同一文档
F005：离线模式下可浏览最近七日文件步骤2 - 设计正反提问
每个功能需同时设定正向问题（提供该功能时用户感受）与反向问题（不提供该功能时用户感受）。
| 问题类型 | 问题措辞示例（以“微信扫码登录”为例） |
|---|---|
| 正向问题 | 如果系统支持微信扫码登录，您会觉得如何？ |
| 反向问题 | 如果系统不支持微信扫码登录，您会觉得如何？ |
步骤3 - 执行用户访谈
- 每个功能均需获得被访者对“正向+反向”两份评价选项的选择
- 选项标准：喜欢 / 理应如此 / 无所谓 / 勉强接受 / 不喜欢
- 单次访谈不宜超过 30 分钟，每个功能正反问题控制在 1 分钟以内
步骤4 - 填入分类矩阵
根据被访者对正向与反向问题的答案组合，对照 KANO 分类矩阵判定该功能属于哪类需求。
典型误用：将“无所谓+无所谓”直接判定为“无差异需求”，而忽略用户可能因不理解功能价值而做出“中性”选择。应在访谈后添加一句了解性问题：“您为什么会选无所谓？”
KANO 五类需求定义
| 需求类别 | 定义 | 用户满意度影响 |
|---|---|---|
| 基本型需求（M） | 用户认为“必须有”的功能；不提供则非常不满意，提供后用户认为理所当然 | 不满足→严重不满；满足→无感激 |
| 期望型需求（O） | 用户已知且明确期待的功能；提供越多满意越高，不提供则不满意 | 线性相关：提供程度与满意度正相关 |
| 魅力型需求（A） | 用户未预期、但一旦提供会带来惊喜的功能；不提供也无不满，提供则极大满意 | 不满足→无影响；满足→高度满意 |
| 无差异需求（I） | 用户完全不关心该功能；提供与否不影响满意度 | 无显著波动 |
| 反向需求（R） | 用户明确表示不希望该功能存在；提供后满意度下降 | 提供→满意度降低 |
分类矩阵图
以下矩阵展示了正向问题（行）与反向问题（列）的交叉结果，各单元格内容表示最终分类结论：
| 正向\反向 | 喜欢 | 理应如此 | 无所谓 | 勉强接受 | 不喜欢 |
|---|---|---|---|---|---|
| 喜欢 | Q* | A | A | A | O |
| 理应如此 | R | I | I | I | M |
| 无所谓 | R | I | I | I | M |
| 勉强接受 | R | I | I | I | M |
| 不喜欢 | R | R | R | R | Q* |
* Q = 可疑结果，常见于被访者理解错误或题目措辞有歧义，需重新采集数据。
误用风险
- 矩阵结果绝对化：单次访谈样本量不足时，矩阵给出的是“该受访者视角下的分类”，不等于全体用户共识
- 混合需求条目：一个需求条目若包含多个子功能，正反问题无法准确映射单一维度，导致分类混乱
- 忽略用户理解偏差：功能描述过于技术化或激进，用户可能在“喜欢”与“理应如此”间凭猜测作答
- 反向需求误判：部分用户出于“不想增加系统复杂度”而选择“不喜欢”，但实际使用后接受度高；需结合上下文判断
实战建议：每个功能至少收集 30 份有效访谈记录后再做统计分类；若某功能正反回答在“O”与“A”间摇摆超过 20%，应单独回访澄清。
输入输出物
| 阶段 | 输入物 | 输出物 |
|---|---|---|
| 步骤1 | 产品功能列表（初版） | 原子化需求条目清单 |
| 步骤2 | 原子化需求条目清单 | 正反问题采访提纲（含问题措辞） |
| 步骤3 | 正反问题采访提纲 | 原始访谈记录（含正反选择答案） |
| 步骤4 | 原始访谈记录 | 需求-KANO分类对照表 |
责任边界
- 需求分析人员：负责设计正反问题、执行访谈、填写分类矩阵
- 产品经理：审核需求条目颗粒度、确认访谈范围，使用分类结果进行优先级决策
- 用户研究员：若团队独立配置，负责管控访谈质量及问卷回收率
- 开发团队：不参与分类判定，但在需求描述不清晰时提供技术可行性补充
记录材料
每个功能条目保存以下记录：
- 需求编号与文字描述
- 正向问题 + 反向问题措辞原文
- 每名受访者的正反选择复盘（不计名但保留数量统计）
- 矩阵判定结果（M/O/A/I/R/Q）
- 若结果为 Q（可疑），需附加备注：受访者理解诊断记录
异常处理
| 异常现象 | 原因 | 处理措施 |
|---|---|---|
| 大量 Q 结果 | 题目措辞歧义或受访者疲劳 | 暂停访谈，重新审题再启新一轮 |
| 某个功能所有受访者分类不一致 | 需求颗粒度不原子，或用户场景差异大 | 拆分为子条目，或按用户角色分群统计 |
| 受访者频繁选“无所谓” | 对功能域不熟悉或动力不足 | 增加功能 Demo 演示后重新提问 |
| 反向需求比例超过 30% | 功能设计可能过度复杂或非用户痛点 | 与产品经理确认初步决策，考虑砍掉或做 AB 验证 |
验收标准
- 每个需求条目至少完成 30 份有效访谈（Q 结果不计入有效样本数）
- 分类矩阵中无空白单元格或未经记录的“推测”结果
- 需求-KANO分类对照表已归档至项目知识库，可被产品经理及开发团队直接引用
- 本次课程基础部分完成后，学员能独立输出一份包含所有五类需求的分类对照表