3. 需求获取技术：访谈法、问卷调查法、观察法、文档分析法、原型法
好，咱们进入第三章。需求获取，说白了就是跟用户「要需求」的过程。很多人觉得这还不简单？问用户想要什么不就行了？嗯，我当年也这么想，结果被现实狠狠教育了一回。
有一次我做一个企业内部管理系统，跑去问业务主管：「您想要什么功能？」他说：「就一个审批流程，很简单。」结果做出来之后，他拍着桌子说：「这根本不是我要的！」——为什么？因为我没问清楚他到底怎么审批的，谁审批，什么情况下要加签，什么情况下要退回。你看，用户说的「简单」，往往是最不简单的地方。
所以这一章，咱们把五种主流的需求获取技术掰开揉碎了讲。每一种技术都有它的适用场景，也有它的坑。我建议你把这些技术当成工具箱里的不同工具，别指望一把螺丝刀搞定所有问题。
3.1 访谈法：最直接，也最容易翻车
访谈法是我个人用得最多的方法。面对面聊，效率高，能挖到深层信息。但这里有个大坑——你问的问题决定了你得到的答案。
所以我建议你这样做：
- 多用开放式问题：比如「您能描述一下每天早上的工作流程吗？」而不是「您早上需要做数据录入吗？」
- 追问细节：用户说「我要一个提醒功能」，你得追问「提醒什么？什么时候提醒？提醒谁？用什么方式提醒？」
- 准备访谈提纲：别空着手去。我习惯列一个半结构化的提纲，核心问题写下来，但现场可以根据对话灵活调整。
访谈法适合什么场景？
| 场景 | 推荐程度 | 原因 |
|---|---|---|
| 用户数量少（5-10人） | ★★★★★ | 一对一聊得透 |
| 需求模糊、不确定 | ★★★★★ | 能深挖，能追问 |
| 用户分布在不同城市 | ★★☆☆☆ | 成本高，建议用视频会议 |
3.2 问卷调查法：量大，但别指望深度
问卷调查法，说白了就是「广撒网」。用户量大的时候，访谈搞不定，问卷就派上用场了。但这里有个问题——问卷设计不好，回收的数据就是一堆垃圾。
我记得有一次帮一个电商平台做需求调研，问卷里问「您希望我们的网站加载速度更快吗？」结果99%的人都选了「非常希望」。废话，谁不希望？这种问题就是典型的无效问题。
设计问卷时，我总结了几个要点：
- 问题要具体：别问「您觉得系统好用吗？」要问「您在使用搜索功能时，平均需要等待几秒？」
- 选项要互斥：比如年龄段，别出现「20-30岁」和「30-40岁」，30岁的人该选哪个？
- 控制题量：超过20道题，用户就开始乱填了。我一般控制在10-15题。
- 先小范围试填：找3-5个人先填一遍，看看有没有歧义。这一步我吃过亏，有一次问卷里有个专业术语，结果一半用户看不懂。
3.3 观察法：看用户怎么做，而不是听用户怎么说
观察法，是我认为最被低估的一种需求获取技术。为什么？因为用户说的和做的，往往是两回事。
我举个例子。有一次做一个医院挂号系统，用户说「我们流程很简单，患者来了先挂号，然后去诊室排队。」结果我去现场一看，根本不是这样——患者来了先在大厅转一圈，找哪个窗口人少，然后去排队，排到一半发现挂错了科室，又去问导诊台……你看，用户描述的流程是理想化的，实际流程充满了各种「意外」。
观察法有两种方式：
- 显性观察：你直接站在用户旁边看，用户知道你在观察。好处是能随时提问，坏处是用户可能会「表演」给你看。
- 隐性观察：通过录像、日志等方式观察，用户不知道。好处是数据真实，坏处是没法追问。
我个人建议，两种结合着用。先隐性观察一段时间，了解真实情况，再针对性地做显性观察，追问细节。
3.4 文档分析法：别重复造轮子
文档分析法，听起来很枯燥，但其实是性价比最高的方法。你想想看，公司里肯定有现成的资料——用户手册、操作规范、历史需求文档、bug报告……这些东西里藏着大量信息。
我习惯的做法是：
- 先找历史文档：看看之前有没有人做过类似的项目，踩过什么坑。
- 再看操作规范：了解用户现有的业务流程，这比听用户口述要准确得多。
- 最后看bug报告：现有系统的bug，往往就是新系统需要改进的地方。
3.5 原型法：让用户「看见」需求
原型法，是我最喜欢的方法。为什么？因为用户看到原型之后，才会真正知道自己要什么。
你想想看，你跟用户说「这个按钮点一下会弹出一个对话框」，用户脑子里可能想的是一个小窗口。但实际做出来之后，用户说「不对，我要的是全屏覆盖的那种！」——这就是语言沟通的局限性。
原型法分两种：
- 低保真原型：用纸笔或者简单的工具（比如Axure、Figma）画个线框图。优点是快，几分钟就能改一版。适合早期需求探索。
- 高保真原型：做得跟真系统一样，能点击、能交互。优点是用户感受更真实，缺点是改起来慢。
我个人的经验是：先用低保真原型快速验证核心流程，等流程确认了，再上高保真原型打磨细节。别一上来就搞高保真，万一方向错了，改起来哭都来不及。
3.6 五种技术的选择策略
好了，五种技术都讲完了。你可能会问：那我到底该用哪一种？
我的建议是：别单选，要组合。比如：
- 项目初期：用文档分析法快速了解背景，再用访谈法深挖关键用户的需求。
- 项目中期：用问卷调查法收集大量用户的反馈，用观察法验证用户的实际行为。
- 项目后期：用原型法让用户确认界面和交互，避免开发完再改。
下面这张图，是我自己总结的需求获取技术选择流程，你可以参考一下：
你看，这个流程的核心思路就是：先低成本获取信息，再逐步深入。别一上来就搞大规模访谈或者高保真原型，那样成本太高，而且容易走偏。