《用户故事地图》读书笔记：产品经理必须掌握的分析利器

在产品工作中，有时候会遇到这样一些问题：

1、做产品规划时，会漏掉一些关键功能，没有很好的需求分析方法论；

2、版本迭代时，只见树木，不见森林，不停的做功能需求，却忽略了产品全景；

3、研发拿到的是产品提交的功能需求，却没有弄清楚真实的用户需求，开发出来的功能达不到预期。

最近读到《用户故事地图》，利用“用户故事地图”，就可以解决以上问题。

01. 用户故事

在讲用户故事地图之前，先来说下用户故事。

用户故事，最早由Kent Beck提出，Kent Beck是敏捷开发创始人，提出用户故事的本意，是想解决共识的问题。

用户基于某个场景，提出了自己的需求，产品经理基于用户的需求提出解决方案，将其转为功能需求，研发基于产品的功能需求文档进行开发， 最终发现开发出来的功能根本就不是用户想要的。

或者本来可以有更好的实现方案，但是因为只看到功能需求，而没了解到用户需求，所以没机会把更好的方案做出来。

产品在产品的认知范围内做决策，研发基于研发的认知做决策，而产品的认知和研发的认知却不一样。

产品经理不断的细化需求文档，写得越来越标准，但不同的人，对相同的文档，理解不一样，共识问题想完全靠文档解决，是不现实的。

那如果让研发能知道用户的真实需求，是不是就能解决这个问题呢？

于是Kent Beck 就提出用户故事这个方法，大家都喜欢听故事，从一开始，就只说用户故事，而不是只说功能需求。

这样，产品和研发对用户需求的理解是一致的，能更好的达成共识。

02. 用户故事怎么写？

一个完整的用户故事，应该包含三部分内容：用户、功能、价值。

-用户：是谁要用这个功能；

-功能：具体是什么功能；

-价值：通过这个功能，用户能获得什么价值；

通常用这样的格式表达：作为一个<用户>，我想要<功能>，以便于<价值>

例如：作为一个<在外务工的农民工>，我想要<一匹马>，以便我<春节可以回家过年，与亲人团聚>。对于这个用户故事，由于产品经理没见过车，也不知道有车的东西，于是提供了马这个解决方案，但是开发人员知道有车，就会提出车这个更好的解决方案。

写用户故事地图，应该遵循几个原则：

1、独立的，如果两个故事有依赖，则合并为一个大的故事

2、可讨论的，故事本身就是一个沟通的工具，用户故事不是合同，不需要写的过于详细；

3、有价值的，这是用户故事最重要的一条，要是没有价值，还做他干什么呢？价值让研发不仅做，还要知道为什么做；

4、可估算的，估算用户故事，可以帮我们更好的判断工期，评估是否有足够的资源，有多少人办多少事，如果不能估算，可能有几种原因：①研发不了解业务；②研发缺少技术知识；③故事太大；

5、颗粒度小的，过大的用户故事不便于评估，如果双周迭代，3-5天的颗粒度是合适的；

6、可测试的，如果故事不可测试，就无法衡量是否达到预期，是没有评判标准的；

03. 用户故事地图

上面说了用户故事，再来说下用户故事地图。

用户故事地图，是由用户故事组成的全景图，用户故事由活动和用户故事组成，活动是完成用户目标的核心步骤，用户故事是根据核心步骤拆分出来的小任务。

例如，用户在电商产品，核心步骤可以分为：浏览商品——下单——付款——收货——评价，在浏览商品这个步骤里，可以分为更细的任务，如查看首页、搜索、对比、查看详情、查看评论等。

用户故事地图，有这样几个作用：

1、和业务、研发，甚至用户一起梳理需求， 不遗漏关键功能；

2、在团队内达成共识，让项目成员 有全局感，既见树木，又见森林 ；

3、更好的规划版本，每次新迭代，都是做的当前最重要的功能， 不浪费研发资源；

04. 用户故事地图的创建方法

绘制用户故事地图，需要 召开一次用户故事会议 ，参与会议的人必须是各岗位关键角色，包括产品负责人、项目负责人、业务负责人、技术和老板，人数控制在7人以内，但不要少于3人。这些人都代表了平台建设中的主要角色的看法。

同时， 要提前准备材料 。和WorkShop一样，我们在开始之前，要准备一个白板、不同颜色的便利贴、胶带等等。同时还要明确产品目标，要解决的用户问题以及或许有的收益等等。

1、第一步，进行产品定义。 我们要确定我们的用户是谁？解决什么问题？用户目标是什么？产品目标是什么？通过这些问题，可以基本框定整体的范围。

2、第二步，梳理骨干故事。 梳理故事要确定好一级故事、二级故事，保证故事的完整性，同时要广度优先，而非深度。最后的效果就是看到故事群。

3、第三步，拆分故事。 在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。项目组会围绕这个故事写出很多细节来。

在这个过程中，先让大家在一定时间内按照自己的想法写出来，每一条写在一张卡片上，做到相互不干扰，然后每个人出声说出自己的卡片内容，让所有人了解并贴在墙上。

项目组人在写想法的时候，相当于脑暴的过程，这时可以通过一些问题来刺激大家脑暴出更多的内容，比如：

– 用户在这步具体做什么?

– 用户还有其他选择么?

– 用户怎么做才能更爽?

– 出现问题如何处理?

在真实业务当中，发生特殊情况该怎么办？所以这一步我们将尽量多的关注到所有场景的故事。做完这步，我们已经获取到了足够多的细节信息，整个项目组都会做到对产品又见森林又见树木的状态。

4、第四步，沟通确认。 这一步是将前面丰满而又臃肿的故事，通过对标标题、充分讨论，把公认的留下来，无用的剔除掉，同时区分要做的故事细节的优先级。完成所有故事梳理后，就出现了下面这张图：用户故事地图。

05. 写在最后

用户故事是方便达成共识的一种沟通工具，用户故事包含3个要素：

用户、功能、价值。

写用户故事，应该遵循6个原则：独立的、可讨论的、有价值的、颗粒度小的、可估算的、可验证（测试）的。

用户故事地图是由用户故事组成，通过用户故事地图，可以更好的分析需求、版本规划，做到既见树木又见森林，创建用户故事地图，分为四步：产品定义、梳理骨干、拆分故事、沟通确认。

用户故事是敏捷开发的起始点，如果团队在用敏捷开发，而又不知道用户故事，那就不是敏捷开发，利用好用户故事和用户故事地图这2个工具，可以更好的践行敏捷开发。