轻松搞定用户故事地图课件

用户故事地图黄河敏捷结构与作用01故事地图产生背景Backlog中的需求该如何产生？用户故事地图就是将story用可视化的方式展现在团队面前，让团队可以仔细梳理、讨论，确认这个story包含的内容，最终产出需求进行开发。用户故事地图是Userstory的前传！故事地图产生背景不是另外一种写需求的方式故事是用来讲的，不是用来写的侧重事件发展过程的描述故事不是忽悠，不是夸大故事地图特点老板团队听众用户故事的听众地图的核心是一条从左到右的时间线通过时间线和卡片进行约束时间线上第一行放置最大粒度的需求，即Epic时间线上第二行放置二级粒度需求，即Theme时间线下自上而下放置三级粒度需求，即Userstory用户故事地图结构Epic1Theme11Userstory111Theme12Userstory121Userstory122Epic2Theme21Userstory211Userstory212Userstory21…Theme22Userstory221Theme23Userstory231Userstory232Epic3Theme31Epic…用户故事地图结构UserTasks（梗概）UserActivities（主干）Epic1Theme11Userstory111Theme12Userstory121Userstory122Epic2Theme21Userstory211Userstory212Userstory21…Theme22Userstory221Theme23Userstory231Userstory232Epic3Theme31Epic…用户故事地图结构TimeRelease1Release2Release和时间线平行，确保在放入Release的过程中考虑故事的完整性。很大的故事存放类似故事的篮子业务角度拆分了解整个产品的全貌。找到整个产品的主干，也就是路径。

促使产生更多用户故事。故事地图作用防止只见树木不见林，更容易看清backlog全貌确保backlog覆盖了最重要的用户体验路径，及当前所规划的场景是否可以为用户提供价值确定发布计划以及发布目标，同时确保早期的发布可以验证整体架构和解决方案可解决的问题需求金字塔需求金字塔金字塔的顶端是需求的目标，也就是解决什么用户或业务问题？金字塔的中间层次是操作和操作流程，为了实现上面目标，系统需要支持哪些用户操作？这些操作的流程是什么样的？金字塔的底层是业务规则，各个操作步骤对应的业务规则是什么样的？需求金字塔MECE原则是麦肯锡方法的核心，在各个层次上都要做到：1）条目之间相互独立（MutuallyExclusive），通俗的讲就是要“分清”各个条目，做到无重叠；2）这些条目作为一个整体要完全穷举（CollectivelyExhaustive），也就是要“分净”，做到无遗漏。这两点合起来就是ME-CE。需求金字塔故事地图步骤02用户故事地图步骤步骤二步骤一步骤四步骤三明确方向骨干故事拆分故事精简故事PO召集3-5人参与故事地图讨论会，讨论以下议题：目标用户，用户目标----用户诉求用户为什么要用这个?能为用户带来什么价值？产品目标，解决什么问题----业务诉求我们为什么要做这个?能为我们带来什么价值？明确方向，防止迷失方向，陷入设计细节的纠结。步骤一：产品定义每个人写下自己认为重要的“所要做的事情”Usertasks（二级需求）。完成后，每个人轮流读出自己的内容，并把便签纸放在桌面上。尽量把故事讲完整，便于对整个产品有全局的印象。做到对产品只见森林不见树木的状态。讲完整的故事，一定要广度优先，而非深度，不要过早沉浸到细节中。步骤二：骨干故事然后，将桌面上所有的便签按类似的任务分为一组。选择另外一个颜色的便签，对每个组命名，作为UserActivities（一级需求）最后，对这些摆放好组的便签进行排序，一般按照用户完成操作的顺序，从左到右摆放如果大家无法决定顺序，那么顺序可能没有那么重要。步骤二：骨干故事步骤三：拆分故事一级需求二级需求三级需求从业务角度，拆分故事，建议分析维度：故事细节、想法、痛点、机会……使用静默头脑风暴方式，把自己的想法写在一张卡片上，相互不干扰，然后每个人大声说出自己的卡片内容，让所有人了解并贴在墙上。这时不必使用用户故事的标准句法（Asa…），因为每张便签都处于地图的特定位置，大家很容易识别其所处的场景和角色。步骤三：拆分故事步骤三：拆分故事大家在写想法的时候，可以通过一些问题来刺激大家脑暴出更多的内容，比如：用户在这步具体做什么?用户还有其他选择么?出现问题如何处理?其他用户来到这里该如何处理?使用之后有什么变化？别的产品怎么做？步骤三：拆分故事这时我们的故事已经变得很臃肿。接下来要对卡片内容讨论，把公认的留下，无用的剔除，同时区分优先级。首先，要对大家写的所有卡片进行对标，排除无效故事。其次，不可能一口吃成胖子，对选定的故事排出优先级。最后，无法梳理清楚的故事卡片，可以先写个占位符。最终，根据排列好的故事优先级，排出迭代计划，并确保我们的第一个发布越小越好，大约在1-2个迭代后可以发布第一个MVP版本。步骤四：精简故事某服装公司需要快速开发一套在线服装销售网站，请讨论完成以下工作：10min：请帮忙输出开发该网站的用户故事地图！5min：请挑出你认为无效的故事，同时补充你认为缺失的故事！案例讨论故事地图价值03故事地图的价值共识参与性设计记录同理心以往我们达成共识的方式有两种：点对点，或者单点对多点，带来信息内容的损耗，甚至错误的信息。共识我以为的其实不是你以为的通过讨论达成一致项目中不同的参与者有不同的关注点，整个项目组就像一个四驱车，一个角色太强势，会导致车子失控。故事地图通过大家一起建立产品全景图的方式，让项目组所有人站在高空俯视产品，达成多点对多点的共识。共识客户SM测试开发PO质量需求进度成本站在用户的频道，说人话！我们在讨论产品需求时，有一个很大问题就是无同理心，面对业务里很多专有名词会很无力，甚至同一项目组不同模块的人都相互不理解对方的专有名词，但又总认为他应该懂。促进理解，建立共识。通过故事地图，我们所有人都可以快速知道用户想要什么，为什么要这个。通过这种简洁明了、场景还原的方式让大家更容易理解同理心经验性设计经验性设计高度依赖前期的用户调研，包括用户访谈和用户观察，但是用户不会成为产品设计的真正参与者，后面的阶段基本是靠设计师经验，几乎没有用户身影。参与性设计用户故事地图易读、易懂，我们边聊故事的同时进行页面框架绘制，因此能激发项目成员的积极性，甚至让客户成为产品设计的参与者。参与性设计随着项目成员渐渐掌握如何口头表达故事来描绘他们的需求，项目组成员间的关系变得更加亲密主动，达成良性互动。参与性设计常见记录方式：文档记录（包括评审记录）、笔记记录或者聊天记录。这些方式大多是单点对单点或多点的，而且记录内容有限。故事地图的每张卡片，记录的不只是卡片上的内容，它记录了大家围绕这张卡片讨论的那个时间段所有的信息，信息量更加庞大。记录我们回头再去看这些卡片的时候，和看照片一样，它会快速唤起我们对那段时间的回忆。记录总结04总结产品定义骨干故事拆分故事沟通确认共识同理心参与性设计记录在复杂产品中，不要试图在项目开始就做一套包罗万象的决策，我们要把各个决策分散到项目过程中，延后决策！故事是一直伴随着产品生命周期的，良性的用户故事地图也是逐渐成长的。总结首先，用大网眼的渔网捞一遍故事池，以此得到所有大故事。通过大故事，形成对产品的整体感觉，接下来用网眼小一些的渔网得到中等大小的故事，最后才是最小的需求。其次，故事会像捕鱼一样，随着时间的推移会成长，会有新出生的鱼，也可能会死亡。另外，不可能也没有必要捕捉到这个区域所有的鱼，我们也不可能捕捉到所有