软件分析与设计笔记 13：需求获取：五种调查方法与一场访谈

这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，示例与图示都是自己编、自己画的。理解有偏差的地方欢迎指出。

贯穿案例：片区家电维修派单系统。02 篇讲了「两路输入」的道理，这一篇讲具体怎么去拿这两路输入。

0 为什么不能直接问「你想要什么」

如果需求获取就是问用户想要什么，那它一周就能做完。真正难的地方在于：

• 用户说的往往是他想象的解决方案，不是他实际遇到的问题；
• 用户对自己行为的描述常常不准确（02 篇那个「一张大表」的例子）；
• 用户讲不出他没见过的东西；
• 一个用户讲的，不代表所有用户都这么想。

所以事实调查（fact finding）不是「问一次」，而是用几种方法互相校验。

1 五种方法，各自的代价

1.1 背景阅读（background reading）

读现有的业务文档、制度、报表。成本最低，能快速建立术语和全貌。风险是材料常常已经过时，尤其是流程改过但文档没更新的情况。

本例的第一手材料很典型：小林那本 Excel 和那张写着「谁欠了哪个配件」的便签纸。便签纸不是正式文档，但它比任何制度文件都更接近真实流程。

1.2 观察（observation）

直接看用户怎么干活。它的价值在于能拿到「真正在发生的事」，而不是「别人说在发生的事」；也包括那些绕过系统的变通做法。风险是被观察者会改变自己的行为（知道有人看，就会做得更规范），以及需要投入较多时间。

本例里观察带来的最大发现是：小林打电话的顺序不是随机的。她总是先打给三个人，如果都没接，才去翻 Excel 找别人。这个「三个人」的名单不在任何文档里 —— 它是她三年攒下来的人情账。

这一类信息只有观察拿得到。访谈时她自己都不会提，因为对她来说那是常识。

1.3 问卷（questionnaire）

面向大量对象收集分布与倾向。适合回答「有多少人这么想」，不适合回答「为什么」。风险是问题设计会引导答案，见下一节。

本例里问卷适合的对象不是客户，而是工程师（40 人）—— 比如「你平均每周因为缺料白跑几趟」，40 份样本足以看出分布。

1.4 访谈

获取动机、原因和细节。信息量最大、成本也最高。风险是自述与实际不符（所以要配合观察）。

1.5 参与式设计（participatory design）

邀请用户直接参与方案设计。适合创新性、不确定性高的场景。风险是少数积极参与者的声音被放大，而那些沉默的多数没被代表。

本例里这一条值得谨慎：小林很愿意参与（她对这个痛点感受最深），但那 40 位工程师不可能都参与。如果只让小林参与设计，做出来的东西可能让她很顺手、却让工程师很难用。

1.6 怎么组合使用

五种方法没有优劣之分，只有「用在哪一步」。一个常见的组合是：先读文档建立框架 → 再观察发现异常 → 用访谈解释异常 → 最后用问卷确认规模。

本例的实际顺序就是这样走的，可以对照着看：

2 问卷设计：三个最容易犯的错

问卷看起来简单，但它的坑很固定。下面三个错例都改成本例的版本。

2.1 错误一：二选一问题（dichotomous question）太随意

「你是否满意当前的派单流程？」这个问题只有是/否两个答案，而绝大多数真实感受落在中间。更糟的是，它对「不满意在哪一步」毫无信息量。

改成：「上一次派单，你从接到报修到确认工程师，花了几分钟？」（填数字）

2.2 错误二：选项不互斥或不全覆盖

「你多久遇到一次缺料？A. 每周一次 B. 每月一次 C. 每季度一次」—— 把「每周三次」的人漏掉了。选项必须覆盖所有可能，且互不重叠。

改成：「A. 几乎每天 B. 每周 2–3 次 C. 每周一次 D. 每月 1–3 次 E. 更少」

2.3 错误三：诱导性提问（leading question）

「你觉得现在的派单流程是不是太麻烦？」已经暗示了预期答案。

改成：「你上一次派单时，哪一步花的时间最长？」—— 答案才可用，而且它同时告诉了你瓶颈在哪。

2.4 一份问卷的结构与试测

一份实用的问卷通常分三段：开头说明目的与用途（让填写者愿意说真话）、中段是主体问题、结尾留开放题（open-ended question）收集前面没覆盖到的情况。

本例里有句话很值得放进开头：「这份问卷是给工程师填的，填完我会在月度会上把结果讲一遍。」 —— 它给出了即时价值，比「感谢您的配合」有用得多。

问卷在正式发放前最好先做一次试测（pilot test），找几个人试填，往往能发现表述歧义和选项漏项。另外要留意：小样本的比例差异通常不具备统计显著性（statistical significance），别拿二三十份问卷的差异当结论。

3 访谈的四个阶段

3.1 准备

先写「信息需求（information requirement）清单」—— 这次访谈到底要弄明白哪几件事。清单来自笔记 04 那张四列表里「待验证的假设」。同时准备好问题顺序：从事实性问题开始，敏感问题放后面。

本例访谈小林前的清单长这样：

第 4 条是准备清单里最有价值的一类：问的是「例外」，而不是「常规」。常规她自己会讲，例外要主动问。

3.2 开场

说明目的、说明记录方式、说明会怎么用。这一步的投入很小，但决定了对方后面愿不愿意说真话。

本例里最有效的一句开场不是「我想了解一下你们的流程」，而是：「我不是来查你工作量的，我是来看哪些重复劳动可以交给系统。」 —— 因为小林一开始确实担心「是不是要用系统取代我」（案例里她听到要关诊所那一段就是这种担心）。

开场要解决的往往不是「愿不愿意配合」，而是「你会不会拿我说的东西对付我」。

3.3 提问

技术细节见下一节。

3.4 记录与回读

当场把关键结论复述一遍给对方确认（「我理解的是……对吗」）。这一步能拦下大量理解偏差，但最常被跳过。

本例里回读拦住了一个大偏差：访谈中团队理解成「她想要一个能看全部排期的页面」，回读时她说「不是全部，我一次只关心三五个」。如果没回读，就会做出 03 篇那个翻车的总览页。

4 提问的几条规则

• 问过去的行为，不问未来的意愿。 「你上次派单是怎么找人的」优于「如果有这个功能你会用吗」；
• 追问「为什么」，直到碰到不能再拆的理由。 小林说「我得打个电话确认」，要接着问「为什么要确认」，答案指向真正的约束：她怕工程师已经在路上；
• 一次只问一件事。「你觉得派单时速度和质量哪个重要」是两个问题粘在一起；
• 不要替用户回答。 说完话留出三秒空白，对方经常会补上最真实的那句。本例里那三秒之后她补了一句：「其实我最怕的是派重了」——这是整场访谈最有价值的一句；
• 允许沉默。 打断会把思路带走。

5 应对抵触

访谈中一定会遇到受访者的抵触（recognized resistance）：

「你们到底要问多久？我手上还有活。」

这时候不要解释调研的重要性（对方不关心），而是给出具体的时间承诺和即时价值：

「再占用十分钟，就问排期那件事。问清楚了，以后你不用一个个打电话问谁有空。」

抵触通常不是不愿意配合，而是担心被占用没产出。把「你能得到什么」说清楚，比讲道理有效得多。

本例里还要注意一类特殊抵触：工程师老陈一开始很不配合，因为他觉得「系统是来监视我的」（能看到他一天跑几单）。这时候有效的说法不是「系统不会考核你」，而是：「你能看到自己这周的排期，客服不会再临时塞单给你。」 —— 给出他真正想要的东西。

6 访谈记录（documenting the interview）必须写下来什么

一份能用的访谈记录，至少包含这些要素：

• 基本信息 —— 对方姓名、职务、部门、日期、时间、地点。缺了这些，几周后这份记录就没法追溯；
• 事实与观点分开 —— 他说「我们现在每天处理 80 通电话」（事实）和他认为「应该加人」（观点）要分栏记录；
• 待验证项 —— 从这次访谈里产生了哪些新的假设，需要下一步验证；
• 未答问题 —— 他没答上来的问题，往往比答上来的更有价值。

本例里「未答问题」栏填了两条，都很值钱：

这两条后来都变成了需求：前者是 10 篇那个「先做分支还是先做主线」的判断依据，后者是 06 篇「来访原因字段」。

7 常见陷阱

• 只找好说话的人。 最配合的人往往不是最有代表性的人。本例里老陈最不配合，但他的信息最值钱；
• 只问一个人就以为能代表整体。 一个用户的说法是一条线索，不是一个结论；
• 记录里混入自己的判断。 「他这里说得不太对」—— 记录只该记他说的，判断另开一栏；
• 事后凭记忆补记录。 隔一天，细节会大量丢失，尤其是数字。

本节自测

1. 五种调查方法里，哪一种最适合发现「用户实际怎么做事，而不是说怎么做事」？本例中它发现了什么？
2. 「你是否满意当前的流程」属于哪一类问题？为什么不好用？
3. 问卷的选项设计要满足什么条件？举出本例中一个改法。
4. 访谈的四个阶段里，哪一步最常被跳过，后果是什么？本例中它拦住了什么？
5. 遇到用户抵触时，与其强调调研的重要性，更有效的做法是什么？本例中怎么应对老陈的抵触？
6. 访谈记录里「未答问题」为什么比答上来的更有价值？举出本例中的一条。
7. 访谈准备清单里，为什么要专门准备「问例外」的问题？

参考答案

1. 观察（observation）。本例中它发现了「小林总是先打给固定的三个人，没接才翻 Excel」—— 这条暗规则不在任何文档里，她自己也不会在访谈时提（§1.2）。
2. 二选一问题（dichotomous question）。因为绝大多数真实感受落在中间，而且它对「不满意在哪一步」毫无信息量。改法是问可量化的具体行为，如「上次派单从接到报修到确认工程师花了几分钟」（§2.1）。
3. 必须覆盖所有可能且互不重叠。本例改法：「A. 几乎每天 B. 每周 2–3 次 C. 每周一次 D. 每月 1–3 次 E. 更少」—— 原版会把「每周三次」的人漏掉（§2.2）。
4. 记录与回读（当场复述确认）最常被跳过。后果是理解偏差一路带到设计里。本例中它拦住了「她想要看全部排期」这个偏差 —— 实际她一次只关心三五个（§3.4）。
5. 给出具体的时间承诺和即时价值，而不是讲调研的重要性。对老陈的有效说法是「你能看到自己这周的排期，客服不会再临时塞单给你」—— 给他真正想要的东西（§5）。
6. 因为答不上来往往意味着「这条规则不在他这儿」或「没人统计过」，那正是需求缺口或数据缺口。本例：「工程师请假了已派的单怎么办」→ 规则缺口；「客户取消后还会再来吗」→ 数据缺口（§6）。
7. 因为常规用户自己会讲，例外要主动问。例外里藏着最多的边界条件和业务规则 —— 本例「有没有派重过、怎么发现的」这一问，直接引出了并发派单这个场景（§3.1）。

术语表