1. 认识用户故事
在传统需求文档（如PRD）中，需求往往被描述为“系统应支持……功能”。这种方式容易陷入解决方案表达的误区，忽略了需求背后的真实用户与业务动机。用户故事（User Story） 从敏捷与用户中心设计（UCD）实践中诞生，它不关心“怎么做”，只关心“谁想要什么以及为什么想要”。
定义核心：用户故事是从最终用户视角出发，用自然语言描述的一个价值明确、可独立交付的需求切片。它不是完整的软件规格，而是团队开始交流需求的起点。
典型的“标准三句式”用户故事模板（Connextra格式）是：
作为 <角色> ，我希望 <功能> ，以便 <价值> 。
实践建议：不要死板套用模板。如果业务背景简单，“以便”部分可以简写甚至省略；但核心原则——“谁 + 做什么 + 为什么”——必须保持完整。
1.1.1 三要素拆解：角色 · 功能 · 价值
一个合格的用户故事必须包含三个不可分割的要素。以下表格总结了每个要素的考察标准和常见误区：
| 要素 | 含义 | 考察标准 | 常见反例 |
|---|---|---|---|
| 角色（Who） | 谁在使用这个功能？这个角色的核心目标是什么？ | 角色名称必须来源于真实用户画像或人物原型（Persona） | “系统管理员”、“运维人员” —— 太笼统，没有个性 |
| 功能（What） | 角色要做什么操作？系统需要提供什么能力？ | 一定是可观察的用户行为，而不是内部实现细节 | “生成报表（实际上用户要的是导出PDF）” |
| 价值（Why） | 为什么用户要做这件事？完成这件事能带来什么业务收益？ | 必须对齐业务指标（KPI）或用户旅程中的关键节点 | “为了提高系统性能” —— 这是技术价值，不是用户视角的价值 |
避坑指南：新手最常见的问题是“功能”写成了UI交互细节或者技术实现方式。例如：“点击绿色按钮保存”。正确的用户故事应该关注用户的目标，而不是界面元素。先写“保存订单草稿”，交互细节留给验收条件去讨论。
1.1.2 用户故事 vs. 传统需求规格
理解用户故事与 PRD 中传统需求规格（SRS）的核心差异，是将用户故事正确嵌入工程流程的前提。下表从多个维度进行了对比：
| 对比维度 | 用户故事（User Story） | 传统需求规格（SRS/PRD条目） |
|---|---|---|
| 表达焦点 | 用户意图与业务价值 | 系统功能与数据规格 |
| 详细程度 | 高抽象，几句话甚至一两句话 | 低抽象，数百字甚至数页详细描述 |
| 验收方式 | 通过 acceptance criteria 和自动化测试验证 | 通过签审文档和功能测试用例验证 |
| 变动成本 | 低，目的是鼓励迭代与反馈 | 高，修改往往需要变更控制流程 |
| 交付粒度 | 可独立开发、测试、交付的切片 | 通常是完整模块或子系统规格 |
| 生命周期 | 持续演变，衍生出更多子故事或验收细节 | 一旦签署即冻结，后期维护需额外文档 |
场景提示：上面两列表格并非对立关系。在实际项目中，用户故事可以作为PRD中“需求描述”部分的核心载体，而传统规格中的约束条件、性能指标等内容，可以放入用户故事的验收条件（Acceptance Criteria） 中，二者互相补充。
1.1.3 用户故事的核心价值：为什么产品经理必须掌握？
用户故事不仅仅是写几行字，它是一种沟通契约，其核心价值在于：
- 对齐认知：强制从“用户角色”出发，避免产品、开发、测试对需求理解产生偏差。
- 聚焦价值：每一条故事都必须回答“为什么要做”，倒逼需求评审时过滤掉低价值需求。
- 灵活拆解：用户故事可以横向按优先级拆分成多个小故事，也可以纵向按用户场景拆分为多个步骤，天然支持迭代开发节奏。
- 促进协作：用户故事是团队（产品、设计、开发、测试）沟通的起点，而非终点。围绕故事的对话要比故事本身更重要。
- 量化验收：通过明确的验收标准（Gherkin格式或条件表），每个用户故事都可以在开发完成后立即进行灰度验收，降低返工风险。
一句话总结：用户故事将“从需求到PRD”的过程从单向文档传递转变为多角色协作探索，这是课程后续所有章节（用户场景、访谈、拆解、方案表达、指标验证等）的底层哲学。
1.1.4 本章核心概念关系图
下面这张svg结构图概括了用户故事的定义、三要素、与传统需求规格的定位差异以及核心价值。它是后续章节所有讨论的基础框架。