无论是做产品还是做运营，需求分析都是一个很重要的环节，在本次文章当中，作者给大家带来了一种她所学习到的需求分析方法，一起看看是要如何做的吧。

如果你是创业公司、还没用过用户故事地图，请一定试试。

今天给大家介绍的，是来自Jeff Patton的《用户故事地图》当中的需求拆分方法。

一款产品的成功，在于比竞争对手更好地满足了用户需求，而这并不是一件容易的事。这是因为，你或多或少总会在以下3件事上掉坑里：

读懂需求本身，能够抓住核心痛点；

选择用自己独特的方式来满足；

将需求实现拆分成大小不同的故事，比竞争对手速度更快、做得更漂亮。

本篇文章，将聚焦第三个坑，并且尤其适用于多需求、复合型产品。

掌握故事地图的方法之后你会发现，无论你是一个喜欢观察用户行为、提取用户行为模式的交互型产品经理，一个注重用户体验、寻找用户high点的用户运营，还是其他任何会参与到业务流程当中、和其他部门发生协作的角色，这都是一种在需求拆分过程中保持全景的视角的技术，一种在部门协作时更有效的沟通方式。

什么是MVP？

最小可行产品（MVP），是指可以产生预期成果的最小产品发布。这里需要说清楚，“最小”是针对哪些用户而言的？这些用户需要通过软件达成哪些目标？

另外，很少有哪个产品是全新的，往往实在现有产品上增加新的功能或者提升现有功能。所以，又可以讲最小可行方案：最小可行方案是指可以产生预期成果的最小发布方案。

而聚焦于学习、验证第一个MVP发布的假设，还需要设置更小规模的实验和原型来验证我们对最小和可行的猜测，所以，MVP根本就不是产品：

最小可行产品是为验证假设而做的最小规模的实验。

如何找到MVP？

很多时候，一个完美产品要做的事情多到我们很快就不堪重负。全部功能的完成，看起来非常重要，但是当我们时候回过头来思考那些特定用户以及用户实现其目标的基本功能时，会发现这些用户和诉求可以用一两句精炼的话来概括。

首先，创建用户故事地图

大家来自不同的团队，每个团队都专注于各自不同的领域，但是要交付的是一个产品。大家必须齐心协力交付这个产品，不可以根据各自团队的视角来制定发布计划，必须以可视化的方式展示出所有的依赖。

故事地图用来建立共识，帮助团队以可视化的方式展示依赖关系。

创建故事地图的过程可以帮助发现设计中的坑。我们常常假设其他团队会处理好相关的事情，而实际上他们并不知道自己需要这样做。有时也可以从中发现，有些设计中竟然遗漏了重点特性之间的关键环节。而团队在构建用户故事地图的过程中，可以提前发现被遗漏的部分。

召开一个用户故事地图的讨论会议吧！

你需要做的准备是：

一个相对不被打扰的空间；

一块白板（如果产品复杂，涉及到的用户行为动作较多，可以用地板、玻璃墙等）；

五个人左右的讨论组（产品、业务、交互设计、运营等，注意人数不宜过多，否则信息会容易失控）；

便利贴若干（最好有不同颜色）。

这个会议，就是让所有参与者一起用便签，一张一个动作，从左至右按照时间线，描绘用户在产品使用场景下所发生的所有用户行为。同一时间发生的，就写在同一位置的下方；出现同一场景不同可能的动作时，可能会形成不同的分支动作；直到重回主线或者结束支线。

在这个描述过程中，可能会非常吵，因为大家会争执用户动作发生先后，身处其中，你也会发现自己不曾想到过的细节。

正是这些细节，有可能让参与的所有人受益需要提醒的是，这是一个自下而上的、不给自己建立任何预先假设的方法；它让你忘记自己曾经把某个行为判定为“必需”还是“非必需”。当全景图出现的时候，你再来合并掉同时的、无关的，你会看到在路线的关键节点上，哪些用户体验非常重要。从用户故事图景出发，来看自己的产品，会有一种豁然开朗的全局感。

故事地图完成后，我们会发现，要做的事情太多了，要完成所有的事情，项目日期几乎看不到头。这时候需要问：“要达到xxx效果，我们需要用到所有的功能码？”

聚焦于系统外的预期成果来决定系统内需要什么功能？

其次，划分MVP发布计划