让沟通变得友好的用户故事地图如何创建

　　用户故事地图以直观易变的方式进行项目的良好沟通，大多数人看重的是地图的形式部分，横向是讲述大故事的部分，纵向是逐步的细化，但是最关键的是产品的构思框架，让团队成员对想要做出的产品一目了然，大大提高了团队之间相互协作的默契度。
　　一、用户故事地图是什么？
　　1、瀑布模型
　　图（1）
　　在进入正题前，让我先来讲讲敏捷开发的诞生。在很早以前的软件开发中，并没有系统的流程管理方式，所以造成大量的人员、时间以及金钱的浪费。于是，在1970年，一个叫做温斯顿罗伊斯的人提出了针对于软件开发的一种架构，叫做瀑布模型，他把大型软件开发分为：分析与编程，像工厂流水线一样把软件开发过程分成各种工序，流程如上图（1），之后，瀑布模型便沿用下去。但是随着时代的进步，人们的需求越来越多，软件迭代越来越快，瀑布模型的缺点暴露的也越来越明显：因为这种一去不复返的流程中没有迭代与反馈，应变能力差，所以对客户需求非常不容易适应，只要有一处修改，就意味着前面的工作都白做了。所以瀑布模型逐渐被淘汰，一种叫敏捷开发的管理新模式应运而生。
　　2、敏捷开发的优势
　　图（2）
　　敏捷开发避免了传统瀑布方式的弊端，主要是吸收了各种新型开发模式的动态特性，敏捷开发把关注点从文档转移到了开发者，管理方式也从工厂的流水线到团队的自我放松式的组织。在这种模式下，客户的需求可以随着进程的推进和实际情况而改变，团队输出的产品也是最小可行产品（MVP），即可以产生预期成果的最小发布方案。这样，就大大降低了成本，提高了灵活性，减小了风险，修改起产品也不需要全盘重做。所以，敏捷开发模式一直沿用至今。
　　3、用户故事地图的诞生
　　在以前，人们确定项目时总要写厚厚的几大本说明，好让开发人员对要做的东西有统一认识，但很快，这种充满条条框框的说明就被淘汰掉了，取而代之的是敏捷开发模式中的用户故事。当然，这并不代表人们不用再写那些恼人的文档，用户故事的创建依然要有文档作为依据，只不过文档的篇幅和格式已经大大优化。通过用户故事这一步骤，避免了团队成员的主观影响，可以客观的搜集整理大量用户需求，形成一个个用户问题、客户问题、公司问题的解决方案。
　　但是问题又来了，因为对于大型产品的开发，用户需求的内容会很多，像是一个庞大的地图，而用户故事擅长聚焦于构建小的特性，专注于小的细节就没法掌握整体，所以会带给人们困惑，不知何时才能完成开发和发布。不同的用户故事块也容易出现互不相匹配的产品部分，所以，为了避免这种管中窥豹的错误出现，人们改进了用户故事的处理方法，这种新的方法就是用户故事地图。下面，就来介绍如何创建用户故事地图。
　　二、如何创建用户故事地图？
　　1、前期准备
　　召集35名产品核心人员，可以包括产品负责人、项目经理、业务分析师、架构师，因为这些人代表了项目中的主要角色的看法，所以创建出故事地图后，在以后的全体计划会上就可以避免出现许多不必要的辩论。准备一面空出的白板，或一面墙壁，若干颜色和数量的便利贴，一卷彩色胶带。
　　2、整理创意框架
　　在正式开始创建用户故事之前，大家要在一起重新明确产品的创意框架，如：
　　明确产品的目标是什么？
　　能为用户解决哪些问题？
　　公司、用户都能获得哪些收益？
　　然后大家统一答案，把明确的目标写在便利贴上，按照优先级排好顺序。
　　3、刻画用户画像
　　下面针对优先级最高的目标开始讨论，开始头脑风暴：
　　产品面向的主要用户群是那些？
　　产品的潜在用户群有哪些？
　　谁会为我们的产品付钱？
　　基于这些问题，罗列不同类型的用户，讨论他们能从中得到什么好处，使用的动机，需要的功能等。精炼出若干类用户，制成用户画像卡片，卡片上的内容不用很详细，可以描述出基本特征即可，给每个类型的人群起一个人的名字，张三李四随意，目的是方便日后讨论，以后这个名字就代表这一类人群，再对每个用户做一下简单的诉求描述。最后，把这些写着用户类型的卡片，按照优先级排好，重要的用户放在上面，贴在白板上。
　　为了讲解的更加清晰，我把之前参与过的一个项目当做例子，演示用户故事地图的产生过程：这是一款大学生的微电影服务平台，我们的初衷是想要大学生影视团队和有拍微电影意愿的人在平台上对接起来，由于摄影团队所驾驭的影片难度低，需要的资金少，所以我们的目标很可能包括这些：学生拍毕业季微电影学校社团宣传婚礼开场微电影烘托气氛等等（下面我所绘制的用户故事地图只是想让大家看起来更直观，如果有不严谨之处还望大家见谅）。
　　4、大故事
　　从最重要的用户类型下手，这里依然使用头脑风暴，可以按照时间顺序挖掘，描述这个人在一天中使用产品的情景，首先他会怎样，然后怎样，然后这些故事可以比较概括，如用户注册或修改日程，团队中安排专门的人负责记录把每一件事都写到一张便利贴中，按照时间顺序从左到右排好便利贴。当有遗漏的故事被挖掘出来时，可以随时调整卡片顺序。在这个过程中，做到了团队成员对所要做的东西达成了一致，产品创意精彩的细节部分被所有人所消化。
　　下图以其中的一个用户类型为例，写出大故事：
　　5、深挖细节
　　在完成第五步的大故事后，用户故事地图的框架已经结束，下面要做的是深挖细节。白板上的卡片已经出现了第一列，这些都是大故事，我们要在每一个大故事上深挖，写出包括的细节：
　　用户在这一步具体要做什么事情？
　　用户在这一步还有其他选择么？
　　如何做才能更符合用户的习惯？
　　出现问题时如何解决？
　　在完成以上等等问题后，记录员要把每一个小细节都写在便利贴上，竖向排列在大故事卡片的下面，如果有与大故事无关的其他细节，可以放在用户卡片的上方区域。到此为止，一个巨大的恐龙骨骼一样的用户故事地图出现在白板上，甚至，它可以占满一面墙。
　　6、划分MVP发布计划
　　在第五步我们所创建的用户故事地图涵盖了多个用户故事和叙事主线，包含了项目人员所有的愿景，但是它太庞大了，如果同时研发这些功能点，可能几年时间都做不完，敏捷开发也不允许我们这么做。所以，为了缩短项目周期，我们要在用户故事地图上进行MVP的内容筛选，把最重要的内容放在前面。横向移动用户目标，纵向移动深挖出的细节，然后用胶带做出分隔，如下面这个例子，在第一个版本中，我只开发标号为1的部分，随着软件的不断迭代，用户故事地图也不断向下推移。此时已经完成了这个产品的发布路线图。
　　三、说在最后
　　用户故事地图以直观易变的方式进行项目的良好沟通，大多数人看重的是地图的形式部分，横向是讲述大故事的部分，纵向是逐步的细化，但是最关键的是产品的构思框架，让团队成员对想要做出的产品一目了然，大大提高了团队之间相互协作的默契度，但是要注意的一点就是，功能的开拓要适度，否则这幅用户地图永远都画不完。正如《用户故事地图》的作者JeffPatton所说：如果不需要讨论，就不必绘制用户故事地图。