用户需求分析方法
# 用户需求分析方法
用户访谈、用户故事地图、Kano 模型——区分"想要"和"需要"
# 一、需求分析的起点：用户不是说谎，是不知道自己想要什么
亨利·福特说过：「如果我问用户要什么，他们会说一匹更快的马。」
用户说的"需求"（want）和真正的"需要"（need）之间有一道沟——需求分析的任务就是跨过这道沟。
从"想要马"到"想要汽车"的过程：
用户说的： "我要一匹更快的马"
↓ 追问
真实场景： 每天通勤 2 小时去城里卖货，马一天只能跑 80 里
↓ 追问
深层痛点： 运输效率低（不是马不够快，是运力上限）
↓ 方案
真正的需要： 一种比马更快、运力更大、可持续更久的交通工具
↓
解决方案： 汽车
需求分析的三个层次：
| 层次 | 问题 | 例子 |
|---|---|---|
| 表层 | 用户说了什么 | "加一个导出按钮" |
| 场景层 | 用户在什么场景下需要 | "运营每周一需要导出数据做报表" |
| 动机层 | 用户为什么需要——完成什么任务 | "需要向上级汇报上周的用户增长数据" |
大多数人停在表层就开始写代码。需求分析的价值就是把问题推进到场景层和动机层。
# 二、用户访谈：不是"问想要什么"，是"看在做什么"
# 2.1 访谈的正确姿势
❌ 错误问法——引导性问题（用户顺着你说，但不说真话）：
- "如果我们加一个一键分享功能，你会用吗？" → 用户：「会啊」（真到上线那天并不会）
- "你觉得这个页面哪里不好用？" → 用户：「还行，挺好的」（不想伤你面子）
- "你希望这个功能怎么改进？" → 用户陷入沉默（他们不是产品经理）
✅ 正确问法——行为导向问题：
- "上一次你分享内容给朋友，是怎么做的？" → 看实际行为
- "可以演示给我看看你平时是怎么处理订单的？" → 观察操作
- "你上次遇到这个问题的时候，是怎么绕过去的？" → 发现变通方案（这是金矿）
核心原则：问过去的行为，不要问未来的意愿。
# 2.2 访谈的黄金 5 问
每次用户访谈，不论场景，这 5 个问题覆盖了需求分析的关键信息：
| # | 问题 | 目的 |
|---|---|---|
| 1 | 能不能给我看看你平时是怎么做这件事的？ | 观察真实行为，不是听描述 |
| 2 | 这个过程中最花时间/最烦人的一步是什么？ | 定位痛点的精确位置 |
| 3 | 如果这一步消失了，接下来你会做什么？ | 判断痛点是不是关键节点 |
| 4 | 你以前用过什么工具/方法解决这个问题？ | 发现竞品和替代方案 |
| 5 | 对于这个问题，你自己有什么想法吗？ | 用户可能是最好的产品经理 |
# 2.3 工程师如何做轻量访谈
工程师不太可能像产品经理一样约 2 小时用户访谈。但你有几个天然的触点：
- oncall/工单群里用户反馈——追问一句"可以截个图给我看看吗？"
- 测试环境 UAT 时——站在测试人员旁边看他们操作，观察哪里卡住了
- 上线后前 3 天——主动点开用了新功能的用户埋点路径，看有没有"走一步退一步"的行为
工程师的特殊优势：你可以看日志。用户说"加载很慢"是主观感受；你查 Nginx 日志看到这个接口 P99 是 4.2 秒——这是客观事实。结合两者，需求分析更准确。
# 三、用户故事地图：把需求串成用户旅程
# 3.1 什么是用户故事地图
用户故事不是零散的一个个"功能需求"——它们属于用户完成某个任务的步骤。用户故事地图把这些步骤按时间顺序排列，形成一条完整的用户旅程。
用户故事地图结构：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
活动 (Activity) "购物"
│
├── 任务 (Task) "浏览商品"
│ ├── 故事 (Story) 用户打开首页 → 看到推荐商品
│ ├── 故事 (Story) 用户搜索 "蓝牙耳机"
│ └── 故事 (Story) 用户在结果列表里翻页
│
├── 任务 (Task) "加入购物车"
│ ├── 故事 (Story) 用户查看商品详情
│ ├── 故事 (Story) 用户选择型号（颜色/容量）
│ └── 故事 (Story) 用户点击"加入购物车"
│
└── 任务 (Task) "付款"
├── 故事 (Story) 用户进入购物车
├── 故事 (Story) 用户选择支付方式
└── 故事 (Story) 用户完成支付
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
↑
按优先级从上到下排列（最上面 = MVP）
# 3.2 为什么要画地图
当你把故事铺在地图上——会发现三类"盲区"：
- 缺失的步骤：用户的旅程在某个环节断了——"浏览商品"和"付款"之间缺了"查看订单详情"。
- 瓶颈步骤：某个步骤有 10 个故事堆在上面（说明太复杂），但用户的真实需求可能只需要其中 3 个。
- 不属于这条旅程的"异物"：有些需求在地图上没地方放——说明它们根本不属于这个用户场景。
# 3.3 5 分钟快速画法（适合工程师）
工具：白板或在线白板（Miro / Excalidraw），不要用任何专业工具。
步骤：
- 横着写：用户完成一个任务的主要步骤（3-5 步即可，不用太细）
- 纵着写：每个步骤下，列出需要做的事（每件事一张便利贴）
- 画一条水平线——线上 = MVP（第一个版本必须做的），线下 = 以后迭代的
- 拍照保存——这就够了，不需要任何软件
# 四、Kano 模型：区分"做了加分"和"不做扣分"
# 4.1 五类需求
Kano 模型把所有功能分成五类——帮你做优先级决策：
用户满意度
↑
│ ╱ 兴奋型（魅力型）───── "没想到你们有这个！"
│ 线性型（一维型）"越多越好"
│ ╱
│ ╱
├────基本型（必备型）"没有这个居然还能叫产品？"
│
│ 无差异型 ──────────────── "有没有无所谓"
│
│ 反向型 ──────────────── "越做用户越烦"
└──────────────────────────────→ 功能实现程度
| 类型 | 特征 | 例子 | 策略 |
|---|---|---|---|
| 基本型 | 不做=严重不满，做了=理所当然 | 登录功能、支付安全、数据不丢 | 必须做——没得商量 |
| 线性型 | 越好用户越满意 | 页面加载速度、客服响应速度 | 持续投入——越好越好 |
| 兴奋型 | 没有=无所谓，有=惊喜 | 首次使用的引导动画、个性化推荐 | 少量投入——做亮点 |
| 无差异型 | 有没有用户不在意 | 某个没人用的设置项 | 别做——浪费资源 |
| 反向型 | 做了反而让用户不爽 | 强制弹窗广告、自动播放视频 | 坚决不做 |
# 4.2 怎么判断一个需求属于哪类
用 Kano 问卷——每个需求问用户两个问题：
需求：App 启动时展示 3 秒开屏广告
正向问题：如果 App 有开屏广告，你感觉如何？
□ 我喜欢 □ 理所当然 □ 无所谓 □ 勉强接受 □ 不喜欢
反向问题：如果 App 没有开屏广告，你感觉如何？
□ 我喜欢 □ 理所当然 □ 无所谓 □ 勉强接受 □ 不喜欢
根据两个问题的回答组合，查 Kano 评价表（网上一搜就有），就能判断这个需求属于哪类。
快速判断法（不用问卷）——问自己：
- "这个功能如果现在砍掉——用户会骂吗？" → 会 → 基本型（或线性型）
- "这个功能竞品都有吗？" → 都有 → 大概率是基本型。都没有 → 可能是兴奋型。
- "这个功能有人提过吗？" → 没人提过 → 大概率是无差异型。
# 4.3 工程师视角的 Kano 应用
你的日常任务列表里，可能有 10 个需求。用 2 分钟给每个需求标上 Kano 分类：
本周需求：
✅ [基本型] 修复支付回调丢失导致订单不更新的 bug ← 不上线用户要疯
✅ [线性型] 商品搜索从 800ms 优化到 200ms ← 越快转化越高
⬜ [兴奋型] 购物车增加"降价提醒"功能 ← 有时间再做
❌ [无差异型] 订单列表页支持"按时间排序"（已有默认排序够用了）
这个分类让你和产品经理讨论优先级时，有共同的判断框架——而不是争论"我觉得这个重要"。
# 五、综合案例：从需求到方案
场景：某电商后台，运营人员说"需要一个批量改价功能"。
1. 用户访谈（5 分钟）
问：能不能给我看看你现在是怎么改价的？ → 运营打开一个 Excel，里面有 200 行 SKU 和价格，手动一个一个在后台改。每次大促前要改 500+ 个 SKU，花 4 小时。
问：最烦人的是哪一步？ → "后台一次只能改一个商品。我得在 Excel 和后台之间来回切，手都点麻了。"
2. 故事地图（2 分钟）
改价流程：
登录后台 → 找到商品 → 修改价格 → 保存 → 确认生效 → 下一个商品（重复 500 次）
↑ 这是瓶颈——每次只能一个
3. Kano 分类（1 分钟）
- 批量导入 Excel 改价 → 基本型（大促是核心业务，没这个运营干不了活）
- 改价后自动发通知给供应商 → 兴奋型（锦上添花但不是必须）
- 改价历史记录和回滚 → 基本型（改错了能撤回——必须的）
4. 方案输出（不是写代码——先定方案）
不要上来就设计"批量导入的数据库结构"。先用一句话定义方案：
做一个 Excel 导入功能，运营上传含 SKU+新价格的表格，系统批量更新。支持预览（改之前看看对不对）、执行（提交变更）、回滚（改错了可以撤回）。
这句话里已经包含了：谁用（运营）、怎么用（上传 Excel）、核心流程（预览→执行→回滚）。
# 六、Jobs-to-be-Done：用户"雇佣"你的产品干什么
# 6.1 JTBD 的核心思想
Kano 模型回答"需求做不做"，JTBD 回答"需求本身是什么"——比"用户想要什么"更根本的问题：用户"雇用"你的产品来完成什么任务？
哈佛教授 Clayton Christensen 提出的经典案例：
麦当劳想提高奶昔销量。
传统思路: 调查"你想要更浓的奶昔吗？加果粒？更便宜？"
JTBD 思路: 观察谁在什么时候买奶昔，买完干什么
结果: 早晨通勤的上班族是主要购买者
——他们"雇用"奶昔来完成:
"在无聊的堵车路上，一只手能拿住、慢慢喝 20 分钟、可以撑到午饭的早餐"
竞争对手不是其他奶昔——是面包圈、香蕉、能量棒。
# 6.2 用户需求 vs 用户任务
| 用户说（需求） | 背后的任务（JTBD） | 完全不同的解法 |
|---|---|---|
| "我要导入 Excel 功能" | "我不想手工录入 200 条数据" | 自动读取第三方数据源 API |
| "我要消息已读回执" | "我想确认对方看到了我的消息" | 显示"对方正在输入…"就够了 |
| "我要更快的搜索" | "我不想翻菜单找目标" | 快捷操作、最近使用、收藏 |
# 6.3 工程师如何用 JTBD
最实用的 JTBD 句式——接需求时在心里填这个空：
当 [场景] 时，我想 [做什么]，以便 [达成结果]
例如："当我在钉钉聊需求时，我想关联 Jira 工单，以便不需要切换窗口"——这个任务的竞品不是其他项目管理工具，是多窗口切换本身。
# 6.4 JTBD + Kano 组合使用
原始需求: "做一个通知中心"
↓ JTBD: 用户真正要的任务是什么？
→ "我想在不打开 App 的情况下知道有没有新消息"
↓ 对应的解法:
→ ① 系统推送（基本型，必须做）
→ ② 桌面小组件（兴奋型，加分项）
→ ③ App 内通知分类+折叠（期望型，做了更好）
↓ Kano 分类 → ① P0 → ② P2 → ③ P1
# 七、访谈后的分析：从原始对话到可执行洞察
# 7.1 亲和图法（Affinity Mapping）
做完 5 场用户访谈，得到一墙便利贴——怎么把散乱的文字变成行动？
第 1 步: 把每一条用户原话写在便利贴上（不归纳、不改写）
第 2 步: 把所有便利贴贴在白板上，沉默分组（每个人自己看、自己挪）
第 3 步: 形成 5-8 组后，给每组一个概括标题
第 4 步: 投票——每个工程师 3 个点，投给"最让我意外/最值得解决"的组
第 5 步: 得票最高的 3 组 → 下一迭代的需求池
为什么有效：沉默分组避免了"声音最大的人主导归类"；"意外"比"重要"更有信息量——你已经知道的重要的事不需要访谈。
# 7.2 五个常见的访谈分析错误
| 错误 | 例子 | 修正 |
|---|---|---|
| 过早抽象 | "用户想要更好的体验" | 保留原话："每次搜索要等 3 秒，我就切出去刷抖音了" |
| 只记自己认可的 | 做了 5 场访谈，只写支持自己假设的 20% | 把和预期相反的用户原话红色标记——最有价值 |
| 把单人意见当群体需求 | "5 个里 1 个说想要 XX" | 1/5 是信号，5/5 是方向。1/5 先验证，5/5 直接做 |
| 忽略用户没说的 | 提了 8 个功能需求，没提"速度" | "速度不差"可能是基本型需求 → 用 Kano 问卷验证 |
| 跳过沉默的大多数 | 只访谈到活跃用户 | 约 3 个"最近一个月没登录"的用户——沉默就是最重要数据 |
# 八、Kano 模型的三个隐秘陷阱
# 8.1 陷阱一：需求类型会随时间漂移
三年前让用户"哇"的自动保存功能，今天如果没有——用户会骂。昨天的兴奋型就是今天的基本型。
| 时间 | 自动保存功能 | 类型 | 用户心理 |
|---|---|---|---|
| 2015 | "它能自动保存！" | 兴奋型 | "好神奇" |
| 2020 | 大部分编辑工具都有了 | 期望型 | 做得不好就换 |
| 2025 | 操作系统原生支持 | 基本型 | 不提供就不用了 |
应对：每个季度做一次 Kano 重评——对 3 个月以上的功能重新跑一遍问卷。
# 8.2 陷阱二：Kano 不适合评估基础设施需求
"换 CDN""数据库迁移""安全漏洞修复"——用户感知不到，Kano 问卷问不出什么。
应对：基础设施类需求用风险量化替代——"不做这个，未来 3 个月出问题的概率 × 影响用户数 = 预期损失"。
# 8.3 陷阱三：社会期望偏差
用户被问到"如果有 XX 功能你会用吗"——大概率说"会"。因为说不用的用户显得自己"不懂欣赏创新"。
应对：不问"你会用吗"，问"把你现有的功能砍掉一个换这个，你砍哪个"。强迫 trade-off 才能测出真实意愿。
# 九、小结
需求分析不是"记下用户说的话然后去实现"。它是：
- 访谈——观察行为，不要听声称
- JTBD——问"用户雇用你做什么任务"，比"你想要什么"更深一层
- 故事地图——把零散需求串成完整旅程，发现缺失和冗余
- Kano 模型——分类需求，知道什么必须做、什么可做可不做
- 亲和图——把原始对话转成可执行的洞察
工具配合使用：
用户访谈 → 收集原始素材
↓
亲和图法 → 从对话中提取核心洞察
↓
JTBD → 识别真实任务，过滤表面需求
↓
故事地图 → 组织成完整场景，画 MVP 线
↓
Kano 模型 → 分类标注，定开发优先级
↓
一个需求分析就完成了——可以进入技术方案了
