在谈如何构建全局用户价值视角之前要与大家分享一个二战时期的故事。
二战时期，美国空军为了加强战斗机的保护措施，对参战飞机中弹区域进行了详细统计，结果显示如下图所示。机翼部位中弹最密集，而机舱部位最少中弹。军方决定对飞机机翼进行加固，但一名统计学家站出来反对。他表示真正需要加固的是机舱，因为机舱中弹的飞机大概率无法返航，才导致了这样的统计结果。最终军方采纳了他的意见，战斗机坠毁率果然降低。
这就是所谓的幸存者偏差，能够返航的飞机给了军方误导，真正应该考虑统计的数据应该是所有飞出去的飞机，而不是返航的这部分飞机。
在软件行业也会存在这样的问题，一个系统进行了模块划分之后，大家所关注的都是自己所在团队的内容，往往很难多走一公里，大家所在的边界都太过于清晰从而导致在两个模块之间交互的时候经常容易出问题，大部分的人会从局部的视角看待当前整个系统的问题，认为整个系统存在的就是自己所在的这个模块最重要。那么一个系统如何改善这样的情况呢？
我的建议是构建用户故事地图从全局视角去观察用户价值，然后基于用户价值进行排序，找到其中的mvp（最小可交付产品），基于MVP进行迭代交付，在最短的时间内给客户进行反馈，并且确认当前交付的MVP是否解决了客户的痛点，为客户创造了价值。
那么如何进行价值排序呢？价值排序有很多种方法，最常见的是MoSCoW法则，MoSCoW法则对应的是Must（必须做），Should（应该做），Could（可以做），Would not（不需要做的）。PO针对当前迭代的用户故事使用MoSCoW法则进行排序，在团队时间固定的情况下，就可以针对重要的用户价值优先实现，从而解决用户痛点。如何确认这些用户故事归属到哪一类中，大家可以在划分用户故事的时候先问问，这一迭代的要实现的用户价值是什么，如果这个用户故事不做会不会对当前的用户价值产生影响，A用户故事不做用户价值就无法实现，那么A用户故事就可以划分到Must中去。B用户故事跟A用户故事属于流程衔接关系，没有B用户故事，A用户故事无法实现，那么B就是Should应该要做的，C用户故事与AB用户故事都没有多大的关联，属于其他模块的一些功能优化，这个做了是加分项，但是在当前迭代时间不够的情况下，这个也是可以先舍弃的，这个C用户故事属于Could可以做。最后就是团队定义的不需要做的，这部分就直接先不做。
所以，你们已经做好了构建用户故事地图的计划了吗？
