【标题】：用户故事地图（下）
【字数】：980
1、一个故事
这里我突然想起了网上的一张图片（如配图），客户说出来的故事，每个人的理解都不一样，最终实际上，客户说出来的和真正想要的都不是一致的，客户也会骗人。图片很生动，以前看到的时候，也就猝尔一笑，现在结合《用户故事地图》这本书结合来看，可能也是受到了多么严酷的摧残才会有这样的意境吧。
2、讨论是最好的传递方式，停止对写错完美文档的追求
用户故事之所以叫故事，因为他是要讲而不是要写的。有不少人相信肯定有完美的写文档的方法，如果有人阅读文档后产生了误解，说明错在写文档的人或者是读文档的人。事实上，写的人和读的人都没有错。同样一份文档，阅读的人不同，各自得到的信息也不一样。
所以说，如果我们每个做开发的都能参与到用户故事的讨论当中来，会大大减少研发过程中对需求细节的讨论，从而加快产品的交付效率和质量。
这一点，我个人是比较有体验的。在实际开发中，评审的时候，下面的开发人员会经常问出很多原始的问题，但是每次我都能够比较快速的回答出答案，诀窍可能不是我对业务有多熟悉，我是站在我是一个客户的角度上去构建我自己的用户地图模板，会想，如果我是客户，我会怎么办，我想要什么，我能得到什么。
3、创造计划与用户沟通
文档通常只描述我需要做什么，缺没有说清楚为什么要这么做。我们开发者，要创造机会，去了解用户的使用动机的人保持沟通，总有更多的机会可以更有效的满足用户需求的方法。但若是不去开始这件事，你永远都不会有计划知道这些。现在我们在实行的轮岗机制就是很好的例子，现在可能是半强制，等什么时候，养成习惯了，随时去找到业务去进行更深层次的沟通，一定会有不一样的火花出现。
4、要能够质疑用户所说的内容
用户在口述需求的时候，可能会带有一部分的实际业务场景，但是他们并不会说出全部内容，我们要带着质疑的眼光去看待。甚至说我们在设计好原型之后，用户看到很漂亮的原型，也会很开心说这正是他想要的，但最终产品出来之后，结果可能不一定会很好。客户说的不一定对，我们要借鉴一部分的对话内容，分步写出用户故事主干，用来构建出一个完整的用户地图，才能做成一款客户真正想要的产品。
5、用户故事的模板
作为【一个用户】，我想要【某个产品】，这样我就可以【获得某种利益】。通过用户故事的模板，我们可以强迫团队成员停下来思考清楚几个问题：用户是谁，他们需要什么特性，解决什么问题？
