软件项目开发全流程 · 第 6 课 · 需求获取：访谈、问卷与用户故事
1、为什么"用户说的"和"用户要的"不一样
一个经典故事：客户说"我要一匹更快的马"，而真正的需求是"更快地到目的地"。如果团队照着字面做，交出去的就是一匹养不起的马。
需求获取（Requirements Elicitation）之所以难，是因为：
- 用户说不清：他们描述的是"解决方案"，不是"问题"。
- 用户不说全：日常习惯性的东西，他们觉得"这还用问？"
- 用户之间会打架：销售要灵活，财务要管控，运维要稳定。
- 用户也不知道未来要什么：需求本身是逐步浮现的。
所以需求获取不是"抄录用户口述"，而是和用户一起把问题问清楚、把假设摆出来。
2、需求从哪来：六类常见来源
| 来源 | 能拿到什么 | 注意 |
|---|---|---|
| 直接访谈 | 目标、痛点、期望 | 要找真正用的人，不只是买单的人 |
| 问卷 | 广度、共性、优先级初排序 | 问题设计差会得到垃圾数据 |
| 观察/影子跟随 | 真实工作流、隐性规则 | 用户"说"的和"做"的常常不同 |
| 现有系统与文档 | 历史包袱、既有字段 | 老系统的字段不代表新需求 |
| 数据与日志 | 真实使用频率、瓶颈 | 用数据反驳"我觉得大家都需要" |
| 竞品与行业规范 | 行业惯例、法规约束 | 抄功能容易，抄不清背后的取舍 |
关键动作：先画干系人地图（第 3 课），再决定"该访谈谁"。 漏掉一个关键角色，后面就会在验收会上第一次听到他的意见。
3、访谈：问对问题的艺术
访谈三禁忌：
- 问"你要什么功能？"——他会给你一个半成品方案。
- 问"是不是这样？"——引导性提问，只会得到点头。
- 只听、不追问——「好的」「还行」背后往往藏着坑。
推荐问法：
- 问场景："上次发生这个问题时，你当时在做什么？"
- 问频率："这事一周发生几次？"（频率决定优先级）
- 问代价："如果做错了，会有什么后果？"（风险等级）
- 问替代："现在你是怎么绕过去的？"（临时方案往往是真需求）
- 追问五个为什么（5 Whys）：从"想要导出 Excel"问到"因为要给老板看日报"，真正的需求可能是"自动日报"。
访谈记录要当场确认："我复述一遍，你看我理解得对不对"——这是最便宜的错误拦截。
4、问卷与观察：补充手段
问卷适合：已经知道问什么、需要覆盖很多人、需要量化排序。
- 少用开放题，多用单选/多选 + 李克特量表（1~5 分）。
- 题目要避免双重问题（"你觉得速度快吗？"——快=响应快还是上手快？）
观察适合：流程复杂、用户说不清、存在大量隐性操作。
- 现场记下：他点了几次？在哪卡住？用了哪个 Excel 绕过？
问卷和观察都不是访谈的替代品，而是交叉验证：访谈说"大家都要这个功能"，问卷一跑才发现只有 3% 的人用。
5、用户故事：敏捷的通用语言
敏捷团队不写厚厚的需求规格书，而是用用户故事（User Story）描述需求：
作为 <某类用户>，
我想要 <某个能力>，
以便 <获得某种价值>。例：
作为 项目负责人，
我想要 一眼看到本周所有逾期任务，
以便 及时调整人力而不是等周报。为什么故事比规格书好用？ 它逼你写清"谁、要什么、为什么"。很多需求一看就知道不成立——因为"以便"那半句写不出来。
关键认知：故事是"对话的占位符"，不是需求的全部。 卡片上写不下所有细节，细节靠沟通补齐，共识靠验收标准固定（第 7 课）。
6、INVEST 原则与 3C
一个好故事要满足 INVEST：
| 字母 | 含义 | 反例 |
|---|---|---|
| Independent | 尽量独立，不互相绑定 | "必须先做 A 才能做 B" |
| Negotiable | 可协商，不是死合同 | 卡片写得像法律条文 |
| Valuable | 对用户有价值 | "重构数据库"（是任务不是故事） |
| Estimable | 团队能估出大小 | "让系统更智能" |
| Small | 足够小，一个迭代内能做完 | "做完整套权限系统" |
| Testable | 可验证 | "体验要流畅" |
3C 原则：Card（卡片）+ Conversation（对话）+ Confirmation（确认）。卡片只是引子，对话产生理解，确认（验收标准）锁定范围。
敏捷里最贵的不是写卡片，而是那张卡片引发的对话。
7、史诗、主题与故事地图
需求不是散点，而是有层次的：
主题（Theme）/ 史诗（Epic） —— 大块价值，如"任务协作"
└─ 用户故事（Story） —— 可在一个迭代内交付
└─ 任务（Task） —— 工程师的执行单元史诗拆分的常见切法：
- 按流程步骤拆（创建 / 编辑 / 归档）
- 按业务规则拆（先做基础规则，再加例外）
- 按用户角色拆（先普通成员，再管理员）
- 按数据范围拆（先小数据量，再做批量）
故事地图（Story Map）：横轴是用户使用流程（从左到右），纵轴是优先级（从上到下）。它能让你一眼看到"先做哪条主线就能跑通整个流程"——MVP 的骨架就这样浮出来。
8、需求获取里最常见的五个坑
- 只找买单人：老板说"要个报表"，真正的用户是天天填数据的专员——他才是决定产品好不好用的人。
- 把方案当需求："加个导出按钮"背后可能是"不想每天手工汇总"。
- 假设没写下来：所有"我以为"都是未来的事故源，必须写进假设清单。
- 跳过非功能需求："要快""要安全"必须量化成可测指标（第 7 课展开）。
- 一次性问完就散：需求是逐步涌现的，敏捷用迭代反复校验，而不是一次会谈定终身。
9、动手实验 🎯
任务：为你的「团队任务清单」项目做一轮需求获取。
- 列出 5 类干系人，为每类写一句"他最关心什么"。
- 挑 1 位真实或假想用户，做一次 20 分钟访谈，用 5 Whys 追到根因，记录原话。
- 把访谈结果写成 8~12 条用户故事（严格用"作为…我想要…以便…"格式）。
- 用 INVEST 逐条检查，把不合格的（不可测、太大、无价值）标出来并改写。
- 画一张 故事地图：横轴是"登录 → 建任务 → 指派 → 提醒 → 完成 → 统计"，纵轴按优先级排，圈出 MVP 的最小闭环。
- 写一份 假设清单（至少 5 条"我们假设…"）与 待确认问题清单。
做完这步，你手里就有一份"从用户嘴里捞出来、还带假设标注"的原始需求池——下一课把它整理成可管理、可验收的规格。
10、今天你带走的三句话
- 用户给的是方案，你要挖的是问题——5 Whys 和场景追问比列功能清单有用得多。
- 用户故事是对话的占位符，卡片之外还必须补验收标准，否则"做完了"没人认。
- 用好故事的三把尺子：INVEST 判断质量，3C 保证共识，故事地图找出 MVP 主线。
下一课我们进入需求分析与需求管理——把这一堆故事变成有优先级、有验收标准、有基线、可追溯的待办列表。