3、需求获取技术：用户访谈、问卷调查、文档分析、头脑风暴、原型法
说到需求获取，我脑子里立刻浮现出刚入行时的一个场景。那时候我拿着笔记本，坐在客户会议室里，听他们讲了三个小时，回来发现记了一堆废话。嗯，后来我才明白——需求获取不是聊天，是技术活。
今天要讲的这五种技术，说白了就是五把钥匙。每把钥匙开一把锁，关键是你得知道什么时候用哪把。
3.1 用户访谈：最直接，也最容易翻车
用户访谈是我个人最常用的方法。为什么？因为面对面聊，你能看到对方的微表情，能听出话外音。但这里有个坑——用户说的，不一定是他真正想要的。
核心要点：访谈不是审问，是引导。你要让用户讲故事，而不是让他填表格。
我在项目中遇到过一位财务总监，他反复强调要“实时报表”。我追问了三次，最后发现他其实只是想要每天早上9点准时收到前一天的汇总数据。你看，他说的“实时”和我理解的“实时”，差了十万八千里。
访谈时我习惯用“5W1H”框架：
- Who — 谁在用？谁受益？
- What — 要做什么？痛点在哪？
- When — 什么时候用？频率多高？
- Where — 在什么环境下用？
- Why — 为什么需要这个功能？
- How — 期望怎么实现？
小技巧：访谈时带个录音笔，但一定要征得对方同意。我吃过亏，有一次凭记忆整理，结果漏掉了关键的业务规则，后来被开发团队追着骂。
3.2 问卷调查：量大，但别指望深度
问卷调查适合什么场景？用户群体大、地理位置分散、或者你想快速收集一些量化数据。但说实话，问卷的局限性很明显——你只能问你知道的问题。
我曾经帮一个电商平台做需求调研，发了2000份问卷，回收了800多份。数据看起来很漂亮，但真正有价值的信息，不到20%。为什么？因为问卷设计本身就有偏见，我预设了答案选项，用户只能在这些选项里选。
设计问卷时，我总结了几个原则：
- 问题不超过15个 — 超过这个数，用户就开始乱填了
- 开放题控制在2个以内 — 没人愿意写小作文
- 先易后难 — 把个人信息放最后，上来就问隐私，人家直接关页面
- 选项要互斥且穷尽 — 别让用户找不到合适的选项
| 对比维度 | 用户访谈 | 问卷调查 |
|---|---|---|
| 样本量 | 小（5-20人） | 大（100-10000人） |
| 深度 | 深，能挖掘隐性需求 | 浅，只能获取表面信息 |
| 成本 | 高（时间、人力） | 低（可自动化） |
| 数据分析 | 定性分析为主 | 定量分析为主 |
3.3 文档分析：别小看那些“废纸”
很多人觉得文档分析就是翻翻旧资料，没什么技术含量。我告诉你，大错特错。文档里藏着的，往往是系统最真实的运行逻辑。
我记得有一次接手一个遗留系统的改造项目。客户说系统太老了，要重写。我花了三天时间，把他们的操作手册、故障记录、甚至员工手写的便签都翻了一遍。结果发现，系统里有个“隐藏功能”——当年某个程序员为了偷懒写的一个批处理脚本，后来成了核心业务流程的一部分。如果我没看文档，直接重写，这个功能就丢了。
文档分析的重点：
- 现有系统文档 — 需求规格说明书、设计文档、用户手册
- 业务文档 — 流程制度、岗位职责、报表模板
- 历史记录 — 变更申请、问题报告、运维日志
- 行业标准 — 法律法规、行业规范、最佳实践
注意：文档可能过时。我曾经遇到过一份“最新版”的需求文档，发布日期是2018年，但系统已经在2020年改过两轮了。文档分析一定要和访谈结合，交叉验证。
3.4 头脑风暴：发散容易，收敛难
头脑风暴，说白了就是一群人坐在一起，天马行空地提想法。这个方法的优点是可以打破思维定势，缺点是容易变成“茶话会”。
我组织头脑风暴时，会定几条铁律：
- 不批评 — 任何想法都先记录下来，哪怕听起来很蠢
- 追求数量 — 目标是50个想法，不是5个完美想法
- 鼓励“搭便车” — 在别人的想法上改进，比自己想一个新点子更有价值
- 限时 — 45分钟，到点就停
我曾经带过一个团队做头脑风暴，主题是“如何提升用户活跃度”。前20分钟大家都很拘谨，后来有个实习生说了句“要不我们做个签到送积分？”全场哄笑。但就是这个看似幼稚的想法，后来演化成了完整的积分体系，日活提升了30%。
头脑风暴之后，最重要的一步是收敛。我会用“亲和图法”把想法分类，然后用“投票法”选出优先级最高的3-5个，进入下一轮讨论。
3.5 原型法：让用户“看见”需求
原型法是我最推荐的方法，尤其是当用户说不清楚自己要什么的时候。你做个原型出来，用户一看，马上就能说“对对对，就是这样”或者“不对，这里应该是那样”。
原型法分两种：
- 低保真原型 — 纸笔、白板、或者简单的线框图工具。快速、低成本，适合早期验证
- 高保真原型 — 用Axure、Figma等工具做的可交互原型。接近真实产品，适合做用户测试
我个人习惯的做法是：先用低保真原型和用户过一遍核心流程，确认大方向没问题，再花时间做高保真原型。为什么？因为用户看到高保真原型，容易把注意力放在“这个按钮颜色不对”上，而忽略了业务逻辑本身。
避坑指南：我曾经花了两周做了一个高保真原型，结果用户看完说“这个流程不对，我们不是这么干的”。两周白干。从那以后，我坚持“先纸笔，后工具”。
原型法的核心价值在于——降低沟通成本。你想想看，你用文字描述一个功能，用户脑子里想象的是一个样子；你画个原型出来，大家看到的是同一个东西。这个差距，有时候就是项目成败的关键。
小结
这五种技术，没有哪个是万能的。我的建议是：
- 项目初期，用文档分析了解背景
- 用用户访谈挖掘核心需求
- 用问卷调查验证假设
- 遇到复杂问题时，用头脑风暴打开思路
- 最后，用原型法把需求落地
嗯，需求获取这件事，说到底就是“听懂人话”。但你要知道，用户说的、用户想的、用户真正需要的，往往是三件不同的事。我们的工作，就是把这三种东西对齐。