1. 什么是用户故事地图1.1 先从一个让我头疼的需求清单说起前阵子带一个产品项目团队十几号人需求文档倒是写了不少功能点列了一百多个但评审会上每个人理解的东西都不一样。做开发的觉得某个功能很简单可以下周上线做测试的却发现几个需求之间逻辑根本对不上业务方在旁边一直追问那你们到底什么时候能上线——场面一度很难堪。我之所以会去读那本关于用户故事地图的书就是被这种需求越细越乱的体验给逼的。所谓用户故事地图字面意思是把用户的故事像地图一样摊开来看。它不是一张普通的需求列表也不是写满了用户故事卡片的白板而是把这些故事按用户完成一件事的完整过程重新组织起来形成一张从左到右展开的行军路线。这张路线图能把用户是谁、要做什么、分几步做、哪些先做哪些后做看得明明白白。如果你和我一样遇到过这些问题——产品规划方向不清晰、需求评审各说各话、版本范围老是定不下来——那么这个故事地图的方法大概率能救你一把。这篇文章我想把读完这本书最核心的收获也就是用户故事地图到底是什么、它到底有啥用用大白话讲清楚顺便穿插一些我自己项目里的实测体会。1.2 用户故事地图的直观定义先别急着把它想复杂。用户故事地图本质上就是一张二维视图横轴是用户完成某件事的时间顺序和过程步骤纵轴是每个步骤下不同细粒度的用户故事。书里最喜欢用的一个类比是地图和路线的关系。你可以想象自己在一座陌生城市里找一家餐厅。如果手上只有一张列满了街道名称的清单哪怕列出了几百条路名你也找不到方向。但如果你手里有一张地图看到河流在某条街的左边、公园在上方、几条主路怎么交织你不仅能找到餐厅还能规划先去哪再去哪、有没有更近的路。用户故事地图做的就是这样一件事把分散的需求放到一个空间结构里让团队看到远近亲疏和前后顺序。具体来说一张典型的故事地图包含四层内容骨架最上面一层通常是用户的宏观行为或目标比如完成一次购物结算。用户任务骨架下面是用户为了实现目标需要做的一系列具体动作比如确认收货地址选择支付方式。用户故事每个任务下面具体的需求描述通常是我们熟知的As a... I want... So that...格式。发布切片最下方横向切割的一条条发布线用来表达第一批做哪些、第二批做哪些。地图的读法是从左上角开始跟着用户的行动轨迹往右走然后从上往下看一层比一层更细。所谓地图感就是它天然带着空间坐标每个需求的位置都透露着自身的重要性和依赖关系。1.3 地图和列表的根本差别很多人第一次接触故事地图时都会冒出一个疑问这不就是把用户故事贴到白板上吗我原来也这么想直到自己动手摆了一遍才发现差别大了去了。一张普通的需求列表是一维线性的。它天然只能做到两件事排序和分类。你可以按优先级排序按模块分类但某一类需求在一整个用户过程中处于什么位置这个信息是丢失的。举个例子同样是注册登录相关的需求有的发生在用户第一次使用产品时有的发生在用户忘记密码时有的发生在用户修改资料时。放到列表里它们可能都归在账号模块下但在地图上它们会出现在用户旅程的不同位置。正是这个位置感带来了理解上的质变。在地图上团队能直观看到某个功能在完整使用流程中承担什么角色它处在用户最常走的主干道上还是在某条支路上它是所有用户都绕不开的必经之路还是少数人偶尔会走的岔路这种观察在一维列表里几乎不可能产生。读完这本书我才意识到之前项目的需求总在评审时扯皮根子就在于团队脑子里没有一个共同的二维图景大家拿到的是同一份列表脑海中走的却是各自不同的路线。2. 为什么需要用户故事地图2.1 传统需求梳理的三大痛点在讲清楚为什么需要之前先聊聊我自己踩过的坑。这些年做产品需求梳理来来去去就那么几板斧几乎每次都会撞上三个老问题。**第一需求要素天生残缺。**业务方提需求往往是从自己的视角说我要一个XX功能至于用户在什么场景下触发、进入功能之前做了什么、之后又要去哪儿全都语焉不详。需求文档倒是试图把这些补全可是补着补着就变成了自说自话的想象没有人去验证用户是否真的这么走。**第二需求之间缺少关联。**一百个功能点堆在一起就像一百颗散落的珠子没有线串着。数据库里虽然说此需求依赖彼需求但那种依赖关系藏在文档角落评审的时候没人看。开发做完A发现B的设计得返工这种悲剧没少发生。**第三范围和优先级拍脑袋。**每次问业务方这一版先做什么得到的答案往往是都重要、都急。为什么因为没有一张可以指着说话的地图。你说先做购物车再做优惠券怎么证明这个顺序有道理大家就只能讨论到脸红脖子粗。这三个痛点本质上是同一个问题**缺少一个把需求放置到用户真实使用语境里的思考框架。**用户故事地图恰好就是为这个问题而生的。2.2 用户故事地图的解题思路书里有一个词我记得很深把需求故事化。什么意思就是不要一上来就拆功能点而是先把用户用产品的过程讲成一个完整的故事再把故事里的关键节点挖出来。比如你做一个支付产品与其列一大堆支付方式管理订单查询退款处理这类功能条目不如先讲一个故事用户小王周末在家用手机购物选中商品后进入结算页想用信用卡因为能积分输入支付密码完成付款三分钟后收到扣款短信和电子小票。故事讲完团队成员心中的画面就统一了。接下来要做的事无非是把这个故事里的每个环节展开、补充细节、讨论替代方案。用户故事地图把讲故事沉淀成了一套结构化方法。它的解题思路是**先建立全景地图再识别局部故事最后切分行动发布。**全景保证我们不看漏、不看偏局部保证讨论的颗粒度可执行行动保证规划能落地。三者环环相扣恰好解决了传统做法里只见树木不见森林或者只见森林看不见树的毛病。2.3 哪些项目最应该用读这本书的过程中我一直在琢磨故事地图是不是一个万能工具什么项目都能套实践下来我的判断是它有明显的适用边界。最适用的是这些场景全新产品从0到1规划团队对用户和产品都还没形成共识已有产品要做大版本迭代涉及多条业务线、多个模块联动调整传统瀑布项目遗留了大量文档需求想转敏捷却不知道从何下手多人协作且角色齐全的团队产品、设计、开发、测试需要同频沟通。不太适用的场景也有单一页面或单一模块的小改动比如改一个按钮文案、调整一次布局吉他地图杀鸡用牛刀商业模式极其复杂、参与角色非常多的大型平台画出来的地图可能大到没人看得完这时候反而需要用其他工具做拆分。我自己的体会是**当团队对用户怎么使用产品这个基本问题都无法达成共识时故事地图的价值最大。**一旦共识建立后续的迭代规划即使不用地图也能高效运转。3. 用户故事地图具体有什么用3.1 让所有人对产品全貌达成一致用了一个多月故事地图之后我最明显的感受是团队开会时终于开始对着同一张图说话了。以前评审需求大家心里各有一张不同的产品长什么样的图像你说东他说西吵一晚上才发现两个人说的其实是同一个功能或者根本不是同一个功能。有了地图桌面上展开一张共同的产品全景图任何讨论都可以落到图上具体某个位置。观点不同没关系指出来哪里不同对着图争论效率高了一倍不止。这个作用听起来很虚实际上是最核心的价值。书里有句话大意是需求文档最大的问题是大家都读过但读出来的东西不一样。而故事地图通过构造一个共享的物理空间把不可言说变成了肉眼可见。尤其对非技术背景的业务方来说让他在文字文档里想象系统交互太难了但让他看着地图说用户走完这一步之后应该到哪一步就简单得多。我做过一次对比同一条需求用传统文档评审业务方来来回回补充了三次细节才说明白用故事地图过一遍十分钟就走完了整个流程业务方甚至主动指出了两个我们压根没考虑到的环节。这就是全景视图的力量。3.2 需求盲区和依赖关系无处遁形地图的第二个直观好处是需求盲区会自己跳出来。当你把用户的完整旅程从第一步排到第十步发现第七步到第八步之间空了一大块或者某个环节下面一个故事都没有不需要任何人提醒你自然就会问一句这里是用户要放弃了吗还是我们漏设计了这种对完整性的事后检查在需求列表里几乎没法做因为你根本不知道缺了什么。依赖关系也是同理。地图把故事按用户过程的顺序排好之后要先有A才能有B这种依赖关系会天然浮现。我参与的一个项目里用户流程是选择模板-修改内容-导出海报地图摆出来之后开发一眼就看出修改内容里有一个字体设置功能依赖后台素材库的建设进度两个故事之间存在强耦合。这个依赖在需求文档里写了但埋得太深要不是地图把流程排在一起根本不会有人意识到它会卡住发布节奏。更妙的是地图还能暴露隐藏用户。有一次我们在梳理地图时发现正常流程右下角的运营人员配置活动分支下居然衍生出了一整条后台操作的路径团队有人拍脑袋说了一句这个运营流程要不要做得问运营。真要按老办法走这个需求可能要到开发中期才会被偶然想起来到时候启动排查就晚了。故事地图强迫我们站在用户角度走完全程每个环节都问这里还有谁——盲区就是这样被一个一个扫掉的。3.3 版本切分从拍脑袋变成有依据参与过版本规划的人都懂那种什么都想做、什么都塞不下的拉扯。书里提出的办法让我眼前一亮不要从功能列表里按优先级挑故事而是直接在地图上横向切一刀。什么意思呢地图最上方是完整的用户过程你第一刀切下来只保留能让用户走通一条最小可行路径的故事这就是第一个版本。第二刀保留更多的分支和优化点这就是第二个版本。切分的过程不是从100个故事里选前50个而是沿着用户旅程先把主干道修通再逐步拓宽。两种做法看着差不多思考逻辑完全不同前者是做哪些功能后者是用户最早能用产品做什么事。我们团队用这个思路重新规划了一个两个月的版本计划。原先计划把所有核心功能塞进第一个月所有人累死不说还天天担心延期。地图切分之后第一个版本只覆盖了主线流程约六成的故事但用户已经能完整走通注册-配置-导出的最短路径足够用来做小范围用户验证。第二版本再补齐模板推荐、数据分析这类锦上添花的东西。整个规划过程只花了一个下午且没人有异议因为切分依据摆在那里比任何争论都有说服力。3.4 一张图贯穿产品全生命周期读到后面我发现故事地图的真正威力不在于画一次图而在于它可以一直用下去。它是动态的、活着的。新需求来了不是贴到某个列表里而是先想一想它放在用户旅程的哪个位置放进去之后整条路径走起来顺不顺版本发布之后地图也不需要丢掉它反而成了下一次回顾的基础。我们团队现在每次迭代复盘都会把故事地图打开指着某个分支说这块做得不对用户到这儿就流失了比对着数据图表空谈直观得多。地图还能在新人入职时当培训教材用。一次新来的前端同学花了半小时把故事地图从头走了一遍立刻理解了产品的整体逻辑比读两小时需求文档有效得多。这让我越来越觉得故事地图与其说是一张图不如说是一种团队的通用语言产品演进的时间越久这张地图沉淀的信息就越值钱。4. 实操亲手搭一张用户故事地图4.1 准备素材和参与者理论说了这么多接下来聊聊怎么落地。我第一次画地图时走了不少弯路比如找错了人、准备不足、颗粒度失控都遇到过。下面这套步骤是我自己调整过几轮之后的版本你照着走基本能顺畅上手。首先直奔主题地邀请对用户和业务最熟悉的人来参与。产品经理、设计师、核心开发、业务方这四类人最好都到场。别拉一堆职责相仿的人凑数那样讨论起来全是同一个视角。我在一次工作坊里只拉了产品组的六个人结果画到用户注册环节大家大眼瞪小眼谁都不知道现在前端到底采集哪些信息最后还是把开发拉进来才解决。血的教训。其次准备足够的卡片和黄签以及一面足够大的白板或墙壁。别用什么在线表格凑合物理空间上手写、移动、圈画的感觉和拖拽鼠标完全不一样。团队成员能够亲手摆放卡片那种参与感和记忆深刻度是工具替代不了的。最后约定一个粗略的主题范围。比如这次我们梳理新版购物车流程或者梳理用户首次注册到完成第一单的完整过程。范围太大比如梳理整个公司的产品线地图会大到失控范围太小比如只梳理结算按钮,又浪费了一次工作坊。4.2 按用户活动搭骨架准备工作做完进入正题。第一步是搭骨架——在墙壁最上方横向排开用户的宏观行为。这里要拿捏一个度。宏观行为的粒度最好是用户做这件事时不会中途想干别的事的程度。还是拿在线购物举例骨架可以是寻找商品→加入购物车→结算→支付→收货→评价。每个骨架行为之间是顺序关系连起来就是用户完成一次购物的完整故事线。搭骨架的时候要注意不要一开始就细化到具体操作。寻找商品是骨架输入关键词搜索是任务点击搜索按钮看到结果列表是故事。三者级顺序不能乱。假如一上来就摆出输入关键词团队的目光就会被吸引到具体实现上很难再退回来思考整体流程——这是我和团队踩过的坑请务必避免。4.3 逐层拆解用户任务骨架搭好接下来在每一条骨架行为下面竖着拆用户任务。所谓用户任务是用户在完成骨架行为过程中需要做的事。以结算为例下面可能跟着核对商品清单填写收货地址选择配送方式填写优惠码提交订单等一串任务。拆解任务时有一个好用的技巧想象你在给一个从没用过产品的人打电话一步步指导他完成任务。你现在要做什么——对点那个去结算按钮。然后呢——填写地址。每个环节你让对方做的事就是一个用户任务。这个环节也是团队讨论最多的地方。不要怕争论争论本身就说明大家对用户的理解不一致这正是故事地图要解决的问题。有人在争结算时到底要不要让用户先登录时不要打断让所有人把自己的观点写到卡片上贴上去。有了视觉化的承载争论会自然从我觉得变成你看如果这样排流程会多一步我们就得多写一步故事。4.4 讲故事走查所有用户任务摆上墙之后地图的骨架任务两层结构已经出来了。此时不要急着往下拆用户故事先做一次讲故事走查找一个人从地图最左边开始用手指着每一张卡片把用户使用产品的过程从头到尾讲一遍。这个环节极其神奇几乎每次都能发现流程断点。有一次我们走查的是后台订单处理流程讲到客服查看退款申请这一格时讲的人卡住了因为卡片上写着客服审核退款但他想不起来申请从哪里来、用户在App上做了哪些操作才会触发这条任务。这一停顿大家立刻意识到少了一张前台的提交退款申请卡片。走查时要注意讲的人最好不是产品经理让开发或者业务方来讲。因为产品经理脑子里已经有了完整的幻想图景他会不自觉地绕过那些没说清楚的地方一个陌生视角反而会暴露问题。走查发现的问题不要当场展开讨论先记录等这一轮讲完再统一消化。4.5 切分发布线走查结束流程通畅了再往下拆用户故事就不容易跑偏。这时候团队可以批量把每个任务拆成具体的用户故事。作为用户我想在地址栏看到上次使用的地址这样结算更快——这种格式的卡片是地图上最底层的元素。故事不必追求一步到位全部写完先写能想到的、重要的后续补充才是常态。完成故事填充之后地图下方便可以做最重要的一步——切分发布线。切发布线的时候别按功能模块来切要按用户能不能走通一段连贯的旅程来切。我常用的判断标准是切出来的第一个版本用户能不能在一个核心场景里从头走到尾哪怕体验糙一点、环节简单一点只要路径是通的就可以作为一个可发布的MVP。第二版第三版以此类推每次切分都能明显看出用户价值的增量。这条横向的发布线就是给团队踩刹车的工具别贪多这一期先把这条线以上的故事做完。5. 避坑指南与常见误区5.1 误区一把故事地图画成了任务墙这是新手最容易犯的错误。看见白板上密密麻麻贴满了卡片就以为故事地图大功告成了。严格来说任务墙和故事地图有本质区别任务墙体现的是任务状态待办、进行中、已完成故事地图体现的是用户旅程位置。前者回答这事做完了没后者回答这个活动在用户完整过程里处于什么位置。如果地图上每张卡片都规规矩矩贴在对应位置但位置之间没有任何用户流程的逻辑关系那它仍然只是一面加了标题的任务墙。一个检验方法给团队一个没看过产品的成员让他看着地图讲一遍用户怎么用我们的产品。如果他讲得出来这就是地图如果只能说出这边是待办的那边是已完成的那你画的不是地图是看板。5.2 误区二故事细到开发直接写代码有的团队一听把用户故事拆细就恨不得把每个按钮、每个接口都写上去。图书里强调过地图上的故事应该保持可讨论的颗粒度而不是可交付的颗粒度。为什么因为地图的使命是帮助团队看清全景和关联不是替代任务管理系统。如果一个需求被拆到点击登录按钮调用接口A那地图上只会堆满噪声真正的用户流程反而看不清。我的经验是地图上的故事以一个正常人能在一分钟内说清楚它的价值为上限。更细的拆分留给进入迭代后的任务看板去处理。5.3 误区三画完一次就束之高阁有人把画故事地图当一次性活动工作坊开完照个相地图就挂墙上吃灰了。这等于白画。故事地图应该跟着产品演进持续更新。每个迭代结束时花十几分钟看看地图上哪些卡片做了、哪些挪了、哪些撕掉了。新需求进来先问一句它应该挂在地图哪个位置而不是扔给产品经理随便归档。只有持续维护地图才真正能履行沟通语言的职责。我在一个项目里试过每两周把团队聚到地图前回顾一次结果发现每个人对产品的理解都在肉眼可见地变深连测试同学写用例都能顺着地图流程逐条梳理不重不漏。这种用起来的地图才是活的工具。5.4 我的几条实践心得最后分享几条我反复试错之后总结出来的心得希望能帮你少走弯路。**第一别追求一次到位。**第一版故事地图必然粗糙必然会缺好多故事。没关系地图的价值在框架不在数量。我有一次带着团队用一个下午画了张框架图之后连续一周每天往里补卡片到发布前地图已经和初始版本完全不同了。这个活的状态才是正常的。**第二用物理白板和卡片别用在线工具代替。**至少第一轮工作坊要在线下做。手写、撕贴、移动、覆盖这些动作会加深参与感和记忆。在线工具适合在后期做记录和远程同步不推荐直接拿来做主战场。**第三请一个不懂业务的人来走查。**每次走查我都会拉上团队里某个对业务还不熟的新人让他试着照着地图讲一遍用户流程。他磕磕绊绊的地方就是团队认知模糊的地方他能流畅讲下来的地方说明这块共识已经足够坚固。这个方法我屡试不爽。**第四地图和用户故事是两个层级的工具别混着用。**地图管全局用户故事管局部。团队开会聊版本规划、流程优化看地图单个功能的开发任务拆分看用户故事和任务卡。两者配合使用才能发挥最大威力。只盯着地图会流于空谈只盯着故事会迷失方向。说实话读完那本关于用户故事地图的书又在自己项目里折腾了几轮之后我对需求梳理这事有了新的判断。以前我觉得好的需求管理就是把文档写得再细一点、流程管得再严一点现在我认为比文档和流程都重要的是让所有人在同一个空间图景里思考问题。用户故事地图提供的不是一张图而是一种把用户放在一切讨论中心的思维方式。每次大家围着地图争论某个卡片放左边还是右边我都会觉得这种争论本身就是产品正在变好的证明。