关于《用户故事地图》的一次分享

本书的作者Jeff Patton是一名独立顾问，曾作过敏捷过程教练，产品设计过程教练和导师。有15年软件产品体验设计和研发经验。本书介绍的用户故事地图是用来弥补敏捷开发的一些问题，目的是为了使得产品和开发及团队、用户能更好地沟通并达成共识。

1

用户故事地图是什么？有什么作用？

（图片过大请把手机横屏）

故事地图是一门在需求拆分过程中保持全景图的技术，故事地图将这些要素组织为结构化，以此来强化软件开发中最关键的部分 — 沟通。《用户故事地图》是可以帮助团队沟通、协作并最终交付好的产品。

2

敏捷开发会遇到的问题

1、沟通中的硬伤，做用户故事地图的目的是达成共识

A同样一份文档，阅读的人不同，各自得到的信息也不一样

文档只是用来备忘的，停止对写出完美文档的追求

人和交互 胜过 过程和工具

可以工作的软件 胜过 面面俱到的文档

B最佳的解决方案来自于需要解决问题的人和有能力解决这些问题的人彼此协作

鼓励敏捷开发中人与人之间的沟通

C使用用户故事地图是为了对需要解决的问题达成一致理解，并找到解决问题的最佳方案

3

怎么讲故事？

1、故事是讲出来的 ，不是写出来的。

A故事是讲用户的故事：设想一下未来，产品上线后，用户在一天中是怎么使用的。

B使用用户故事的目的并不是为了写出更好的用户故事，使用用户故事的目的是为了达成共识

使用用户故事的目的并不是为了写出更好的用户故事

产品开发的目的也并不是开发出产品

4

邀请大家动手创建一个用户故事地图

1、试着创建一个用户故事地图，构建一个大家都认可的叙事流

即：组织情节——补充细节——探索替代故事——提取故事主干——切分出能帮助达成特定目标的任务——指出设计方案中的问题和改进点，并对需要的时间进行估计——指出产品意识不到的技术上的依赖

重要流程分成四个步骤：产品定义——梳理骨干故事——拆分故事——沟通确认。

邀请项目组成员共创，参与人员包括：技术开发、产品经理、设计师、用户、测试。

2、开始分步骤写出你的故事

A今天早上起床的过程（最后大家决定选择这个主题）

B用户去故宫的过程

C用户使用APP2.0的过程

D用户使用一年后APP的过程

E内容管理系统故事让每个团队都可以看清楚自己在全景图的哪个部分

为了方便大家理解，选择了一个大家生活都会发生的例子。

故事的整个范围：起点是起床——终点是到达公司。闭上眼睛，回想一下今天早上起床的过程。把这段故事分成这样几个阶段，起床——洗漱——穿衣——出门——上班途中——到达公司。

3、组织流程

第一步：产品定义

主要有几点内容：

1.产品的目标用户。

2.解决了哪些问题。

3.用户目标。

4.产品目标。

应该先初步定义为：女性APP 解决早晨醒来后到出发去公司的问题

将这些内容记录在黑板上，与大家讨论达成共识，最终确定产品定义。简单来说，需要明确“我们为什么要做这个？”以及“用户为什么要用这个？”明确业务诉求和用户诉求为之后的设计提供了指导，不仅可以在接下来在讨论的过程中不易迷失方向，还可以避免陷入设计细节纠结。

（当时没有意识到这步骤的关键性。）

第二步：发散思维＋梳理骨干故事

产品小马初步讲述了一个大众化的起床故事

接着大家发散思维，写了更多故事的细节。比如起床就可以再拆分为：闹铃响了——挣扎——关闹钟——下床。

这样我们骨干故事就有两层，一级故事和二级故事，故事的发生从左至右是一个叙事流。

第三步：拆分故事

在这一步，我们需要在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。如果二级故事是一个海平面的话，那二级故事以上就是海平面故事，那现在我们需要关注的是海平面以下更多不可见的故事。项目组会围绕这个故事写出很多细节来。我们可以按照以下几个维度对细节进行归类，分别是：故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得，也可以通过用户想法、用户的痛点结合主观判断。

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

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

1.用户在这步具体做什么？

2.用户还有其他选择么？

3.用户怎么做才能更爽？

4.出现问题如何处理？

5.其他用户来到这里该如何处理？

回到我们的例子，我们洗澡的时候有正常的流程，但当没有热水时这个流程就会发生变化。同样，在真实业务当中，这类情况将更普遍的发生，所以这个步我们将尽量多的关注到所有场景的故事。

做完这步，我们已经获取到了足够多的细节信息，整个项目组都会做到对产品又见森林又见树木的状态。

第四步：沟通确认

这里我们的故事已经变得很丰满，甚至变得臃肿，所以沟通确认变得极为重要。我们在这步需要花费相对多的时间，大家对内容进行对标、充足讨论，把公认的留下来，无用的踢出掉。同时可以区分要做的故事细节的优先级。

5

价值

A共识

用户故事地图过程中做到多角色、多视角，尤其是中后台产品不只是单纯的估计用户需求。项目里不同的参与者有不同的需求，PM想跟踪进度，开发人员想实现，产品经理想功能，产品老大有更高的视角，而用户想要一个可用的系统，在这些充满冲突的视角中，想要做出一个人人都支持、皆大欢喜的决定，并且持续保持平衡是很困难的事情。整个项目组就像一个四驱车，一个角色的强势就相当于一个轮子转的过快，这对产品都是损失，导致车子的方向偏移。我们通过大家一起建立产品全景图的方式，让项目组所有人包括用户站在八百里高空俯视产品，这种同一空间多点对多点的共识就自然的完成了，这种共识应该是空前的。

B同理心

所有人都可以快速知道用户想要什么，为什么要这个。通过这种简洁明了、场景还原的方式让大家都更容易理解，每个故事我们都做到站在用户的频道，说人话。

6

总结

1、关于产品

A在讲故事的过程中，产品和开发就自己的产品创意细节达成如此这般的理解。

B也许产品和COO的宏图中有很多坑，用故事地图的形式提前发现这些坑。

C想做的功能，总远远超出你来得及做的。不再用必须做，应该做，可能做去区分。只区分做和不做。

满足所有人的需求太困难，请聚焦

聚焦于成果，即产品发布后用户能使用和感知的东西,聚焦于特定的目标成果，来排定开发工作的优先级、

D对需求的理解更深刻，寻求更小的可用发布集

MVP（最小可行方案）并不是发布粗糙拙劣的产品，而是指可以产生预期成果的最小成品发布。

E产品经理最大的挑战之一就是，如何像对待自己的创意一样接纳并实现别人的想法，并使之产生成果或证明这些想法不靠谱。

F验证问题

2、好的团队，差的团队

3、好的产品

用户可以用不同于以前的方式做事情，因此而感到开心，产品给用户解决问题的方式带来了变化，最重要的是使得这个世界变得更好了。

关于人

你的工作不是开发更多而是开发更少的功能，你的工作不是收集需求而是改变世界。

用户购买的不是你的产品，而是更好的自己。

你的产品是用户通往更好自己的解决方案。

所以，用户不会为功能买单。人们购买的是解决方案。

你的工作不是更快的开发更多的功能，而是使那些投入精力开发的功能在成果和影响上可以最大化。

4、估算的秘密

最靠谱的估算，来自于真正理解自己在估算什么的工程师

成员对开发什么东西以及设计方案缺乏一致理解的情况，没有任何作用，

达成一致理解才是成功估算的最大秘密、

5、迭代与增量

御用迭代思维持续评估和打磨作品

运用增量思维做加法

在这个过程中不断学习修正最初的设想

上周六给大家做了用户故事地图分享很开心，因为伙伴们的积极参与，我当时讲的不多，一方面想把更多的时间留给大家动手，一方面想自己探索出适合的模式，毕竟用户故事地图一定不是一个固定的样子。哈哈哈其实是我好多流程还没搞清楚，感谢遇到你们一堆真诚羞涩的伙伴，小马、大禹、季白、马奈、曹操、贺仔、百里、武松···真的特别好玩。