用户需求分析方法
# 用户需求分析方法
用户访谈、用户故事地图、Kano 模型——区分"想要"和"需要"
# 一、需求分析的起点：用户不是说谎，是不知道自己想要什么
亨利·福特说过：「如果我问用户要什么，他们会说一匹更快的马。」
用户说的"需求"（want）和真正的"需要"（need）之间有一道沟——需求分析的任务就是跨过这道沟。
从"想要马"到"想要汽车"的过程：
用户说的： "我要一匹更快的马"
↓ 追问
真实场景： 每天通勤 2 小时去城里卖货，马一天只能跑 80 里
↓ 追问
深层痛点： 运输效率低（不是马不够快，是运力上限）
↓ 方案
真正的需要： 一种比马更快、运力更大、可持续更久的交通工具
↓
解决方案： 汽车
2
3
4
5
6
7
8
9
需求分析的三个层次：
| 层次 | 问题 | 例子 |
|---|---|---|
| 表层 | 用户说了什么 | "加一个导出按钮" |
| 场景层 | 用户在什么场景下需要 | "运营每周一需要导出数据做报表" |
| 动机层 | 用户为什么需要——完成什么任务 | "需要向上级汇报上周的用户增长数据" |
大多数人停在表层就开始写代码。需求分析的价值就是把问题推进到场景层和动机层。
# 二、用户访谈：不是"问想要什么"，是"看在做什么"
# 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）
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 3.2 为什么要画地图
当你把故事铺在地图上——会发现三类"盲区"：
- 缺失的步骤：用户的旅程在某个环节断了——"浏览商品"和"付款"之间缺了"查看订单详情"。
- 瓶颈步骤：某个步骤有 10 个故事堆在上面（说明太复杂），但用户的真实需求可能只需要其中 3 个。
- 不属于这条旅程的"异物"：有些需求在地图上没地方放——说明它们根本不属于这个用户场景。
# 3.3 5 分钟快速画法（适合工程师）
工具：白板或在线白板（Miro / Excalidraw），不要用任何专业工具。
步骤：
- 横着写：用户完成一个任务的主要步骤（3-5 步即可，不用太细）
- 纵着写：每个步骤下，列出需要做的事（每件事一张便利贴）
- 画一条水平线——线上 = MVP（第一个版本必须做的），线下 = 以后迭代的
- 拍照保存——这就够了，不需要任何软件
# 四、Kano 模型：区分"做了加分"和"不做扣分"
# 4.1 五类需求
Kano 模型把所有功能分成五类——帮你做优先级决策：
用户满意度
↑
│ ╱ 兴奋型（魅力型）───── "没想到你们有这个！"
│ 线性型（一维型）"越多越好"
│ ╱
│ ╱
├────基本型（必备型）"没有这个居然还能叫产品？"
│
│ 无差异型 ──────────────── "有没有无所谓"
│
│ 反向型 ──────────────── "越做用户越烦"
└──────────────────────────────→ 功能实现程度
2
3
4
5
6
7
8
9
10
11
12
13
| 类型 | 特征 | 例子 | 策略 |
|---|---|---|---|
| 基本型 | 不做=严重不满，做了=理所当然 | 登录功能、支付安全、数据不丢 | 必须做——没得商量 |
| 线性型 | 越好用户越满意 | 页面加载速度、客服响应速度 | 持续投入——越好越好 |
| 兴奋型 | 没有=无所谓，有=惊喜 | 首次使用的引导动画、个性化推荐 | 少量投入——做亮点 |
| 无差异型 | 有没有用户不在意 | 某个没人用的设置项 | 别做——浪费资源 |
| 反向型 | 做了反而让用户不爽 | 强制弹窗广告、自动播放视频 | 坚决不做 |
# 4.2 怎么判断一个需求属于哪类
用 Kano 问卷——每个需求问用户两个问题：
需求：App 启动时展示 3 秒开屏广告
正向问题：如果 App 有开屏广告，你感觉如何？
□ 我喜欢 □ 理所当然 □ 无所谓 □ 勉强接受 □ 不喜欢
反向问题：如果 App 没有开屏广告，你感觉如何？
□ 我喜欢 □ 理所当然 □ 无所谓 □ 勉强接受 □ 不喜欢
2
3
4
5
6
7
根据两个问题的回答组合，查 Kano 评价表（网上一搜就有），就能判断这个需求属于哪类。
快速判断法（不用问卷）——问自己：
- "这个功能如果现在砍掉——用户会骂吗？" → 会 → 基本型（或线性型）
- "这个功能竞品都有吗？" → 都有 → 大概率是基本型。都没有 → 可能是兴奋型。
- "这个功能有人提过吗？" → 没人提过 → 大概率是无差异型。
# 4.3 工程师视角的 Kano 应用
你的日常任务列表里，可能有 10 个需求。用 2 分钟给每个需求标上 Kano 分类：
本周需求：
✅ [基本型] 修复支付回调丢失导致订单不更新的 bug ← 不上线用户要疯
✅ [线性型] 商品搜索从 800ms 优化到 200ms ← 越快转化越高
⬜ [兴奋型] 购物车增加"降价提醒"功能 ← 有时间再做
❌ [无差异型] 订单列表页支持"按时间排序"（已有默认排序够用了）
2
3
4
5
这个分类让你和产品经理讨论优先级时，有共同的判断框架——而不是争论"我觉得这个重要"。
# 五、综合案例：从需求到方案
场景：某电商后台，运营人员说"需要一个批量改价功能"。
1. 用户访谈（5 分钟）
问：能不能给我看看你现在是怎么改价的？ → 运营打开一个 Excel，里面有 200 行 SKU 和价格，手动一个一个在后台改。每次大促前要改 500+ 个 SKU，花 4 小时。
问：最烦人的是哪一步？ → "后台一次只能改一个商品。我得在 Excel 和后台之间来回切，手都点麻了。"
2. 故事地图（2 分钟）
改价流程：
登录后台 → 找到商品 → 修改价格 → 保存 → 确认生效 → 下一个商品（重复 500 次）
↑ 这是瓶颈——每次只能一个
2
3
3. Kano 分类（1 分钟）
- 批量导入 Excel 改价 → 基本型（大促是核心业务，没这个运营干不了活）
- 改价后自动发通知给供应商 → 兴奋型（锦上添花但不是必须）
- 改价历史记录和回滚 → 基本型（改错了能撤回——必须的）
4. 方案输出（不是写代码——先定方案）
不要上来就设计"批量导入的数据库结构"。先用一句话定义方案：
做一个 Excel 导入功能，运营上传含 SKU+新价格的表格，系统批量更新。支持预览（改之前看看对不对）、执行（提交变更）、回滚（改错了可以撤回）。
这句话里已经包含了：谁用（运营）、怎么用（上传 Excel）、核心流程（预览→执行→回滚）。
# 六、小结
需求分析不是"记下用户说的话然后去实现"。它是：
- 访谈——观察行为，不要听声称
- 故事地图——把零散需求串成完整旅程，发现缺失和冗余
- Kano 模型——分类需求，知道什么必须做、什么可做可不做、什么坚决不做
三个工具配合使用：
用户访谈 → 收集原始素材
↓
故事地图 → 组织成完整场景，画 MVP 线
↓
Kano 模型 → 分类标注，定开发优先级
↓
一个需求分析就完成了——可以进入技术方案了
2
3
4
5
6
7
