【标题】：鸿沟
【字数】：1111
大多数的时候，我们其实都是错的 -- 来着《用户故事地图》
1、前言，在我眼中的用户故事地图
用户故事地图，看起来这是产品经理才会关注的词语，这是大部分开发人员看到这个标题的第一感觉，我也不例外。在日常的开发工作中，我们好像很少直接去接触到这个定义。更多人的工作内容是，产品说什么，就是什么。在某些人的眼里，产品经理就用户的化身。当开发的产品出现问题了，我们也就可以理所当然的推卸自己的责任，“产品就是这样说的”“我们又没有直接接触到用户”。
看了《用户故事地图》部分内容，当然我还没有看完，200多页呢，这本书更多的是讲述了团队如何沟通，如何协作，最终交付好的产品，书中的语言幽默有趣，特别能引人入胜。
2、鸿沟的形成
一个场景，设计师按照需求原型，开心的在做着页面设计；开发在对着需求文档，吭哧吭哧的写着数据库的数据结构；当两者不得不去进行互相评审的时候发现，双方做的事情根本不在一个频道上。设计决定开发应该要按照设计图来进行编码，开发任务设计师要考虑一些实际的逻辑实现，页面别太花俏。双方讨论再三，很难找到共同的语言，最终的结果是双方互相妥协，勉强做出一个产品。当用户看到实际产品的时候，结果可想而知。
3、那么我们怎么去跨越这种类似的鸿沟？
用户故事地图方法是连接设计和开发的纽带。当然，这里不是特指设计和开发两个角色所定义的，指的是我们参与到产品开发的所有岗位。我们首先要从关键的业务指标出发，观察用户的痛点和分析用户使用中产生的数据，不断尝试新的技术方案解决现实问题。业务目标、业务价值都是关键指标，无时无刻设身处地的站在用户的角度上思考问题，提高自己的格局，才是跨越鸿沟的根本。
4、找到自己对用户地图理解错误的影子
在上一整年的工作中，我们不停的堆砌着新的功能，看起来，菜单超级多的。但是，总会有客户找到我说，为什么系统做了这么久，那么多功能，好像没有什么核心的竞争力，更多的只是帮助到业务做一些数据录入的工作。她们并不喜欢这个系统，但是由于工作需要，不得不用。
说起来好像很残忍，看了用户故事地图这本书，虽然没有说大切大悟，但是至少找到了部分症结所在。我们总以为我们自己所想的就是用户所想，其实大部分时候，我们都是错的，我们只看到表面，只是做了用户说出来的需求，没有做到深度挖掘到这些需求背后代表的信息，然后彻底解决用户的痛点。
用户故事地图可以使我们专注于用户和用户体验，产生更好的沟通效果，最终做出更好的产品。
5、关于作者的好奇
“这本书本来是想做成一本小......小......小册子的，真的”，作者的直白，幽默，和喜欢折腾，充满着新引力，才会让着看是很无趣的话题变得有趣，更加贴近实际，拥有了想继续看下去的欲望，加油，明天继续撸。
