用户故事三品

用户故事虽小，用好了不易。谈谈我观察到的用户故事之“上中下”三品。

下品：写故事

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

特点

1. 内容丰富。从业务流程说到 UI 设计，甚至连像素都定好了。
2. 主语不是用户。比如：“显示商品列表。”而不是：“浏览商品列表”。

示例对话：

1. 程序员：“这个提示信息应该是什么？你 Story 里没写啊！”
   产品经理：“好，应该是‘名称不可为空，接叹号’， 你等等，我补一下。”
2. 产品经理：“你写代码前能不能好好读一下我的验收条件？”
   程序员（盯着电脑，阅读理解中）：“中！”

解读
这只是披着用户故事的皮，实际什么也没改。

1. 团队内的交流仍以文档为准。口头说的不算数，出了问题没法撕。
2. 没有站在用户角度，更没有站在用户角度思考。

中品：讲故事

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

特点

1. 内容适中，只写重点。
2. 在需求梳理会上，产品经理讲，其它人听。

示例对话：
产品经理：“blabla，听明白了吗？不明白我再讲一遍。”
程序员（一激灵）：“我没睡着。”

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

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

要进入上品，需要转变意识：产品经理负责产品价值，产品经理和程序员一起负责用户故事。

上品：聊故事

我有酒，你有故事吗？

特点

1. 内容简短，刻意留白。
2. 需求梳理会上，你一言我一语，大家参与度都很高。

常见对话
程序员：“为什么有这个业务规则？”
产品经理：“这个背景是这样的，作为一个销售……”
程序员：“明白了。那我举个例子……是这样吗？”

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

• 业务价值
• 产品方向
• 技术可行性

这就需要团队聊出一个平衡来。

结尾

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

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

祝大家开心编故事。