无论是做产品还是做运营，需求分析都是一个很重要的环节。用户故事地图作为一种有效的需求工具，越来越广泛地应用于开发实践中。
一款产品的成功，在于比竞争对手更好地满足了用户需求，而这并不是一件容易的事。这是因为，你或多或少总会在以下3件事上掉坑里：
- 读懂需求本身，能够抓住核心痛点
- 选择用自己独特的方式来满足
- 将需求实现拆分成大小不同的故事，比竞争对手速度更快、做得更漂亮
接下来我们聚焦于尤其适用于多需求、复合型产品的第三个坑。
掌握故事地图的方法之后你会发现，无论你是一个喜欢观察用户行为、提取用户行为模式的交互型产品经理，一个注重用户体验、寻找用户high点的用户运营，还是其他任何会参与到业务流程当中、和其他部门发生协作的角色，这都是一种在需求拆分过程中保持全景的视角的技术，一种在部门协作时更有效的沟通方式。
关于MVP
最小可行产品（MVP），是指可以产生预期成果的最小产品发布。这里需要说清楚，“最小”是针对哪些用户而言的？这些用户需要通过软件达成哪些目标？
另外，很少有哪个产品是全新的，往往实在现有产品上增加新的功能或者提升现有功能。所以，又可以讲最小可行方案：最小可行方案是指可以产生预期成果的最小发布方案。
关于MVP的更多介绍这里不多陈述，感兴趣的可以看这篇文章：《MVP的四级台阶》
如何找到MVP？
很多时候，一个完美产品要做的事情多到我们很快就不堪重负。全部功能的完成，看起来非常重要，但是当我们时候回过头来思考那些特定用户以及用户实现其目标的基本功能时，会发现这些用户和诉求可以用一两句精炼的话来概括。
首先，创建用户故事地图
通常大家来自不同的团队，每个团队都专注于各自不同的领域，但是要交付的是一个产品。大家必须齐心协力交付这个产品，不可以根据各自团队的视角来制定发布计划，必须以可视化的方式展示出所有的依赖。
而用户故事地图已经成为敏捷需求规划中的一个流行方法，它可以将你的backlog（产品功能列表）变成一张二维地图，而不是传统的简单列表。
简而言之，故事地图用来建立共识，帮助团队以可视化的方式展示依赖关系。
它可以解决以下问题：
- 让你更容易看清backlog的全貌
- 为新功能筛选（grooming）和划定优先级提供了更好的工具，帮助你做出决策
- 便于使用静默头脑风暴模式和其他协作方式来产生用户故事
- 帮助你更好的进行迭代增量式开发，同时确保早期的发布可以验证整体架构和解决方案
- 为传统的项目计划提供了一个更好的替代工具
- 有助于激发讨论和管理项目范围
- 允许你从多个维度进行项目规划，并确保不同的想法都可以得到采纳
总之，创建故事地图的过程可以帮助发现设计中的坑，甚至有些设计中遗漏的重点特性之间的关键环节，也可以提前发现。
那么，召开一个用户故事地图的讨论会议吧！
你需要做的准备是：
- 一个相对不被打扰的空间
- 一块白板（如果产品复杂，涉及到的用户行为动作较多，可以用地板、玻璃墙等。）
- 3-5个人左右的讨论组（产品、业务、交互设计、运营等，注意人数不宜过少和过多，因为更少的人意味着你无法获得足够的建议，而更多人则会因为讨论和协调降低会议效率。）
- 便利贴若干（最好有不同颜色）
这个会议，就是让所有参与者一起用便签，一张一个动作，从左至右按照时间线，描绘用户在产品使用场景下所发生的所有用户行为。
建议使用静默头脑风暴模式，让每个人在便签纸上写下自己认为重要的“所要做的事情”也就是用户任务（user task）。每个人都用同样颜色的便签来书写自己的用户任务描述，这个阶段不要互相讨论。
一旦大家都基本完成了准备，让每个人轮流大声读出自己的内容，并把便签纸全部放置在桌面上，这时如果出现重复的内容就可以省略掉：
- 根据你的产品规模，这个过程可能需要3-10分钟的时间；你可以观察大家的行为来判断是否需要停止。
- 尽量每张便签以一个动词开头，如：发送邮件、创建联系人、添加用户等。
- 这些便签组成了一级用户故事，Jeff Patton称为用户任务（user tasks），它们组成了用户故事地图上的 “行走的骨骼” （the walking skeleton）部分。
- 这时可以提示参与者：我们只用了很少的时间就完成了需求的收集过程，而且有些内容你可能没有想到，而其他人帮你想到了。
同一时间发生的，就写在同一位置的下方。出现同一场景不同可能的动作时，可能会形成不同的分支动作，直到重回主线或者结束支线。
然后，让大家将桌面上所有的便签进行分组，将类似的任务分为一组。如果发现重复的内容，就略过。
需要提醒的是，这是一个自下而上的、不给自己建立任何预先假设的方法。它让你忘记自己曾经把某个行为判定为“必需”还是“非必需”。
当全景图出现的时候，你再来合并掉同时的、无关的，你会看到在路线的关键节点上，哪些用户体验非常重要。从用户故事图景出发，来看自己的产品，会有一种豁然开朗的全局感。
故事地图完成后，我们会发现，要做的事情太多了，要完成所有的事情，项目日期几乎看不到头。这时候需要问：“要达到XXX效果，我们需要用到所有的功能码？”
也就是说，我们需要聚焦于系统外的预期成果来决定系统内需要什么功能！
其次，划分MVP发布计划
在用户故事地图上划分出第一个发布需要做的内容，其他的在之后的版本中完成。
思考过程是这样的：“如果能在XX预期里达到YY成果，那么产品亮相时看起来会不错。发布计划中的所有功能都是用户的基本需求，并且是惊艳的，可以让人眼前一亮。”
聚焦于成果，即发布后用户能使用和感知的东西，切分发布计划应该以成果为导向。
接着，划分发布路线图
整个故事地图包含许多的东西，但是完成所有功能所需的时间通常是无法接受的。这就需要我们聚焦于最首要的一个目标成果，识别出第一个发布要包含哪些内容。
我们水平划分用户故事地图上的便签，在划分的每一个发布的左边贴上便签，上面写上少量文字描述预期能产生的成果。
然后在各个发布之间移动卡片，尽可能匹配各个发布的成果预期。这样，在整个地图的左侧，是发布的名称列表，这些名称标识着目标成果，这就是发布路线图。
聚焦于特定的目标成果，这是排定开发工作优先级的秘密。
最后，为成果排列优先级，而非功能。
拆分大型输出的秘密在于聚焦于小的、特定的成果。成果的背后是参与特定活动的特定用户之特定行为的改变。
通过聚焦于即将发生的活动，选择参与活动的用户。但是，聚焦于活动用户，无法同时满足其他用户的需求，这些用户在比较长的一段时间内还是继续通过现有系统来满足需求。你无法一次性取悦于所有人。
用户故事地图样例
电子邮件系统的用户故事地图
第一行对这些操作邮件的事情进行了分组。
第二行所包含的内容就是“大家在电子邮件系统所要做的事情”，包括类似：书写邮件，发送邮件，创建约会等等。
黄色的便签的第一行包含了最小化的用户故事，如：写邮件只包括发件人，收件人，标题，内容和发送取消按钮。其他如支持RTF，HTML格式，添加附件，从通讯部获取联系人邮件地址等，都不在此行，放入更靠下的便签中。
黄色便签右上角更小的蓝色和橘黄色便签表示了不同的状态，比如：蓝色代表完成，橘黄色代表进行中（wip），这样你就可以看到项目的进展。
现在如果我们专注于从左到右完成第一行的黄色便签，我们就可以确保很快发布一款包含了最最基本功能的邮件系统。这样我们就可以验证我们的邮件系统整体架构（发送邮件同时确保其可以被阅读）可行。
同时，也可以帮助我们对系统的功能进行端到端的测试，确保我们可以从用户处获取到反馈，知道我们是否解决了它们的问题（提供了商业价值）。注意我们在第一行没有包含“删除邮件”这一功能，因为并不一定要完成所有用户任务的开发。
用户故事地图规范
- 第2个步骤中的便签表示 用户任务（user tasks），蓝色便签
我们可以把这理解为用户的大故事，这个是用户故事地图的框架。 - 第3-4个步骤中的便签表示 用户行为（user activies），橘色便签。Jeff 称这两行的内容为 “行走的骨骼”（walking skeleton）和 “主干”（backbone）
- 用户故事（user stories），黄色便签在每个用户任务下自上而下排列，便于我们确定优先级
我们可以把这理解为用户的小故事，是用户故事地图的细节。记录员要把每一个小细节都写在便利贴上，竖向排列在“大故事”卡片的下面。如果有与大故事无关的其他细节，可以放在“用户卡片”的上方区域。
到此为止，一个巨大的恐龙骨骼一样的“用户故事地图”出现在白板上，甚至，它可以占满一面墙。一般来说用户会按照从左到右的顺序来使用你的系统（用户故事地图）。
最后，正如我们上文所言，为了缩短项目周期，我们要在“用户故事地图”上进行MVP的内容筛选，把最重要的内容放在前面。横向移动用户目标，纵向移动深挖出的细节，然后用胶带或其它工具做出分隔，以此划分不同版本。
随着软件的不断迭代，用户故事地图也会不断向下推移。此时，我们就完成了这个产品的发布路线图。
小结
“用户故事地图”以直观易变的方式进行项目的良好沟通，大多数人看重的是地图的形式部分，横向是讲述大故事的部分，纵向是逐步的细化。
但是最关键的是产品的构思框架，让团队成员对想要做出的产品一目了然，大大提高了团队之间相互协作的默契度。
要注意的一点就是，功能的开拓要适度，否则这幅用户地图永远都画不完。
