第3章需求获取技术

3、需求获取技术：访谈法、问卷调查法、原型法、场景分析法、用户故事

好，咱们进入第三个核心模块。需求获取，说白了就是「怎么把用户脑子里的东西掏出来」。

我见过太多项目，需求文档写得天花乱坠，结果开发到一半，客户说「这不是我要的」。为什么？因为获取方法不对。你想想看，你问用户「你想要什么功能」，他大概率说不清楚。但如果你给他看个原型，或者让他讲个故事，效果完全不一样。

这一章，我把自己踩过的坑和总结的经验，一次性倒给你。

访谈法，就是面对面聊。听起来简单吧？但这里面的门道不少。

我个人习惯把访谈分成两类：结构化访谈和非结构化访谈。

类型	特点	适用场景
结构化访谈	提前准备好问题清单，按顺序问	需求明确、时间紧张、多人对比
非结构化访谈	开放式聊天，顺着话题深入	探索性需求、挖掘痛点

我的经验： 刚开始做访谈时，我总喜欢用结构化方式，觉得效率高。但有一次，一个用户被我「逼问」得有点不耐烦，随口说了句「其实我们最烦的是每次启动都要等10秒」。这句话完全不在我的问题清单里，但恰恰是核心痛点。从那以后，我学会了「先聊后问」。

访谈时要注意几点：

避坑指南： 我曾经访谈一位产品经理，他全程都在讲「我们想要一个高大上的界面」。结果开发出来后，实际用户根本用不惯。记住：访谈对象要选对，最好是实际使用者，而不是决策者。

问卷调查适合收集量化数据。比如「80%的用户觉得当前界面太复杂」，这种结论靠访谈是得不出来的。

但问卷有个大坑：设计不好，数据就是垃圾。

我总结了几条铁律：

    核心要点： 问卷只能告诉你「是什么」，不能告诉你「为什么」。所以它通常和访谈法配合使用——先用问卷发现问题，再用访谈深挖原因。

这个方法我特别喜欢。为什么呢？因为用户看到实物，才会真正思考。

你问用户「你要不要一个一键导航功能？」他可能说「要」。但当你把原型摆在他面前，他点了一下，发现要跳转三个页面，他立刻会说「算了，太麻烦」。

原型法分两种：

我的习惯： 我一般先用低保真原型和用户过一遍流程。确认大方向没问题，再上高保真。有一次我直接做了高保真，结果用户说「这个颜色不好看」，然后花了半天调色——其实核心逻辑还没确认呢。

原型法的关键：迭代要快。别想着一次做完美。我通常的做法是：

场景分析法，说白了就是讲故事。但这个故事不是随便编的，它要回答三个问题：

举个例子：

场景：车主小王，早上7:30，赶着去上班。
他坐进车里，发现油量只剩一格。
他需要：1. 快速找到最近的加油站
        2. 导航过去
        3. 全程不超过5分钟操作

你看，这个场景一出来，需求就清晰了：

避坑指南： 我曾经遇到一个团队，写了20个场景，每个都特别详细。结果发现很多场景是重复的。后来我学会了：先列核心场景，再补充边缘场景。核心场景不超过5个。

用户故事，是敏捷开发里最常用的需求表达方式。格式很简单：

作为 <用户角色>
我想要 <功能>
以便 <价值>

举个例子：

作为 车主
我想要 在仪表盘上看到胎压数据
以便 及时发现问题，避免爆胎

嗯，这里要注意：用户故事不是需求文档，它只是一个占位符。真正的细节，要在后续的对话中补充。

我个人的经验是：

别写太大：一个用户故事最好能在1-2天内开发完成。如果太大，拆成多个。
加上验收条件：比如「胎压低于2.0bar时，仪表盘显示黄色警告」。这样开发和测试都知道「做完」的标准是什么。
优先级要明确：我习惯用MoSCoW方法——Must have（必须有）、Should have（应该有）、Could have（可以有）、Won't have（这次不做）。

    总结一下： 这五种方法，没有哪个是万能的。我一般这样搭配使用：
    项目初期：用访谈法+场景分析法，摸清用户痛点
中期：用原型法，快速验证想法
后期：用用户故事，细化开发任务
需要量化数据时：用问卷调查法

好了，这一章就到这里。下一章我们聊聊「需求分析与建模」，到时候我会讲怎么把今天获取到的这些「原材料」，加工成真正的软件需求。