3、需求获取方法：访谈法、问卷调查法、观察法、文档分析法、原型法、头脑风暴法
需求获取，说白了就是「把用户脑子里的想法掏出来」。
我做了十几年需求分析，见过太多项目死在「我以为我知道用户要什么」上。用户说「我想要一个快的系统」，结果他理解的快是0.1秒，你理解的是1秒——这差距，够你加班三个月。
所以，掌握正确的获取方法，比什么都重要。今天我把六种最常用的方法掰开揉碎讲给你听。
3.1 访谈法：最直接的沟通方式
访谈法是我个人最常用的方法。没有之一。
为什么？因为你可以直接问，直接听，直接看对方的反应。你想想看，一个眼神、一次停顿、一句「嗯...其实吧」，这些细节里藏着多少真实需求。
核心要点：
- 结构化访谈：提前准备好问题清单，按顺序问。适合明确已知领域。
- 半结构化访谈：有个大纲，但允许跑题。我80%的访谈都用这种。
- 非结构化访谈：随便聊，像朋友聊天。适合探索全新领域。
我在项目中遇到过一件事。一个财务系统的需求，结构化访谈问了三天，用户都说「没问题」。后来我改用半结构化，聊到下班时间，用户随口说了句「其实那个审批流程，我们私下都是先找领导签字再走系统的」——这才是真实流程！
我的小技巧：
访谈时带个录音笔，但一定要征得对方同意。我习惯同时记笔记，记关键词就行，别埋头猛写——那样会错过对方的微表情。
3.2 问卷调查法：量大管饱
当你要问的人超过20个，访谈就不太现实了。这时候，问卷上场。
问卷的好处是覆盖面广，坏处是——你永远不知道对方是不是在认真填。
| 类型 | 适用场景 | 样本量 | 我踩过的坑 |
|---|---|---|---|
| 开放式问卷 | 探索性需求 | 30-50份 | 回收率低，很多人懒得写 |
| 封闭式问卷 | 验证性需求 | 100份以上 | 选项设计不合理，数据失真 |
| 混合式问卷 | 大多数场景 | 50-200份 | 分析起来比较费劲 |
注意：
问卷设计有个黄金法则——一个问题只问一件事。别问「您觉得系统快不快、好不好用、稳不稳定？」这等于没问。
我曾经设计过一个问卷，把三个问题揉在一起，结果回收的数据完全没法用。从那以后，我每个问题都自己先答一遍，确认没有歧义。
3.3 观察法：看比问更真实
用户说的，和他做的，往往是两码事。
我记得有一次做仓储系统的需求。用户说「我们流程很简单，扫码入库就行」。结果我去仓库蹲了一天，发现他们实际流程是：先手写单子→再扫码→再核对Excel→再入库。为什么？因为系统不支持批量扫码。
这就是观察法的价值——你看到的是真实世界，不是用户脑补的世界。
观察法分类：
- 参与式观察：你跟着用户一起干活。适合了解完整流程。
- 非参与式观察：你站在旁边看，不打扰。适合发现细节问题。
- 时间采样观察：固定时间点记录。适合高频操作场景。
嗯，这里要注意——观察法很费时间。我一般只用在关键流程上，比如核心业务环节、高频操作点。别什么都去观察，你观察不完的。
3.4 文档分析法：从历史中找答案
新项目还好说，如果是做系统升级或替换，文档分析法就是你的救命稻草。
我习惯先找三类文档：
- 现有系统的操作手册——看用户现在怎么用
- 历史需求文档——看之前踩过哪些坑
- 问题反馈记录——看用户骂得最多的是什么
有一次我接手一个老系统的改造项目。用户说「需求很简单，照旧就行」。结果我翻出三年前的运维日志，发现光「导出报表报错」这个问题就提了47次。你说这需求能「照旧」吗？
我的习惯：
文档分析不是通读全文。我一般先看目录和索引，找到和当前需求相关的部分，再精读。别从头读到尾，你会疯的。
3.5 原型法：让用户「看见」需求
很多用户说不清楚自己要什么，但你给他一个东西，他马上能说「这里不对」「那里少了」。这就是原型法的价值。
我个人最喜欢用低保真原型——纸笔画的、或者Axure做的简单线框图。为什么？因为用户看到太精美的原型，会误以为系统已经做好了，然后开始纠结按钮颜色、字体大小这些细节。
原型法流程：
- 第一步：快速做一个可交互的原型（1-2天）
- 第二步：让用户试用，记录反馈
- 第三步：修改原型，再次试用
- 第四步：迭代3-5轮，直到需求稳定
我曾经用原型法帮一个客户省了三个月开发时间。他们原本想做一个复杂的审批流，原型做出来给用户一看，用户说「其实我们只需要三个节点就够了」。你想想看，如果直接开发，那得浪费多少人力？
避坑指南：
我曾经犯过一个错误——原型做得太逼真，用户以为系统已经开发完了，天天催上线。所以我现在做原型，都会在页面上加个水印「原型演示，非最终产品」。
3.6 头脑风暴法：打破思维定势
前面五种方法都是「从用户那里获取需求」。但有时候，用户自己也不知道未来需要什么。这时候，头脑风暴就派上用场了。
头脑风暴不是随便聊天。我主持过上百场头脑风暴，总结出几个原则：
- 不批评——任何想法都先记下来，哪怕听起来很蠢
- 追求数量——先求量，再求质
- 鼓励跨界——让开发、测试、运营都参与进来
- 限时——一般30-45分钟，时间太长会疲劳
我记得有一次做电商系统的需求，用户一直强调「我们要做推荐算法」。头脑风暴时，一个运营小姑娘随口说了句「其实我们客服最清楚用户想要什么，每天接几百个电话呢」。后来我们真去分析了客服录音，发现用户最常问的是「这个商品有没有货」——而不是「推荐什么给我」。你看，需求方向完全变了。
我的小技巧：
头脑风暴结束后，一定要做「需求收敛」。把所有想法分类、排序、打分。不然你得到的只是一堆天马行空的想法，没法落地。
小结：六种方法怎么选？
说实话，没有哪种方法是万能的。我一般这样组合：
| 项目阶段 | 推荐方法 | 原因 |
|---|---|---|
| 项目启动期 | 访谈法 + 文档分析法 | 快速了解背景和现状 |
| 需求探索期 | 观察法 + 头脑风暴法 | 发现隐藏需求和创新点 |
| 需求验证期 | 问卷调查法 + 原型法 | 验证假设，确认细节 |
记住一句话：方法只是工具，真正重要的是你能否听懂用户没说出口的话。
嗯，这一章就到这里。下一章我们聊聊怎么把这些获取到的需求整理成文档——那可是个技术活。