不懂需求分析的开发不是好开发。上周经过一周的紧张准备，在周五做了一次关于需求全景及用户故事地图的分享；期间，快速阅读了Jeff的《用户故事地图》。把上周学到的和分享的内容总结如本文。
需求全景
首先需求全景，从字面意思理解，就是指对需求的完整认识，也是项目中经常提到的whole picture。打个比方，买房子的时候我们在售楼部看到的沙盘，就是那种高空俯瞰全景的感觉。
什么是用户故事地图
那么用户故事地图就是帮我们构建需求全景地图的工具。随着敏捷软件开发的兴起，它带来了很多积极的影响，比如人们开始认同，大型需求是可以拆分为一个个小的用户故事的。但是需求拆分也带来了相应的负面影响，那就是容易造成只见树木不见森林，丢掉需求全景的理解。用户故事地图就是一种在需求拆分过程中仍然保持需求全景图的一种方法。
那么什么是用户故事地图呢？它是一个有方向的图表，以时间线为横轴，以优先级为纵轴，然后会涵盖所有的用户故事，表达需求全景。用户故事地图长这样：
上图中标出了时间线作为横轴，优先级为纵轴，里面是全量的用户故事。我们用卡片表示用户故事，同时我们看到这里有不同的颜色表示不同层级的用户故事：其中上面是主干部分（橙色和蓝色），下面是细分需求的用户故事（黄色）。
通常我们在创建用户故事地图的时候，首先从用户角度来讲用户故事，一边讲一边把其中的重要步骤记录在便签纸上，从左到右排列，这个过程的产出就是图中的主干部分，这个过程中我们需要注意的几个原则，第一是力求把故事讲完整，第二是坚持广度优先，不过度涉及细节。故事讲完之后我们就有了主干部分，这个时候是一种只见森林不见树木的状态。接下来第二步我们就回过头来讨论每个步骤的细节，这个过程中我们会进行头脑风暴，期间会通过一些问题启发思考，比如用户在这一步具体会做些什么，怎样让用户在这一步获得更好的体验，如果出现问题该怎么处理，然后把这些细节在每个步骤下面垂直排列。这样我们就形成了图上这种网格结构，并且达到一种又见森林又见树木的状态。
同时我们可以看到，用户故事地图上还有蓝色的彩带，它表示三次发布计划。也就是说当我们完成了需求细分之后，我们需要进行第三步，通过充分的讨论对细分需求，也就是用户故事排列优先级。并且基于优先级，制定发布计划。这里我们就需要提到MVP的概念。MVP，Minimum Viable Product就是最小化可用产品，这个概念源于精益，他的目的是用最小的投入发布对用户有价值的产品，来帮助我们快速获得反馈，快速试错，并且不断迭代找到产品的正确方向。针对MVP可以举个例子，比如产品需要登录功能，那么MVP1我们可以只上线最简单的用户名密码登录。然后在后续MVP实现手机验证码登陆；然后再后续的MVP中实现其他比如微信扫码登录等等。
最后我们用一句话概括用户故事地图：用户故事地图是一种识别需求和梳理需求的工具，同时能帮我们建立需求全景图。
通常在项目的起始阶段也就是inception阶段，我们的产品经理，BA，Tech lead连同客户会一起梳理需求并达成共识，这个过程使用的工具和产出就是用户故事地图；那么当项目进入交付阶段，我们会把用户故事地图带到交付团队，以用户故事地图为载体，帮助交付团队理解需求。用户故事地图也是一个很好的沟通平台，比如项目交付中间，客户那边的stakeholder来了，我们可以很方便的展示我们的当前进度，完成了哪些部分，还剩下哪些部分，等等。
用户故事地图的简单示例
这是一个非常简单的取钱的场景。首先我们以时间顺序列出取钱需要经过的步骤：开车去银行，使用ATM，查看账户，取钱，拿到交易凭条，开车去high。或者还有另一种场景，查看账户之后发现自己太穷了，于是取消交易，开车回家。这就是我们说的广度遍历，从用户角度讲出一个完整的故事。
第二步，我们对以上步骤进行细分，比如查看账户的时候，分为几种情况：查看活期账户；查看定期账户和查看交易记录。其中每一个都是一个用户故事，并且按照必要程度自上而下排序。同时再比如取钱，也细分为：用户能够有取现金的选项；用户能够有默认金额选项从而改善用户使用体验；用户能够有无卡取现选项。
在完成第二步的拆分并且划定优先级后，我们可以识别出第一次上线，也就是第一个MVP：包括两个用户故事，用户能够看到活期余额及用户有取现选项，这就是一个基础款的实现。那么后面第二次可以是支持用户更开心更便捷的取钱；第三次是支持用户无卡取钱。需要提及的是，整个过程无论是第一步讲用户故事；第二步细分需求；第三步排列优先级并制定发布计划，都是可协商的过程，没有标准答案。
构建用户故事地图的练习
讲解的时候穿插了一个构建用户故事地图的练习。题目来源于《用户故事地图》这本书，对上班过程（起床为起点，到公司为终点）进行需求梳理和拆分，并划分MVP。
练习没有标准答案，练习过程中首先梳理骨干故事：回想一下起床的过程，分为几个阶段：比如起床，洗漱，穿衣，出门，上班途中，到达公司。如果任务太多，可以通过摘要行的任务来描述一堆任务，即引入任务层级，当我们提取用户故事的主干时，建议用一个不同颜色的便签纸，来涵盖下方任务卡所要表达的意思，即使手边没有不同颜色当便签纸，也可以把便签纸旋转45度变成菱形从而让故事层级更加清晰。使用便签纸而不是直接用笔写在白板上，是因为便签纸可以更方便的移动（体现优先级，顺序等），讨论。
第二步需求拆分过程中，需要进行头脑风暴，期间我们可以用问题启发他人：想一想你今天早上做了什么？是不是还有一些不太顺利的早晨，停水了，没有热水了，忘带手机了，没有挤上地铁。再想一想完美的早上是什么样的？头脑风暴的过程是一个充分发散的过程，这个过程中我们并不需要筛选，想到的都可以列出来，为了充分发挥大家的创造性，这是一个不会否定他人的阶段。同时头脑风暴应该首先关注于主要场景，然后才是次要场景，什么是主要场景，比如对于一个创建试题的步骤，创建试题是主要场景，而编辑试题和删除试题是次要场景。
第三步，对细分需求进行讨论并排列优先级和必要性。经过步骤二的头脑风暴，我们得出的用户故事是丰满的，甚至近乎臃肿，那么此时我们会经过讨论来进行收敛。同时完成了优先级排序，我们就可以制定发布计划，比如mvp1就是我们要迟到了，需要几分钟内出门，我们就拉一条彩带或者画一条彩线，把这种情况下不需要的任务都转移到彩带下方。然后会有其他目标，比如过一个豪华的早晨；两周长假出行前的早晨。
就像前面说过的，构建用户故事地图的过程没有标准答案，有的人可能会列出更多细节，比如做早餐会写成热面包片和热牛奶。有一个来自《用户故事地图》的比喻，用户任务就像石头，如果用锤子敲打，他就会变成小石子。
练习过程中其实会有一些尴尬的点，每个人的任务可能不一样，有的人起床要化妆，有的人起床要锻炼，有的人起床要照顾小朋友，或者遛狗。这里也就引出了用户画像的概念，用户画像就是我们针对不同场景对用户分类，给每类用户建立用户画像。使用用户画像非常大的优点是建立同理心，当你建立起用户画像的时候，就会产生代入感，站在用户的角度思考问题。用户故事地图本身期待用户加入一同梳理需求，也就是所谓的参与性设计，与之相对的经验性设计则着重于前期的客户调研，然后设计师以一己之力完成产品设计。在刻画用户形象时，我们需要讨论哪些客户会使用我们的产品，为我们的产品付钱，罗列各种用户，讨论他们的使用方式，思考他们需要哪些功能。
再次归纳构建用户故事地图的步骤：
通常，我们拿到一个项目时，他的需求文档是这样的：
那么同样的需求我们希望翻译为用户视角：
有了用户视角的需求文档，我们就开始试着构建用户故事地图：
第一步，梳理应用的骨干业务流程
出题人出题，然后老师布置作业，然后学生答题，然后老师批改，最后学生查看成绩，这就是完整的用户故事，这里我们有不同的用户角色。
第二步，准备好核心用户的用户旅程（user journey）
比如出题人出题时首先需要创建题目，然后创建试卷，然后把题目和试卷关联起来。同样老师布置作业的时候，首先创建作业，然后关联作业和试卷，然后选择布置作业的班级。那么学生答案的过程包括首先查看作业，然后答题，最后提交答案。老师改卷的时候需要首先查看学生提交的试卷，然后批改，最后发布成绩。之后学生就可以查看成绩。
第三步，从核心场景出发，头脑风暴支撑每个用户任务的功能需求
比如针对出题人创建题目的用户任务，其核心场景就是创建题目。
第四步，针对其他次要场景，头脑风暴支撑每个用户任务的功能需求
次要场景比如上图的编辑题目和删除题目，所谓次要场景，指的是即使没有这两个功能系统仍然可用，比如我在第一次上线的时候不包括这两个场景，那么产品仍然可用，用户可以暂且通过后台编辑和删除题目。
第五步，头脑风暴每个功能需求的支撑性需求
紫色的部分就是支撑性需求，相对于功能性需求，也成为非功能性需求。支撑性需求指的是一些技术故事，比如邮件服务器的集成。那么之所以把这些支撑性需求在用户故事地图列出来，是为了tech lead和开发团队可以针对性对这些需求提前进行技术预研或者实现，那么当我们的功能性需求涉及到比如和邮件服务器的集成，就可以直接引用预研结果。保证我们的交付进度。这些支撑性需求往往由Tech lead和BA一起列出来。这也是为什么不仅产品经理和BA（Business Analyst）需要学习用户故事地图，开发与测试人员同样需要的原因，因为有一天你也会成为Tech lead呀！：）
以上就是用户故事地图的内容总结了，最后强烈推荐《用户故事地图》一书，作者就是用户故事地图这一工具的提出者，本书从作者亲身经历出发，讲述用户故事地图是如何让需要梳理更加清晰，如何拯救项目于混乱的需求的，同时语言轻快，阅读愉快！