用户故事地图

用户故事是描述用户需求分析的一个好方法，可以将backlog变成一个二维地图，从而容易看到整个规划的全貌，帮助开发人员快速的了解客户的需求，并确定产品模块的实现优先级，实现最大用户价值，学会讲一个好的用户故事是很有用的。

一个基本的用户故事包括三个要素：角色、活动、商业价值，其固定的描述格式：作为什么角色，要进行什么活动，才能实现什么商业价值。这个固定语句格式，只是了解用户故事的第一步，用于描述一些简单的用户故事。但实际中的用户故事是很复杂的，简单的套用固定语句格式，只能带给我们一堆零散的故事点。从公司角度来讲，一个好的故事，应该是具有很好的商业价值体现，尤其是以客户为中心的情况下，是具有很强的说服力的。而且，在项目协作的过程中，一个好的故事是很容易促成大家的共识，一致协作，制作出更好的计划，便于减少工作开发量，更快的学习和按时发布。

之前在进行工作分析、计划制定的时候，总是怀着一步到位的想法，给一个最终的完美的解决方案，试图快速开工、一气完成，但结果却得不到好的反馈。想了很多，是没有站在用户角度，不清楚用户的诉求，无法针对相应的故事，给出针对性的、阶段性的计划，方便我们进行任务的评估，具体的落地实现，而且，向别人解释的时候，也难有理有据的去说服别人。

另一方面，在描述用户故事的时候，尽量不要过多涉及到技术细节，因为设计人员更关注的是用户使用、功能实现，企图给用户呈现一个完整的功能图。之前在进行系统设计的时候，犯的一个比较严重的错误，在未讲清故事的情况下，直接给了一个大而全的设计图，讲了一个“史诗级”的故事。庞大的故事，能给我们一个初步的认知，但未遵从敏捷开发的原理，给出了一个瀑布式工作量评估，乍一看，貌似给出了一个很好的设计思路以及工作量评估，但其实隐藏了很多隐患：

1、用户故事不明确：一个好的设计应该是源自一个好的用户故事，但是我在还没有讲清用户故事的前提下，就给出一个庞大的系统设计，一般而言，这样的一个设计看起来很好看，但是却很难说服别人；

2、用户故事粒度不够小：故事应该是从大到小去分解的，按照每一个小的粒度故事去实现，才是正确的方法；

3、未遵从敏捷开发的准则：给出一个大而全的设计，企图以瀑布式的开发完成我们的脚本开发，这在当前的一个开发准则下是极为不合适的，一旦发现目标不合适，或是出现偏差，那么瀑布式的开发将带来更为大的人力物力损失，而敏捷迭代这种循序渐进的方式就可以；

4、未给出一个最小的解决方案：设想的东西，永远比实际开发的东西要多，因此，我们需要从最小型、可行走的解决方案入手。

庞大的史诗级故事很容易造成预算的超出、延期等措手不及的事故，不容易兼容细小软

件需求变化。

后来偶然发现一本Jeff Patton《用户故事地图》，里面有非常好的讲故事、描述问题的方式，是团队进行设计、规划、沟通交流非常好的方法，也觉察到方法论的重要性。但是书中的的一些观点可能不是很清晰，但是确实受益匪浅，也建议大家去看一下。这里给出理解的故事地图绘制方法，方便大家快速理解入门。

用户故事地图的本质是为了更好的沟通，不是为了写用户故事而写用户故事，要抱着一颗改变世界的心，这是制定一个完善的计划的前提。用户故事借鉴了敏捷开发的原则，需要多人共同交流完成，碰撞思想的火花。作为用户故事的书写者，其充当了一部分产品经理的角色，但要明白，产品设计，绝不能是独自坐在一起，而是要和工程师、用户等深入交流后，进行深入的分析设计。

那么如何完成一个好的用户故事地图呢？可以使用卡片的驱动方式进行。这里方式有很多种，不过采用纸质卡片有一定的优点：随时写随时贴；随时撤销、修改；随时更改顺序；大家很方便一览全局，可长时间反复思考观看。重要的一点，其他人可很快融入，并通过卡片补充提出建设性的想法。

绘制一个好的用户故事地图，可以按照下述方式进行：

1、团队内达成初步共识：

为什么要在部门内部达成一致的共识呢？达成共识后，不仅仅是为了认清我们的目标，并且这也是我们去沟通、交流、促进团队协作的资本，否则有时候连我们自己都无法说服。

达成一致的、初步的共识，可以从下面三个方面讨论：

a、正在解决什么问题？明确当前的痛点。

b、为谁解决？明确用户的类型、群体。

c、公司/用户等如何从开发的产品中受益？明确公司/产品在解决这些痛点之后的收益。

回答完这几个问题，基本就能明确我们想要达成目标。

2、给用户画像:

寻找故事相关者，这里的故事相关者，可以是用户、设计者、开发者等。每个用户的使用方式、行为、场景都不一样，产品的开发，需要尽可能的了解客户的需求，这样做出的产品一个产品。对于提出的每一个用户需求，使用卡片记录下来，用户信息需求包括如下：

a、客户类型

b、使用动机，得到的好处

c、客户使用的方式、频率等

通过跟用户、开发人员等进行深入交流，列出各类用户的需求并以卡片的形式记录下来。可以使用who、what、why进行询问，确保能沟通到用户的真实诉求。如果有特别强烈的需求，那么就特殊标记出来，确保我们后续的讨论中，不偏离我们用户的初衷。这里也可以采用QCC的方式，深入探讨用户的需求、痛点，任何小的方式都可以先写下来，确保不遗漏任何用户的需求。

3、完成基本的故事框架：

故事框架设计，可以遵循如下原则：

A、需要一个引导者，能完整的描述产品的目标、用户的场景等，并引导与会者进行故事的探讨，否则可能会陷入秩序混乱，或者一言不发地情况；

B、故事探讨的人数不要太多，3-5人就可以。过少的人提出的意见不足，而过多的人参与讨论，不仅造成人力时间浪费，而且可能会导致各执一词，造成长时间的无意义的讨论。

C、先完成故事主脉络。这里就要参考第二步的用户画像，只有明确用户的需求，才能知道我们需要完成的故事是什么样子的，应该遵循从大到小的故事描述。

基本上，完成故事的脉络之后，我们就可以初步窥见故事的全景图，这对我们把控全局有很好的把握，至少不会偏离故事的主次。

用户故事的地图框架如下：

4、拆分故事：

故事的主脉络有利于我们窥见全局，但是不具备落地实施的指导性，因此需要需要将故事拆分至可独立执行、可测试的粒度。在拆分每个故事的时候，可发挥与会者的主观能动性，将每一个想法都写到独立的标签上，记录下来，并评价拆分故事的可行性：如达成这个小故事，用户可以完成什么功能。完成后，对小的用户故事进行分类，确保其归类到正确的故事主脉络里面，而对话讨论是拆分故事的最好方式。每一个小故事应遵循：

A、工作量保持在单人花费3天以内；

B、每个小故事都是一个独立的模块，可以执行、可以测试、有确定责任人的。

故事的主脉络是讨论的入口，而小故事则具有具体落地指导意义。

5、排定故事优先级，选取最小可行性方案

在拆分完故事之后，可能会陷入一个小故事的卡片海洋之中，而现在我们的目标就是寻找一个最小的可行性方案。因为客户的需求，永远是无穷无尽的，如果从一开始就企图满足用户所有的需求，那么就会陷入一个无尽的恶性循环里面，要么是不知如何开始，要么只是完成一堆毫无用处的功能组合产品而已。而且，庞大而复杂的功能设计开发不仅浪费巨大的财力人力，而且得不到预期的效果。因此，产品实现的目标，从来都不是满足所有人的需求或功能，而是开发尽可能少的功能。如果能以20%的功能，满足80%人的需求，那么这个产品就成功了一大步。

这个时候就需要进行优先级的排序，从上到下，依次确定卡片的执行优先级，并按照敏捷的方式给出最小可行性方案，并交由用户进行验证，因为，想要开发的功能，总是超出你要投入的资源。

这个时候就显现出卡片的优势了，可以很快的进行上下、左右移动。而优先级的排序准则有很多，通过共同探讨，并遵从用户收益最大，以及工程复杂度最小的方式。移动完成后，就可以从上到下，按优先级确定大致的迭代的方式，最终完成的地图会是这样：

说明一下：这个故事地图中的主脉络有两层：最上一行有4个卡片，是最大的故事脉络，第二层蓝色的卡片是根据需要进一步拆分的故事主脉络，这两行的故事主脉络划分，很容易向其他人介绍我们的全景图。而第一个蓝色的卡片“Search Email”，又可以拆分成下面的5个小故事，这些小的故事的都是很容易落地实现的。对于不同的内容，可以使用不同的颜色的卡片进行实现。

这个故事地图，其实也响应了敏捷的宣言：可以工作的软件胜过面面俱到的文档。通过Realease迭代发布的形式，逐步执行故事。

6、度量、反馈、修正故事

在开发过程中，故事的实现方式、意图肯定会存在一定的偏差，需要不断纠错改正，这也是敏捷的理念之一。因此，故事地图完成之后，可以一直保留下来，在实现一个阶段之后，回过头来，根据用户的反馈，增加风险故事，并修改完善用户地图。

综述：

最终，一个好的用于沟通的用户故事地图实现方式，可以是如下这种流程：