第二章：需求获取——用户访谈、问卷调查、观察法、文档分析等常用方法详解

大家好，我是你们的老朋友。

上一章我们聊了需求分析的整体框架，说白了就是搞清楚「我们要做什么」。但问题来了——这些需求从哪来？怎么才能挖到真实的需求，而不是用户随口说的「我想要个蓝色的按钮」？

这一章，我就把压箱底的四种需求获取方法掰开揉碎讲给你听。每种方法我都踩过坑，也总结了一些实战技巧，希望能帮你少走弯路。

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

用户访谈，听起来简单吧？找几个用户聊聊天，问问他们想要什么。但我告诉你，这里面的门道可多了。

我个人习惯把用户访谈分成三类：

我在项目中遇到过最典型的翻车案例：问用户「你觉得这个功能怎么样？」用户说「挺好的」。然后我就信了，结果上线后根本没人用。

为什么会这样？因为用户说的「好」不代表他真的会用。你想想看，当面说「不好」多尴尬啊。

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

问卷调查，说白了就是「广撒网」。它能帮你快速收集大量数据，但别指望从问卷里挖到深层需求。

我总结了一套问卷设计的「三要三不要」：

• 要：问题控制在15题以内，超过这个数，用户就开始乱填了
• 要：先问行为，再问态度。比如「你每周用几次？」比「你觉得好用吗？」靠谱
• 要：留一个开放题，但别指望太多人填
• 不要：用专业术语。用户听不懂「并发量」「延迟」这些词
• 不要：问「如果...你会...」这种假设性问题
• 不要：设置「其他」选项时，不给输入框

嗯，这里要注意一点：问卷的数据只能告诉你「是什么」，不能告诉你「为什么」。比如你发现80%的用户选了A选项，但为什么选A？你得去访谈里找答案。

2.3 观察法：看用户怎么做，而不是听用户怎么说

这个我特别有感触。用户说的和做的，往往是两码事。

我记得有一次做电商后台的需求调研。运营主管跟我说「我们想要一个批量导出功能」。我问他「你平时怎么导出的？」他说「一个一个点啊」。然后我去观察他操作，发现他其实每次只导出3-5个订单，根本不需要批量导出，他真正需要的是「快速筛选出特定状态的订单」。

观察法分两种：

1. 自然观察：用户不知道你在观察，数据最真实，但可能有伦理问题
2. 参与式观察：你扮演一个角色融入场景，比如假装成新员工去体验系统

我个人更推荐第二种。你想想看，如果你直接告诉用户「我来观察你怎么用系统」，他立马就紧张了，操作都变形了。

2.4 文档分析：别小看那些「没人看」的文档

很多产品经理觉得文档分析就是翻翻竞品报告、看看用户手册。其实不然。

我一般会找这几类文档：

我曾经从一份客服工单里发现了一个致命问题：用户反复投诉「保存失败」，但开发查了日志说没问题。后来我仔细看了工单描述，发现用户是在「网络断开的瞬间」点击保存。这个场景测试环境根本复现不了。你看，文档分析有时候能发现测试都测不出来的问题。

2.5 四种方法的组合策略

说了这么多，你可能会问：到底该用哪种？

我的建议是：别只用一种。四种方法组合使用，效果最好。

我一般会这样组合：

1. 第一步：先做文档分析，了解背景和历史
2. 第二步：发问卷，快速摸清用户分布和大致需求
3. 第三步：选几个典型用户做深度访谈
4. 第四步：去现场观察用户实际操作

这个顺序不是固定的。有时候时间紧，我会跳过问卷直接访谈。但文档分析和观察法，我建议无论如何都要做。这两步能帮你发现用户自己都没意识到的需求。

2.6 实战案例：一个真实的组合应用

最后分享一个我亲身经历的案例。

当时要给一个物流系统做升级。我先调了客服工单（文档分析），发现投诉最多的是「地址录入太慢」。然后我发了问卷，发现85%的录入员每天要处理200+订单。接着我去访谈了3个录入员，他们都说「想要一个智能地址补全功能」。

但我去观察他们操作时发现——他们真正慢的地方不是打字，而是「在多个系统间切换查地址」。所以真正的需求不是智能补全，而是「减少系统切换次数」。

你看，如果我只做访谈，可能就做了个智能补全功能，但实际问题是系统集成。这就是组合方法的价值。

好了，这一章就到这里。下一章我们聊聊「如何把获取到的需求整理成需求清单」，也就是需求分类和优先级排序。到时候我会分享一个我用了多年的「需求四象限法」，保证实用。

专注课程资料整理