前言
用户故事地图通过对话，让不同的角色之间彼此对齐需求认知，发现Gap，增强协作，达成一致的目标。在产品开始动工前，可以说是成本最低的一种假设推研的方式，能够更早地发现不合理或者遗漏点。这也是为什么用户故事地图成为Product Owner工具箱中必备的工具。那么如何用好这一利器呢？今天就给大家介绍一下如何有效的组织场用户故事地图工作坊。
工作坊步骤
参与的人员
如果团队较小(5~9人)，可以选择全员。如果是大型团队(20~100人)，建议核心成员或者Lead参与，尽可能包括广泛的角色，例如：开发，QA，BA，PO，Design等。
场地选择
有较大的白板、墙壁或者有较大的桌子的场地。使用相对封闭的会议室较好，因为workshop过程中会有很多讨论，声音会影响到周围同事。
具体步骤
- 勾勒框架(Frame)
在绘制用户故事地图前，请考虑你的产品或者功能的主要内容以及主要的约束。例如：- What：命名你要加入产品的功能，你想解决的主要问题是什么?
- Who：定义将要使用或购买产品的不同类型的客户。对每一个类型的用户进行用户画像，描述产品将给他们带来的好处。
- Why：描述这个产品或功能将会给客户的组织带来的变化，例如利润增加和成本降低？
- 绘制一个大的蓝图(Map the Big Picture)
- 始终聚焦整体
让思考始终保持在”一公里宽，一英尺深”。活动和主要用户任务作为你的用户故事地图的主骨架，始终呈现给我们一个需求全景图。 - 从对你的产品成功最关键的用户类型开始
想象一下你的用户使用你的新产品或功能的一天是什么样子的。从左到右绘制每一个用户的使用步骤。 - 定位用户活动
为了实现一个目标，将一组相互配合的任务组合在一起就形成了用户活动。活动通常在你看到更多的用户任务之后出现。 - 增加额外的用户
除了使用典型用户模拟产品的使用，你会发现还需要其他类型的用户来应用你的用户故事，继续模拟他们的故事，从左到右排列活动或任务。
- 始终聚焦整体
- 探索细节(Explore)
- 填充用户故事地图的身体
将大的用户任务拆分成小的子任务或者用户交互细节。在这期间你可能要加入新的卡片，将一个卡片拆分成两个，重写卡片，或者重新摆放卡片的顺序。 - 用这个阶段来思考所有可能性
用这个时间思考所有可能出错的地方，不用担心你的想法是否在当前业务范围内。后面你会有机会将多余的部分移除的。- 经常问“如果有了这个会不会更酷一点？”: 用这个来激发更多的产品买点。
- 寻找可能性：用户还会怎么使用这个系统？
- 寻找异常情况：如果出现了异常，用户需要做什么？
- 考虑其他用户：其他类型的用户要怎么实现他们的目的。
- 增加更多产品细节：描述UI细节；业务规则；数据元素。
- 把故事讲给更多人听
将故事讲给更多人听，他们会帮你发现漏洞，并重建他们。讲故事给开发团队，他们会告诉你风险和成本高昂的地方。总之会有更多好点子被加入解决方案的。
- 填充用户故事地图的身体
- 划分可行的Release(Slice out Viable Releases)
- 把你的地图按release分片
按照最小可用产品将产品的roadmap划分成若干次可增量交付的release。 - 给每个release按照目标成果和影响来命名
成果和影响能够告诉我们，当前release是为了达到某个目标，这个“目标”就是我们构建产品的动力。同时也会指出用户将如何行动来帮助我们达到这个目标。 - 给每一个release定义成功的度量标准
试着回答这个问题“我们用什么来度量产品成功了？” 理想状况下，你会通过用户故事地图想象用户使用产品的情况，并发现产品对他们行为的改变，以此来度量是否产品成功的影响了用户的行为。
- 把你的地图按release分片
- 划分开发策略(Slice Out a Development Strategy)
- 给第一次release分出来3或更多个交付阶段
团队结合时间约束，考虑可能的产品发布目标，制定快速并能规避风险的可行的release方案。可以使用如下的方式：- 开场
沿着功能骨架看当前版本的功能是否是最简单的，满足用户和干系人需求的。 - 中场
丰富和完善主要功能，反复推敲测试各种可能的情况，考虑性能和可扩展性。 - 结束
基于产品release目标，查看是否还有可能未预见的工作，完善产品开发。
- 开场
- 为开发工作完善必要的用户故事
- 让开发和测试人员走读所有release的用户故事，对验收标准达成一致。
- 规划开发和测试计划
- 开始构建可工作的软件
- 给第一次release分出来3或更多个交付阶段
电子工具推荐
物理看板的用户故事地图用来线下讨论是很用冲击力的。而且移动方便，上手快速。不过会有一些小弱点，例如会议室如果不是你们团队的专属作战室，那么无法保证便签可以保留完好，随着时间的推移，粘性降低，风吹等外部因素可能会导致丢失便签。而用户故事地图作为一个产品的全景图最好是能够根据产品的迭代持续维护更新，否则将没有意义，也造成了浪费。所以这里推荐几个在线工具来将物理看板电子化。Miro和MURAL，这两个都是在线协作看板工具平台，免费版本一般就够用了，可以多人协作编辑一个看板。手机版App还有一个亮点功能——OCR，拍照将物理便利贴转换成电子便签，方便快捷。
Bruce有话说
是不是迫不及待地想拉着团队马上尝试一下这神奇的工具？且慢，在这之前，建议你读一下Jeff Patton著的<用户故事地图>这本书，书中很多案例和理论描述会让你有更深入的理解。在这之后去尝试一下用户故事地图吧，我相信他会给你带来惊喜，你也会在过程中发现更多新的idea。下图是我做的用户故事地图工作坊产出：
Tips: 我们的惯性思维MVP必须是一个可运行的软件。而迭代思维实际是希望用最小的成本换回用户的反馈从而验证我们的假设。如果一个线框图能够做到，那他也可以称之为MVP，你觉得呢？
