一篇带你读懂用户故事地图

之前在敏捷产品管理系列中，我讲了产品 Backlog 作为敏捷团队管理开发过程的核心，所有的活动和交付物是如何围绕它展开的。我也给你讲了组成产品 Backlog 之一的用户故事又是如何经过建模、搜集、编写、估算这些过程之后，发挥出它的洪荒之力，让全员快速挖掘需求，理解需求的。

很多看完我文章的小伙伴告诉我已经在敏捷开发这些事件中体会到了可视化和全员深入加入这些好处，但是随之而来的问题也出现了，有小伙伴问我当需求拆分出来的用户故事越全面详细，不可避免的容易丢失产品全景图，有时候大家过度陷入到细节而丢失了用户诉求的本质，严重甚至生产出用户不需要的产品。
所以今天我就来带你通过了解故事地图，来解决你在需求拆分过程中如何保持全景图的问题。

故事地图的目的

首先，我想请大家记住，使用用户故事的目的并不是为了写出更好的用户故事，就像产品开发的目的也并不是开发出产品。停止你对故事模版的追求，就像停止你对完美文档的追求一样。
用户故事地图是一种建立共识的机制，之所以叫“用户故事”，因为故事是要讲的，就像文档只是为了备忘一样。
好的用户故事地图讨论的永远是为谁做和为什么做，而不仅仅是做什么。

谁来描绘故事地图

很多敏捷团队要求 PO 来写所有的故事和开展所有故事对话，不管是因为 PO 的精力有限，还是团队的参与共同输出来说，这显然是行不通的。
但是这并不是要求敏捷团队中所有人都有平等的发言权，这是一种“委员会模式”，最终剩下的只有无限制的讨论和错误的结论。
我们要的是做“社区设计”，不要“委员会设计“。即 PO 会借力作出好的决策，他会组建一个核心团队来协助自己绘制用户故事地图，核心团队人数不要超过4人，包括用户体验专家、设计专家和技术专家这些角色。
了解了谁来构建故事地图，下面就来开始带你从开始一步步建立属于团队的地图故事地图。

如何创建

一. 从机会开始

当 PO 发现了市场机会，就要尽快形成机会待办事项，尽可能与核心团队成员就每个机会展开对话。每个机会都要问我们自己几个问题：
对象是谁
我们要解决什么问题
我们的构思是什么
为什么要这么做
视觉上估算机会大小
在这个阶段你们团队已经丢弃了一些经不起推敲的机会，那让我们继续进行下一步。

二. 深挖机会

通过思考的机会进一步来到挖掘阶段，这里依然不是开发产品的开始，依然是一个丢弃或者前进的筛选过程。
这里可以运用“机会画布”这个工具来驱动。从左到右是现在到未来；从上到下是用户诉求到商业诉求。

机会画布的内容包括以下几点：

问题和想法：
为用户解决问题的产品、功能或优化想法。以及如何为用户或客户解决当下哪些问题？

用户或客户：
方案针对谁而设计。探索用户目标和用户行为在使用产品过程中的差异，并根据这些差异将用户和客户分为不同的类型。不要把所有人都列为产品的目标用户，不解释为什么。

现有的解决方案：
竞品，或用户为满足需求而采取的变通方式；

用户价值：
用户使用新方案获得的收益；

用户度量：
能反应用户接受新方案的行为；

接受策略：
客户与用户如何发现和接受你的方案；

业务问题：
新方案中，需要解决的业务问题；

业务度量：
新方案会影响哪些业务绩效指标；

预算：
探索、开发和改进你提议的方案，需要哪些预算和开发成本。

针对以上九点，与团队逐一讨论。若某项没有结果，则可以先写下假设。通过这一方法，可以更全面的了解机会，且找到各项之间的关系，但最终结果依然是由 PO 决定。

机会画布可以让团队一眼看出机会中所有重要的关注点，以及相互之间的关系，协作让团队来达成共识。
经过一系列的分析，核心团队已经知道哪些机会是可以丢弃的，哪些是可以继续推进的。

三. 探索

通过机会的判断和深挖，我们已经知道什么是我们要做的，但是不要着急，我们要继续往下探索，不断的学习和了解我们需要做的功能。力求在找到最小的可行的方案，这就是探索的过程。探索的四个核心步骤：

从业务角度来组织想法
使用结构化的讨论来为当下的工作设置边界，知道怎样更好的终止讨论对解决问题无用或者对用户没有帮助的主题
理解客户和用户，搞清楚怎样做才能帮到他们
勾勒轻量级的人物画像，这其实就是“设计思维”里面第一步的“共情”。理解了你的用户和他们的需求，并且你已经在确定问题阶段分析和综合了你的观察结果，并以人为中心陈述了问题。
把自己的解决方案呈现出来
使用地图来呈现你的方案，最好是文字和图形的结合，这是“设计思维”的第二步：聚焦，第三步：形成想法。
简化并计划
找到最小化的可行方案以及具体的开发方式，这也是 “设计思维”的第四步：做原型测试。

由于设计思维本质就是一个比较复杂的方法论，之后我会单独介绍。

四. 创建

经过了机会、深挖、探索之后，我们已经最终确定了我们要做什么，现在可以创建我们的用户故事地图了。
用户故事地图有两个原则：从左到右讲故事（主干），从上到下拆故事（细节）

主干故事
覆盖整个发布计划，涵盖多个用户和系统的叙事总线。
主干故事卡片是用户任务，即使用软件达到他们的目的。是构建故事地图的基本模块。这里的主干卡片被称之为海平面级别的任务（汇总小任务，分解大任务），卡片尽量用动词短语组成，这样能使整个故事具有流动性。
故事的背景可以摆在地图周围，比如，产品目标、客户信息、用户信息。
注意在这个阶段，我们要聚焦整体故事，不要过早的讨论细节，这要求我们思路宽广，细节有度。
细节故事
接下来通过深潜故事工作坊来讨论细节，拆分故事，要记得细节可以不断变化，但是注意，主干要保持稳定。
为了保证整个故事卡片的完整性，可以问自己以下几个问题：
用户在这一步具体要做什么事情
这一步还有别的选择么
如何做才能让用户觉得更炫酷
出现问题如何处理
你可以试着在故事里面可以加入风险故事，让团队了解工作和复杂程度。我还见过有些团队在功能燃尽图旁边，增加了风险燃尽图。

如何有效的拆分编写故事卡片，可以查看我之前的文章：

接下来就是把这些拆分故事有效的形成发布计划。
我的建议是可以从上到下分成三个部分：第一是跑通整个流程的故事，这是基础核心的，也有人叫它”开局“；第二是下一步对产品的完善，这时候要注意完善核心功能的用户体验，即”中局“；第三是进一步的打磨产品，让产品尽可能的接近完美，这是”终局“。
在每一部分之后可以列出迭代发布名称列表，即以主题为单位的目标输出的，这样可以对故事卡片进行有效分类归类。

如何制定发布计划和迭代计划，可以查看我之前的文章：
敏捷产品管理之发布、迭代计划
检验输出
有了用户故事地图，这只是一个开始，我们要时刻学习和改善。你要知道第一次就把事情做对其实是一个冒险。
最佳时间每次迭代之后的回顾会议，从以下几个方面去检验输出。
1.产品
讨论用户体验的质量、讨论功能上的质量、讨论代码的质量。
2.计划
确定哪个故事已完成，哪个没完成；团队速率；统计已经开始和没有完成的故事；讨论研发工作预算的时间量。
3.过程
最近开发周期的改变；讨论希望下一个周期中做的改变。
我希望你们的卡片也是一个学习过程。对于每一个故事，看板待办列表都有三个与之呼应的任务卡片。你要问我写什么？我就告诉你：第一张是用户故事，第二个是修正第一张，第三个是修正第二张。
我的目的很简单，通过一次次的反馈改善你的下一步要做的任务，保持全景一致。

小结

最后的最后，我来总结几点请你记住。

故事地图是一门在需求拆分过程中保持全景图的技术。
没有讨论输出的故事地图是无效的。
如果没有解决团队的问题，永远记住不是工具的无效，而是你没有用对工具。