让沟通变得友好的用户故事地图如何创建?

0 评论 20392 浏览 89 收藏 12 分钟

“用户故事地图”以直观易变的方式进行项目的良好沟通,大多数人看重的是地图的形式部分,横向是讲述大故事的部分,纵向是逐步的细化,但是最关键的是产品的构思框架,让团队成员对想要做出的产品一目了然,大大提高了团队之间相互协作的默契度。

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

1、瀑布模型

1

图(1)

在进入正题前,让我先来讲讲敏捷开发的诞生。在很早以前的软件开发中,并没有系统的流程管理方式,所以造成大量的人员、时间以及金钱的浪费。于是,在1970年,一个叫做温斯顿·罗伊斯的人提出了针对于软件开发的一种架构,叫做“瀑布模型”,他把大型软件开发分为:分析与编程,像工厂流水线一样把软件开发过程分成各种工序,流程如上图(1),之后,“瀑布模型”便沿用下去。但是随着时代的进步,人们的需求越来越多,软件迭代越来越快,“瀑布模型”的缺点暴露的也越来越明显:因为这种“一去不复返”的流程中没有迭代与反馈,应变能力差,所以对客户需求非常不容易适应,只要有一处修改,就意味着前面的工作都白做了。所以“瀑布模型”逐渐被淘汰,一种叫“敏捷开发”的管理新模式应运而生。

2、敏捷开发的优势

2
图(2)

敏捷开发避免了传统瀑布方式的弊端,主要是吸收了各种新型开发模式的“动态”特性,敏捷开发把关注点从文档转移到了开发者,管理方式也从工厂的流水线到团队的自我放松式的组织。在这种模式下,客户的需求可以随着进程的推进和实际情况而改变,团队输出的产品也是“最小可行产品”(MVP),即可以产生预期成果的最小发布方案。这样,就大大降低了成本,提高了灵活性,减小了风险,修改起产品也不需要全盘重做。所以,“敏捷开发”模式一直沿用至今。

3、用户故事地图的诞生

在以前,人们确定项目时总要写厚厚的几大本说明,好让开发人员对要做的东西有统一认识,但很快,这种充满条条框框的说明就被淘汰掉了,取而代之的是“敏捷开发”模式中的“用户故事”。当然,这并不代表人们不用再写那些恼人的文档,“用户故事”的创建依然要有文档作为依据,只不过文档的篇幅和格式已经大大优化。通过“用户故事”这一步骤,避免了团队成员的主观影响,可以客观的搜集整理大量用户需求,形成一个个用户问题、客户问题、公司问题的解决方案。

但是问题又来了,因为对于大型产品的开发,用户需求的内容会很多,像是一个庞大的地图,而“用户故事”擅长聚焦于构建小的特性,专注于小的细节就没法掌握整体,所以会带给人们困惑,不知何时才能完成开发和发布。不同的用户故事块也容易出现互不相匹配的产品部分,所以,为了避免这种管中窥豹的错误出现,人们改进了用户故事的处理方法,这种新的方法就是“用户故事地图“。下面,就来介绍如何创建用户故事地图。

二、如何创建用户故事地图?

1、前期准备

召集3-5名产品核心人员,可以包括产品负责人、项目经理、业务分析师、架构师,因为这些人代表了项目中的主要角色的看法,所以创建出故事地图后,在以后的全体计划会上就可以避免出现许多不必要的辩论。准备一面空出的白板,或一面墙壁,若干颜色和数量的便利贴,一卷彩色胶带。

2、整理创意框架

在正式开始创建用户故事之前,大家要在一起重新明确产品的创意框架,如:

  • 明确产品的目标是什么?
  • 能为用户解决哪些问题?
  • 公司、用户都能获得哪些收益?

然后大家统一答案,把明确的目标写在便利贴上,按照优先级排好顺序。

3、刻画用户画像

下面针对优先级最高的目标开始讨论,开始头脑风暴:

  • 产品面向的主要用户群是那些?
  • 产品的潜在用户群有哪些?
  • 谁会为我们的产品付钱?

基于这些问题,罗列不同类型的用户,讨论他们能从中得到什么好处,使用的动机,需要的功能等。精炼出若干类用户,制成“用户画像”卡片,卡片上的内容不用很详细,可以描述出基本特征即可,给每个类型的人群起一个人的名字,张三李四随意,目的是方便日后讨论,以后这个名字就代表这一类人群,再对每个用户做一下简单的诉求描述。最后,把这些写着用户类型的卡片,按照优先级排好,重要的用户放在上面,贴在白板上。

为了讲解的更加清晰,我把之前参与过的一个项目当做例子,演示“用户故事地图”的产生过程:这是一款大学生的微电影服务平台,我们的初衷是想要“大学生影视团队”和“有拍微电影意愿的人”在平台上对接起来,由于摄影团队所驾驭的影片难度低,需要的资金少,所以我们的目标很可能包括这些:“学生拍毕业季微电影“”学校社团宣传“”婚礼开场微电影烘托气氛“等等(下面我所绘制的用户故事地图只是想让大家看起来更直观,如果有不严谨之处还望大家见谅)。

3

4、大故事

从最重要的用户类型下手,这里依然使用头脑风暴,可以按照时间顺序挖掘,描述这个人在一天中使用产品的情景,“首先他会怎样,然后怎样,然后……“这些故事可以比较概括,如“用户注册”或“修改日程”,团队中安排专门的人负责记录把每一件事都写到一张便利贴中,按照时间顺序从左到右排好便利贴。当有遗漏的故事被挖掘出来时,可以随时调整卡片顺序。在这个过程中,做到了团队成员对所要做的东西达成了一致,产品创意精彩的细节部分被所有人所消化。

下图以其中的一个用户类型为例,写出大故事:

4

5、深挖细节

在完成第五步的“大故事”后,“用户故事地图”的框架已经结束,下面要做的是深挖细节。白板上的卡片已经出现了第一列,这些都是大故事,我们要在每一个大故事上深挖,写出包括的细节:

  • 用户在这一步具体要做什么事情?
  • 用户在这一步还有其他选择么?
  • 如何做才能更符合用户的习惯?
  • 出现问题时如何解决?

在完成以上等等问题后,记录员要把每一个小细节都写在便利贴上,竖向排列在“大故事”卡片的下面,如果有与大故事无关的其他细节,可以放在“用户卡片”的上方区域。到此为止,一个巨大的恐龙骨骼一样的“用户故事地图”出现在白板上,甚至,它可以占满一面墙。

5

6、划分MVP发布计划

在第五步我们所创建的“用户故事地图”涵盖了多个用户故事和叙事主线,包含了项目人员所有的愿景,但是它太庞大了,如果同时研发这些功能点,可能几年时间都做不完,“敏捷开发”也不允许我们这么做。所以,为了缩短项目周期,我们要在“用户故事地图”上进行MVP的内容筛选,把最重要的内容放在前面。横向移动用户目标,纵向移动深挖出的细节,然后用胶带做出分隔,如下面这个例子,在第一个版本中,我只开发标号为1的部分,随着软件的不断迭代,用户故事地图也不断向下推移。此时已经完成了这个产品的发布路线图。

6

三、说在最后

“用户故事地图”以直观易变的方式进行项目的良好沟通,大多数人看重的是地图的形式部分,横向是讲述大故事的部分,纵向是逐步的细化,但是最关键的是产品的构思框架,让团队成员对想要做出的产品一目了然,大大提高了团队之间相互协作的默契度,但是要注意的一点就是,功能的开拓要适度,否则这幅用户地图永远都画不完。正如《用户故事地图》的作者Jeff Patton所说:“如果不需要讨论,就不必绘制用户故事地图。”

 

本文由 @孙昊 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!