软件分析与设计笔记 04：接手陌生案例的第一步：三问与一张表

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

本篇起进入贯穿案例：片区家电维修派单系统 —— 客户报修 → 客服派单 → 工程师接单上门 → 回填工单 → 仓管备料 → 片区经理看板。这一篇先做预习（把陌生案例读出条理），05 做范围界定，06 用数据校验，07 写成用户故事，08 起画图。

0 空白页恐慌

给你一份二十页的业务介绍材料，告诉你「下周要开始访谈用户」，多半会经历这样一个阶段：对着空白文档不知道该写什么，于是直接开始想方案 —— 「我觉得应该做一个 App，里面有这些功能……」

这是需求分析里最典型的起手错误：信息还没拿到，方案已经想好了。一旦进入这个状态，后面所有的访谈都会变成「验证我的方案」，而不是「发现真实的问题」。

这一篇讲一个最小的起步动作：用三个问题把自己锚在问题上，再用一张表把发现的东西固定下来 —— 也就是先做一次预习工作坊（preparatory workshop）。

1 只问三个问题

1.1 三个问题

面对陌生业务，先只问三件事：

1. Who（谁参与） —— 这个流程里有哪些角色？他们分别代表谁的利益（也就是利益相关者，stakeholder）？
2. What（做什么） —— 每个角色具体在做哪些事？动作是什么？
3. Why（为什么） —— 为什么要这么做？不做会怎样？这一步是为了满足什么？

三问的顺序不能换。先跳到最后一步「那应该怎么做」，就回到了上面说的那个坑。

1.2 为什么 Why 最值钱

Why 这个问题的价值常常被低估。拿贯穿案例里的第一句话试一次：

客服小林每天要接 80 多通电话，她最头疼的是不知道哪个工程师现在有空，只能一个个打过去问。

• What —— 客服在打电话问排期；
• Why —— 因为系统里没有排期，她只能靠人问。

如果只看到 What，方案会是「做一个更快的拨号工具」—— 这毫无意义，问题不在拨号速度。看到 Why 之后，真正的需求浮出来了：让排期可见。对应的方案是派单看板，而不是通讯工具。

这个问题在本系列后面还会反复出现：动作（What）几乎总是可以被替代的，目的（Why）才是需求。

2 为什么要把「假设」单独拎出来

2.1 事实与猜测必须分开记

在信息不全的阶段，你一定会有推断（assumption，假设）。比如看到「客服每天处理 80 通电话」，很自然会想「所以客服人力是瓶颈」。

问题在于：这个推断是事实还是猜测，必须分开记。如果不分开，几轮讨论之后，猜测就会变成「大家都知道的事实」，最后写进需求文档，没人记得它从来没被验证过。

而且在这个案例里，这个假设其实是错的：瓶颈不在客服的人手，而在于她必须一个个打电话确认排期 —— 电话量是症状，不是病因。如果照「加人手」的方案做，电话量不会降，只是多雇一个人一起打。

这就是为什么「假设」这一列必须存在：它保护你不把猜测当结论，也方便日后被数据推翻。

2.2 那张四列表

所以我用四列：

2.3 假设必须带上理由

关键在最后一列：假设（assumption）必须带上理由（justification）。因为理由是验证时唯一能操作的东西 —— 没有理由，你不知道该去看什么数据、问什么问题，也就无法推翻它。

拿贯穿案例里的一行填出来：

有了「理由」这一栏，验证动作就很具体：去看这 40 通电话里有多少是在问进度。如果确实是，那「客户自助查进度」这个功能就成立；如果不是，就得重新找因。

3 一个完整的预习输出长什么样

预习的产出不需要很好看，但要素要齐。用贯穿案例来说，一份预习材料通常包含三块：

3.1 组织结构

有哪些角色，各自负责什么。注意只记「谁负责什么」，不评价合理不合理。

客服 小林        接报修电话、记地址故障、找工程师、回电客户
工程师 老陈等40人  上门维修、回填维修记录、领配件
仓管 小周        收发配件、记录出入库
片区经理 王姐     汇总月度数据、向总部汇报
（外部）配件供应商  提供库存查询接口

3.2 端到端流程（end-to-end process）

从用户产生需求到需求被满足，中间经过哪些角色、哪些系统、哪些手工环节。这一块记录的是现有业务流程（current business process），也就是现状（as-is）；系统上线后希望达到的样子通常叫目标态（to-be）。

贯穿案例的现状可以画成一串方框：

客户打电话 → 客服手记 Excel → 客服逐个电话找工程师 → 客服回电客户
          → 工程师上门（可能发现没配件，白跑）→ 工程师回填纸质单
          → 仓管事后补录出入库 → 月底王姐手工汇总 Excel

注意这条链里有三个手工环节：手记 Excel、逐个电话找、纸质单回填。它们各自对应一个痛点，后面都会变成需求。

3.3 现存问题清单

上面那张四列表。这一块是最有价值的，因为痛点（pain point）往往就藏在这些问题背后：哪些环节在返工、哪些地方靠变通做法（workaround）绕过去。它同时记录了「已知」和「待验证」。

贯穿案例里已经能看出两类：

• 返工 —— 工程师白跑一趟（到现场才发现没配件）；
• 变通 —— 仓管在纸上记「谁欠了哪个配件」，因为系统里没有这块。

变通做法特别值得记。它说明现有流程有缺口，而人们已经自己补了一个临时方案 —— 那个补丁就是需求的原型。

这三块拼起来，你就有了一个可以拿去访谈的框架：你知道该问谁、该问什么、以及最该被验证的是什么。

4 带着问题进访谈

4.1 为什么带着清单去更有效

事实调查（fact finding）的方法有很多种 —— 访谈、观察、问卷、读现有文档 —— 但无论用哪一种，空手去最容易得到的是一段泛泛的介绍；带着一张问题清单去，得到的是具体的答案。

原因是：你问的是他实际做过的事，而不是抽象的「你们有什么需求」。

举例对比：

• 空手问：「你们现在的流程有什么不方便的地方？」—— 得到的往往是抱怨，不是事实。
• 带着清单问：「上周有多少单是到了现场才发现没配件的？那单后来怎么处理的？」—— 得到的是可以被记录、被验证的事实。

4.2 一个具体的提问顺序

预习工作坊（讲义里叫 preparatory workshop）给了一个很实用的顺序，用在访谈里同样成立：

第 5 个问题最有杀伤力。贯穿案例里问「如果客服不用一个个打电话找工程师会怎样」，答案不会是「那就没法派单了」—— 而是「那就太好了，我每天能省两小时」。这一句就已经把需求说出来了。

5 常见的三个错误

• 直接跳到解决方案。 讨论到第三句就开始说「这个用系统很好做」，从此再也听不到真实流程；
• 把假设写成结论。 「因为人工处理，所以一定很慢」—— 慢不慢要有数据，「人工」只是理由；
• 不问 Why，只记录动作。 你知道他每天做三件事，但不知道哪一件是真正不能省的那件。

再加一个这个案例里特有的：

• 只记正式流程，不记变通。 如果只记「仓管收发配件」，就漏掉了「纸上记谁欠配件」这件事 —— 而那恰恰是最有价值的一条。

本节自测

1. Who / What / Why 三问里，为什么最后才问 Why 会出问题？
2. 「客服日均接 80 通电话」和「客服人力是瓶颈」，哪一条是事实，哪一条是假设？本例中这个假设错在哪？
3. 为什么假设必须写明理由？只写结论会导致什么后果？
4. 一份预习输出通常包含哪三块内容？
5. 为什么「变通做法」特别值得记录？举出本例中的一个。
6. 访谈提问顺序里，「如果这一步消失了会怎样」为什么放在最后？它想挖出什么？

参考答案

1. 因为一旦先想方案，后面的访谈会退化成「验证我的方案」，听不到真实流程。三问的顺序是先弄清现状（Who/What），再问目的（Why），跳过 Why 就等于放弃判断这条流程该不该保留（§1.1）。
2. 「日均 80 通」是事实，「人力是瓶颈」是假设。 本例中它错在把症状当病因：真正的瓶颈是「必须逐个打电话确认排期」，所以加人手不会减少电话量，只是多一个人一起打（§2.1）。
3. 因为理由是验证时唯一能操作的东西 —— 没有理由，你不知道该查什么数据、问什么问题，也就无法推翻它。只写结论的后果是几轮讨论后猜测变成「大家都知道的事实」，最后写进需求文档（§2.3）。
4. 组织结构、端到端流程（as-is）、现存问题清单（即那张四列表）（§3）。
5. 因为变通做法说明现有流程有缺口，而人们已经自己补了一个临时方案 —— 那个补丁就是需求的原型。本例：「仓管在纸上记谁欠了哪个配件」，说明系统缺少配件挂账这块能力（§3.3）。
6. 放在最后是因为它直接指向「这一步该不该存在」。前面四个问题都在描述现状，只有这一问会逼出「那就太好了」这种答案 —— 而那就是需求（§4.2）。

术语表