需求获取技术：用户访谈、问卷调查、头脑风暴、场景与用例分析、原型法

说到需求获取，我脑子里立刻浮现出刚入行时的一个场景。那时候我拿着笔记本，坐在客户对面，问一句记一句，结果回去一整理——全是废话。为什么？因为我根本没掌握获取需求的正确姿势。

需求获取不是简单的「你问我答」。它是一门技术活。今天我就把这五种主流方法掰开揉碎了讲给你听。

用户访谈：最直接，也最容易翻车

用户访谈，说白了就是跟客户聊天。但这里有个坑——你问的问题，决定了你得到的答案。

所以我的建议是：

• 别问「想要什么」，问「现在怎么做的」——了解当前流程，痛点自然浮现
• 准备半结构化提纲——既要有固定问题保证覆盖，也要留出自由发挥空间
• 录音！录音！录音！——重要的事情说三遍。我习惯访谈后24小时内整理纪要，否则细节全忘

访谈对象怎么选？我一般遵循「3+1」原则：3个业务骨干 + 1个决策者。骨干告诉你细节，决策者告诉你方向。

问卷调查：量大，但别指望深度

问卷调查适合什么场景？用户基数大、地理位置分散、或者你想验证某个假设的时候。

但说实话，我对问卷一直又爱又恨。爱的是它能快速收集大量数据，恨的是——你永远不知道填问卷的人是不是在认真回答。

问卷的题型我推荐这样搭配：

题型	占比	用途
单选题	60%	收集明确偏好或事实
多选题	20%	了解多维度需求
李克特量表	15%	测量态度和满意度
开放题	5%	留个口子，万一有惊喜

头脑风暴：别让「不可能」扼杀创意

头脑风暴是我个人最喜欢的环节。为什么？因为它能打破思维定势。

我记得有一次做智慧园区项目，大家卡在「如何让访客登记更高效」这个问题上。传统思路是优化登记表、减少字段。结果头脑风暴时，一个刚入职的小伙子说：「为什么非要登记？人脸识别+预约制不行吗？」——你看，换个角度，问题就解决了。

头脑风暴有几个铁律：

• 不批评、不评价——任何想法都是好想法，哪怕听起来很蠢
• 追求数量——先求量，再求质。100个想法里总能筛出3个能用的
• 搭便车是美德——在别人想法上叠加、改进，往往能产生更好的方案

场景与用例分析：把需求「演」出来

场景分析，说白了就是讲故事。你描述一个用户在特定情境下如何使用系统完成目标。

举个例子：

场景：小李是仓库管理员，每天早上8点上班。
他打开系统，看到今日待入库清单有3批货物。
他扫描第一个货物的条码，系统自动显示货物信息和存放位置。
他确认入库，系统更新库存并生成入库记录。
整个过程不超过2分钟。

你看，这样一个场景，就把「入库管理」这个需求具象化了。比干巴巴地写「系统应支持入库操作」强一百倍。

用例分析则更结构化。我习惯用这个模板：

元素	内容
用例名称	货物入库
参与者	仓库管理员
前置条件	管理员已登录系统，货物已到达仓库
基本流程	1. 管理员扫描条码 2. 系统显示货物信息 3. 管理员确认入库 4. 系统更新库存
扩展流程	2a. 条码无法识别 → 手动输入
后置条件	库存数据更新，生成入库记录

嗯，这里要注意——用例不要写得太细。我见过有人把「点击按钮」都写进用例里，那就变成详细设计了。用例的粒度应该是「用户能完成一个有价值的业务目标」。

原型法：一张图胜过千言万语

原型法是我最推荐的需求确认方式。为什么？因为用户看到界面原型，比听你讲需求文档要直观得多。

我习惯用低保真原型做早期沟通。为什么是低保真？因为用户看到高保真原型，容易纠结颜色、字体、图标这些视觉细节，反而忽略了功能逻辑本身。

原型法有几个关键点：

• 快速迭代——别追求一次完美，先做出能用的版本，让用户试用反馈
• 聚焦核心流程——先做主要业务路径，异常流程和边界情况可以后面再补
• 明确告知「这是原型」——我吃过这个亏。有一次原型做得太逼真，客户以为系统已经开发完了，催着要上线

五种方法怎么选？

你可能会问：这么多方法，我到底用哪个？我的建议是——组合使用。

一般来说，我会这样安排：

1. 项目启动阶段：用户访谈 + 头脑风暴，快速了解业务全貌
2. 需求细化阶段：场景与用例分析，把模糊需求变成可执行的描述
3. 需求确认阶段：原型法，让用户「看到」系统长什么样
4. 大规模验证阶段：问卷调查，收集更多用户的反馈

说白了，没有万能的方法。关键是根据项目特点、用户情况、时间成本来灵活搭配。你想想看，如果用户只有3个人，你搞什么问卷调查？直接访谈就完了。反过来，如果用户有1000人，你一个个访谈，那得访谈到猴年马月去。

最后说一句——需求获取不是一次性工作。它贯穿整个项目生命周期。你以为你懂了，其实你只是「以为」懂了。多问、多听、多验证，这才是做好需求的不二法门。