【UXRen原创】增强团队协作，洞察真实需求，研磨优良产品——译《用户故事地图》书籍有感
文章作者：向振东，《用户故事地图》译者之一，UXRen翻译组管理员
书籍信息：
- 作者: Jeff Patton
- 出版社: 清华大学出版社
- 原作名: User Story Mapping
- 译者: 李涛、向振东
- 书籍链接：《用户故事地图》
一、用户故事地图的来源
用户故事（user story）是敏捷软件开发过程中管理需求的重要方法。它就像这样：
作为一个咨询师，我想要操作我的邮件，这样我就可以和客户、同事、朋友保持联系。
它从用户的角度描述了谁（who）要做什么（what），以及为什么要这样做（why）。
最初的想法来自Kent Beck。他发现，使用文档来精确描述我们的需求根本是不可能的，文档只告诉我们做什么，却没有告诉我们为什么要这样做；同样的文档，阅读的人不同，得到的信息也会不一样；如果大家能够坐在一切讨论软件要解决什么问题，哪些用户会用，为什么用，我们就可以得到解决方案，并在这一过程中达成共识。用户故事的要义便在于团队聚在一起对用户故事进行充分讨论。
2001年，Ron Jeffries提出了著名的3C原则，对用户故事进行了概要总结：
-
卡片（Card）：把用户想要的产品功能写在卡片上。
-
对话（Conversation）：干系人（用户、客户、产品、开发、测试等）聚在一起讨论用户故事，对要解决的问题达成一致理解，并努力找到最佳方案。
-
确认（Confirmation）：确定验收条件是什么。
2005年，Jeff Patton在他的一篇名为《How You Slice it》的文章中提出了一种协作式的、基于卡片的方法。这是用户故事地图（User Story Mapping）的雏形。
二、什么是用户故事地图？
用户故事地图的理念很简单。它强调和他人一起协作来讲述产品的故事，看到故事的全景，然后进一步细分以制定良好的规划决策。
地图的顶部是大故事（big stories），或者叫用户活动（user activities），它通常需要一些小步骤来完成。活动所在的行是用户故事地图的主干，从左到右的活动构成了基本的叙事流。关于活动的故事可能是这样：
作为一个咨询师，我想要操作我的邮件，这样我就可以和客户、同事、朋友保持联系。
对一次迭代来说，这样的故事显然太大了。大故事可以拆解成小故事，就像大石头可以打碎成小石头一样，但石头仍是石头，故事也仍是故事。操作邮件可以分解成“发邮件”、“读邮件”、“删除邮件”、“标记垃圾邮件”等。这些称为用户任务（user tasks），它们是用户为达到一定目标需要完成的动作，也是开发人员可以实现的东西。
诚如Martin Flowler在序言中所说，用户故事地图是拆解细化需求的重要技术，并让我们在拆分需求过程中保持全景图，始终牢记用户诉求。
图片来自：http://jpattonassociates.com/the-new-backlog/
三、使用用户故事地图的目的和优势
3.1 促进讨论和对话，建立共识，找到最佳解决方案
在产品开发过程中，建立共识的重要性不言而喻。Jeff在《用户故事地图》中谈到，两个人认为已经对某个功能达成了共识，而实际开发中却发现别人的理解和自己大相径庭。这样的场景并不鲜见。而使用故事地图的目的就是为了达成共识。
通过文档来完美地描述一个东西是不可能的，人们会根据自己的经验展开想象。但（1）如果是大家聚在一起，针对故事地图展开讨论；在讨论过程中，听的人可以通过反复提问或追问来修正对事情的最初理解，最终使所有参与者都达成共识。而且，（2）文档只会告诉我们做什么，却不会告诉我们为什么要这样做。如果需要解决问题的人和有能力解决问题人没法充分沟通，就不可能找到最佳的解决方案。
3.2 故事地图帮助我们思考故事全景
我们以功能模块来组织所有需要开发的功能，与开发团队逐条讨论。这种讨论关注开发细节，忽视整体愿景。当使用故事地图来组织我们的产品创意时，在深入细节前，我们会首先关注产品全景，避免在拆分需求时迷失于细节，遗忘用户诉求（为什么要这样做；预期结果是什么），遗漏任务之间的关键环节，或环节之间的衔接和依赖关系。
3.3 充分思考各种可行方案，最小化投入产出比
我们想要开发的功能，总是会超过你能够投入的资源。而最小化输出的秘诀在于，聚焦于系统外的预期成果来决定系统需要什么功能。
Golobo.com是巴西最大的媒体传播公司，他们要升级目前正在使用的内容管理系统，该系统涉及的业务和团队相当多。他们用便签在墙上描述了内容管理系统的故事，每个团队都是全景图中的一部分。可是，要完成所有的事情可能1年都不够。Jeff在对话中了解到，他们的CEO希望在几个月后的巴西大选上用上这个系统。团队开始聚焦于巴西大选，在大选中提供全新性感的互动内容，给网站访问者、广告商和合作媒体留下深刻的印象成为他们考虑到的最大成果，而这并不需要开发所有功能。
成果是用户可感知的东西，即他们可以用不同的方式来解决他们的问题，相比于之前，他们变的更开心了。聚焦于成果，以成果为导向切分发布计划。为成果排列优先级，而不是功能。
但是，在划分发布计划时，我们实际上是在假设许多事情的发生。我们假设产品发布后用户会使用它、喜欢它，能够解决用户遇到的问题；我们假设这些功能在有效的时间内可以开发出来。实际情况可能并不是这样。学习的重要性不言而喻。
3.4 组织最小化产品试验，进行验证性学习
在开发产品时了解用户的方式有许多，例如前期的用户调研和用户交流；或者通过原型、线框图来验证产品方案是否有用。但是，在真正接触到可使用的产品前，用户都只是在猜测自己是否会使用或喜欢它。真正的信心来自于用户每天会使用我们的产品。
在开发过程中利用MVP进行学习。MVP是我们的最小可行产品，我们把它拿给我们的“开发伙伴”（他们来自于早期访谈或原型测试以验证问题的受访人群），从他们的真实使用和反馈中进行学习，不断学习、持续迭代，直到得到真正解决用户问题、让用户满意的产品。
3.5 制定合理的开发计划，预估开发时间，按时发布
达成一致是成功预估的秘密。另外一个秘密则是，度量得越频繁，预估就越接近实际值。通过把大计划切分成小的部分，我们获得了许多度量的机会。
四、如何创建用户故事地图
4.1 分步骤写出你的故事
用户任务（动词短语）是构成用户故事地图的基本要件。
任务就像石头，可以分解为更小的石子。目标层级的概念有助于汇总小任务、分解大任务。
4.2 从左到右组织你的故事
这是我们讲故事的顺序（叙事流），是我们的故事地图。这样做的好处是我们可以看到整个故事，找到我们可能遗漏的部分。
4.3 探索替代故事（刨根问底游戏）
细节、替代、变化、异常构成了用户故事地图的主体（地图的深度）。例如，同样是讲述一天的故事，你可以讲述普通的一天、美妙的一天，或忙乱的一天。
4.4 提取故事地图的主干
活动构成故事地图的主干。所谓活动是指更高目标层级的任务，它由一群相似的人在相似的事件完成的任务组成，旨在达到特定的目标。活动所在的行是故事地图的主干。
4.5 切分出达成特定目标的任务集
这个环节你要思考哪些事情是可有可无的。如果早上起晚了，马上就要迟到了，你的任务肯定与你平时不一样。
利用切分来识别与特定结果相关的任务和细节。
五、故事对话
对话是拆解大故事的工具。一个人也可以创建故事地图，但如果使用故事地图时团队没有聚在一起对用户故事进行充分讨论，就说明使用用户故事的方式不对。同样的道理，故事地图是为开展用户和产品想法对话而服务的，如果不需要讨论，就不必使用故事地图。
5.1 从机会开始
机会是指我们认为可以解决一个问题的所有想法。机会讨论的目的在于我们是决定继续深入这一机会，还是把它当作垃圾扔掉（通过／不通过决定）。如果团队没有足够的信息来做出通过／不通过的决定，就要列出还需要了解哪些信息，然后一起来寻求答案。对于机会，我们要讨论正在解决的问题是什么；为谁解决；我们的构想是什么；公司如何从中获益、是否符合公司的商业策略；成本大小等。
5.2 探索讨论：将大故事进行分解，探索最小可行方案
在探索阶段，你需要广泛展开讨论，不仅是和同事，而且要深入客户和用户，了解他们目前解决问题的方式；有了你的方案后，他们的世界会发生怎样的变化；你的方案要花多长时间开发。我们需要建立起应该开发什么的共识，并确保我们开发的东西是正确的。
在这一阶段，故事地图有助于我们理解目前人们是如何解决问题的，然后你可以为自己的方案绘制故事地图。
5.3 故事工作坊：验收标准
这一阶段我们要回答的问题是，我们到底要开发什么？我们需要通过对话对软件各个模块的验收标准达成一致，因为下一步就正式开发了。
六、总结
Jeff Patton认为，软件本身并不重要，重要的是我们有没有改变世界。改变世界并不一定是翻天覆地的变化，而是在软件发布后，人们解决问题的方式变得不一样了，他们变得更开心了，这就是改变世界。在改变世界前，所有的产出都叫做输出，如果有些事情需要交代给别人，这通常叫做需求。然而，产品的成功绝不是以输出的多少或需求的多寡来评判的，唯一的度量标准只能是产品产生的影响即它的成果，即人们是否以不同于以往的方式解决遇到的问题，并且变得更开心了。Jeff Patton提醒我们，在使用故事地图或参与产品工作时，不妨以改变世界的模型来帮助自己思考。例如以成果为导向来排列优先级或规划产品发布。
当然，改变世界绝非易事。这往往需要一群人的努力。而这一群人要想产生合力、高效运作，建立共识则是第一要义。用户故事地图就是建立共识的一种机制。大家就用户故事展开充分讨论，产品要解决什么问题，哪些人会用，为什么用，一边倾听一边提问，不断修正最初的认识以在团队间达成共识，而不是追求完美的文档来试图达成一致；基于卡片的故事地图也让团队看到故事全景，增强沟通默契，在拆分需求时时刻牢记用户诉求。
故事远没有这么简单。我们并不能保证我们讨论的东西都是事实，它们很可能只是假设而已。故事地图帮助我们拆解出最小可用产品，建立学习目标，在迭代中不断接近用户的真实需求。
用户故事地图不仅仅是贴在墙上错落有致引人注目的一张张卡片，它也是一种理念、一种工作方式。我希望你可以通过Jeff Patton的《用户故事地图》真正理解和实践这一理念。
扫一扫，加入UXRen社区大家庭：
扩展阅读：
欢迎加入UXRen翻译组：
-
翻译组介绍
-
已翻译的100+优质译文
-
翻译组QQ群：220325211
=======================================================
不知不觉UXRen社区官网已经2岁了， 在这里小编要感谢那么一如既往支持本站的油茶人。
UXRen.cn欢迎油茶人投稿，提供有价值的资讯、线索、点子及建议。
注明：本站内容及数据部分来自互联网及公开渠道，如有侵权请及时联系我们。
========================================================
可以
1