用户故事地图阅读笔记01

读《用户故事地图》，我最大的收获是：用户故事不应是一张张孤立的卡片，而应放在一张二维地图中理解。横轴是用户完成目标的活动流程，从左到右展开；纵轴是故事的粗细层级，上边是主干活动，下边是具体故事。Jeff Patton 把上边的主干称为“骨架”，把下边支撑发布的故事称为“切片”。传统 backlog 往往只列出一堆“作为……我要……以便……”的条目，看起来完整，却丢失了用户使用产品的整体路径。团队容易陷入局部优化，做了很多功能，却没有形成顺畅的用户体验。

故事地图的价值首先在于恢复上下文。它要求团队先讲清楚“谁、为了什么、经过哪些步骤、最终得到什么”。在绘制时，产品、设计、开发、测试一起参与，把用户旅程贴出来，再拆分故事。这种协作过程本身就是需求对齐。其次，故事地图能暴露缺口：某个活动下没有故事，可能意味着遗漏；某个故事横跨多个活动，可能意味着职责不清。它还能帮助识别真正的最小可用产品，因为团队可以看到哪些故事组合起来才能形成端到端价值。

我过去是怎么做的：我习惯把用户故事一张张列出来，认为只要卡片够细，需求就清楚了。
结合书中所讲，说明为什么这样不好：书中强调用户故事不应是孤立卡片，而应放在二维故事地图中，横轴是用户活动流程，纵轴是故事层级。只列卡片会丢失用户使用产品的整体路径，导致团队局部优化、功能堆砌，做了很多却走不通一条完整路径，缺口和依赖也难以发现。
提出一个解决办法，避免再次掉入陷阱：版本规划前先画用户旅程主干，再往下拆故事，按端到端价值做纵向切片；让团队成员一起参与绘图，并指定负责人定期维护地图，避免变成一次性海报。