# 把问题写成用户故事：让团队对齐“为谁、在什么情况下、要完成什么”

用三段式模板、Job Story 和 Given-When-Then，讲清怎样把已经定义清楚的问题写成团队能讨论、能反驳的卡片，而不是直接跳到功能清单

> 用户故事 · 需求文档 · 团队协作 · 约 5 分钟 · 09 月 21 日

## 本篇要点

1. 用户故事的作用是把一个已经定义清楚的问题变成团队能一起讨论、能反驳的东西，它不是给功能换一种写法。
2. “作为谁、我想要什么、这样为了什么”这个句式来自 2001 年 Connextra 团队；三句里最容易被省略的“这样”恰恰是唯一能被质疑、也最需要被记住的部分。
3. “作为用户，我想要一个导出按钮，这样我就能导出数据”有三处毛病：受益者笼统、第二句写的是功能而非目的、第三句是同义反复。
4. 把开头从“谁”换成“什么时候”，写成“当……我想要……这样我就能……”，卡片里的“导出”就消失了：邮件周报、汇总页面、导出文件都成了候选，团队可以比成本。
5. 换成情境开头，是因为属性解释不了动机；同一条需求里店长和区域经理的动机可能一样，按属性拆成两个画像反而割裂受众，但画像在推广和定价上仍然有用。
6. Ron Jeffries 说用户故事有三部分——卡片、对话、确认，卡片信息量最小；确认就是验收标准，常写成 Given（开始前的状态）、When（发生的事件）、Then（期望的结果），写不出来往往意味着情境还没问够。
7. 模板和 INVEST 都不是门禁：Cohn 说这个句式只是思考工具，Wake 说这些标准该在写和做的过程中一直用，而不是开工前的检查站。
8. 写完卡片最该问团队的是“哪里不对”，而不是“写得清楚吗”。

---

上一篇讲的是需求总比产能多，所以真正的动作不是排一张总榜，而是反复回答“接下来做什么、这一轮明确不做什么”。但在排序之前还有一步经常被整个跳过：把你已经想清楚的那个问题，写成团队里其他人也能看懂、能反驳、能照着动手的东西。

大多数人的默认动作是直接拉一张功能清单：加导出按钮、加工单合并、加审批流。功能清单的毛病不是它错，而是它来得太早——它在你还没让团队理解“为什么”的时候，就把方案锁死成了唯一答案。

## 用户故事是一句给对话用的占位符

“作为……我想要……这样……”这个句式是 2001 年 Connextra 团队的 Rachel Davies 等人提出的，后来因为 Mike Cohn 在《User Stories Applied》里的推广变成行业通用写法[1]。它一共三句：

- **作为 [谁]**：这件事的受益者是谁。
- **我想要 [做什么]**：这个人想推进的一件事，不是系统上的一个功能。
- **这样 [为什么]**：这件事对他的价值。

三句里最容易被省略的是第三句，而它恰恰是唯一能被质疑的部分。Mike Cohn 在博客里讲过一个真实的例子：一位 CTO 要求团队复用公司现有的订单数据库，不要新建一个。如果需求只写成“必须使用现有订单数据库”，几个月后没人记得原因，产品负责人被问到“能不能建第二套库”时可能回答说“我没意见”，团队就会犯下当初被明令禁止的错误。写成“作为 CTO，我希望系统复用现有订单数据库，这样我们不用多维护一个数据库”，原因就被钉在了卡片上[2]。

## 一个写坏的例子

假设你在一家做连锁餐饮后台系统的公司。店长每周一早上要向区域经理汇报上周的门店经营情况，现在他得从三个页面把数据抄进 Excel。这件事你已经问清楚了：谁、什么时候、要完成什么，都说得出来。

第一版卡片往往长这样：

> 作为用户，我想要一个导出按钮，这样我就能导出数据。

三处毛病：

1. **“用户”是谁？** 抄数据的店长和看数据的区域经理是两个不同的人，诉求不一样。用一个笼统的“用户”把他们都盖住，等于谁都没写。
2. **第二句是功能，不是目的。** “导出”只是可能达成目的的方案之一，它被写进卡片的那一刻，讨论就结束了。
3. **第三句是同义反复。** “导出是为了导出”，等于没有第三句。

## 换个开头，把情境放进来

2013 年前后，Intercom 的产品团队发现按传统方式写卡片很难讨论下去，于是把开头从句式里的“谁”换成了“什么时候”[3]：

> 当 [情境]，我想要 [动机]，这样我就能 [结果]。

上面那张卡片改写之后：

> 当我在周一早上要向区域经理汇报上周经营情况时，我想要一次拿到上周全部门店的关键经营数据，这样我不用在三个页面之间来回抄。

“导出”这个词消失了。这不是文字游戏：方案空间被打开了——自动周报邮件、页面上的汇总视图、导出 CSV 都可能是答案，团队可以拿它们比成本、比工期。而原来那张卡片只有一个答案，就是那个按钮。

Intercom 换开头是因为一个更大的判断：用户画像关注的是人的属性，而“要完成的活”关注的是情境和动机[3][4]。属性常常会人为地把受众割裂开——同一件“周一早上要拿出上周数据”的事，店长和区域经理的动机可能完全一样，硬拆成两个画像，反而把一个需求拆成两个。这里说的不是画像没用（它在推广、定价、找访谈对象时仍然有用），只是它解释不了“人为什么做这件事”，而设计产品要的正是后者。

## 卡片只是三分之一：还有对话和确认

Ron Jeffries 有个被反复引用的说法：一个用户故事其实有三部分——卡片（Card）、对话（Conversation）、确认（Confirmation）[5]。卡片是三者里信息量最小的那个，它只是“承诺将来要好好聊一次”的凭证。

**确认**就是验收标准：怎样算做完了。这里通行的写法是 Dan North 在 2006 年提出、用来描述 BDD（行为驱动开发）场景的 Given-When-Then[6][7]：

- **Given**：开始之前，世界是什么状态。
- **When**：发生了什么事件。
- **Then**：期望出现什么结果。

上面那张周报卡片的确认部分可能是：

- Given 今天是周一早上，上周数据已经全部入库；
- When 我打开周报页面；
- Then 我能看到上周全部门店的核心指标，并且能把这份内容发给区域经理。

为什么必须补这一段？因为卡片本身是**故意写得含糊的**——这是模板的设计意图，不是偷懒。含糊的代价是每个人心里想的不是同一件事。验收标准是在含糊被兑现成代码之前，唯一能把它变成可争论内容的地方。写不出 Given-When-Then，通常说明情境还没问够，而不是说明这个需求太简单。

## 两个容易踩的边界

**第一，用户故事不是任务拆解。** 如果卡片写成“在前端加一个下拉框”，它已经不是用户故事了。Bill Wake 提出的 INVEST 就是判断一张卡片好不好的几条标准（独立、可协商、有价值、可估算、足够小、可验证），这里不展开；只需要记住它不是开工前的门禁，应该在写卡片和做卡片的过程中一直用[8]。

**第二，模板也不是门禁。** Cohn 明确说过，这个句式只是思考工具；某条约束用这个句式写出来别扭，那就别用模板，换一种自然的写法写清楚[2]。

## 回到“对齐”这两个字

真正要交付的不是卡片，是共识。检验方式很土：把卡片念给设计和研发听，让他们各自复述一遍“我们到底要解决什么”。如果有人说“我以为这个是要给区域经理做自动推送”，你就拿到了一次非常值的反驳，而且它发生在写代码之前。

所以写完一张卡片之后，最该问团队的不是“写得清楚吗”，而是“哪里不对”。

## 术语表

- 用户故事（user story）：用一两句话把“谁、想要什么、为什么”写下来的短卡片，作用是引发讨论，不是把需求说全。
- 三段式模板：作为 [谁]、我想要 [什么]、这样 [为什么]，三句分别固定受益者、动机和价值。
- Job Story：把模板开头从“谁”换成“什么时候”，写成“当……我想要……这样我就能……”，用情境代替画像。
- 验收标准（确认）：判断一张卡片算不算做完的具体描述，常写成 Given、When、Then 三段。
- 三 C：卡片、对话、确认——用户故事的三个组成部分，卡片只占其中三分之一。

## 来源

1. [BDD 历史文档 — 记录 Connextra 三段式用户故事模板及 Given-When-Then 的形成](https://github.com/cucumber/website/blob/main/docs/bdd/history.md)
2. [Mike Cohn: Non-functional Requirements as User Stories — 用 CTO 要求复用订单数据库的例子说明“这样”这一句的价值](https://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories)
3. [Intercom: How we accidentally invented Job Stories — Job Story 的由来，以及为什么属性导向的画像会限制对用户的理解](https://www.intercom.com/blog/accidentally-invented-job-stories/)
4. [Intercom: Designing Features Using Job Stories — 从观察到写出 Job Story 的具体步骤](https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/)
5. [Bill Wake: All You Need is INVEST? No! — 回顾 INVEST，说明它不该被当作开工前的门禁](https://xp123.com/all-you-need-is-invest-no/)
6. [Dan North: Introducing BDD — Given-When-Then 场景写法的出处](https://dannorth.net/blog/introducing-bdd/)
7. [Martin Fowler: GivenWhenThen — 解释 Given、When、Then 三段各自描述什么](https://martinfowler.com/bliki/GivenWhenThen.html)
8. [INVEST (mnemonic) — INVEST 六条标准的含义与出处](https://en.wikipedia.org/wiki/INVEST_(mnemonic)

---

原文：https://pangzhengboyin.com/articles/writing-user-stories-and-job-stories-1f5e6ae1

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com