用户故事的使用，有上中下三品：下者写故事，中者讲故事，上者聊故事。来对号入座一下？

下品：写故事

宣言

哪有什么用户故事？我只不过是把之前写需求规格书的时间用在了写用户故事上。

特点

1. 内容丰富。从业务流程写到 UI 设计，甚至连像素都定好了。

2. 主语不是用户。比如：“显示商品列表。”而不是：“浏览商品列表”。

示例对话

程序员：「这个提示信息应该是什么？你 Story 里没写啊！”」

产品经理：「好，应该是‘名称不可为空，接叹号’， 你等等，我补一下。」

产品经理：「你写代码前能不能好好读一下我的验收条件？」

程序员（盯着电脑，阅读理解中）：「中！」

解读

这只是披着用户故事的皮，实际什么也没改，比如：

• 交流仍以文档为准。口头说的不算数，出了问题没法撕。

• 仍然以团队为中心，而不是以用户为中心。

中品：讲故事

宣言

有些故事，还没讲完，那就算了吧。那些需求，在岁月中，已经难辨真假。

特点

1. 内容适中，只写重点。

2. 在需求梳理会上，产品经理讲，其他人听。

示例对话

产品经理：「blabla，听明白了吗？不明白我再讲一遍。」

程序员（一激灵）：「我没睡着。」

解读

团队开始面对面交流，而不是背对背拥抱了。但大部分时间都是产品经理的单向输出。

根源在于分工太明确：产品经理负责用户故事，程序员负责写代码。

要进入上品，需要转变意识：产品经理聚焦于问题（用户价值），产品经理和程序员一起共同设计方案（用户故事）。

上品：聊故事

宣言

我有酒，你有故事吗？

特点

1. 内容简短，刻意留白。

2. 需求梳理会上，你来我往，气氛热烈。

示例对话

程序员：「为什么要这么做？」

产品经理：「这个背景是这样的，作为一个销售……」

程序员：「如果是这个原因，我们是否可以换个做法？……」

产品经理：「只要这个业务规则被遵守，那样做也可以。」

程序员：「对于这个业务规则，我来举个例子……是这样吗？」

产品经理：「是的，你这提醒了我，我又想到一个场景……」

解读

用户故事是对业务需求的解决方案，它至少应该考虑到

• 业务价值

• 产品方向

• 技术可行性

这就需要团队在各个因素的平衡取舍中，一起聊出一个好的故事出来。

另外，程序员对业务规则的理解，不是靠产品经理单方面的传递，而是靠举出实例来验证对它的理解。

结尾

用户故事不是需求，它是一个用来「理解需求，共创解决方案」的协作工具。

上中下三品，不是针对产品经理或者程序员，说的是整个团队。要达上品，非凭单个角色一己之力可以达成。

祝大家开心编故事。