时间: 2021-07-30 09:31:17 人气: 21 评论: 0
通过用户故事地图，我们可以进行需求的收集和整理。
我认识的很多团队都是在敏捷的方法，近些年来，这类快速迭代的开发流程在整个圈子里面迅速的流行起来。
不管是出于为了快速交付、快速验证、还是不写文档等诸多原因。
不知道大家在执行敏捷过程中，特别是作为BA或者产品经理，发现有个问题。
这么多用户故事，这么多高内聚低耦合的用户故事，你有办法组织在一起吗？
其实我一直在考虑一个问题，就是敏捷执行一段时间后，如何能保证不偏离当初设定好的目标。
有人说，我们就没目标。
是，可能刚开始做产品并没有一个非常清晰的目标，比如我要做个共享单车，比如我要做个共享女友。
但是总**有个愿景或者是想要解决的问题。
我想要解决从家到地铁的500米距离的问题，我想要结束单身狗的命运……
而且在评估一个需求或者用户故事是否重要的时候，也很纠结。
因为目标和问题不明确，所以也不知道到底重不重要。
于是最后很可能演变成功能的堆砌。
连产品经理或者需求负责人都有这种感受的话，就更别说其他干系人了。
这种只见树木，不见森林的方法，想想可能引发的后果，就有点“不寒而栗”。
我不是来抨击敏捷的，因为我发现即便你用瀑布，可能也**有同样的问题。
你同样**进行需求的拆分，类似拆故事一样。
形成需求矩阵或者需求树进行管理。
但是顶层需求之间有什么样的关系，和你的整体目标以及要解决的问题有什么样的关系，这个估计也**有欠缺考虑的时候。
最近很巧的，看了三本书，介绍了三种方法，从三个不同的角度，都是为了解决同样的这个问题：
“只见树木，不见森林”。
那我这边**结合我的理解来和大家分别说一下这三种方法。
这篇先谈谈第一种。
敏捷里面有个很重要的概念叫做“用户故事”。
用户故事是从用户的角度来描述自己渴望得到的特性以及带来的价值。
现在流行的模板是：
英文：As a <Role>, I want to <Activity>, so that <Business Value>.
中文：作为一个<角色>, 我想要<活动>, 以便于<商业价值>
关于用户故事应该怎么写，这又是一个很大的命题了，如果感兴趣我们可以另外开一系列的文来写。
我们今天想要讨论的是，如果在你们的开发流程中已经使用了用户故事，怎样做才能“又见树木，又见森林”呢？
用户故事地图，顾名思义就是使用用户故事组成一个地图。
地图一般的作用有两个：寻找路径，了解全貌。
寻找路径
我们一般想要去一个地方，现在都**使用电子地图，输入起点和终点，APP**自动帮你规划出路径。
以前使用纸质地图的时候，也是在地图上要起点和终点，然后自己谋划一下路径。
这个应该是我们比较常用的功能了。
了解全貌
上学那**儿，地理课老师用世界地图也好，中国地图也好，来给我们讲解几大洲几大洋，地质情况等等。
我们在知道了地球是圆的基础上，还知道了中国就是雄鸡，意大利是靴子……
这就是了解全貌。
我之前刚工作的时候做的就是GIS（地理信息系统），所以对于上海市（区县合并以前）的各个区的方位以及轮廓铭记于心。
同理，用户故事地图也起到同样的作用。
用户故事地图主要起到两个作用。
一个是找到整个产品的主干，也就是路径。
一个就是了解整个产品的全貌。
通过我来描述用户故事地图怎么画，我相信大家可以理解我为什么这么说了。
你事先需要准备一些便签纸。
1.按照时间顺序整理出来整个产品的主要任务
就好像我们做西红柿炒鸡蛋一样，将每个任务都写出来。
这个时候你可能**得到很多的任务。
比如，打鸡蛋，放油，开火，炒鸡蛋……
2.组织情节
把同时发生的任务放在一起。
有些任务是**同时发生的，比如放盐和味精。
当然有的人可能还**放葱花啥啥啥的。
你可以把同时发生的便签纸放在一起，同时思考下有没有什么细节遗漏。
3.探索
有没有什么异常、变化可能**发生。
这个要看你探索的深度了，比如盐不够了，或者火太大糊了甚至着火了……
探索一下，你又可以得到一大堆的任务便签纸。
4.提取主干
把这么多的任务归归类，把主干归纳出来。
西红柿炒鸡蛋的主干可能是：准备工作、放油、开火、炒鸡蛋、加西红柿一起翻炒、加调料、出锅。
这里面，准备工作就包括：西红柿去皮、打鸡蛋……
加调料就包括：加盐、味精……
出锅可能**包括：没有客人情况下的拿个破碗装装，有客人情况下的摆个炫酷的**。
虽然我不知道西红柿炒鸡蛋怎么炫酷摆**，也许知乎知道答案。
5.补充
把用户、细节、可替代方案、异常以及优先级加上去。
比如，盐没有了，是用酱油或者用番茄酱……
基本上画出来的用户故事地图差不多是长这个样子。
其中最上面一层是用户，这个用户包括操作用户和系统。
比如，炒菜的你，吃菜的客人以及控制火力的电磁炉或者燃气灶。
骨干被分成了两层。
下面一层是第4步提出出来的按照时间顺序排列的主干。
上面一层是再进行抽象的到的高级别的任务。
骨干的下面就是脊柱了，每个主干任务的关联任务**有很多。
将他们按照优先级进行排列。
这样的一个用户故事地图就完成了。
我们回到之前的那个问题。
“只见树木，不见森林”。
你看这张图是否能够又见树木，又见森林呢？
能。
我们通过按照时间顺序讲述的主干故事，可以轻松的找到整个路径。
通过脊柱故事，我们可以清晰的知道如何达成某一个主干故事。
思路宽广，细节有度。
当我们看到这样一份用户故事地图后，我们很清楚的可以知道整体的任务有哪些。
在开发过程中，可以很清楚的知道，整个故事的开发进展情况。
如果要定义MVP，我们通过用户故事地图最上面的，优先级最高的脊柱，可以很快的给出评估结果。
大家感兴趣的话可以拿自己的产品来模拟的试一下。
《用户故事地图》这本书里还有很多精彩的插图和故事。
作者有一个观点我很**同：
用户故事不是另外一种写需求的方式，故事是用来讲的，不是用来写的，主要是为了建立共识。
小婧是一名行走在实践路上的资深业务分析师（BA），如果想与我同行，就请关注我呗！
作者：小婧，个人公众号：与小婧同行
本文由 @小婧 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自PEXELS，基于CC0协议
