产品经理 用户故事地图
一款帮助产品经理工作效率提高99.9倍的工具[视频讲解一]
一款帮助产品经理工作效率提高99.9倍的工具[视频讲解二]
用户故事源自于敏捷开发，因此对敏捷开发有事先了解，尤其是了解SCRUM开发，对于理解用户故事地图会更有帮助。为了大家有更一致的知识基础，先快速过一遍SCRUM：
Sprint：冲刺周期，通俗的讲就是实现一个“小目标”的周期。一般需要2-6周时间。
User Story：用户的外在业务需求。拿银行系统来举例的话，一个Story可以是用户的存款行为，或者是查询余额等等。一个sprint可包含若干 User Story。
Task：由User Story 拆分成的具体开发任务。
Backlog：需求列表，可以看成是小目标的清单。分为Sprint Backlog和Product Backlog。
Daily meeting：每天的站会，用于监控项目进度。有些公司直接称其为Scrum。
Sprint Review meeting: 冲刺评审会议，让团队成员们演示成果。
Sprint burn down：冲刺燃尽图，说白了就是记录当前周期的需求完成情况。
Rlease：开发周期完成，项目发布新的可用版本。
以上已经出现了用户故事，也就是User Story。因此我们可以看出，用户故事 本质上就是我们常说的用户需求，但会更具象化为用户的某一个完整的需求。
为什么需要用户故事地图？
SCRUM开发本身非常好，但是和所有开发流程一样，还是很难解决以下常见的问题：
需求繁乱，无边无际，甲方爸爸往往什么都想要，业务讨论经常陷入迷失
开发人员在原型后才介入，信息偏差导致交付结果偏差
总想一口气完成软件开发，即使切分版本，也不知道为什么这么切分。
因此《用户故事地图》的本质是希望通过将用户故事，写在标签卡片上的形式，粘贴在墙上，变成全局的地图，来解决问题：
让参与人能聚焦在一起讨论，针对实物，移动，归类，直观高效
让研发很早就介入进来，并在讨论后，获得强大的共识，从而开发的软件不至于偏差太大
从用户故事出发，确定具体的目标，从而确定版本如何切分，并在交付后，验证和改善
因此，用户故事地图是一种需求阶段团队协作的方法模式，可以理解为一种有特殊约定的头脑风暴会议。其实在电影行业，尤其是皮克斯这样的动画电影团队中，已经有很多类似的实践。
对于产品经理而言，用户故事地图也可以非常好地应用在战略层和范围层，帮助我们确认目标用户，产品价值，需求范围，版本计划和需求优先级。
产品经理在使用用户故事地图时，扮演着关键的角色。他们负责定义产品的愿景、确保团队对需求有清晰的理解，并推动产品向目标方向发展。以下是产品经理如何使用用户故事地图的几个方面：
制定产品战略：
产品经理可以利用用户故事地图来描绘产品的整体愿景和战略。
定义史诗有助于确定产品的核心功能领域。
组织和管理需求：
用户故事地图提供了一种有效的方式来收集和整理用户需求。
产品经理可以将需求分解为易于理解的用户故事，并按顺序排列，以便于团队成员理解和实现。
协调跨部门协作：
用户故事地图可以帮助产品经理与不同部门（如设计、开发和测试）之间进行有效的沟通和协作。
地图中的任务层有助于明确每个团队成员的责任和预期输出。
规划产品路线图：
根据用户故事地图上的优先级，产品经理可以制定短期和长期的产品路线图。
这有助于指导团队的工作重点，并确保产品的发展符合业务目标。
驱动迭代开发：
在敏捷开发环境中，产品经理可以根据用户故事地图来规划每个迭代的目标和内容。
地图提供了迭代之间的连续性，使团队能够在保持对产品整体视角的同时，专注于当前的迭代工作。
评估进展和效果：
通过用户故事地图，产品经理可以轻松地跟踪团队的进度和完成度。
地图还可以帮助产品经理根据用户的反馈和市场变化调整产品策略。
总的来说，用户故事地图是产品经理在产品研发过程中的一种重要工具。它为产品经理提供了一个框架，用于可视化地组织和管理产品需求、优先级和开发过程。
如何制作用户故事地图？
创建用户故事地图的8个步骤
1. 召集到3-5名对产品非常熟悉的人员参与。3-5人听上去像是个魔法数字，实际上是的。因为更少的人意味着你无法获得足够的建议，而更多人则会因为讨论和协调降低会议效率。
2. 使用静默头脑风暴模式，让每个人在便签纸上写下自己认为重要的“所要做的事情”也就是 用户任务（user task）。每个人都用同样颜色的便签来书写自己的用户任务描述，这个阶段不要互相讨论。一旦大家都基本完成了准备，让每个人轮流大声读出自己的内容，并把便签纸全部放置在桌面上，这时如果出现重复的内容就可以省略掉：
根据你的产品规模，这个过程可能需要3-10分钟的时间；你可以观察大家的行为来判断是否需要停止。
基本上每张便签都会以一个动词开头，如：发送邮件、创建联系人、添加用户等。
这些便签组成了一级用户故事，Jeff Patton称为用户任务（user tasks），它们组成了用户故事地图上的 “行走的骨骼” （the walking skeleton）部分。
这时可以提示参与者：我们只用了很少的时间就完成了需求的收集过程，而且有些内容你可能没有想到，而其他人帮你想到了。
3. 然后，让大家将桌面上所有的便签进行分组，将类似的任务分为一组，其他的的类似
这个过程最好也让大家采用静默模式进行，因为这样做会更快。如果发现重复的内容，就略过
基本上分组会很容易完成
这时同样观察每个人的行为，判断大家是否已经做完，基本上这个过程需要2-5分钟
4. 选择另外一个颜色的便签，对每个组进行命名，并贴在每组便签的上部
5. 对这些分好组的便签进行排序，一般按照用户完成操作的顺序，从左到右摆放
如果大家无法决定顺序，那么顺序可能没有那么重要（明显）。
这一组便签，Jeff Patton称为 用户活动 （User Activities）
这时你的地图应该类似于
6. 现在，按照 “行走的骨骼” 用户行为 这行开始讲述用户故事，确保你没有遗漏任何用户行为和用户任务。这时一般由组织者进行讲述，其他人提出意见，甚至可以让最终用户来参与讨论。
7. 这时，我们已经完成了用户故事地图的基本框架；可以在每个用户任务下面添加更加细节的 用户故事（User Stories）了。这时仍然建议使用静默头脑风暴的模式来进行第一轮用户故事的产生，同时借助如Persona和Scenario等方式协助完成这个过程。一旦你完成了用户故事的创建，就可以开始划定你的 发布计划（Releases）了
一般我习惯在第一个发布中只选择每个用户任务的2-3个用户故事。这对于帮助大家排定优先级和范围将很有帮助。
基本上我们不必使用用户故事的标准句法（As a …）来书写这些故事，因为每张便签都处于我们的地图的特定位置，大家很容易识别其所处的场景和角色。
8. 最后，针对第一个发布的所有用户故事进行分解，确保我们的第一个发布越小越好，基本上你需要保证在1-2个迭代后就可以发布你产品的第一个版本。
故事卡片模板
英文：As a <Role>, I want to <Activity>, so that <Business Value>.
中文：作为一个<角色>, 我想要<活动>, 以便于<商业价值>
版本划分，移动故事
当地图制作完毕后，接下来是版本划分，我们按照任何事物的发展都会经历3个阶段（开始，发展，结束）也先按三步走，后续可以根据实际情况，再拆分版本。
第一版：开局 解决核心问题，跑通关键流程
第二版：中局 完善核心功能体验，更易用
第三版：终局 打磨产品，让产品接近完美
然后将故事移动到对应的版本。这里需要特别之指出的是，划分版本的依据是：根据本次交付能满足用户完成什么目标来划分，因为没有目标成果，就无法排优先级。我们经常犯的错误是：哪些功能简单先做，复杂的往后放，出发点已经不是用户。
拍照和记录
讨论的场景和最终的地图最好能记录和拍摄下来，和成员分享，一图胜千言，事后成员可以理解回忆当时的场景和细节。
制作用户故事地图的意义
一、梳理需求并有全局的需求把握
对于产品经理而言，用户故事地图从用户角度，按操作流程展开，比思维导图，表格梳理需求更自然，全面，并可以从全局森林的视角来把握产品，而不是陷入树木细节，导致遗漏。
二、达成最大程度的共识
我们理解，通过一群人一起制作用户故事地图，甚至和甲方一起，可以形成最大程度的共识，尽管看上去会多花一点时间，但是达成的共识比其他方式都要更大。而共识是后续开发最重要的支柱。没有共识，开发会不理解为什么需要开发这个功能，或者开发出一个不同的结果。没有共识，最后甲方或者用户想要的和交付软件天差地别。
不是如何写出更好地用户故事，而是在写故事的过程中，达成共识
三、达成敏捷开发的效果
敏捷宣言提到：“个体和互动高于流程和工具，工作的软件高于详尽的文档”
产品经理一顿操作，输出原型PRD，技术开发和测试同学再阅读文档，进入开发，本质上和瀑布开发没有太大区别，只不过现在很少有以前那种特别复杂的软件开发，开发周期都相对较短，大家察觉不出这种方式的弊端。
敏捷开发重要的是背后的理念和思想，用户故事地图就是贯彻这种思想的一种实践，千万不要把用户故事地图当成另一种文档，而忽视了它背后的意义：那就是团队内的互动高于流程和工具，交付的软件高于详尽的文档。
