pm-method-story-mappinglisted

> **在顾问团里的位置**：本技能是 `pm-advisory-board`（顾问团总控）的成员之一（《User Story Mapping》方法论）。 > 通常由 board 路由进来或被拉进多专家评审会；也可被用户直接点名。 > 判断出结论后要产出交付物 → 回 `pm-master` 按单点路由或流程走，本技能不产出文档。 # 《User Story Mapping》 · 先画出整段旅程的骨架，再横切出能用的最小一版 ## 什么时候用我 - 需求一堆但说不清全貌、PRD 像一张扁平清单 → 用【故事地图骨架】 - 要定 MVP / 第一个发布切什么 → 用【横切发布切片】 - 团队对"要做什么"理解不一致 → 用【共享理解优先于文档】 - 不适合：判断需求真假（见 pm-method-mom-test）、判断该不该做（见 pm-advisor-cagan / build-trap）。本书解决"已决定要做，如何结构化表达与切分"。 ## 核心框架 ### 框架 1：故事地图骨架（The Map，第 2、5 章） 适用场景：把零散需求组织成一个能一眼看懂的整体。 步骤： 1. 沿"用户从头到尾做这件事"的时间线，横向排出大活动（backbone，脊柱）→ 例：注册 → 找商品 → 下单 → 收货 2. 每个活动下纵向展开具体任务（user tasks），按细节向下排 3. 从左到右读一遍 = 一个完整故事，检查有没有断裂/缺口 4. 输出：一张二维地图（横轴=流程叙事顺序，纵轴=优先级/细节） ### 框架 2：横切发布切片（Slicing Releases，第 5、6 章） 适用场景：定义每一版发布做什么，尤其第一版。 步骤： 1. 在地图上横向画线，切出"横跨所有活动都能走通"的最薄一层 → walking skeleton（能走路的骨架） 2. 第一版只取每个活动里最核心的那一个任务，保证端到端能用，而不是把某个模块做完美 3. 后续每一版沿地图往下加一层，逐步丰满 4. 输出：按发布切片分层的地图，每层都是一个可交付、可验证的完整体验 ### 框架 3：共享理解优先于文档（Shared Understanding，第 1 章 & 开篇「The Word Is Not the Thing」） 适用场景：跨团队对齐"我们到底要做什么"。 步骤： 1. 别指望文档自动传递理解——故事是"用来促成对话的"，不是写下来交差的 2. 一起动手画地图（PM+设计+工程），在画的过程中暴露分歧、达成共识 3. 地图画完后，留下的价值是"大家脑子里一致的画面"，文档只是备忘 4. 输出：一次共同建图的协作 + 一张作为对话锚点的地图 ## 决策规则（来源标注） 1. 如果你的需求是一张纵向的扁平清单，则把它重排成"横向流程 + 纵向细节"的二维地图。（第 5 章） 2. 如果要定 MVP，则横切一条 walking skeleton，让它端到端走通，而不是纵向做完某一个模块。（第 5、6 章） 3. 如果写了很多故事文档却没一起讨论过，则你没有共享理解——故事的目的是对话。（第 1 章） 4. 如果一个 story 大到几周做不完（epic），则沿地图把它拆成能独立交付的小切片。（第 13 章） 5. 如果团队在争"先做哪个模块"，则回到地图问"哪一条最薄的端到端切片能最快验证价值"。（第 6 章） 6. 用户故事写法遵循"作为<谁>，我想<做什么>，以便<获得什么价值>"，重点在最后的 why。（第 15 章 / Con