如何快速输出产品的用户故事地图

01 结构与作用

故事地图产生背景

• 用户故事地图就是将story用可视化的方式展现在团队面前，让团队可以仔细梳理、讨论，确认这个story包含的内容，最终产出需求进行开发。
• 用户故事地图是Userstory的前传！

故事地图特点

• 不是另外一种写需求的方式
• 故事是用来讲的，不是用来写的
• 侧重事件发展过程的描述
• 故事不是忽悠，不是夸大

故事的听众

用户故事地图结构

• 地图的核心是一条从左到右的时间线
• 通过时间线和卡片进行约束
  • 时间线上第一行放置最大粒度的需求，即Epic
  • 时间线上第二行放置二级粒度需求，即Theme
  • 时间线下自上而下放置三级粒度需求，即Userstory

Release和时间线平行，确保在放入Release的过程中考虑故事的完整性。

故事地图作用

• 了解整个产品的全貌。
• 找到整个产品的主干，也就是路径。
• 促使产生更多用户故事。

可解决的问题

• 防止只见树木不见林，更容易看清backlog全貌
• 确保backlog覆盖了最重要的用户体验路径，及当前所规划的场景是否可以为用户提供价值
• 确定发布计划以及发布目标，同时确保早期的发布可以验证整体架构和解决方案

需求金字塔

 

• 金字塔的顶端是需求的目标，也就是解决什么用户或业务问题？
• 金字塔的中间层次是操作和操作流程，为了实现上面目标，系统需要支持哪些用户操作？这些操作的流程是什么样的？
• 金字塔的底层是业务规则，各个操作步骤对应的业务规则是什么样的？

• MECE原则是麦肯锡方法的核心，在各个层次上都要做到：
• 1）条目之间相互独立（Mutually Exclusive），通俗的讲就是要“分清”各个条目，做到无重叠；
• 2）这些条目作为一个整体要完全穷举（ Collectively Exhaustive），也就是要“分净”，做到无遗漏。
• 这两点合起来就是ME-CE。

02故事地图步骤

步骤一：产品定义

• PO召集3-5人参与故事地图讨论会，讨论以下议题：
  • 目标用户，用户目标----用户诉求
    • 用户为什么要用这个?能为用户带来什么价值？
  • 产品目标，解决什么问题----业务诉求
    • 我们为什么要做这个?能为我们带来什么价值？
• 明确方向，防止迷失方向，陷入设计细节的纠结。

步骤二：骨干故事

• 每个人写下自己认为重要的“所要做的事情”User tasks（二级需求）。
• 完成后，每个人轮流读出自己的内容，并把便签纸放在桌面上。
  • 尽量把故事讲完整，便于对整个产品有全局的印象。
  • 做到对产品只见森林不见树木的状态。讲完整的故事，一定要广度优先，而非深度，不要过早沉浸到细节中。
• 然后，将桌面上所有的便签按类似的任务分为一组。
• 选择另外一个颜色的便签，对每个组命名，作为User Activities（一级需求）
• 最后，对这些摆放好组的便签进行排序，一般按照用户完成操作的顺序，从左到右摆放
  • 如果大家无法决定顺序，那么顺序可能没有那么重要。

步骤三：拆分故事

• 从业务角度，拆分故事，建议分析维度：故事细节、想法、痛点、机会……
• 使用静默头脑风暴方式，把自己的想法写在一张卡片上，相互不干扰，然后每个人大声说出自己的卡片内容，让所有人了解并贴在墙上。
• 这时不必使用用户故事的标准句法（As a …），因为每张便签都处于地图的特定位置，大家很容易识别其所处的场景和角色。

 

• 大家在写想法的时候，可以通过一些问题来刺激大家脑暴出更多的内容，比如：
  • 用户在这步具体做什么?
  • 用户还有其他选择么?
  • 出现问题如何处理?
  • 其他用户来到这里该如何处理?
  • 使用之后有什么变化？
  • 别的产品怎么做？

步骤四：精简故事

• 这时我们的故事已经变得很臃肿。接下来要对卡片内容讨论，把公认的留下，无用的剔除，同时区分优先级。
  • 首先，要对大家写的所有卡片进行对标，排除无效故事。
  • 其次，不可能一口吃成胖子，对选定的故事排出优先级。
  • 最后，无法梳理清楚的故事卡片，可以先写个占位符。
• 最终，根据排列好的故事优先级，排出迭代计划，并确保我们的第一个发布越小越好，大约在1-2个迭代后可以发布第一个MVP版本。

03故事地图价值

共识

• 以往我们达成共识的方式有两种：
  • 点对点，或者单点对多点，带来信息内容的损耗，甚至错误的信息。

项目中不同的参与者有不同的关注点，整个项目组就像一个四驱车，一个角色太强势，会导致车子失控。

• 故事地图通过大家一起建立产品全景图的方式，让项目组所有人站在高空俯视产品，达成多点对多点的共识。

同理心

• 站在用户的频道，说人话！
  • 我们在讨论产品需求时，有一个很大问题就是无同理心，面对业务里很多专有名词会很无力，甚至同一项目组不同模块的人都相互不理解对方的专有名词，但又总认为他应该懂。
• 促进理解，建立共识。
  • 通过故事地图，我们所有人都可以快速知道用户想要什么，为什么要这个。通过这种简洁明了、场景还原的方式让大家更容易理解

参与性设计

• 经验性设计
  • 经验性设计高度依赖前期的用户调研，包括用户访谈和用户观察，但是用户不会成为产品设计的真正参与者，后面的阶段基本是靠设计师经验，几乎没有用户身影。

  • 

• 参与性设计
  • 用户故事地图易读、易懂，我们边聊故事的同时进行页面框架绘制，因此能激发项目成员的积极性，甚至让客户成为产品设计的参与者。
  • 随着项目成员渐渐掌握如何口头表达故事来描绘他们的需求，项目组成员间的关系变得更加亲密主动，达成良性互动。

记录

• 常见记录方式：文档记录（包括评审记录）、笔记记录或者聊天记录。这些方式大多是单点对单点或多点的，而且记录内容有限。
• 故事地图的每张卡片，记录的不只是卡片上的内容，它记录了大家围绕这张卡片讨论的那个时间段所有的信息，信息量更加庞大。

• 我们回头再去看这些卡片的时候，和看照片一样，它会快速唤起我们对那段时间的回忆。

 

04 总结

• 在复杂产品中，不要试图在项目开始就做一套包罗万象的决策，我们要把各个决策分散到项目过程中，延后决策！
• 故事是一直伴随着产品生命周期的，良性的用户故事地图也是逐渐成长的。

• 首先，用大网眼的渔网捞一遍故事池，以此得到所有大故事。通过大故事，形成对产品的整体感觉，接下来用网眼小一些的渔网得到中等大小的故事，最后才是最小的需求。
• 其次，故事会像捕鱼一样，随着时间的推移会成长，会有新出生的鱼，也可能会死亡。
• 另外，不可能也没有必要捕捉到这个区域所有的鱼，我们也不可能捕捉到所有的需求，可以先实现已捕捉到的需求，再继续捕捉剩下的需求。
• 最后，在捕鱼的时候也可能捞到一些废弃物和残骸，就是不是故事的故事，这些要及时抛弃！
• 项目前期是不可能正确的捕捉并写出所有的需求，用户故事地图这个方法也不可能在一个阶段捕获出所有的用户故事。
• 随着时间的推移以及产品不同阶段要加入新的用户故事，捕捉故事的渔网网眼也要一直变化。