第3章 用户故事与需求收集方法：如何获取原始需求
用户场景
产品经理小陈接到业务方需求：“我们要一个智能报表系统”。当他追问具体需要什么数据时，业务方说“你把所有订单数据都放上去就行”。两周后原型评审，业务方却表示“这根本不是我要的”。
这是典型的原始需求失真场景——干系人以为自己说清楚了，产品经理以为自己听懂了，但双方心智模型从未对齐。问题根源在于：需求收集阶段缺少结构化方法，直接跳到了方案设计。
核心洞察： 原始需求不是“用户说的话”，而是“用户未说出口的目标与约束”。需求收集的本质是翻译，而非记录。
业务问题
从“干系人表述”到“可执行需求文档”，中间存在三层断裂：
- 表述层断裂：干系人用业务语言描述，丢失技术实现约束；
- 理解层断裂：产品经理按自己经验补全信息，带入主观假设；
- 传递层断裂：书面需求转给设计师/开发时，上下文与优先级被稀释。
| 断裂层 | 典型表现 | 后果 |
|---|---|---|
| 表述层 | “我要一个能自动预警的仪表盘” | 未定义预警规则、数据源、刷新频率 |
| 理解层 | 产品经理直接设计5个图表类型 | 与业务真实看数习惯偏离 |
| 传递层 | 开发只看PRD中的功能列表 | 忽略业务目标与用户场景 |
避坑提示： 不要用“用户说了什么”替代“用户真正需要什么”。原始需求收集的目标是消除假设，而不是积累笔记。
需求拆解：用户故事三要素法
解决需求失真的标准工具是用户故事（User Story）。它强制从三个维度描述需求：
- As a（角色）：谁在使用？区分请求者与受益者；
- I want（功能）：要做什么？聚焦行为而非界面；
- So that（价值）：为什么做？可衡量的业务目标。
案例拆解：
原始表述：“我要一个异常订单报表”
↓
用户故事：
As a 运营主管
I want 每天9点自动收到前一日异常订单清单
So that 我能在10点前跟进处理，将履约延迟控制在2小时内
追问技巧： 当干系人提出“我要XX功能”时，连续追问三次“为什么”即可拆出So that（价值）。例如：“为什么需要报表？”→“因为要看异常订单”→“为什么看异常订单？”→“因为要跟进处理”→“为什么要跟进处理？”→“因为要控制履约延迟”。第三层回答就是真正的业务目标。
方案表达：从访谈笔记到用户故事卡
使用5W1H框架将访谈笔记结构化转写为用户故事卡：
| 维度 | 问题 | 产出 |
|---|---|---|
| Who | 谁提出？谁受益？ | 角色定义 |
| What | 想要什么功能？ | 功能描述 |
| Why | 为什么需要？ | 价值目标 |
| When | 何时使用？频率如何？ | 使用场景 |
| Where | 在哪个界面/流程中？ | 上下文位置 |
| How | 期望如何完成？ | 约束条件 |
用户故事卡模板（标准格式）：
用户故事卡
编号：US-003
标题：运营主管每日异常订单推送
角色：As a 运营主管
功能：I want 每天9:00自动收到前一日异常订单清单（含订单号、异常原因、金额）
价值：So that 我能在10:00前完成跟进，将履约延迟控制在2小时内
验收条件：
1. 推送时间可配置（默认9:00）
2. 清单支持按异常原因筛选
3. 数据延迟不超过15分钟
需求来源：运营部张经理（2025-03-10 访谈）
关联原型：PRD-03-异常订单看板
交付标准： 每张用户故事卡必须同时包含角色·功能·价值三要素，并注明需求来源（访谈人+日期）与关联原型页码，确保可追溯。
原型交互说明：用户故事与原型绑定
在Axure原型中，通过编号标签将页面元素与用户故事卡一一对应：
- 在原型页面的标题区或批注区标注
【US-003】编号； - 使用Axure的注释面板（Notes）填写用户故事的So that价值描述；
- 在交互说明中注明“该交互覆盖US-003验收条件1、2”。
这样做的好处：评审时业务方能直接看到需求来源，开发排期时可快速追溯到原始价值目标。
指标验证：需求收集阶段完成标准
| 指标 | 定义 | 验收阈值 |
|---|---|---|
| 需求收集完整率 | 已收集用户故事数 ÷ 计划覆盖干系人角色数 | ≥90% |
| 需求可追溯率 | 有关联来源的用户故事数 ÷ 总用户故事数 | 100% |
| 三要素完整率 | 同时包含As a/I want/So that的故事数 ÷ 总故事数 | 100% |
| 验收条件覆盖率 | 有明确验收条件的用户故事数 ÷ 总用户故事数 | ≥80% |
验收标准：原始需求收集交付物清单
- 用户故事卡集合（每个需求一张卡，含三要素+验收条件）；
- 需求来源登记表（记录每位干系人的访谈时间、参与人、核心诉求摘要）；
- 原型-需求映射表（展示Axure页面编号与用户故事编号的对应关系）；
- 需求收集完整性检查报告（按角色维度统计覆盖率）。
交付物模板：需求收集检查清单
需求收集阶段检查清单
□ 所有关键干系人已完成访谈（至少覆盖：业务负责人、运营主管、技术对接人）
□ 每张用户故事卡包含 As a / I want / So that
□ 每张用户故事卡标注需求来源（访谈人 + 日期）
□ 每张用户故事卡关联至少一个Axure原型页面编号
□ 用户故事卡已按RICE维度初步标注（Reach / Impact / Confidence / Effort）
□ 验收条件已覆盖主要正向场景 + 1~2个异常场景
□ 需求收集完整率 ≥ 90%
□ 需求可追溯率 = 100%
RICE前置标注： 在需求收集阶段即可对每张用户故事卡打上预估的RICE分值（Reach影响人数、Impact业务影响、Confidence置信度、Effort开发人天），为后续第8章优先级排序准备原始数据。标注格式建议：
R:2000 / I:0.8 / C:70% / E:5人天。
流程说明： 三种需求收集方法（访谈·观察·文档分析）并行开展，产出物统一汇入原始需求池。随后按用户故事三要素法拆解为结构化卡片，并定义每张卡片的验收标准。此流程确保每个需求可追溯、可验证、可排序，为后续RICE优先级评估打下坚实基础。