《用户故事地图》读书笔记

2017/03/19

3.7k 字

《用户故事地图》以用户故事地图为主题，强调以合作沟通的方式来全面理解用户需求。作者从故事地图的构建、需求分解优化、团队协同工作等多个角度，深入探讨了如何通过用户故事地图建立共识、进行验证性学习，最终开发出真正有价值的、小而美的产品和服务，为现代产品开发和敏捷管理提供了实用的方法论指导。

简介

用户故事地图作为一种有效的需求工具，越来越广泛地应用于开发实践中。这本书以用户故事地图为主题，强调以合作沟通的方式来全面理解用户需求，涉及的主题包括：

怎么以故事地图的方式来讲用户需求
如何分解和优化需求
如何通过团队协同工作的方式来积极吸取经验教训
从中洞察用户的需求，开发真正有价值的、小而美的产品和服务

要点

用户故事地图是为了建立一种共识
对用户故事应当进行合理的拆分
最小可行产品，为验证假设而做的最小规模的实验
验证性学习，制作有一定保真度的原型

书摘

第 0 章使用前必读

好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。
只有满足顾客和用户的需要，公司才能实现自己的诉求。
记住以下几点：
- 用户故事不是另一种写需求的方式，讲述用户故事，在过程中用文字和图片相结合的方式辅助讨论，这是一种建立共识的机制
- 用户故事也不是需求，用户故事是关于问题解决方案的讨论，解决公司的问题，解决客户的问题，解决用户的问题，目的是我们对要开发的功能达成共识
- 你的工作不是更快开发更多功能，而是使那些投入精力开发的功能在成果和影响上可以最大化

第 1 章产品全景图

用户故事地图，就是在讲大故事的同时进行拆分。
边讲边记：在讲故事的同时，通过写卡片或便签来具体化你的想法。
在软件开发中，我们想要开发的功能，总比我们能负担的时间和金钱多得多。所以软件开发的目标从来就不是开发所有的功能，而是开发尽可能少的功能。
使用卡片，能够提升沟通的默契程度。
使用用户故事地图可以提前识别产品创意中的那些坑。
"思路宽广，细节有度"。在迷失于细节之前，先走一遍整个故事。聚焦于故事的整体，不要过早陷于细节。
用户故事地图通过良好的沟通并以地图的形式来组织沟通的内容。大多数人看重的是地图的形式部分，从左到右是人们讲述大故事的步骤，从上到下是逐步的细化。但是最关键的部分是产品构思框架，更多的背景信息就摆放在地图的周边，其中包括产品目标以及客户信息和用户信息。如果把故事地图贴在墙上，你会发现把用户界面草图和其他注释贴在地图周边是一个不错的主意。

第 2 章计划，为了更少的开发

贯穿各个团队的产品发布地图，可以帮助团队以可视化的方式展示依赖关系。
团队在构建用户故事地图的过程中，可以提前发现被遗漏的部分。需求范围并没有蔓延，而是我们对需求的理解更深刻了。
聚焦于系统外的预期成果来决定系统内需要什么功能。
聚焦于成果，即产品发布后用户能使用和感知的东西，切分发布计划应该以成果为导向。
聚焦于特定的目标成果，这是排定开发工作优先级的秘密。
最小可行产品并不是发布用户只在特定场景下使用的产品，也不是只把产品发布给忍受度非常高的用户，而是指可以独立生存的软件，是可以产生预期成果的最小产品发布，是为验证假设而做的最小规模的实验。

第 3 章计划，为了更快的学习

对产品故事进行首次讨论，应聚焦于如何具象化产品的机会。
手绘线框图和高保真原型可以帮助你具象化解决方案
把每次发布都当成一次实验，关注于自己要学习的东西。

第 4 章计划，为了按时发布

构建故事地图的最终目的：团队所有成员能够达成一致的理解，能够指出设计方案中的问题和改进点，并对需要投入多少开发时间进行估计。
最靠谱的估算，来自于真正理解自己在估算什么的工程师。
运用迭代思维持续评估和打磨作品。运用增量思维做加法。

第 5 章如何创建故事地图

用户任务是构建故事地图的基本模块。
使用目标层级的概念，可以帮助汇总小任务或分解大任务。
故事地图通过自左向右的叙事流来组织，这种概念是人们讲故事最自然的方式。
细节、替代、变化和异常，构成故事地图的主体。
活动组成故事地图的主干。
使用切分来识别与特定结果相关的所有任务和细节。

第 6 章用户故事的故事

最佳的解决方案来自于需要解决问题的人和有能力解决这些问题的人彼此协作。
用户故事之所以得名，并不是要人们如何写出更好的用户故事，而是如何在写作中更好地使用它。
我们在一起讨论用户故事，力求对要解决的问题达成一致理解，并努力找到可以解决问题的最佳方案。

第 7 章如何把故事讲得更好

模版格式并不是用户故事的唯一要素。
提升讨论效果的检查单：
- 讨论用户角色
- 讨论要做的功能
- 讨论为什么
- 讨论软件之外的东西
- 讨论异常情况
- 讨论问题和假设
- 讨论更好的解决方案
- 讨论方案如何实现
- 讨论开发周期

第 8 章不要把所有内容都写在卡片上

每个用户故事，也包括和各个角色之间进行的各种各样的讨论。
在视频会议过程中，让摄像头始终聚焦于贴着便签的墙上。
远程协作，需要借助与工具，使每个人都可以同步看到并操作卡片。
使用工具来保存文字、图片和视频，可以帮助恢复讨论时的场景细节。
使用工具来安排开发顺序，跟踪和分析开发过程。

第 9 章卡片只是个开始

把故事的所有细节交接给开发人员，以这种方式来组织开发工作的做法是行不通的，千万不要这样做。
验证性学习胜过可以工作的软件。
尝试通过用户故事来驱动所有的事情，不论软件或是其他。

第 10 章做产品好比烤蛋糕

如果故事描述的方案过于昂贵，就应当考虑替代方案。
如果故事描述的方案符合预算，但是仍然很大，那么切分成小块可以帮助你更及时地评估产品和把控进度。
不要把大故事切到大计划中。把大故事切小，做小计划。

第 11 章碎石行动

从用户角度看，大小规模恰当的故事，是一个可以满足某一需要的故事。
从开发团队角度看，大小规模适当的故事，是一个只需要几天时间就可以完成开发和测试的故事。
从业务角度看，大小规模适当的故事，是一个有助于实现业务目标的故事。
使用机会讨论来达成问题是否值得解决的共识，最终做出继续进行或取消的决策。
通过探索和对话，力求找到最小的、可行的方案。
通过深潜式故事工作坊来讨论细节，拆分故事，并对我们将要开发的内容达成共识。
开始开发产品细节时，通过对话的方法对正在开发的软件给出反馈信息。
经常反思产品质量、工作计划以及工作方式。
拿有意义的工作软件模块去测试客户和用户，并从中学习。
对组织内的干系人而言，项目的进度和完成质量要保持持续可见。
运用度量和直接接触用户来真正了解结果是否达到预期。

第 12 章谁是碎石负责人

要求一个产品负责人来写所有故事和开展所有故事对话，显然是行不通的。
一个好的产品开发团队，产品负责人是一个关键的领导者，他可以使产品和整个团队在整个过程中做到同心协力。另一个糟糕的反模式是委员会设计，即每个人有平等的发言权，可以参与开发决策，在一个委员会中，当我们只有做一件事情的时间和资源时，往往会倾向于妥协。
一个由产品负责人带领的小型的、跨功能的团队来精心安排产品的探索工作。探索团队最理想的规模是 2 到 4 个人，这是餐桌交谈的规模，这样一来，大家可以快速建立共识。
组建一个核心团队来协助产品负责人，包括用户体验专家、设计专家和技术专家。
身为产品负责人，要兼顾其他干系人的想法，扮演制作人的角色，帮助他们获得成功。

第 13 章从机会开始

针对每个机会，讨论以下五个方面：
- 它们的对象是谁
- 我们正在解决什么问题
- 我们的构想是什么
- 为什么
- 大小
利用为现有产品创造的地图来发现机会或者基于现有产品的背景考虑当下已经拥有的机会。

第 14 章通过探索来建立共识

探索的四个核心步骤：
- 从业务角度来组织想法
- 理解客户和用户，搞清楚怎样做才能帮到他们
- 把自己的解决方案呈现出来
- 简化并计划找到最小化的可行方案及其具体开发方式
一起创建轻量级的用户画像，力求在团队中建立共识和同理心。
将用户界面可视化，力求建立对解决方案的共识。
为特定的业务目标、客户和用户确定优先级，然后再为他们的目标确立优先级，最后才是功能。

第 15 章通过探索来进行验证性学习

下意识地构思针对客户和用户问题的若干个可能的解决方案。
制作简单的原型进行探索，得出最好的解决方案。制作有一定保真度的原型，让用户和客户可以评价解决方案是否真的可以解决他们的问题。
将解决方案拿给可能购买或使用产品的人看，不要期望它们一开始就能取得成功，不断加以迭代和完善。
在精益创业中，学不到东西通常才是最大的失败。在精益创业方法中，开发意味着尽可能进行最小可行试验。

第 16 章提炼、定义和开发

在传统的软件过程中，"检查后拿掉"的东西称为"糟糕的需求"。但在敏捷过程中时，这只是学习和迭代改善而已。
在每个开发周期，都要在地图上找到下一步应该投入哪个故事。带着这些故事进入故事工作坊的最后一次最佳对话。

第 17 章故事呢，就好比《行星战机》

对故事循序渐进进行分解，而不是一次性完成。每一个故事讨论和分解阶段，都要一心想着目标。
故事地图是为开展用户和产品想法对话而服务的，一个好的经验法是，如果不需要讨论，就不必绘制用户地图。

作者简介

Jeff Patton，在过去二十多年的经历中，Jeff Patton 得到一个教训：虽然设计和构建软件的正确方式并不只有只有一种，但错误的更是多得数不胜数。

Jeff 有十五年丰富的产品经验，做过网上飞机零件预定和电子病历卡等，主要是帮助客户组织改进工作方式。在很多开发流程都只着眼于交付速度和效率时，Jeff 早已经在此基础上同时兼顾交付具有非凡价值并且能获得市场成功的软件产品。

早在 2000 年，Jeff 加入一个早期的极限编程团队以来，就一直专注于敏捷方法，尤其专长于把有效用户体验设计和产品管理实践融入扎实的工程实践当中。

目前，Jeff 的身份是独立顾问、敏捷过程教练、产品设计过程教练和导师。他针对敏捷产品管理各个主题所发表过的文章、随笔和 PPT 都可以从 agileproductdesign.com 和 Alistair Cockburn 的 Crystal Clear 找到。Jeff 是敏捷-使用性雅虎讨论小组的创办人和协调人，StickyMinds.com 和 IEEE Software 的专栏作者，CST（Certified Scrum Trainer），敏捷联盟 2007 Gordon Pask 奖的获得者。