用户故事地图 | 作者：Jeff Patton
《用户故事地图》其实非常接近互联网项目管理相关的课程。大篇幅落在如何有效的沟通项目，以提高最终的项目成功性为目标。阅读的过程是一次思维框架的重新整理的过程，Jeff在书中创建出的工作模式是基于在一个相对透明度更高的工作环境里，彼此聚集在一起，你描述你的想法，我边听边提问。结合文字和图片，帮助大家最终达成一致的看法，这就是用户故事图的最大前提。大家首先要能够面对面针对同一个问题，达成共识。
开篇Jeff就表明态度，文档是用来备忘的，并不是用来讨论的。在过去工作中曾经经历过，直接扔个文档给开发就此了事的情况。现在来看，当时项目进展总是磕磕碰碰不太顺畅是存在其道理的。首先世上不存在完美的文档，其次阅读的过程很容易因为解读歧义而误读，实际上却获得了适得其反的结果。以后还是放弃共享文档，勤快一点，约相关同事一起开会讲故事，效率会更高。
关于用户故事概念
第一个提出用户故事概念的人名叫Kent Beck，他的想法非常简单，团队在一起讲述用户故事，通过讲故事的办法，大家获得对产品远景的一致理解，然后共同创建更好的产品解决方案。
用户故事地图是一个模式，团队对整个产品或整个特性达成共识，将大的用户故事进一步拆分。开始讲故事时应先关注故事整体，不要过早陷入细节。讲故事的同时，通过写卡片或标签来具体化你的想法，通过这个过程，可以提前识别产品创意中的坑和风险。在宽度上完成故事地图后，就该开始进行细化了。每一列顶层的卡片都是大故事，拆分的细节放在对应的下方。在每一个大故事上停一下，然后可以提出以下问题：
1. 用户在这一步具体要做什么事情？
2. 用户在这一步还有其他选择吗？
3. 如何做才能使用户觉得更酷炫？
4. 出现问题时如何处理？
如何讲用户故事
讲故事一般有六个步骤，分别如下：
1. 首先理清问题，这个大想法到底是什么？客户是谁？用户是谁？用户购买和使用动机？（关于产品和功能的构想）为什么要开发这款产品？（组织如何受益于这个产品）
2. 构建全景图，分步骤写出你的故事。
建立故事的过程中，你可以了解到以下几点：
（1）任务是描述人们做什么事情的动词短语。
（2）任务有不同的目标层级。
（3）故事地图中的任务被布置在从左到右的叙事主线中。
（4）地图的深度包含变化性和替代性的任务。
（5）通过故事地图顶部的活动将各个任务组织到一起。
（6）活动构成了故事地图的主干。
（7）通过切分地图找出达到一个具体结果需要完成的任务。
3. 探索。向深度发展，讨论其他类型的用户存在的意义和可能性。
4. 制定发布策略。
在拆分的过程中，团队逐渐识别出可能导致时间和预算管理失控的因素。这些因素就是风险。需要运用增量思维做加法，制定开局、中局和末局策略。
（1）开局
聚焦于必备功能或者用户步骤，重点关注技术挑战或风险。暂且跳过用户主流程之外的步骤，也先不管可能导致问题复杂化的商业规则。所有开发都只要满足跑通主流程就好。
（2）中局
补充周边功能，用户主流程之外的可选流程以及复杂的商业规则。如果开局阶段做的不错，在中局可以开始测试产品的非功能需求，比如性能、可扩展性和可用性。这些更多是质量方面的考量，要认识到这些方面的工作并持续进行测试。
（3）末局
打磨发布，使其更抢眼。此时，已经可以在生产环境中使用真实数据，此时能识别出改进点事原型阶段无法识别出来的。同时，也可以从真实用户那里听取他们对产品的反馈。
5. 制定学习策略。
如果你已经认识到使用用户故事可以避免团队开发出糟糕的产品，至此，事情才做对了一半，实际上，聚焦于解决问题的讨论，距离做出一款很棒的产品还有很长的一段路要走。
Alistair Cockburn作为敏捷开发社区的名人，曾说过一句话“对于每一个用户故事，在待办列表中应该有三张卡片与之对应。”第一张卡写上用户故事，第二张卡上写“修正第一张卡”，第三张卡上写“修正第二张卡片”。在敏捷过程的定义中，学习过程是有意为之。所以，需要为开发的每一个用户故事计划好学习过程，并为学习中会犯的错误预留时间。
作者特别强调了精益创业中的MVP模式对任务进行拆分，最小化可行性产品。探索活动不是要开发可交付的软件，而是学习和了解。通过发现活动，我们可以进一步多了解我们可以做哪些功能。通过发现活动，我们可以提出和解答如下问题：
（1）我们实际想要解决哪些问题？
（2）哪些方案对我们的组织和购买或采用该产品的客户有价值？
（3）基本可用的方案是什么样子的？
（4）在现有时间和工具的前提下，可以开发哪些功能特性？
6. 制定开发策略。将最小可行方案进行切分。
对于确定优先级，大多数人常犯的错误是试图首先确定功能的优先级。正确的做法是为特定的业务目标、客户和用户先确定优先级，然后再为他们的目标确立优先级，最后才是功能。
故事并不存在所谓的适当的大小规模。从用户、开发团队、业务角度看出去，大小规模适当的故事是完全不同的定义。由此又引到作者最重视的沟通方式，对话是拆分故事最好的工具之一。
探索最小可行方案具体涉及为方案建立原型，并用目标受众来验证。具体步骤包括：
（1）同理（共情或称移情）。直接与客户和用户交谈。亲身体验你想帮他们解决的实际困难。
（2）定义：实际聚焦于一个或多个问题并加以详细阐述。
（3）形成想法：有意识地针对客户和用户的问题构思若干个可能的解决方案。
（4）制作原型：制作简单的原型进行探索，得出最好的解决方案。制作有一定保真度的原型，让用户和客户可以评价解决方案是否真的可以解决他们的问题。
（5）测试：将解决方案拿给可能购买或使用产品的人看。不要期望它们一开始就能取得成功。不断加以迭代和完善。
其他一些有启发的内容：
1. 故事并不存在所谓的适当的大小规模。从用户、开发、业务角度，对大小规模适当的故事的理解是如此不同。
（1）从用户角度来看，大小规模适当的故事，是一个可以满足某一需要的故事。
（2）从开发团队角度来看，大小规模适当的故事，是一个只需要几天时间就可以完成开发和测试的故事。
（3）从业务角度看，大小规模适当的故事，是一个有助于实现业务目标的故事。
2. 我们有时很容易忽略客服工作带给我们的重大意义。用户故事地图和客服投诉的结合，可以很好用于辨认客户真正的诉求，最终引导向正确可能性更高的需求。
首先将用户参与产品的整个流程通过故事地图完整画出，再向这个地图的纵列任务侧，增加写有用户抱怨的卡片。为了保持平衡，查看用户目前喜欢的部分功能并把它们添加到地图中。如果发现有些环节有很多用户痛点，但目前还看不出任何机会，那产品经理就要认真反思自己需求梳理的流程是否存在疏漏。
3. 使用故事地图可用来评估发布是否准备就绪，在故事地图中每个纵列任务进行完成情况的评估，最终汇总成大的故事模块的上线分数，以评估上线前的准备工作。
网友评论