用户故事脑图帮你快速理解新产品新需求

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