提示：本文共有 2721 个字，阅读大概需要 6 分钟。
面对陌生的业务领域，产品经理如何快速了解业务模式、商业模式呢？通过用户故事做深入会是一个高效的做法。
随着互联网+各行各业的深入发展，互联网产品经理也在持续的向其他行业溢出。这也对产品经理的能力提出挑战：经常会遇到陌生的业务领域（2B产品更甚）。
对于这种新业务领域，产品经理在不了解商业模式、业务流程、不了解功能范围，怎么切入？
这时可以试试花个30分钟，列举一个全局的用户故事脑图，它能帮助你快速建立对业务的商业模式、范围、流程、人员角色、各自需求的思考。
开始之前
我们知道，通常可以使用四个问题，来控制产品的思考范围：
谁是核心用户他什么问题备受困扰我的产品能如何解决为什么是我们来解决，而不是别的产品这几个问题问完，我们的产品就有一个大致的范围概念了，那么接下来怎么分析、分解呢？总有一种千头万绪无处下手的感觉。这时就可以考虑用户故事了。
一、为什么需要用户故事（或者至少用户任务）
用户故事的开发方法是跟随敏捷开发产生的一种需求分析、产品分解落地的方法。
传统的敏捷开发会通过用户故事看板工具，来解决了团队一致性的沟通问题、产品的分版本、分阶段落地等问题。
而现在，为了能帮助自己梳理思考问题的逻辑链条，辅助后续工作的思考，可考虑将用户故事看板简化为用户故事脑图。
作为用户故事看板的轻量形式，用户故事脑图在使用的过程中，可以让我们所有的功能都有场景、有依据，从而减少在产品设计阶段伪需求的产生。
再多轮业务的使用中，我认为它是一种独立建立角色设定、明晰场景、分析需求的一个很有效的方法。能够为后续的产品业务架构设计、产品迭代规划等提供高效的指导。
抽30分钟的时间，我们来看看怎么做一个有效的脑图用户故事：
二、如何做脑图用户故事
常规单条用户故事的结构一般是：
我是XX【某个角色】，当我在XXX【某个场景】的时候，我希望能够XXX【做某件事情】，因为这样我就能XXX【实现某个目的】
当所有的用户故事罗列完成后，根据不同的角色、场景、任务之间的重要等级、关联和依赖程度去做功能开发的取舍、阶段版本的定义，从而推进到后续的产品设计、研发以及线上验证反馈阶段。
而脑图的用户故事中，因为是给自己做思路梳理的，所有它可以根据实际情况做简化。通常我会至少保留用户故事的基本结构，其他的信息在根据需要，做针对性深化。
另外，在做用户故事梳理还有一个原则，即：梳理阶段，只考虑用户与场景的需求，不考虑技术实现路径。
三、脑图用户故事的层级结构
我所使用的脑图用户故事的结构层级如下：
第一层 典型角色第二层 典型场景（或者叫用户行为、骨干故事）第三层 典型的用户任务有些人会在用户任务下再细分一些更细致的用户故事，不过我感觉自己用到第三层次已经可以了，就没有再细分。
第一层 典型角色
举个例子，假设我们要做一个餐饮点单的产品，应该怎么来列这个脑图用户故事呢？
首先来看典型用户。所谓典型用户就是和这个产品有关联关系的角色，通常会有直接角色和间接角色。
在餐饮点单系统里，点单肯定会有的角色就是 顾客和点单员（也可能只要顾客就行了）。
点单前和点单后会涉及到的角色，比如 点单后的主厨角色、配菜角色、上菜角色；以及点单之前的迎宾角色等。
这样其实我们能看到，直接的角色就是顾客和点单人，其他人可以被视为间接角色，这样就可以在列角色的时候顺便把他们的重要等级也思考一下了。（当然脑图里可以不体现）。
命名可以使用“我是XX”做假设引入。注意，这个假设在思考过程中很重要。
比如：
这一步的原则是有多少和系统产品有可能有关系的角色都罗列，也许某个角色后续分享下来没有使用场景，那么后续即使空着也无妨。因为这样可以让你的思考更全面。毕竟：做不做先不管，产品得先想到是不是~
第二层 典型场景
这里叫用户行为&场景&骨干故事，都行，随便你怎么叫。它的核心就是描述某个角色在和产品交互时的所有场景的划分。
这里要注意划分的分类必须时单一维度上完全分类，需要确保在这个维度上的所有场景都要有。比如常规的划分方法可以按生命周期、过程时间线等。
回到顾客点单场景，典型用户是顾客，那么如何做全顾客的场景？这时我们就可以考虑吃饭决策的全生命周期了。具体就是：
不饿->饿了->进店->点单->等餐->就餐->结账->离店
作为示例，这里简化了很多决策环节。（比如进店前还有叫外卖等决策的可能）
那么它的典型生命周期全场景就是：
当我不饿的时候当我开始饿的时候当我进店的时候当我点菜的时候当我等菜的时候当我就餐的时候当我结账的时候当我离店之后注意这里的格式时：当我XXXX的时候
当然根据业务情况也可以简化，比如这里我们的产品重心并不是所有场景完全发力，所以就可以根据情况做一下非重点场景的合并调整，如下：
第三层 典型用户任务
这里就到了这个脑图最核心的部分了，用户故事（也可以叫用户任务，随便怎么称呼了）。它的格式就是我希望能够XXX【做某件事情】，因为这样我就能XXX【实现某个目的】。
这里希望能够【做某件事】一定是从角色的口吻描述。
这样梳理会帮助你释放大脑的禁锢，更好的去输出想法。
总之，能让各方理解场景的描述就是好的描述。如下：
这样从头到尾读下来就是：
餐饮系统，我是顾客，当我进店点餐的时候，我希望能够看到这个菜是什么意思，这样我好直观的知道菜怎么样。
这就是一个简单的用户故事描述了。
把所有的角色、场景、任务，都这样罗列之后，我们就获得一个餐饮产品的用户脑图了。以它为蓝本，再加上持续的角色调研、场景调研、头脑风暴，你的产品覆盖会十分完善。对后续的工作也能提供强有力的支撑。
（当然这个例子我就不做更细致的罗列了）
四、最后的一些细节
1. 这应该是谁的用户故事
有时候我们会遇到一些故事场景可能放哪个角色下都可以，这时候应该放到那个角色下面呢？
个人建议无需太教条，不过可以遵循一个简单的原则：去想象一下如果不做这个需求，那个角色的反对声最大。这说明这个用户故事与他关联最大。
2. 那要做到什么深度呢？
这个深度其实可以继续细化到第四层（将用户故事按照功能实现的版本层次继续拆分），可还需要继续做吗？
我建议是跟着你的阶段走，大网大鱼 小网小鱼。找到适合自己的颗粒深度就行了。毕竟它是用来指定你做产品设计的。
3. 接下来做什么呢？
后续可以针对用户故事，继续做功能分类，从场景关联性、角色任务重要等级等等，对应你的产品思路，产品功能的重要等级等，列产品业务框架，开始准备最小版本，进入持续一轮一轮的产品迭代落地了。
总之，找到你最适合的方法，让你的团队能够更好的转起来，就是好的方法。
结束，欢迎各位老板在评论里一起交流。
本文由 @skyknow_小天 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
看到此处说明本文对你还是有帮助的，关于“用户故事脑图 帮你快速理解新产品/新需求”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
