用户故事作为一种图形化的需求分析技术，在敏捷开发中被广泛使用，本文作者对用户故事展开了梳理分析，希望通过此文能够加深你对用户故事的认识。

一、什么是用户故事？

故事地图是一门在需求拆分过程中保持全景图的艺术。—-Jeff Patton《用户故事地图》

1. 用户故事

用户故事是一种需求分析和产品分解落地的方法，在敏捷开发中被广泛使用。敏捷开发会通过用户故事看板工具，来解决团队一致性的沟通问题、产品的分版本、分阶段落地等问题。

用户故事是一个可视化的过程，使用文字和图片相结合的方式辅助讨论，是一种在产品早期阶段建立共识的机制。

2. 用户故事地图

用户故事地图是一个有风向的图表，横轴为时间线，放置延时间线的用户故事，

纵轴为开发优先级，自上而下。用户故事地图覆盖了所有用户需求场景。

3. 用户故事的组成

还记得以前写作文事件的三要素：时间、地点、人物吧？用户故事地图也有三

要素：

1. 角色：谁要使用这个功能。

2. 活动：需要完成什么样的功能。

3. 业务价值：为什么需要这个功能，这个功能带来什么样的价值。

举例：

作为一个“零售门店店长”，我想要“统计每天有多少人到过我的店铺”，以便于“我的门店是否有足够多的客户关注和客户来源。”

4. 3C原则

由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。

• 卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，工作量估算等。
• 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
• 确认（Confirmation）：通过验收测试确认用户故事被正确完成。

二、为什么使用用户故事？

1. 避免陷入细节

用户故事地图通过讲故事的方式和场景化技术可以让产品经理更多关注用户场景和用户体验，避免沉入技术细节之中。

2. 面向业务

用户故事不但要说明要什么，还要思考为什么要，它的商业价值是什么？它可以帮助我们聚焦于成果，即产品发布后用户能使用和感知的东西。

3. 易于理解

用户故事使用了大家熟悉的“讲故事”的表达方式，代入感很强，便于理解，而且全程都是可视化的。用户故事可以降低沟通与达成共识的成本，可以让团队将关注力更多集中在产品上而非术语的理解。

4. 敏捷驱动

用户故事地图提供了一种从大故事(史诗故事)到小故事，从高层次场景到低层次场景的需求建模技术，整个过程遵循全场景交付、逐层细化的敏捷开发原则，可以让开发团队使用敏捷中的迭代和增量开放方法跟踪、优化内容，确定版本计划和目标。

三、如何编写用户故事？

编写用户故事地图一般包括4个步骤：

1. 识别机会

在故事编写准备阶段，我们首先要识别用户面临的挑战和大的机会是什么，也就是识别问题。通常由BA或PM 主导产出，主要有几点内容：

• 这个大想法到底是什么？
• 客户是谁？我们认为哪些故事会采购这款产品？
• 用户是谁？采购这款产品的公司中，哪些人会用到该产品，他们会用它来解决什么问题？
• 购买和使用的动机？解决了那些客户和用户当前无法解决的问题？使用之后能获得什么样的收益？
• 为什么要开发这款产品？如果开发出兵获得成功，我们的公司又会得到哪些收益？

2. 骨干故事

按照广度优先而非深度优先的原则尝试展示用户故事的全景，包括所有的步骤，用户的关切和痛点。

通常可以用时间轴为顺序，将用户的主要活动轨迹分解为几个关键步骤，从而构建一个用户活动全景图。

例如，如果我们从“和女友吃西餐”这个故事开始：

首先，我浏览菜单和食物的图片，然后再检查价格。我希望服务员给我一些推荐，告诉我一些特色菜品。然后我会咨询一下女友的建议，让后我下订单。

我们把这个故事分解为四个步骤：

浏览菜单-》选择菜品-》匹配口味-》下单

按照这个顺序，用户的主要活动如下:

1. 我想要一个菜单，其中列出每个商品的说明、图片和价格，以便我可以决定要哪些菜品，同时我希望服务员给我一些建议。
2. 我希望每天提供特殊的食物，以便我可以尝试菜单上通常没有的独特菜肴。
3. 我想花点时间了解大家的口味偏好，这样我会让大家都感到满意。
4. 我希望在下单后可以更新菜单，这样我在点餐的过程中会更加舒心。

3. 拆分故事

向深度拓展，此时我们讨论：用户在这关键步骤还会做什么？怎样才能更爽？出了问题以后怎么办？

可以按照以下几个维度对细节进行归类，分别是：故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得，也可以通过用户想法、用户的痛点结合主观判断。

继续拆分“和女友吃西餐”这个故事：

1. 我想要一个菜单，我希望提供一些菜品搭配建议或套餐组合，以便我可以快速做出选择。
2. 我希望菜单信息中包含了卡路里信息，我有健康饮食的习惯
3. 我希望可以提前预定一个蛋糕和现场有音乐伴奏，这样可以给女友更多的惊喜。
4. 我希望可以可以在下单时提供多种支付选择，这样我会避免忘带现金的尴尬

按照这样的拆分方式我们可以细分出更多层级，层级的规模取决于主干故事的规模。

4. 沟通和确定

通过讨论果断去掉那些无助于取悦用户用户的东西，确定达成目标的最小解决方案(MVP)。可以按实现顺序和优先级，将最小可行方案进一步切分。这些用户故事加在一起就构成了产品需要做的主要功能。

四、如何实现一个电子版的用户故事地图？

通常我们可以将用户故事的描述信息以传统的手写方式写在纸质卡片上，这样便于大家讨论。作为便于记录和保存，我们也可以使用Leangoo这样的工具来实现一个可以协同工作的电子版用户故事地图。

Leangoo看板工具很容易实现，在看板中，我们有列表和泳道的概念，列表代表了纵向的纬度，泳道代表了横向的纬度。

在Leangoo中，使用列表代表不同的发布，我们通常建立这么几个列表：史诗级故事(主干故事)，Sprint1，Sprint2，Sprint3-N，已交付的故事。横向的泳道代表的是史诗故事和史诗故事拆分的子故事的对应关系。如下图所示：

1. 故事背景

在园区、景区、校区等业务环境中，我们经常会遇到故障上报的场景：故障接待员员在巡视过程中如果遇到各种异常，需要通过客户端系统上报故障并提交故障信息，然后由项目经理安排故障处理员现场处理。

故障上报的主要活动步骤为：管理账号-》上报故障-》安排人员处理-》处理故障。

2. 主干故事

0-1.作为系统管理员,我希望可以初始化报障接待员、项目经理、故障处理员的身份信息,以便我控制系统的用户权限

0-2.作为报障接待员,我希望可以在遇到故障时填写并提交故障登记表,以便我可以更有效的完成故障登记工作。

0-3.作为项目经理,我希望可以收到填好的故障登记表, 以便我可以对项目的故障处理进行安排。

0-4.作为故障处理员,我希望可以及时的处理设备发生的故障,以便我可以做好自己的工作。

3. 二级故事

1-1.作为系统管理员,我希望可以在遗失密码时提供面找回功能，以便管理我的账号

1-2.作为报障接待员,我希望可以在遇到故障时登记客户信息,以便统计。

1-3.作为项目经理,我希望可以可以按项目查询维修单和关闭无效任务单，以便维护和管理维修单。

1-4.作为故障处理员,我希望在故障处理后可以记录故障原因和故障处理方法,以便归纳和总价故障案例。

4. 三级故事

2-1.作为系统管理员,我希望可以记录操作日志，以便账号安全

2-2.作为报障接待员,我希望可以在遇到故障时可以上报附件,以便增加现场原始记录。

2-3.作为项目经理,我希望可以可以按时间/原因/客户等维度查询故障单，以便维护和管理维修单。

2-4.作为故障处理员,我希望在可以将任务单重定向到其他人，以便在指派错误的情况下，指派任务可以继续履行

通过Leangoo将上述用户故事记录下来同时生成用户故事看板：

通过Leangoo看板，我们可以非常方便的通过故事地图把产品的需求全景图展示出来，产品的规划也一目了然，这对于我们持续地关注产品核心价值，更好地进行产品规划非常有帮助。

#相关阅读#

B端产品经理养成记（1）：业务场景

作者：涛哥，微信公众号：涛哥笔谈。前华为高级产品经理，TOGAF认证专家，PMP认证专家，PPV课数据科学社区创始人，数字化转型实践者

本文由 @涛哥 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议