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

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

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

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

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

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

一个写坏的例子

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

第一版卡片往往长这样：

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

三处毛病：

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

换个开头，把情境放进来

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

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

上面那张卡片改写之后：

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

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

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

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

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

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

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

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

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

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

两个容易踩的边界

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

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

回到“对齐”这两个字

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

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