前言

tips：

好的团队，从关键业务指标得到启发，通过观察用户的痛点和分析用户使用过程中产生的数据，不断尝试新技术解决现实问题。差的团队，从销售人员和用户那里收集需求。

好的团队，理解谁是主要干系人，干系人所受的约束，承诺引入解决方案，方案对用户和客户有用，同时也满足业务上的约束条件。差的团队，只知道从干系人那里收集需求。

好的团队，掌握大量的技术手段，这些技术手段可以快速验证哪些产品创意是值得开发的。差的团队，召集会议来制定路标和排列优先级。

好的团队，产品经理、交互设计师和开发工程师坐在一起，对功能、用户体验、技术可行性达成一致见解。差的团队，各自坐在小格子间里，没有文档和会议安排，就不会主动响应其他人的请求。

好的团队，保证开发工程师每天有时间参与产品原型的讨论，为做好产品献计献策。差的团队，在迭代计划会上展示原型，一心只为了估出工作量。

tips2

只有满足顾客和用户的需要，公司才能实现自己的诉求

第1~5章 用户故事地图概览

用户故事地图：就是在讲大故事的同时进行拆分

构建故事地图的最终目的：团队成员需要能够支出设计方案中的问题和改进点，并对需要投入多少开发时间进行估计

用户故事地图详细说明

每一列顶层的卡片都是大故事。拆分的细节放在下方，在每个大故事上停一下，然后提出以下问题： 

用户在这一步具体要做什么事情？ 

用户在这一步还有其它选择吗？ 

如何才能使用户觉得更酷炫？ 

出现问题了如何处理？ 

tips:拆分大型输出的秘密在于聚焦小的、特定的成果。 

MVP：

1.MVP是为验证假设而做的最小规模的实验

2.MVP是指可以产生预期成果的最小产品发布

划分MVP发布计划

1.聚焦于成果，即产品发布后用户能使用和感知的东西，切分发布计划应该以成果为导向

2.聚焦于特定的目标成果，这是排定开发工作优先级的秘密

优先级模型

差异化功能（显著区分于其它竞争对手的功能）

搅局功能（针对竞争对手差异化功能）

降成本功能（降低组织运作成本的功能）

基础功能（进入市场竞争所需的基础功能）

需求验证及原型设计

通过原型和用户测试验证产品方案是否真的有用，有价值

下面两点最重要： 

* 最大胆、风险最大的假设是什么？哪些是最不确定的？ 

* 为了消除假设或风险，需要哪些真实的信息？ 

估算与发布计划

1.最靠谱的估算，来自于真正理解自己在估算什么的工程师2.在开发过程中，我们也会对已经投入的开发时间进行记录，这个活动叫做度量；度量越频繁，估算会越接近实际值

用户故事地图三部分：

第一部分：跑通整个流程（团队可以看到一个端到端可用的软件，通过加载数据来观察软件性能，引入自动测试工具来检验稳定性）

第二部分：团队进一步对产品进行完善，使其接近可发布的标准，在这个过程中，会学习到此前无法预计的许多东西，比如可能在原型阶段忽视一些有用的特性，或者发现现有系统无法满足性能上的需求而需要额外的投入来解决问题，这些称为"可以预计的不可预计因素"

第三部分：打磨产品特性，使其接近完美，这个阶段也会加入此前没有预计到的一些东西

管理研发预算

当可能延期时的方法

* 项目外协调更多的人力

* 砍掉对用户没有明确收益的功能

* 在问题发生的时候想办法改变用户的预期

在拆分的过程中，团队逐渐识别处可能导致预算管理失控功能的因素，这些因素就是风险，整个团队一起讨论，对识别风险很有帮助

其它解决方案：在用户故事地图中加入风险故事

迭代与增量

运用迭代的思持续评估和打磨作品，则意味着评估和改变

运用增量的思维做加法

开局中局与末局

开局

聚焦于必备功能或者用户步骤，重点关注技术挑战或风险，暂且跳过哦用户主流程之外的步骤，也先不管可能导致问题复杂化的商业规则。所有开发只要满足跑通主流程就好

中局

补充周边功能，用户主流程之外的可选流程一级复杂的商业规则。如果开局阶段做得不错，在中居可以开始测试产品的非功能需求，比如性能、可扩展性和可用性。这些更多是质量方面的考量，要认识到这些方面的工作并持续进行测试

末局

打磨发布，使其更抢眼，使用起来更高效。此时，已经可以在生产环境使用真实数据，此时能识别出的改进点是原型阶段无法识别出来的。同时，也可以从真实用户那里听取他们对产品的反馈。

一旦确定第一个对用户可行的发布，就和团队成员一起把发布计划分成开局、中局和末局。

故事地图六步法

1.厘清问题。用户是谁，带来什么价值？

2.构建全景图。广度有限，而非深度。尝试用故事地图描述所有内容，包括用户的痛苦和喜悦

3.探索。  向深度拓展，讨论其它类型的用户，这些人又要做什么？哪些环节会出现问题

4.指定发布策略  过段砍掉无助于取悦用户和帮助公司达成目标最小方案的东西

5.制定学习策略  帮助自己发现有哪些最大的风险。为用户群的子集切分更小的MVP实验，不断学习真正对用户有价值的东西6.指定开发策略，在去掉所有不必要的东西之后，留下的就需要投入开发。早期先聚焦于关键技术问题和开发风险

第6-12章 深入理解用户故事

简介：用户故事背后的故事、工作原理，如何在敏捷和精益项目中更好地使用用户故事。

最佳的解决方案来自于需要解决问题的人和有能力解决这些问题的人彼此协作

用户故事模板：

作为【一个用户】

我想要【某个产品特性】

这样我就可以【获得某种收益】

提升讨论效果的检查单：

1.讨论用户角色（who）

2.讨论要做的功能（what）

不要忘记那些用户关注这些功能以及要解决什么问题

3.讨论为什么（why）

讨论为什么特定的用户会关注这些功能。多问几个为什么，可以发现隐藏在背后的真正原因

4.讨论软件之外的东西

讨论用户会在何时何地使用产品，使用的频度如何，在使用过程汇总用户身边是否还有其它人

5.讨论异常情况

肯呢个会出现哪些异常情况？系统宕机会引发什么问题？用户还有没有其它完成任务的手段？

6.讨论问题和假设

你会发现有许多未知的事情阻碍了讨论的继续进行，把这些问题识别出来，讨论它们的重要性

你真的了解用户吗？这是用户真正想要的吗？这些问题真的是用户痛点吗？用户会接受这个方案吗？

技术-我们需要依赖哪些底层系统？我们是否已经正确理解了这些系统的工作原理？还有哪些需要关注的技术风险

7.讨论更好的解决方案

讨论要对为什么做、做成什么样一级如何实现这三个问题进行优化

8.讨论开发周期

故事卡片

1.简短的标题

2.描述信息who、what、why

3.故事序号

4.估算、规模或预算

5.优先级

6.度量给故事指定度量标准，根据数据判断是成功还是失败

7.依赖该故事依赖或者需要一起发布的其他故事

8.状态计划到哪个发布中？启动了么？进行中？已完成？

9.日期

检视产出

-用户体验质量

从目标用户角度来审视产品。简单易用吗？使用过程中是否能体验到乐趣？看起来还让人觉得舒服吗？和品牌诉求及其他功能之间的一致性保持得怎样？

-功能质量

功能正确吗？是否还有遗留的bug或者错误？测试人员和团队其它成员可能已经完成测试和bug修复。好的测试人员会告诉你产品中还隐藏着更多bug,也可能会告诉你产品的质量坚如磐石

-代码质量

代码质量高吗？符合编码规范吗？这些代码会在系统中留存一段时间，因此最好搞清楚它们是一u扩展和维护还是堆砌了迟早要还的技术债

如果一个故事没有进行三次锤炼，那么这个过程就不能称之为一个学习过程

拆分

对技术来说-将故事拆分成可以在两三天时间内完成开发和测试的模块，是一个非常好的经验法则

对话是拆分故事最好的工具之一

探索最小可行方案

*你认为哪些用户和客户会使用你的方案？

*没有你的方案时，他们如何满足自己的需求？

*有了你的方案，他们的世界会法伤怎样的变化？

*你的方案看起来怎样？ 它是如何发挥作用的？

*你的方案要花长时间开发？

在开发过程中保持日常对话

不管多么努力，即便是故事工作坊也不能预测处开发启动之后会遇到的各种情况，为每天进行频繁的非正式故事对话做好准备。在每天的站会踢出讨论的需求

开发过程中的反思：计划如期达成了吗？延期了？或提前了？和预期的产出一致吗？适时对工作方式进行微调和改变，力求获得质量更高，更符合预期的产出

经常反思产品质量、工作计划及工作方式

评估

*拿有意义的工作软件模块去测试客户和用户，从中学习

*利用评审会议向利益干系人展示产品

发布

发布

指足以给这些客户和用户以得到我们想要的结果。一旦天平两段达到平衡，就可以开始发布

学习的主要目标，就还需要使用度量来了解人们是否使用以及如何使用产品

运用度量和直接接触用户来真正了解是否达到预期

身为产品负责人，要兼顾其它干系人的想法，扮演制作人的角色，帮助他们获得成功。

第13-15章 用户故事地图的整个声明周期

探讨机会

团队可能没有足够的信息做出通过还是不通过的决定。如果是这种，列出还需要了解哪些信息，然后一起寻求答案。

如果仍然无法做出通过还是不通过的结论，可以将这个机会放回机会待办列表，供日后讨论。这叫推迟决策。

事实上，我们不应该将所有这些聪明的想法都变成软件，不管踢出想法的人究竟是什么头衔

通过探索来建立共识

探索的4个核心步骤：

1.从业务角度来组织想法

2.理解客服和用户，搞清楚怎样才能帮到他们

3.把自己的解决方案呈现出来

4.简化并计划招到最小化的可行方案及具体开发方式

一起建立轻量级的用户画像，力求在团队中建立共识和同理心

如果保留下来的想法超出扔掉不用的想法，就说明你的探索工作可能没有作对

一个可行的产品意味着对特定商业策略、目标客户和用户都是成功的

制作优先级的秘诀：

具体的业务结果可以驱使我们聚焦于特定的用户，他们的目标及其使用活动。对这些活动的关注驱使我们聚焦于用户需要哪些具体的特性和功能

特定的业务目标，客户和用户确定优先级，然后再为他们的目标确立优先级。最后才是功能

探索的目的是建立共识

验证性学习

设计思维的第一个步骤是同理

直接与客户和用户交谈。亲身体验你想帮助他们解决的困难。

下一步是形成想法

制作简单的原型进行探索，得出最好的解决方案。制作一定保真度的原型，让用户和哭胡可以评价解决方案是否真的恶意解决他们的问题

最后一步是测试

得到一个你认为可以解决自己所关注问题的原型之后，再把它拿给潜在用户看。

将解决方案拿给可能购买或使用产品的人看。不要期望它们一开始就能去的吃那个工。不断加以迭代和完善

以下几种方式注定可以把设计过程搞砸

*没有对业务需求和目标客户进行慎密思考就盲目开始。这会使我们难以确定谁才是最值得关注的人以及是否找到了好的解决方案

*花大量时间进行全面研究并理解已经了解的东西。世界那么大，总有你不了解的东西，为什么不及时停止呢？

*不花时间与用户或客户交谈，不从他们那里学习。毕竟，有很多数据是现成的，而且我们已经想好了很好的解决方案。现在只需要着手设计就行了

*无法聚焦于具体的问题，而是一心想着要为普罗大众广泛解决许多问题。解决的问题越多越好，对吗？ 此外，大问题通常会导致大的解决方案。想为有冲突需求的人解决问题，最终可能导致没有人会喜欢你的解决方案，

*考虑的解决方案多，但只局限于征询设计师对解决方案的想法，因为他们才是唯一受过专业想法训练的人

*不花时间多考虑几个解决方案，因为现有的想法已经很好了

*做的原型看起来很逼真，但等客户和用户真正使用时并没有很好地发挥作用。尽管如此，遇到这种情况还是会言不由衷地客套一下『看起来很漂亮』

*说服自己和其他人，这个经过充分研究和专业设计的解决方案是可以发挥作用的。毕竟，遵循的是一个严谨的设计过程。哪里会有什么差错呢？

*不担心开发成本。这个方案是正确的，因而任何开发成本都是合理的

*将解决方案拿到客户和用户面前，并不关注是否达到自己预期的结果，而是关注整个过程中出错的环节，出现问题，一味指责别人

第16-18章 深入介绍如何在持续迭代中使用用户故事

以下集中情况故事工作坊的效果会变得不那么好

* 没有人积极参与，一言堂，只有一个人在描述需要什么，其他人都只是听

* 只关心验收标准，不讲3W的故事

* 不能从功能的角度和技术的角度来考虑各种方案

每一个故事讨论和分解阶段，都要一心想着目标

1.对于机会，要讨论它们究竟针对谁，它们要解决什么问题，它们是否与你的商业策略想匹配

2.在探索阶段，要详细讨论谁会用，为什么要用以及怎样使用你的产品。团队的目标是构思一个有价值、有用、可行的产品。这时，要做许多碎尸的工作。幸运的是，你只需要将最少数量的故事推入发布待办列表中，这些列表描述了一个最小可行产品版本

3.规划开发策略，要讨论有哪些风险：用户是否喜欢和接受的风险，技术可行性的风险。要以学习的心态展开碎石行动，首先开发原型和做技术穿刺，力求从中充分了解到信息

4.规划下一步开发周期时，要进行最后一次最佳讨论，明确做出开发决策并就验收标准达成一致意见。这些一致一件中的每一条都提供一个可以进一步分解的故事的计划，每个故事满足一条一致意见就可以了

产品回顾会

与团队成员回顾

回顾三个要素：产品、计划和过程

产品

从已经完成开发的、以故事结果的软件产品开始讨论。确保把它投影在屏幕在屏幕上，并且有机会试用。

团队对质量的主管评级：

*讨论用户体验的质量。不只是UI看起来怎样，还包括它的具体使用体验，它有逾期的那样好吗？在5点量表上自己做评级，5是最好

*讨论功能上的质量。测试过程还流畅吗？ 是不是还有许多bug'? 测试人员认为测试更多或有更多时间爱你测试可以发现更多bug吗？ 在5点量表上自己做评级，5是最好

*讨论代码的质量。 写的代码容易维护和拓展吗？还是只是写了新的一批遗留代码？ 

计划

如果此时正处于一个有着时间盒约束的迭代或sprint,可以考虑先制定计划和预估可以完成多少任务。

*确定哪个故事已完成，哪个没有完成。讨论这个问题可以帮助团队建立验收标准的共同定义。"完成"意味着有自动化测试？意味着所有手工测试完成？还是意味着负责人和UI设计师评估过产品？

*统计你们人文已经完成的故事数量。这是你的进度

*统计已经开始和没有完成的故事，如果还有很多，就表明还需要继续规划

*讨论探索工作预算的时间量。充分利用这些时间了吗？ 用的时间是否超出了预期?没有准备充分就开始开发自己觉得有信心的东西，化的时间太少，其后果你很快就能体会。花的时间太多又不利于准时交付

*讨论希望下一个周期中做的改变。不要过度承诺。最好是小改变一次性改变太多就好比一次承担太多的工作。你最后肯定会失望的。

与干系人评估回顾

评估探索性工作

*简要讨论每一个已经开始处理的机会；为谁，为什么，如果成功，又期望得到什么结果

*讨论并展示为理解问题和解决方案而做过的所有工作

*讨论并展示前面所做的原型和实验。讨论客户和用户对解决方案的看法

评估交付工作

*评估方案的目标客户、用户以及预期结果。记住做这个方案的动机一级成功的意义，这样做总是极好的

*讨论并展示为每个方案构建的故事成果。干系人会为此提供反馈，值得欣慰的是，如果有机会在探索工作时就得到他们的反馈，那么反馈一般是『看起来还不错』

*从整体上讨论故事，如果采取蒙娜丽莎这样的方法，就需要向他么解释为什么软件在此之后看起来不完整。

每次已发布，团队都要讨论如何完成度量或观察用户，借此来了解是否真正取得了预期结果

*为产品建立度量指标，追踪新功能的使用情况

*在用户使用新产品时安排时间对他们进行观察

实际实施

作为一个产品不得不说，关于用户故事地图这本书，我学到了太多。

1.从对产品的规划上来说，我会以迭代的成果为依据，来判断每次迭代的功能需要哪些

2.在对故事的拆分上，每次的正式迭代上线计划，都是以完成这次目的所需的最小功能来做工呢个能规划。不是必须要上的功能就先砍掉。来整个迭代能以最快速度得到自己需要的观测结果

3.在原型设计上，会在一开始考虑到哪些是大胆的假设，尽量得去得到消除假设

4，与开发及其相关成员的沟通上，始终让他们了解用户、了解目的。参与到产品设计中，共同得到大家认为的最优解。让他们明白自己做的东西是为了什么，最后得到了一些什么成果。共同与整个产品学习成长。

5.时刻记得所做的一切都是为了更好的学习 在产品迭代完成后，与所有相关成员一起好好聊聊回顾，如何能更好地学习进步。在产品发版后，去度量观察用户，了解是否达到预期结果，得到了哪些之前并未知晓的信息

6.对重要的是与用户对话，了解用户的需求是什么。真正帮助到了用户，产品才能成功，公司也才能实现自己的诉求

本文首发于公众号『里柳的产品之路』（ID:pmliliu）