读书《用户故事地图》

主题：用户故事地图

• 用户故事地图核心在于讲故事，让大家都看到这个故事的全貌，达成共识。

• 任务颗粒度，切分一个完整的任务，一早上起起床为例，洗澡可以是一个单独的任务，因为不会洗澡到一半去扫地。洗澡过程中的洗头，擦沐浴露部分可以细化在洗澡内部，并且顺序可以有一定的调换而不影响全局。

• 大家一起讲故事，相关部门（运营和技术负责）应该更早的参与到项目中，提出各自的观点，即可以发挥各自的作用从不同角度看问题，也可以增强对产品的ownership。而不是老板给了一个项目，运营只能想这个东西怎么卖。

• 讲故事之前需要明确目标用户，即用户画像，这也可以大家一起讨论。

  专业的用研会觉得用户画像需要很多的数据支持，而不是用喇叭喊。如果有用研同事可以一起参与，但这一步和讲故事一样，重点是达成共识。

看起来很正确的部分

• 一些需求需要排优先级的话，从成果出发，哪些更能改变参与用户的行为。
• 传统的模式需求方提需求，实现方砍，这种讨价还价的模式甲方乙方模式最后没有一个赢家。
• MVP不是发布一个拙劣的产品，那样会给用户留下很差的印象。

让人心碎的部分

• Eric做了很多研究以后才意识到我们的方案是靠蒙的（但我们不能说），在真正推到市场检验之前，即使有调研其实也是猜的，这是为什么要用MVP方法，去真正的做实验。
• 我们说MVP测试，既然是测试不意外后面会有优化改变，但对于技术的迭代，修改通常会被任务是一种失败，被认为做决策的人产出了错误的需求导致的。
• 20%的产品上线可能会是灾难，而大多数（60%）的产品上线反应都很平平，我们只是安慰自己，东西是好的，只是没人用。默默维护产品到生命衰退。

疑问

• 大部分的书里都在说自砍需求，留下最小的部分。而举的例子都是一下超级大项目，这些项目在最开始的时候的确需要精简，并且书中没有再说后续这些项目是怎么持续迭代的。现实中我们很多项目本身就是小优化，自砍需求这一步做的还是不错，不过很多项目像是一次性的，初版项目上线后数据能看到一些，但也可能什么也看不出来...所以要MVP上线以后什么情况下开始持续迭代，做什么，什么时候做？