用用户故事地图高效进行需求组织和迭代规划

　　用户故事地图以直观易变的方式进行项目的良好沟通，大多数人看重的是地图的形式部分，横向是讲述大故事的部分，纵向是逐步的细化。但是最关键的是产品的构思框架，让团队成员对想要做出的产品一目了然，大大提高了团队之间相互协作的默契度。
　　在公司推行敏捷开发的过程中，产品常常抱怨每次迭代就向需求池里添加本次迭代的需求，若干次迭代后，需求池便变得零碎而混乱，产品面临既无法理清各个需求间的逻辑关系，也很难清楚的知道每个用户故事被开发的程度。中间尝试过使用需求分类来将需求按功能模块归类，但效果欠佳。
　　反思后，认为问题出在：
　　由于是产品开发一段时间后才引入敏捷方法，因此前期需求并没有在需求池中体现。
　　一开始推行敏捷方式时，仅比较好的落地了scrum的组织流程，对于如何用用户故事来组织需求没有落实好，因此需求并非端到端的，既有大的功能模块，也有很小的UI调整。
　　由于产品比较复杂，要一边开发一边探索需求，并没有一个一开始就想清楚的功能架构，于是常常陷入功能细节而忽略了整体。
　　为了解决上述问题，我了解到用户故事地图这一方法，并进行了一点研究。下面是对这个方法论的一个梳理，附带一些帮助组织和思考的小工具。
　　用户故事地图已经成为敏捷需求规划中的一个流行方法。用户故事地图可以将你的backlog变成一张二维地图，而不是传统的简单列表，用户故事地图可以解决以下问题：
　　只见树木不见林，重要的待办项容易淹没在各种细节中看不到全貌，因而难以排列优先级：
　　不能明显地聚焦于用户需求；
　　很难了解不同粒度故事（史诗故事、主题故事以及故事）之间的关系；
　　不能方便地了解系统提供的功能的完整性；
　　不能方便地了解系统提供的工作流以及价值流；
　　不能方便地利用递增和迭代的方式去确定发布计划以及发布目标。
　　用户故事地图概览
　　一般来说用户会按照从左到右的顺序来使用你的系统（用户故事地图）
　　橘色便签表示用户行为（useractivies），由一群相似的人在相似时间完成的任务组成，旨在达到特定的目标。当你阅读整个地图顶部的活动时会发现，这些活动组成了一条叙事主线。
　　蓝色便签表示用户任务（usertasks），是描述人们做什么事情的动词短语，用以表示用户如何使用软件来达成他们的目标。按照从左到右的顺序组织卡片的摆放形式，先发生的任务在左，后发生的在右。
　　黄色便签表示用户故事（userstories），黄色便签在每个用户任务下自上而下排列，便于我们确定优先级。
　　最后，正如我们上文所言，为了缩短项目周期，我们要在用户故事地图上进行MVP的内容筛选，把最重要的内容放在前面。横向移动用户目标，纵向移动深挖出的细节，然后用胶带或其它工具做出分隔，以此划分不同版本。
　　小结
　　用户故事地图以直观易变的方式进行项目的良好沟通，大多数人看重的是地图的形式部分，横向是讲述大故事的部分，纵向是逐步的细化。
　　但是最关键的是产品的构思框架，让团队成员对想要做出的产品一目了然，大大提高了团队之间相互协作的默契度。
　　要注意的一点就是，功能的开拓要适度，否则这幅用户地图永远都画不完。
　　怎么做？
　　在支持项目的过程中，初期会选择采用故事编写工作坊的形式来梳理产品的用户故事地图。
　　准备工作
　　一个相对不被打扰的空间
　　一块白板
　　35个人左右的讨论组（产品、业务、交互设计、运营等，注意人数不宜过少和过多，因为更少的人意味着你无法获得足够的建议，而更多人则会因为讨论和协调降低会议效率。）
　　便利贴若干（最好有不同颜色）
　　这个会议，就是让所有参与者一起用便签，一张一个动作，从左至右按照时间线，描绘用户在产品使用场景下所发生的所有用户行为。
　　重要流程分成四个步骤：产品定义刻画用户画像梳理骨干故事深挖细节划分发布计划。
　　下面简要介绍下这四步分别需要做哪些事情。
　　第一步：产品定义
　　一般是在故事编写工作坊准备阶段，首先由PO主导产出，聚焦于具象化产品的机会：
　　这个大想法到底是什么？
　　客户是谁？我们认为哪些公司会采购这款产品？
　　用户是谁？采购这款产品的公司中，哪些人会用到该产品，他们会用他来解决什么问题？
　　购买和使用的动机？解决了哪些客户和用户当前无法解决的问题？使用之后能获得什么样的收益？
　　为什么要开发这款产品？如果开发出来并获得了成功，我们的公司又会得到哪些收益？
　　将这些内容记录在黑板上，与大家讨论达成共识，最终确定产品定义。
　　可以从产品图景练习开始，采用电梯测试或者封面故事的形式，团队描述一下一年之后在杂志上看到自己的产品介绍是怎样的。这可以帮助我们识别团队对产品方向是否有一致的理解，或者团队是否需要作进一步的研究（比如进一步的用户访谈和原型测试等）。
　　简单来说，需要明确我们为什么要做这个？以及用户为什么要用这个？明确业务诉求和用户诉求为之后的设计提供了指导，不仅可以在接下来讨论的过程中不易迷失方向，还可以避免陷入设计细节的纠结。
　　第二步：刻画用户画像
　　下面针对优先级最高的目标开始讨论，开始头脑风暴：
　　产品面向的主要用户群是那些？
　　产品的潜在用户群有哪些？
　　谁会为我们的产品付钱？
　　基于这些问题，罗列不同类型的用户，讨论他们能从中得到什么好处，使用的动机，需要的功能等。
　　精炼出若干类用户，制成用户画像卡片，卡片上的内容不用很详细，可以描述出基本特征即可，给每个类型的人群起一个人的名字，张三李四随意，目的是方便日后讨论，以后这个名字就代表这一类人群，再对每个用户做一下简单的诉求描述。
　　最后，把这些写着用户类型的卡片，按照优先级排好，重要的用户放在上面，贴在白板上。
　　第三步：梳理骨干故事
　　从最重要的用户类型下手，这里依然使用头脑风暴，按照时间顺序挖掘，描述这个人在一天中如何使用产品的情景，首先他会怎样，然后怎样，然后这些故事可以比较概括，如用户注册或修改日程，团队中安排专门的人负责记录把每一件事都写到一张便利贴中，按照时间顺序从左到右排好便利贴。
　　当有遗漏的故事被挖掘出来时，可以随时调整卡片顺序。在这个过程中，做到了团队成员对所要做的东西达成了一致，产品创意精彩的细节部分被所有人所消化。
　　为了方便大家理解，在这里举一个大家生活都会发生的例子。故事的整个范围：起点是起床终点是到达公司。闭上眼睛，回想一下今天早上起床的过程。把这段故事分成这样几个阶段，起床洗漱穿衣出门上班途中到达公司。
　　在真实做项目过程中，大家在这一步可能会写出不同颗粒度的故事，需要设计师把控故事的大小，这段故事可以再往下梳理一层颗粒度更小一点的故事。比如起床就可以再拆分为：闹铃响了挣扎关闹钟下床。剩下的故事卡片都可以继续这样拆分归类。
　　这样我们骨干故事就有两层：一级故事和二级故事，故事的发生从左至右是一个叙事流。
　　注意点：
　　我们在第一步确定产品整体范围之内尽量的把故事讲完整，比如我们这个例子，起床洗漱穿衣出门上班途中到达公司。这样我们项目组的所有人就可以对整个产品有个全局的印象。
　　我们需要注意是要讲完整的故事，但是一定要广度优先，而非深度，要做到一公里宽一厘米深。比如刷牙这个故事里面，找牙刷、挤牙膏这类故事在这个阶段我们无须关注，不要过早的沉浸到细节中。在这步让大家做到对产品只见森林不见树木的状态。
　　在真实业务中，故事的流程不可能是一帆风顺的，情况会变得复杂，我们可以借助流程图的图例线连接我们的故事卡片。
　　每张卡片上写的都是动词短语，描述的是特定类型用户的行为。这样写可以帮助我们把故事讲得更好。比如一个上班族要起床，为此首先闹铃响了，然后他开始挣扎，然后关闹钟，然后下床。使用然后连接每张卡片上所写的内容时，就是在讲一个好故事。
　　第四步：深挖细节
　　在完成上面的大故事后，用户故事地图的框架已经结束，下面要做的是深挖细节。
　　在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。如果二级故事是一个海平面的话，那二级故事以上就是海平面故事，那现在我们需要关注的是海平面以下更多不可见的故事。
　　一个海平面级别的任务，是指我们会连贯完成的任务，通常在完成之后才去做其他事情。比如洗操，就是一个海平面级别的任务，因为你不会在洗到一半的时候就转去打扫浴室。类似的任务洗操可以分解成很多小的子任务，如调节水温、洗头发，还会涉及诸如用丝瓜瓢搓操去死皮之类的事情。
　　请记住，人与人不同，你可以从他们做任务的方式中看出这种行为差异。可以用鱼来表述这个级别的任务，因为它们在海平面之下。
　　项目组会围绕这个故事写出很多细节来。我们可以按照以下几个维度对细节进行归类，分别是：故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得，也可以通过用户想法、用户的痛点结合主观判断。
　　在这个过程中，先让大家在一定时间内按照自己的想法写出来，每一条写在一张卡片上，做到相互不干扰，然后每个人出声说出自己的卡片内容，让所有人了解并贴在墙上。
　　项目组人在写想法的时候，相当于脑暴的过程，这时可以通过一些问题来刺激大家脑暴出更多的内容，比如：
　　用户在这步具体要做什么？
　　用户在这一步还有其他选择么？
　　用户怎么做才能更爽？
　　出现问题如何处理？
　　其他用户来到这里该如何处理？
　　回到我们的例子，我们洗澡的时候有正常的流程，但当没有热水时这个流程就会发生变化。同样，在真实业务当中，这类情况将更普遍的发生，所以这一步我们将尽量多的关注到所有场景的故事。写下用户会做什么事情，并把它们添加到地图中。
　　细节、替代、变化和异常，做完这步，我们已经获取到了足够多的细节信息，整个项目组都会做到对产品又见森林又见树木的状态。
　　但同时，这里我们的故事已经变得很丰满，甚至变得臃肿，所以沟通确认变得极为重要。我们在这步需要花费相对多的时间，大家对内容进行对标、充足讨论，把公认的留下来，无用的剔除掉。
　　依次类推，当所有故事梳理完成之后，就完成了如下这样一张完整的用户故事地图了。
　　当全景图出现的时候，你再来合并掉同时的、无关的，你会看到在路线的关键节点上，哪些用户体验非常重要。从用户故事图景出发，来看自己的产品，会有一种豁然开朗的全局感。
　　注意点：
　　为了把故事讲得更好，使用的仍然是动词短语。
　　讲述故事时，你会发现有各种不同的方式来讲述。既可以讲普通的一天故事，也可以讲美妙的一天故事，还可以加上一两个紧急事件来讲一个忙乱的一天故事，在整个讲故事的过程中，通过指向正在发生的任务的便签，按照从左至右的顺序一个一个地讲。尝试使用连词使讲故事的过程更加顺畅。你可能会说：通常这样做，但有时这样做或先做这个，然后做这个，最后做这个。
　　同一时间发生的，就写在同一位置的下方。出现同一场景不同可能的动作时，可能会形成不同的分支动作，直到重回主线或者结束支线。
　　这是一个自下而上的、不给自己建立任何预先假设的方法。它让你忘记自己曾经把某个行为判定为必需还是非必需。
　　让大家将桌面上所有的便签进行分组，将类似的任务分为一组。如果发现重复的内容，就略过。
　　针对一个庞大的系统，叙事主线可能贯穿于好几个不同的用户和系统中。可以在主干上方贴上便签或简单的用户画像，以便在讲述故事的同时看到我们到底在讲述谁的故事。当然，也可以对后台服务或者复杂系统做拟人化处理，把它们视为一个特定的用户角色。
　　第五步：划分发布计划
　　故事地图完成后，我们会发现，地图涵盖了多个用户故事和叙事主线，包含了项目人员所有的愿景，但是它太庞大了，如果同时研发这些功能点，项目日期几乎看不到头。
　　这时候需要问：要达到XXX效果，我们需要用到所有的功能码？也就是说，我们需要聚焦于系统外的预期成果来决定系统内需要什么功能，区分要做的故事细节的优先级。
　　比如写一张在几分钟内出门的卡片，贴在故事地图左边靠近顶部的位置。现在，想象有一条线从左到右划分整张故事地图，有点像一条彩带。然后，把几分钟内出门不需要做的卡片全部移到这条切分钱的下方。不要移动活动卡片，即使该活动下方没有任何任务卡片。没有任务卡片的活动卡片，提醒我们今天早晨不需要达成这个目标。
　　可以通过思考将不同的目标挂在左侧尝试这一招。就像过一个最豪华的早晨或两周长假出行前的早晨会发现叙事主线在这个过程中表现出相当好的延续性，只需要通过添加或删除任务，就可以帮助你达成不同的目标。
　　首先，我们要聚焦于最首要的一个目标成果，即进行MVP的内容筛选识，别出第一个发布要包含哪些内容，把最重要的内容放在前面。
　　其次，我们水平划分用户故事地图上的便签，在划分的每一个发布的左边贴上便签，上面写上少量文字描述预期能产生的成果。
　　再次，在各个发布之间移动卡片，尽可能匹配各个发布的成果预期。
　　最终，团队得出一个增量发布策略，可用于管理更新整个内容管理系统所渺及的工作，增量发布策略也使得团队能够在每一次发布之后得到实实在在的收益。在整个地图的左侧，是发布的名称列表，这些名称标识着目标成果。这就是发布路线图。
　　聚焦于特定的目标成果，这是排定开发工作优先级的秘密。
　　这样，自上而下，我们可以划分出不同的R同时因为每个Release都是和时间线平行的，确保了在放入Release的过程中必须考虑故事的完整性。现在如果我们专注于从左到右完成第一行的黄色便签，我们就可以确保很快发布一款包含了最最基本功能的系统。
　　这样我们就可以验证我们的系统整体架构可行。同时也可以帮助我们对系统的功能进行端到端的测试，确保我们可以从用户处获取到反馈，知道我们是否解决了它们的问题（提供了商业价值）。
　　随着软件的不断迭代，用户故事地图也会不断向下推移。此时，我们就完成了这个产品的发布路线图。
　　注意点：
　　聚焦于成果，即发布后用户能使用和感知的东西，切分发布计划应该以成果为导向。
　　为成果排列优先级，而非功能。
　　地图的深度包含变化性和替代性的任务。
　　小结
　　首先，我们需要对大家写的所有卡片进行对标，排除无效故事。
　　其次，因为我们一般项目时间不够，开发资源紧张，不可能一口吃个胖子，所以把要做的事情达成共识排出优先级变得尤为重要。
　　最后，并不是所有的故事卡片都需要在同一时间细化，在真实业务中有些模块的故事是无法一开始就梳理清楚的，所以可以先写个占位符，待合适的时机再做拆分。
　　我们通过这种一目了然、格式一致的故事地图，让项目组所有人都获得足够的信息，让项目有一个明朗的开发流程。
　　上图中，橙色的卡片代表的是粗粒度的用户故事，可以理解为Epic史诗故事，JeffPatton称之为用户的活动（UserActivity），这些用户的活动代表了产品的骨架，我们从左到右按照时间线来排列这些活动，排列好之后，系统的主要的业务流程就呈现出来了。
　　需要注意的是，为了找出这些用户活动，第一步要做的是做角色建模，把用户角色先提炼出来。在每个史诗故事下面，我们可以拆分出更细粒度的用户故事。这些用户故事加在一起就构成了产品需要做的主要功能，并且已经按照系统骨架组织好了。
　　在横向的纬度，我们使用橙色的虚线把这些卡片横切成了3个泳道，每个泳道代表一个发布。所以，从这个故事地图上看，横向代表的是系统的骨架，脉络，纵向代表的是重要性，优先级，发布顺序。
　　我们需要根据用户的价值来思考在这个业务流程上，哪些是最核心、最重要的，我们可以按照提炼MVP（最小可行产品）的思路把核心场景找出来，放到前面的发布中，把低优先级的放到后面的发布中。这样做的目的是做价值驱动，让我们从用户的视角产品核心价值，并且持续地、增量地交付。
　　总结
　　故事地图六步法：
　　厘清问题。用户是谁，带来什么价值？
　　构建全景图。广度优先、而非深度。一公里宽一厘米深。尝试用故事地图描述所有内容，包括用户的痛苦和喜悦。
　　探索。向深度拓展，讨论其他类型的用户，这些人又要做什么，哪些环节会出问题。使用画像、原型和实验不断优化解决思路，尽量改变和完善故事地图。
　　制定发布策略。请记住一点：要开发的东西总是太多。聚焦于业务目标的达成和目标用户，果断砍掉无助于取悦用户和帮助公司达成目标最小方案的东西。
　　制定学习策略。你可能已经识别出最小可行产品方案，但是请记住，在经过实际验证之前，这些都是假设。使用故事地图和讨论，帮助自己发现有哪些最大的风险。为用户群的子集切分更小的MVP实验，不断学习真正对用户有价值的东西。
　　制定开发策略。在去掉所有不必要的东西之后，留下的就需要投入开发。根据实现的先后顺序、将最小可行方案进一步切分，早期要聚焦于关键技术问题和开发风险。
　　用捕鱼的比喻来理解：
　　我想强调一点，在复杂产品中，不要试图在项目开始就做一套保罗万象的决策。相反，故事是一直伴随着产品生产周期的，我们要把各个决策分散到项目过程中。为此我们要确保一个获取信息的过程方法，这就是一个良性的用户故事地图。
　　这里再做一个比喻，良性用户故事地图像一个捕鱼的过程。
　　首先，不同大小的网用来捕获不同大小的故事，第一遍我们可以用大网眼的渔网捞一遍故事池，以此得到所有大故事。通过大故事，形成对产品的整体感觉，接下来用网眼稍微小一些的渔网得到中等大小的故事，暂时还不用顾及那些小需求。最后才是最小的需求。
　　其次，捕鱼表达了另外一层含义，故事会像捕鱼一样，随着时间的推移会成长，会有新出生的鱼，也可能会死亡。有些需求在某一阶段不重要，但会像鱼一样成长，随着产品阶段的不同变的越来越重要，有些需求我们曾经认为很重要，但是会随着产品阶段不同逐渐变的重要性会降低，有时甚至降低到我们任务这些需求已经无效。
　　最后，正如捕鱼一样，不可能捕捉到这个区域所有的鱼，我们也不可能捕捉到所有的需求，另外，在捕鱼的时候也可能捞到一些废弃物和残骸，就是不是故事的故事。
　　从上面的比喻可以看出来，项目前期是不可能正确的捕捉并写出所有的需求所有故事的，用户故事地图这个方法也不可能在单一阶段捕获出所有的用户故事。用户故事不是二维的产物，应该是三维的，需加上时间这个维度，随着时间的推移以及产品不同阶段加入产品新的用户故事。捕捉故事的渔网网眼也会一直变化。
　　参考资料：
　　《用户故事地图》，JeffPatton，清华大学出版社
　　《如何做好用户故事地图？来看蚂蚁金服的实战案例！》
　　《使用Leangoo玩转故事地图》