【UXRen原创】增强团队协作,洞察真实需求,研磨优良产品——译《用户故事地图》书籍有感

111

文章作者:向振东,《用户故事地图》译者之一,UXRen翻译组管理员

uxren-tg-adong

 

 

书籍信息:

  • 作者: Jeff Patton
  • 出版社: 清华大学出版社
  • 原作名: User Story Mapping
  • 译者: 李涛、向振东
  • 书籍链接:《用户故事地图》

    111

 

 

一、用户故事地图的来源

用户故事(user story)是敏捷软件开发过程中管理需求的重要方法。它就像这样:

作为一个咨询师,我想要操作我的邮件,这样我就可以和客户、同事、朋友保持联系。

它从用户的角度描述了谁(who)要做什么(what),以及为什么要这样做(why)。

最初的想法来自Kent Beck。他发现,使用文档来精确描述我们的需求根本是不可能的,文档只告诉我们做什么,却没有告诉我们为什么要这样做;同样的文档,阅读的人不同,得到的信息也会不一样;如果大家能够坐在一切讨论软件要解决什么问题,哪些用户会用,为什么用,我们就可以得到解决方案,并在这一过程中达成共识。用户故事的要义便在于团队聚在一起对用户故事进行充分讨论。

2001年,Ron Jeffries提出了著名的3C原则,对用户故事进行了概要总结:

 

  1. 卡片(Card):把用户想要的产品功能写在卡片上。
  2. 对话(Conversation):干系人(用户、客户、产品、开发、测试等)聚在一起讨论用户故事,对要解决的问题达成一致理解,并努力找到最佳方案。
  3. 确认(Confirmation):确定验收条件是什么。

 

2005年,Jeff Patton在他的一篇名为《How You Slice it》的文章中提出了一种协作式的、基于卡片的方法。这是用户故事地图(User Story Mapping)的雏形。

 

 

二、什么是用户故事地图?

用户故事地图的理念很简单。它强调和他人一起协作来讲述产品的故事,看到故事的全景,然后进一步细分以制定良好的规划决策。

地图的顶部是大故事(big stories),或者叫用户活动(user activities),它通常需要一些小步骤来完成。活动所在的行是用户故事地图的主干,从左到右的活动构成了基本的叙事流。关于活动的故事可能是这样:

作为一个咨询师,我想要操作我的邮件,这样我就可以和客户、同事、朋友保持联系。

对一次迭代来说,这样的故事显然太大了。大故事可以拆解成小故事,就像大石头可以打碎成小石头一样,但石头仍是石头,故事也仍是故事。操作邮件可以分解成“发邮件”、“读邮件”、“删除邮件”、“标记垃圾邮件”等。这些称为用户任务(user tasks),它们是用户为达到一定目标需要完成的动作,也是开发人员可以实现的东西。

诚如Martin Flowler在序言中所说,用户故事地图是拆解细化需求的重要技术,并让我们在拆分需求过程中保持全景图,始终牢记用户诉求。

3

图片来自:http://jpattonassociates.com/the-new-backlog/

 

 

 

三、使用用户故事地图的目的和优势

3.1 促进讨论和对话,建立共识,找到最佳解决方案

在产品开发过程中,建立共识的重要性不言而喻。Jeff在《用户故事地图》中谈到,两个人认为已经对某个功能达成了共识,而实际开发中却发现别人的理解和自己大相径庭。这样的场景并不鲜见。而使用故事地图的目的就是为了达成共识。

通过文档来完美地描述一个东西是不可能的,人们会根据自己的经验展开想象。但(1)如果是大家聚在一起,针对故事地图展开讨论;在讨论过程中,听的人可以通过反复提问或追问来修正对事情的最初理解,最终使所有参与者都达成共识。而且,(2)文档只会告诉我们做什么,却不会告诉我们为什么要这样做。如果需要解决问题的人和有能力解决问题人没法充分沟通,就不可能找到最佳的解决方案。

2

 

 

3.2  故事地图帮助我们思考故事全景

我们以功能模块来组织所有需要开发的功能,与开发团队逐条讨论。这种讨论关注开发细节,忽视整体愿景。当使用故事地图来组织我们的产品创意时,在深入细节前,我们会首先关注产品全景,避免在拆分需求时迷失于细节,遗忘用户诉求(为什么要这样做;预期结果是什么),遗漏任务之间的关键环节,或环节之间的衔接和依赖关系。

 

3.3 充分思考各种可行方案,最小化投入产出比

我们想要开发的功能,总是会超过你能够投入的资源。而最小化输出的秘诀在于,聚焦于系统外的预期成果来决定系统需要什么功能。

Golobo.com是巴西最大的媒体传播公司,他们要升级目前正在使用的内容管理系统,该系统涉及的业务和团队相当多。他们用便签在墙上描述了内容管理系统的故事,每个团队都是全景图中的一部分。可是,要完成所有的事情可能1年都不够。Jeff在对话中了解到,他们的CEO希望在几个月后的巴西大选上用上这个系统。团队开始聚焦于巴西大选,在大选中提供全新性感的互动内容,给网站访问者、广告商和合作媒体留下深刻的印象成为他们考虑到的最大成果,而这并不需要开发所有功能。

成果是用户可感知的东西,即他们可以用不同的方式来解决他们的问题,相比于之前,他们变的更开心了。聚焦于成果,以成果为导向切分发布计划。为成果排列优先级,而不是功能。

但是,在划分发布计划时,我们实际上是在假设许多事情的发生。我们假设产品发布后用户会使用它、喜欢它,能够解决用户遇到的问题;我们假设这些功能在有效的时间内可以开发出来。实际情况可能并不是这样。学习的重要性不言而喻。

 

3.4  组织最小化产品试验,进行验证性学习

在开发产品时了解用户的方式有许多,例如前期的用户调研和用户交流;或者通过原型、线框图来验证产品方案是否有用。但是,在真正接触到可使用的产品前,用户都只是在猜测自己是否会使用或喜欢它。真正的信心来自于用户每天会使用我们的产品。

在开发过程中利用MVP进行学习。MVP是我们的最小可行产品,我们把它拿给我们的“开发伙伴”(他们来自于早期访谈或原型测试以验证问题的受访人群),从他们的真实使用和反馈中进行学习,不断学习、持续迭代,直到得到真正解决用户问题、让用户满意的产品。

 

3.5 制定合理的开发计划,预估开发时间,按时发布

达成一致是成功预估的秘密。另外一个秘密则是,度量得越频繁,预估就越接近实际值。通过把大计划切分成小的部分,我们获得了许多度量的机会。

1

 

 

 

四、如何创建用户故事地图

4.1 分步骤写出你的故事

用户任务(动词短语)是构成用户故事地图的基本要件。

任务就像石头,可以分解为更小的石子。目标层级的概念有助于汇总小任务、分解大任务。

 

4.2 从左到右组织你的故事

这是我们讲故事的顺序(叙事流),是我们的故事地图。这样做的好处是我们可以看到整个故事,找到我们可能遗漏的部分。

 

4.3 探索替代故事(刨根问底游戏)

细节、替代、变化、异常构成了用户故事地图的主体(地图的深度)。例如,同样是讲述一天的故事,你可以讲述普通的一天、美妙的一天,或忙乱的一天。

 

4.4 提取故事地图的主干

活动构成故事地图的主干。所谓活动是指更高目标层级的任务,它由一群相似的人在相似的事件完成的任务组成,旨在达到特定的目标。活动所在的行是故事地图的主干。

 

4.5 切分出达成特定目标的任务集

这个环节你要思考哪些事情是可有可无的。如果早上起晚了,马上就要迟到了,你的任务肯定与你平时不一样。

利用切分来识别与特定结果相关的任务和细节。

 

 

五、故事对话

对话是拆解大故事的工具。一个人也可以创建故事地图,但如果使用故事地图时团队没有聚在一起对用户故事进行充分讨论,就说明使用用户故事的方式不对。同样的道理,故事地图是为开展用户和产品想法对话而服务的,如果不需要讨论,就不必使用故事地图。

 

5.1 从机会开始

机会是指我们认为可以解决一个问题的所有想法。机会讨论的目的在于我们是决定继续深入这一机会,还是把它当作垃圾扔掉(通过/不通过决定)。如果团队没有足够的信息来做出通过/不通过的决定,就要列出还需要了解哪些信息,然后一起来寻求答案。对于机会,我们要讨论正在解决的问题是什么;为谁解决;我们的构想是什么;公司如何从中获益、是否符合公司的商业策略;成本大小等。

 

5.2 探索讨论:将大故事进行分解,探索最小可行方案

在探索阶段,你需要广泛展开讨论,不仅是和同事,而且要深入客户和用户,了解他们目前解决问题的方式;有了你的方案后,他们的世界会发生怎样的变化;你的方案要花多长时间开发。我们需要建立起应该开发什么的共识,并确保我们开发的东西是正确的。

在这一阶段,故事地图有助于我们理解目前人们是如何解决问题的,然后你可以为自己的方案绘制故事地图。

 

5.3 故事工作坊:验收标准

这一阶段我们要回答的问题是,我们到底要开发什么?我们需要通过对话对软件各个模块的验收标准达成一致,因为下一步就正式开发了。

 

 

六、总结

Jeff Patton认为,软件本身并不重要,重要的是我们有没有改变世界。改变世界并不一定是翻天覆地的变化,而是在软件发布后,人们解决问题的方式变得不一样了,他们变得更开心了,这就是改变世界。在改变世界前,所有的产出都叫做输出,如果有些事情需要交代给别人,这通常叫做需求。然而,产品的成功绝不是以输出的多少或需求的多寡来评判的,唯一的度量标准只能是产品产生的影响即它的成果,即人们是否以不同于以往的方式解决遇到的问题,并且变得更开心了。Jeff Patton提醒我们,在使用故事地图或参与产品工作时,不妨以改变世界的模型来帮助自己思考。例如以成果为导向来排列优先级或规划产品发布。

当然,改变世界绝非易事。这往往需要一群人的努力。而这一群人要想产生合力、高效运作,建立共识则是第一要义。用户故事地图就是建立共识的一种机制。大家就用户故事展开充分讨论,产品要解决什么问题,哪些人会用,为什么用,一边倾听一边提问,不断修正最初的认识以在团队间达成共识,而不是追求完美的文档来试图达成一致;基于卡片的故事地图也让团队看到故事全景,增强沟通默契,在拆分需求时时刻牢记用户诉求。

故事远没有这么简单。我们并不能保证我们讨论的东西都是事实,它们很可能只是假设而已。故事地图帮助我们拆解出最小可用产品,建立学习目标,在迭代中不断接近用户的真实需求。

用户故事地图不仅仅是贴在墙上错落有致引人注目的一张张卡片,它也是一种理念、一种工作方式。我希望你可以通过Jeff Patton的《用户故事地图》真正理解和实践这一理念。

 

 

扫一扫,加入UXRen社区大家庭:

UXRen公众账号

 

 

扩展阅读:

 

 欢迎加入UXRen翻译组:

 

=======================================================

不知不觉UXRen社区官网已经2岁了, 在这里小编要感谢那么一如既往支持本站的油茶人。

UXRen.cn欢迎油茶人投稿,提供有价值的资讯、线索、点子及建议。

邮箱:contact@13tech.com.cn

注明:本站内容及数据部分来自互联网及公开渠道,如有侵权请及时联系我们。

========================================================

 

 

 

2 条回复

  1. 头像 Nick说道:

    可以

发表评论

您的电子邮箱地址不会被公开。