pm-method-story-mapping

name	pm-method-story-mapping
description	《User Story Mapping》方法论。把 Jeff Patton 的用户故事地图转化为可执行框架， 用于：把需求拆成能沟通的整体骨架、切出最小可用的发布切片、避免扁平待办清单。 每条规则标注原书章节，可追溯。 触发词：「User Story Mapping」「用户故事地图」「故事地图」「需求拆解」「MVP 切片」 「backbone」「walking skeleton」「怎么写用户故事」及"需求太碎/PRD 说不清全貌"类场景。

《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 章 / Connextra 模板）
7. 如果只盯着输出的功能，则补一步"我们希望用户行为/业务结果发生什么变化"（outcome 优先于交付清单）。（第 3 章）

检查清单：一张健康的故事地图（综合第 5、6 章）

• 有一条从左到右读得通的 backbone（完整用户旅程）
• 纵轴按优先级排，越上面越必要
• 第一个发布切片是横切的、端到端能用的（不是某模块的完美版）
• 每个切片都对应一个可交付、可验证的完整体验
• 大故事（epic）已拆到能在一个迭代内完成
• 地图是团队一起画的，不是 PM 独自写完再宣讲
• 每张卡片能引出对话，而不是只当规格来执行

反模式（书中明确警告）

1. 扁平待办清单（flat backlog）——一长条纵向列表，读不出全貌也切不出版本。（第 5 章）
2. 把写故事当成写详细规格——以为文字够细就能免掉对话，理解照样丢失。（第 1 章）
3. 纵向切 MVP——把某个模块做到完美却端到端走不通，用户拿到手不能用。（第 6 章）
4. 只有 PM 一个人建图/写故事——失去了故事最大的价值（共同理解）。（第 1 章）
5. 追求"把所有故事写全"而非"把要做的第一版说清"——细节应随临近开发才展开。（第 14 章）

边界声明

• 出版于 2014 年，方法稳定；它解决"如何结构化表达与切分已决定要做的东西"，不解决"该不该做/需求真假"
• 适用：有明确用户流程的产品功能拆解与发布规划；对纯算法/基础设施类无清晰用户旅程的工作，地图形态需变通
• 它假设团队能一起协作建图；远程/异步或话语权不对等的团队，"共享理解"需要额外机制保障
• 术语细节若按二手资料提炼有出入，以原书为准

工作流

收到用户问题后：

1. 匹配场景 → 选框架（建骨架 / 切发布 / 对齐理解）
2. 缺核心输入（目标用户、这件事的主流程）→ 一次性列出需补的信息；缺次要信息用[假设]标注补全
3. 按框架步骤执行：帮用户把散乱需求排成 backbone + 任务，并横切出第一版
4. 用"健康地图检查清单"复核结果，标注未通过项（尤其"第一版是否横切端到端"）
5. 结尾声明边界，提示可换视角交叉验证（如"该不该做这一版，问 pm-advisor-cagan 的四大风险"）

本 Skill 由 career-skill-factory 生成。内容提炼自原著，版权归原作者 Jeff Patton，仅供个人学习。