用户故事地图是一门在需求拆分过程中保持全景的技术

　　信息共享不等于共识
　　火星气候探测器在1998年12月11日UTC18点45分51秒于佛罗里达州卡纳维拉尔角空军基地17号航天发射复合体发射，运载火箭为德尔塔II7425。发射42分钟后，火星气候探测者号顺利进入霍曼转移轨道。火箭最后的相对速度为每秒5。5公里，并将探测器送往6亿6900万公里外的目标，朝向火星前进。
　　火星气候探测者号在1999年9月23日UTC9点00分46秒开始插入火星轨道，火星气候探测者号的无线电在UTC9时04分52秒（比预期还要早49秒）终止联络，当时探测器已经进入火星的另一侧，但是它与地球通讯从未重新建立。探测器由于人为错误，导致探测器在低于预期的高度接近火星，最终因为大气层的压力来解体。后来的火星侦察轨道器才完成火星气候探测者号的预期目标。
　　根据火星气候轨道器事故调查委员会发布了第一阶段报告，火星气候探测者号任务失败的主要原因是人为因素，因为火星气候探测者号上的飞行系统软件使用英制单位磅力计算推进器动力（由洛克希德马丁公司设计），而地面人员（NASA飞控人员）输入的方向校正量和推进器参数则使用公制单位牛顿，导致探测器进入大气层的高度有误，最终瓦解碎裂。
　　共享的汗牛充栋的文档没有能挽救这个总价3亿2，760万美元的项目。反而《赋能》一书中所提到的早期阿波罗登月项目中，不同子系统的工作人员可以随时的在无线通信网络中听到其他人员正在讨论的话题，并且可以随时插嘴表达自己的想法。要知道人类要达成共识是必须是要有对话的过程的。
　　人类达成共识的过程从万米高空俯视一下用户故事地图
　　高空俯览用户故事地图用户故事之所以叫故事，因为它是要讲出来给人理解的，而不是要写成一个重量级的文档，然后共享给别人去读。建议在使用用户故事地图工具的时候，可以将一个大故事（有的书上称为史诗故事）进行拆分。一边讲一边记录下来，在讲故事的同时，通过写成卡片或便签来具体化你的想法，同时不断地沟通来达成共识。在此过程中建立起来的整个故事地图不光可以给出一个需求的全景展示，也可以提前识别产品创意中的那些坑。但是一定要注意不要过早地陷入到细节当中，尤其是做开发出身的同学特别容易被其中的技术细节所吸引到。始终要把握好整体，就要在抓所有的细节之前先走一遍整个用户故事。大家一定会有这样的经历，Backlog上面永远列着做不完的功能。而想要开发完这些功能，总是要超出你能投入开发的资源。为此故事地图帮助大型组织建立共识，贯穿各个团队的产品发布地图，可以帮助团队以可视化方式展示以来关系。根据故事地图从左到右的主骨架就可以看出用户的使用产品的顺序。而从上到下的故事线上则展示了更多的细节。由此就可以规划出来MVP的范围。而MVP并不是一个真正意义上的产品，而是为了检验假设、想法而实施的一个最小规模的实验。
　　用户故事地图结构对用户故事进行首次讨论，应该从商业机会开始。即问清楚几个问题：我们为什么要做这个产品？我们的用户是谁？他们能从这个产品上有什么获益？类似于《用户体验要素》一书作者在战略层讨论的时候提出的问题一样。在设计原型的过程中进行学习和验证，无论是高保真的交互模型还是粗略的线框图都可以带来同样的效果，只是使用的场景略有不同而已。通过验证得到的数据进一步改进方案并保持迭代。使用迭代思维持续评估和打磨作品。如果是达芬奇老大爷会怎么思考他的画作呢？这个答案想必大家心中是有明白的。
　　达芬奇老大爷的思考1
　　达芬奇老大爷的思考2
　　如果你看到这里，非常感谢您的支持！
　　请关注我，转发点赞，私信我可以得到《用户故事地图》一书14章完整版pdf。