需求获取技术：用户访谈、问卷调查、观察法、文档分析、原型法
说实话，需求获取这事儿，看着简单，做起来全是坑。
我见过太多项目，开发团队闷头写了三个月代码，最后发现客户要的根本不是那个东西。为什么会这样？说白了，就是需求没拿准。今天咱们就聊聊五种最常用的需求获取技术，都是我这些年摸爬滚打总结出来的。
用户访谈：最直接，也最容易跑偏
用户访谈是我个人最常用的方法。面对面聊，能捕捉到很多文档里看不到的东西。
但这里有个大坑——用户说的不一定是他真正想要的。我在一个智能家居项目里遇到过，用户反复强调要「一键控制所有灯光」。结果做出来之后，他说「不对，我要的是能分场景控制」。你看，他说的「一键」其实是「场景切换」。
访谈技巧清单：
- 准备开放式问题，别问「是不是」，多问「为什么」
- 录音前必须征得同意，我吃过这个亏
- 带一个懂技术的同事去，防止被带偏
- 访谈后24小时内整理纪要，记忆会骗人
我的小习惯：每次访谈结束前，我会把关键点复述一遍给用户听。「您看我理解得对不对，您刚才说的是...」这一步能避免至少一半的返工。
问卷调查：量大，但深度有限
问卷调查适合做定量分析。你想知道「有多少用户需要这个功能」？那就发问卷。
但要注意，问卷设计不好，数据就是垃圾。我曾经设计过一份问卷，问题全是「您是否希望系统更智能？」——废话，谁不希望？后来被老领导骂了一顿，说这叫「引导性问题」。
| 问卷类型 | 适用场景 | 样本量建议 |
|---|---|---|
| 纸质问卷 | 展会、线下活动 | 50-200份 |
| 在线问卷 | 大规模用户调研 | 200-1000份 |
| 嵌入式问卷 | 设备端用户体验 | 30-100份 |
避坑指南：我曾经在问卷里放了一个「其他」选项，结果80%的人都选了它。后来发现，是因为我列的选项太理想化了，根本没覆盖真实场景。记住：选项要基于前期访谈结果来设计，别拍脑袋。
观察法：看用户怎么做，而不是听他说什么
这个技术被很多人忽略了。你想想看，用户嘴上说的操作流程，和他实际做的，往往差着十万八千里。
我在一个工业控制项目里，蹲在车间看了三天。操作工告诉我「按A键再按B键就行」。结果我发现，他们实际是按A、C、B、A——因为系统有bug，按C才能绕过某个校验。如果只靠访谈，我永远不知道这个「潜规则」。
观察法的三个要点：
- 别干预：让用户按他的习惯操作，别指手画脚
- 记录异常：用户皱眉、犹豫、骂脏话的地方，都是需求点
- 注意环境：光线、噪音、操作空间，这些都会影响需求
文档分析：从旧系统里挖金子
很多项目不是从零开始的。客户可能有旧系统、旧文档、旧代码。这些东西里藏着大量需求。
我习惯先要三样东西：用户手册、故障记录、变更日志。用户手册告诉你「系统应该怎么用」，故障记录告诉你「系统哪里容易出问题」，变更日志告诉你「客户之前改过什么」。
文档分析清单：
- 需求规格说明书（如果有的话）
- 测试报告和bug列表
- 用户反馈邮件或工单
- 竞品分析报告
- 行业标准文档（比如IEC 62304、ISO 26262）
嗯，这里要注意：文档可能过时。我见过一份需求文档，日期是五年前的，但客户说「一直用这个」。结果一核对，系统早就改了三轮了。所以文档分析一定要配合其他方法交叉验证。
原型法：让需求「看得见摸得着」
这是我最喜欢的方法。为什么？因为用户看到原型之后，才会真正说出他的想法。
抽象的需求描述，用户可能说「都行」。但你把原型往他面前一放，他立刻会说「这个按钮不对」「这个流程太绕了」。说白了，原型是需求的照妖镜。
原型法的两种常见做法：
- 低保真原型：纸笔、Axure线框图，快速迭代，适合早期
- 高保真原型：Figma、Sketch，甚至可交互的HTML，适合确认细节
我的经验：在嵌入式项目里，我经常用「硬件原型+软件模拟」的方式。比如用一个开发板跑核心逻辑，屏幕显示UI效果。用户能摸到按键、看到反馈，反馈质量比纯软件原型高出一大截。
五种方法怎么选？
别想着只用一种方法。我一般这样搭配：
- 项目启动阶段：文档分析 + 用户访谈（快速了解背景）
- 需求探索阶段：观察法 + 问卷调查（发现真实痛点）
- 需求确认阶段：原型法（验证理解是否正确）
当然，这不是死规矩。项目时间紧，可能就访谈+原型两步走。项目复杂，五种方法全上也不嫌多。
最后说一句：需求获取不是一次性工作。你拿到的需求，会随着项目推进不断变化。保持开放心态，随时准备调整。这才是资深分析师该有的样子。