让沟通变得友好的用户故事地图怎样创建？.pdf

让沟通变得友好的用户故事地图如何创建 ？ “用户故事地图”以直观易变的方式进行项目的良好沟通 ， 多数人看重的是地图的形式部分 ，横向是讲述 故事的部分 ，纵向是逐步的细化 ，但是最关键的是产品的构思框架 ，让团队 成员对想要做出的产品一目了然 ， 提高了团队之间相互协作的默契度。 一、用户故事地图是什么 ？ 1、瀑布模型 图 （1 ） 在进入正题前 ，让我先来讲讲敏捷开发的诞生。在很早以前的软件开发中 ，并没有系统的流程管理 方式 ，所以造成 量的人员、时间以及金钱的浪费。于是 ，在1970年 ，一个叫做温斯顿·罗伊斯的 人提出了针对于软件开发的一种架构 ，叫做“瀑布模型” ，他把 型软件开发分为 ：分析与编程 ，像 工厂流水线一样把软件开发过程分成各种工序 ，流程如上图 （1 ），之后 ，“瀑布模型”便沿用下去。 但是随着时代的进步 ，人们的需求越来越多 ，软件迭代越来越快 ，“瀑布模型”的缺点暴露的也越来 越明显 ：因为这种“一去不复返”的流程中没有迭代与反馈 ，应变能力差 ，所以对客户需求非常不容 易适应 ，只要有一处修改 ，就意味着前面的工作都白做了。所以“瀑布模型”逐渐被淘汰 ，一种叫“敏 捷开发”的管理新模式应运而生。 2、敏捷开发的优势 图 （2 ） 敏捷开发避免了传统瀑布方式的弊端 ，主要是吸收了各种新型开发模式的“动态”特性 ，敏捷开发把 关注点从文档转移到了开发者 ，管理方式也从工厂的流水线到团队的自我放松式的组织。在这种模 式下 ，客户的需求可以随着进程的推进和实际情况而改变 ，团队输出的产品也是“最小可行 产品” （MV P ），即可以产生预期成果的最小发布方案。这样 ，就 降低了成本 ，提高了灵活性 ，减小了风险 ，修改起产品也不需要全盘重做。所以 ，“敏捷开发”模式一直沿用至今。 3、用户故事地图的诞生 在以前 ，人们确定项目时总要写厚厚的几 本说明 ，好让开发人员对要做的东西有统一认识 ，但 很快 ，这种充满条条框框的说明就被淘汰掉了 ，取而代之的是“敏捷开发”模式中的“用户故事”。当然 ，这并不代表人们不用再写那些恼人的文档 ，“用户故事”的创建依然要有文档作为依据 ，只不过文 档的篇幅和格式已经 优化。通过“用户故事”这一步骤 ，避免了团队成员的主观影响 ，可以客观 的搜集整理 量用户需求 ，形成一个个用户问题、客户问题、公司问题的解决方案。 但是问题又来了 ，因为对于 型产品的开发 ，用户需求的内容会很多 ，像是一个庞 的地图 ，而“用 户故事”擅长聚焦于构建小的特性 ，专注于小的细节就没法掌握整体 ，所以会带给人们困惑 ，不知何 时才能完成开发和发布。不同的用户故事块也容易出现互不相匹配的产品部分 ，所以 ，为了避免这 种管中窥豹的错误出现 ，人们改进了用户故事的处理方法 ，这种新的方法就是“用户故事地图“。下面 ，就来介绍如何创建用户故事地图。 二、如何创建用户故事地图 ？ 1、前期准备 召集3-5名产品核心人员 ，可以包括产品负责人、项目经理、业务分析师、架构师 ，因为这些人代 表了项目中的主要角色的看法 ，所以创建出故事地图后 ，在以后的全体计划会上就可以避免出现许 多不必要的辩论。准备一面空出的白板 ，或一面墙壁 ，若干颜色和数量的便利贴 ，一卷彩色胶带。 2、整理创意框架 在正式开始创建用户故事之前 ， 家要在一起重新明确产品的创意框架 ，如 ： 明确产品的目标是什么 ？ 能为用户解决哪些问题 ？ 公司、用户都能获得哪些收益 ？ 然后 家统一答案 ，把明确的目标写在便利贴上 ，按照优先级排好顺序。 3、刻画用户画像 下面针对优先级最高的目标开始讨论 ，开始头脑风暴 ： 产品面向的主要用户群是那些 ？ 产品的潜在用户群有哪些 ？ 谁会为我们的产品付钱 ？ 基于这些问题 ，罗列不同类型的用户 ，讨论他们能从中得到什么好处 ，使用的动机 ，需要的功能等 。精炼出若干类用户 ，制成“用户画像”卡片 ，卡片上的内容不用很详细 ，可以描述出基本特征即可 ， 给每个类型的人群起一个人的名字 ，张三李四随意 ，目的是方便日后讨论 ，以后这个名字就代表这 一类人群 ，再对每个用户做一下简单的诉求描述。最后 ，把这些写着用户类型的卡片 ，按照优先级 排好 ，重要的用户放在上面 ，贴在白板上。 为