《用户故事地图》这本书从去年买来就没有翻动过，这周花了点时间匆匆刷了一遍。感觉还是有挺多收获的，所以记录之。

概要

在敏捷软件开发中，大型需求往往需要进行拆分的，拆分后的需求我们称之为“故事 story”，故事的使用使得软件开发项目的过程进一步可视化。

但是暴力的进行需求拆分很容易丢失软件系统的全景图，导致最后得到一堆无法拼接在一起的需求碎片，或者过度陷入需求细节，而忽略了用户诉求的本质。

首先假设现在有这么一个情景：

老板 A：B，C，D 你们仨明天去上海出个差。

员工 B：好的，那我们坐火车去。

员工 C：好的，那我们坐汽车去。

员工 D：好的，那我们坐飞机去。

上面这种情景，员工B，C，D对老板给的同一份出差任务都有自己的交通工具选择。这像极了传统软件开发中，对于同一份（需求）文档，每个人的理解会有或多或少的出入，这就会导致在交付产品的时候，可能会出现功能缺少，功能冗余，功能不正确等等各种各样的问题出现。使用用户故事地图技术目的就是为了达成各方的共识（用户故事之所以流行，就是因为其鼓励在敏捷开发中人与人之间的沟通，而不是只写下故事，当然记录故事也是必不可少的，你可以拍照，视频，文字等方式来记录讨论结果）。

关于 output 和 outcome

在创意“ideas”和发布之间，所有的东西都可以叫做“输出”output，输出就是我们开发出来的东西，在开发过程中，我们可能会关注开发成本，开发速度。然而我们(老板)并不会那么关注输出，我们最关注的是这些输出所产生的“成果”outcome，成果只有在事情完成之后才能看到，但是成果的影响需要一定的时间累加，数量累加才能显现出来。

99% 的公司都是关注成果影响而不是输出的。这对绩效与业务挂钩的研发人员有利也有弊，可能你辛辛苦苦用了各种酷炫的技术加班加点完成了开发，结果这个功能需要经历 n 年时间才能出实际效果，这就非常难受了。还有一种就是你啥也不用做，通过行政手段搞定了业务需求，嘿嘿，这就是躺着把绩效升上去了，舒坦！。虽然成果只有一个度量标准，即软件给用户解决问题的方式带来了什么样的变化，但是，作为有追求的你来说，应该有着更高的理想：“你的软件是否使这个世界变得更好！”（还是先看看这个软件有没有让我挣钱吧）。

只有满足顾客和用户的需要，公司才能实现自己的诉求

大抵是从乔布斯的第一次 iPhone 发布会开始，有了“用户体验”这个词，注重用户体验就是一种关注用户的体现，但是在如今，街角那家连门都没有的黄焖鸡都喊着他们有高质量的“用户体验”，那么凭什么你的用户体验就更好呢？所以仅仅关注用户还是不够的，还要特别关注特定的顾客或者用户群，改善软件。

公司为员工发薪水，员工的目标肯定是帮公司获得更多的收入，保护现有市场，拓展新市场，提高运营效率等。这样就是良性循环，可持续发展的。如果公司不健康，员工没有充分资源可以帮助用户，而公司又没有及时调整该舍弃部分用户，重点关注能产生收益的用户群体，那么就容易很容易造成人员快速流失，软件质量低，用户群体流失等恶性循环。

产品全景图

在刚入职的时候，记得那时还没有使用用户故事地图技术来分析需求，那时应该是比较纯粹的“敏捷开发”，每隔几周就能发一个版本，确实很“敏捷”，就是有种拧螺丝的感觉，知道这种感觉吗？就是那种你知道要这么做，但是却不知道为什么要这么做，你不知道手里做的这个需求对整体项目而言有何具体影响，对用户会带来哪些便利或者收益。

后来用户故事地图在组内流行开了，几乎所有项目都会采用用户故事地图来分析，这样团队的所有成员都能对项目达成一致的理解，同时也能将比较大的用户故事拆分成小故事。

好的用户故事应该讨论什么

• 做什么
• 为谁而做
• 为什么做

所有的软件开发目标从来不是开发出所有功能，而是开发尽可能少的功能（为什么是尽可能少的功能，后续会说明），所以我们就需要明确哪些用户是我们真正关注的，哪些需求是能让利益最大化的。

过用户故事地图的时候需要参与人员做什么?

思考---》记录---》讲解---》摆放

不是所有的故事/需求里只对应一个用户（嗐！刚接触用户故事的时候，天真的以为一个故事对应一个用户来着。）所以在思考阶段，我们通常会把参与的小伙伴分配以故事里的不同用户角色，每个小伙伴都以各自的角色思考在这个故事里“具体要做什么，为什么要做，做这个带来什么影响等”，然后将其记录于小纸片上。在思考完之后，所有小伙伴都要说明一下自己的想法，并将小卡片按故事顺序（时间，权重等方式）贴在玻璃墙上。

当完成了所有故事之后，我们接下来要做的就是对细节进行优化了，比如 老板 A 说去上海出差，那么这里就可以引申出“出差具体要在几点带什么东西去见什么客户完成什么任务？去上海除了海陆空还有什么其它交通方式吗？有没有什么办法不用出差也能完成老板的任务呢？如果出差过程中出现了问题该怎么处理？等”

注意：探索细节是在所有故事框架都已经完成的情况下才做的，千万不要在还在思考单个用户故事的时候就钻牛角尖。（个人的亲身体验告诉你，如果思考单个用户故事阶段就钻牛角尖的话，你的思想可能会进入死循环，更有甚者带领着整个团队剑走偏锋“剑走偏锋”，3分钟的思考，硬生生思考了 30 分钟，到最后还是无解。所以在故事宽度还没完成的时候先放过细节，如果你真的觉得很重要，那也请先把你的想法记录下来，到后面再和所有小伙伴讨论。）

计划，为了更少的开发

你有没有这样的经历，我私心里喜欢称之为“呵呵哒”。

通常的 呵呵哒 经历：有时候 PM 想要开发功能，总是超出你所拥有的“资源池”范围？（“资源池”：时间，人员，技术，精力等等）

如果你也被 呵呵哒 了，那要要怎么做？

跑！（嘿！如果跑不掉，那就把自己当作一个产品经理，把 他/她 教会。真 TMD 的心累，幸运的是我还没遇到这种情况。）

所以如何才能在尽可能避免 呵呵哒 呢？

聚焦于系统外的预期成果来决定系统内需要什么功能。（用户说要一瓶矿泉水来解渴，你别故作聪明的递上满满一盆 99.9 度的开水，还美其名曰“送温暖，送到客户心里”，相信我，用户只会觉得你把这矿泉水都倒进自己脑子里了。）

划分 MVP（最小可行产品） 发布计划

为成果排列优先级，规划好发布路线图。一般情况下第一期都是会以 MVP 发布的，第二期优化一下，第三期锦上添花，等等。

这个 MVP 其实也是比较讲究的，你需要统筹各方需求，寻找一个最小的可用可发布集，难！但是 值！。

为什么第一期一般要以 MVP 发布？

我可以举个不那么友好但是却很生动的例子：如何让一个人快速增重。如果你马上就端来各种甜品，牛，羊，鸡，鸭，鱼，鹅。估计所有人都只吃那么几口就罢了。那么如果我们先上（MVP）分量比较少的甜品，外加品相比较朴素但是味道还可以的肉，相比没有人会拒绝吧。然后第二餐在把品相较好的肉端上来，这一餐也没有人能拒绝吧。第三餐，摆盘搞起来，前菜上点酸的开胃，正菜辅以烤，煎，炸，辅以各种沙拉。嘿，这么三餐下来，基本上就是量变产生质变了。（所以什么 MVP 是第一期，就是为什么第一餐要这么选甜品和朴素的菜了）

划分 MVP 很重要的一点就是：最小化输出，最大化成果和影响。

该书中还有很多方法论，像大故事如何拆分为更小多故事，如何按时发布等，这里就不再一一总结了，有时候只有通过实践来总结，远比看书总结效果好的多。

当然或许有时间......也不会再进行补充了。