【推荐】产品经理必须掌握的10种优先级决策技术详解---技术10：故事地图---Story mapping

故事地图是什么

故事地图（Story Mapping），也被称为是“故事映射”，当然，全称是“User Story Mapping（用户故事地图/映射）”。

熟悉Scrum的朋友应该对“User Story（用户故事）”非常熟悉，但是“用户故事”和“故事地图”是一回事吗？

是这样的，2005年的时候，Jeff Patton（老汤注：他提出了要融合敏捷思维、精益化和精益创业思维、用户体验设计和设计思维，最终形成一种以产品为中心的整体工作方式）在他的《User Story Mapping: Discover the Whole Story, Build the Right Product》一书中首次提出了“Story Mapping”的思想，但是，直到2008年，它提出的这个思想才正式命名为“Story Mapping”。

不说别的，单看诞生的时间，我们就知道，“User Story（用户故事）”和“Story Mapping（故事地图）”不是一回事，因为“User Story”是Scrum的联合创始人Mike Cohn在2004年正式确立的，但如果再往前导的话，其实“Story”这个概念在1996年就有了。

但是，两者又不是完全不相干的，可以这么理解，正是因为有了“User Story（用户故事）”，才产生了“Story Mapping（故事地图）”，或者这么说，US是SM的基础和素材，SM是US的结果和结构。

要不我觉得这篇文章不好写，为什么呢，因为要谈SM，就不能不谈US，但是仅仅一个US就是要用一本书去说的，当然，SM也是一本书，而本篇的主题又是要放到优先级决策上的，我试着讲一下啊。

故事地图涉及到的两个基本概念

1、用户故事

用户故事是什么呢？没法详细介绍，内容太多，这里只做一个和本篇主题有关的总结，大家看下图：

关于用户故事更详细的介绍，大家可以参考这篇文章：《产品经理们，今天我们讲“故事”》

大家只需要记住一点就可以：

用户故事是从用户/客户角度（实际使用产品的人）叙述需求的一种形式。

2、用户/客户旅程

一样，这个也不详细介绍了，大家可以参考这篇文章：《业务流程&客户旅程分析表》

本篇中，重点展示一下这张图，大家看下图：

如果我们把这张分析表用最简单的形式来表示，那么，就是这样的，大家看下图：

有朋友会问了，“用户故事”的形式我知道了，“客户旅程”的结构也我了解了，但是这和“故事地图”有什么关系呢？

别急，咱们继续往下看。

故事地图是什么样子的

故事地图是什么样子的呢？大家看下图：

猛一看，这张图貌似和“客户旅程”类似，都是由不同颜色的区块绘制而成的，但仔细一看，还是不一样，构成元素上差别很大。

这就对喽，之所以前面先要简单说一下“用户故事”和“客户旅程”，就是因为“故事地图”涵盖了它俩的部分关键元素。

1、“故事地图”和“用户故事”的关系

是这样的，在Scrum中，用户故事通常是以前文提到的那种一句话的格式来描述的，但是，这有一个比较麻烦的问题，就是没有一种形式对众多的故事进行分类、组合，以及进行优先级的排序，总不能按照故事撰写的时间顺序来吧。

因此，故事地图对于用户故事的最直接作用就是对其进行分类，组合，优先级排序。

做个类比，这就好你手里有一堆乐高的零件，准备搭建个汽车，如果没有一个搭建指导的话，不是说你最终搭建不出来，而是可能会非常花费时间，而这又正好和Agile的原则相违背。

2、“故事地图”和“客户旅程”的关系

我们已经知道，用户故事是从客户角度对需求的一种描述，而不是我们的一种判断，言外之意，用户故事本质上是客户想如何使用产品的一种说明，无论这种说明是否符合我们构想的过程，我们更多的是讨论，而非替用户做出选择。

如果站在这个角度看，那么众多的“用户故事”其实就是“客户旅程”的一个阶段性的体现。

简单来说，“客户旅程”涵盖“发现→选择→购买→使用”这四个大的阶段中的活动和任务，而“故事地图”涵盖的只是“使用”这个阶段中所有的活动和任务。

这是一方面，另一方面，我们对比前面两张图，也可以发现，“故事地图”实际上就是从“客户旅程”（图中的第三行）的“活动”（图中的第一行）这个级别开始的。

总结一下，可以这样来理解，在“故事地图”中：

内容上用的是“用户故事”的素材，形式上用的是“客户旅程”的结构。

如何使用故事地图

怎么来使用“故事地图”进行优先级管理呢？

三个关键条件：

1、只要你会撰写“用户故事”；

2、只要你会绘制“客户旅程”；

3、你得熟悉一些其它优先级决策的技术。

前两个条件我都有文章可参考，当然，不算是太详细，但足够用了，如果大家愿意深入了解，我可以另文再讲。

主要是第三个条件，你不是说“故事地图”就是一种优先级决策技术吗，怎么又和其它的优先级技术拉扯上了呢？

这确实是一个比较费解的问题，后来我想明白了，和大家说一下。

假设我们已经绘制完了“故事地图”，大家看下图：

细心的朋友可能已经发现，这张图相对于上面那种图，好像少了点什么，没错，少了左侧的“版本”，为什么呢？

这就是“故事地图”优先级技术的关键所在，敲黑板，划重点了啊。

在绘制完上图后，我们只是对“用户故事”进行了分类和组合，但这并没有确定出“故事”的优先级，它只是对用户的使用过程进行的一种流程化构建。

基本构建层级是：

用户活动→用户任务→用户故事

当然，这只是从开发团队的角度来看的，如果从产品管理的角度看，其实它的层级是这样的：

愿景→目标→用户活动→用户任务→用户故事

因此，要确定每个“故事”的优先级，就必须使用其它的优先级技术来做，也就是说，要用“故事地图”的优先级决策技术，首先要用其它的优先级决策技术来确定“故事”的优先级。

那么，“故事地图”的优先级决策确定的是什么的优先级呢？

版本！

怎么确定的呢？

这就涉及到“故事地图”中的一个术语，slice，切片。

这个切片是怎么使用的呢，大家看下图：

通过其它的优先级管理技术（比方说本系列中的技术2：价值与努力决策矩阵，和技术3：莫斯科方法，就是比较常用的）确定出了每个“故事”的优先级，那么，这些优先级最高的“故事”就被分为一类，形成第一个你要做的版本，也就是优先级最高的版本，后续当然就是版本2，版本3了。

老汤注：如果是新产品的话，通常会作为MVP的开发依据。

需要注意的四个地方

1、目标用户一定要准确

这个不用多说，大家都明白，既然是让用户描述他们的期望，那么，一旦用户不确定或不清晰，那么，你绘制“故事地图”的整个工作一定是徒劳的，因为你绘制了一个错误用户的故事地图。

2、故事地图不仅仅是Agile的专属

尽管故事地图诞生于Agile开发中，但其实就是换个马甲，如果我们把“故事”理解成“需求”的话，那是不是可以称其为“需求地图”呢？

我觉得没啥问题，因此，非IT行业或者没有使用Agile的朋友别觉得这个技术和自己没关系，其实完全可以把它的底层思想应用到自己的行业和产品中。

3、故事地图其实是PO的专属优先级决策技术

按照Agile的规范要求，“故事”是由PO来写的，PM写什么呢？

Epic，史诗（可以简单理解为一堆有联系的故事的集合，就是故事地图中的第二行：用户任务），因此，事实上，这个技术原本就是PO的专属技术，因为PO隶属于Scrum开发团队，但是考虑到国内（也包括国外）大部分的PM其实也扮演者PO的角色，因此，这个技术也得掌握不是。

如果你很幸福的不扮演PO的角色，那么，前面的九种技术一定要好好掌握才行。

4、故事地图要常改常新

故事地图并不是一劳永逸的事，说实话，就现在这个市场的动态环境，客户的多变心态，你第一版故事地图做完可能就有点不赶趟了，因此，故事地图必须要常改常新，而常改常新的前提是你和客户之间必须有一个持续交流和学习的机制，也就是产品探索。

看看，又涉及到产品经理的另一个工作，现在谁还说产品管理的工作好做呢，看起来是一个孤立的工作，但很可能牵扯很多其它工作的。

故事地图常见应用场景

这个就不用多说了，最多的应用场景就是产品版本的优先级决策，至于能否应用到更细的层面，我个人觉得是可以的，但我没试过。

故事地图的优势和不足

优势：

1、它可以帮助你快速有效地确定你的MVP

前面提到过，Jeff Patton之所以提出“故事地图”的思想，其中就融合了精益创业的思想，而精益创业的思想又是ERIC.RIES在《Lean Startup》提出的，而在LS思想的核心之一就是MVP。

因此，对于那些初创企业或者新产品而言，“故事地图”可以很好的让你明确你的产品首秀应该是什么样子。

2、它以用户体验为中心

“故事地图”之所以一经推出，就大受欢迎，其中一个重要的原因就是它所要构建的产品完全是以用户的体验为核心的，而不是传统的基于我们分析的结果，因此，它在用户体验的设计和完善上有着最大的优势。

3、依靠协作，而非某个人的观点

在以前，需求优先级的确定可能产品经理一个人就搞定了，但是在“故事地图”中就走不通了，在这种技术中，需要涉及到的团队至少要包括三类：

领域专家、测试人员和UX设计师：熟悉用户和功能的人

利益相关者：对产品如何为公司赚钱有想法的人

开发人员：那些知道这需要多长时间才能完成的人

这三类人需要构成一个4-8个人的小组来一起完成这个技术的操作。

不足：

1、它不考虑外部的产品优先级因素，如业务价值和复杂性。

究其根本原因，还是因为客户不会考虑业务价值和复杂性，他们只想要他们想要的。

2、很难做长期的优先级管理

按照实践的经验，这个技术通常做的优先级管理周期不会超过6个月，一般只涉及3-6个月，原因在于市场的复杂性和动态的变化。

故事地图的底层逻辑

在产品管理中，我们经常头疼的一个问题就是“如何处理我们的判断和客户的真实想法”，与其陷入纠结，不如把这个判断的权利交给客户，让他们告诉我们他们想怎么来和我们的产品互动，因此，“故事地图”的底层逻辑就是：

客户在完成一次完整的“客户旅程”中所遇到的障碍，问题，困惑，集中度越大的优先级越高。