读书笔记#
我正在读《用户故事地图》这本书是我的专业技能主题阅读中业务分析的第一本，这本书我一直想读完，但是一直没有持续下去，读专业书籍不像其他类型的书籍那么有趣，但是这本书里提到的的好的产品经理和坏的产品经理，全球顶尖产品经理都有哪些相似点？好的团队和差的团队之间主要有什么不同？这三篇文章之后，我越发觉得，做好一个产品经理、打造一个成功的团队显得格外有价值。

你读这本书的动机是什么？想通过学习用户故事地图，运用到工作中，做出用户喜爱和有商业价值的软件
它哪里吸引你？用户故事地图BAT和硅谷大厂都在使用的需求管理方法
你想获得什么? 学习如何发现和管理用户故事，如何做好团队沟通，协调，并最终交付好产品

读完截止时间：2020年04月12日

《用户故事地图》
**

前言 核心概念

1.使用用户故事的目的不是为了写出更好的用户故事
2.产品开发的目的也不是开发出产品
3.用户故事不是需求，而是关于问题解决方案的讨论，解决公司和客户的问题，目的是让大家对开发的功能达成共识。

文档的弊端
人们只看到自己想看到的内容，人们在阅读文档时总会产生误解，因此写出好的的文档并不能达成共识。
有时候我总觉得是文档写的还不够完整，但是在产品开发的过程中总是有那么一些信息被同事们遗漏和误解了。最抓狂的是，我画的流程图开发们都不喜欢看或者直接忽视，当我和他们沟通讨论的时候他们财知道这是要做什么。就是说只有沟通过后产品和工程师们才会达成共识。

举个例子
最近参加一个习惯训练营，在开营第二天营长让我写个建议给他。我整理了10条，其中有一条是最好在课前把课程的计划和上课方式发给大家。不要等到当天才确定用何种上课方式，什么时间上课。
过了三天，我在翻群里聊天记录才发现当天开营就发出来了，而且写的清清楚楚。为什么我就没有什么印象呢，我这种情况就跟开发看我的文档一样，我明明写了，工程师就是看不到。
所以有一句说的有点道理，一千个人眼中就有一千个哈姆雷特，人们都只愿意看到他们想看到的。每个人的知识和经验不相同，理解文档的内容肯定是不相同的。
这时候就应该通过讨论，让大家的彼此交流想法，而不能只是问这个需求有没有问题，没有问题下一个。

停止对完美文档的追求
再完美的文档也会产生误解，这个问题不是写文档和读文档的错。作者最终建议停止写出完美的文档，让大家坐在一起有效讨论，通过文字和图片到组合方式，达成一致的理解。
用户故事的目的不是故事本身，仍而是借助这个故事让大家交流达成共识。
所以这本书的作者并不是教大家如何写文档，如何写用户故事，而是教大家如何沟通。
是呀，文档不就是沟通的一种方式吗？
个人理解可以通过用户故事让大家充分交流，然后达成共识，最后仔把大家的共识和细节补充到文档中，这样文档的内容就不只是产品经理自己的生产的内容，而是大家群体的智慧。

软件本身并不是重点
这个是什么意思呢，就是说开发软件并不是最终的目的，而是达成目标的一种资源和条件。我们在做产品的时候，不要只关注产品本身的各种属性，而忽略了用户使用产品的目的。
在讨论需求的时候可以更多讨论用户的使用场景和用户的诉求，讨论为谁开发，用户正在做什么，他们需要怎么做才更好。让用户未来的产生积极变化就是产品所要达到的目的本身。
《俞军产品方法论》讲过，好的产品是有两种属性的，既效用和商业价值。
效用是针对用户的，商业价值是实现企业目标。没有商业价值便无法为用户服务，因为任何的商业行为都是有相应的成本的。

少开发功能
想要的功能总是比能开发的多，这是一个不变的事实。就像人们想买的物品，总比能买到的物品多。过去我们总想开发出第1xx个功能吸引用户，觉得功能越多覆盖多场景越多，产品才越有价值。实际上做上来发现，团队和公司资源有限，不可能把更多的想法实现，我们只能停下来想想，做哪些事情能够产出最大的成果，选择那个最有价值和成本最小的去做。

第1章 产品全景图

什么是用户故事

伴随着企业的成长和用户的爆发，软件已经逐步从一个小工具，变成了一个庞然大物。在开发的过程中，已经不可能一次性把所有的需求都做到，这时候需要把需求以用户为核心去拆分，分阶段去开发，拆分后的需求就叫做用户故事User Story。

为什么需求不太好使

因为前面讲到功能太多，很多个需求拼凑起来才能变成一个完整的功能，如果只是单纯的拆分，容易导致把软件开发变成了积木游戏，想象一下把一个完整东西拆成零件再组装起来，如果不关注用户是用来干什么的，拼凑出来的产品不一定是用户想要的，这时候就需要一个名为用户故事的工具出场了。

用户故事的好处

故事一般来说都相对完整，没人愿意听一个不完整的故事
故事是讲出来的，大家都乐意传播和讨论，比起那冷冰冰的需求文档来说，故事给人们印象更深刻
故事能够聚焦产品的整体性，而不是以开始就关注细节，有利于构建产品的全景图，故事就像一部电影一样大家都知道我们的用户跟产品之间有哪些有趣的故事
在开发的过程中，开发人员也能够非常方便的理解这些“故事”，大家都能贡献自己的智慧参与到其中，而不是被要求这么做

用户故事的例子

用户可以参与到开发中，我经常建议提需求的人用这种通用的语言格式描述，作为[哪种角色]，我希望[做什么,怎么做]，以便于[所带来的价值]
举个例子，作为一个孩子，我希望爸爸每天能够下班后能够关注我，以便于获得内心的安全感，否则我会觉得很孤独，觉得自己不被重视。
如果不关心故事，只关心需求，这个爸爸可能只是给孩子买了一个玩具，很少关注他，走近他的内心而已。买玩具对孩子来说可能是个伪需求。
我们在做产品的时候，很多时候就只是关心这个玩具，很少关心用户的本质诉求。

第2章 计划，是为了更少的开发

产品的需求实在是太多了，想要开发的功能现有的资源总是无法满足，因此我们要有所取舍

我曾经写了101个人生目标，然后看到这么多目标之后我发现如果要全部实现可能要花大量的时间，然后我就挑出来几个最重要的，但是看到其他的也想做怎么办呢？。

这里分享一个巴菲特和他的飞行员的故事

有一天巴菲特和弗林特开玩笑说：“事实上你还在为我工作，让我觉得我做的还不够好。你在实现你的目标和梦想后可以回家养老退休了。”
第一步：巴菲特让弗林特写下25个目标，这些目标是他工作和生活中最重要的事情，然后弗林特花了些时间思考并写下了25个目标。
第二步：巴菲特让弗林特再次认真思考下这个单子中哪5个是首要的目标，这5个目标是他在这个世界中最最重要的。
这对弗林特来说有些困难了。因为在这个单子上的每一件对于他都很重要（毕竟他也是花费时间考虑把这些事情写在单子中的）。但是巴菲特坚持他只能选5个。弗林特仔细想了想然后就选择了5个。
巴菲特问，“那其他20件事情你怎么计划和安排呢？”
弗林特回答说：“我已经确定好了最重要的5个目标，另外的20个也会很快安排的，这20个目标也很重要，在我实现最重要的5个目标的时候，我也同时会努力去做的，虽然这20个目标不是特别重要，但是我也要花些时间精力来追求下。”
巴菲特说：“弗林特，当你觉得第6-20件事情也是非常重要的，你非常在乎的。但是当你在去追求实现最最要的第1-5项时，第6-25项就是个干扰，在你没有实现能最重要的5件事情之前，其他的事情都应该尽量避免，注意力和精力不要花费在这些事情上。”

我们在生命中想做很多事情，有谁不想把25个目标都实现呢？但是当我们一起追逐25个不同的事情的时候，我们成了万金油，而不是一个大师。这个就像之前暴雪的暗黑破坏神2一样，当我们觉得5个英雄都很像玩的时候，如果我们这几个英雄都创建一般，然后玩一遍，但是最后你会发现你跟你一起只创建1个英雄的玩家分分钟就把你创建所有的英雄给秒了。

这个就像去沙漠，我们带上了很多行李，最后发现重要的东西才能让我们生存下来。比如水和食物、还有可以保暖的衣服。

用户故事地图的要素

1. 主干，英文叫Backbone，骨架的意思，一般是从左往右

可以理解成电影的主要故事情节，比如金庸小说张无忌从出生前到他最后退隐江湖的主要情节点，之所以从左往右也是基于两点，一个是现实世界的事务流程是线性的，故事的情节也是线性的，这样比较容易知道依赖关系，先有什么后有什么。比如肯定是先有张无忌年幼失去父母，才有后面的故事。主角的故事主干的经历会影响到后面的决策，比如张无忌听父母说越漂亮的女人越会说谎，这个就导致张无忌后面的人生走向，他一生都被四个女人爱恨情仇所纠缠。

1. 用户画像，让我们知道这个系统的故事主角

比如张无忌、赵敏、周芷若等，每个主角的属性，张无忌的性格特点是什么等。

1. 支干，英文叫Body，可以理解成细节部分

比如故事情节的一些细节，张无忌被玄冥二老种下寒冰掌，长大之后为了寒冰之毒无意中习得九阳神功

用户故事的原则
整体来说《用户故事地图》就是根据现实世界的把用户的场景故事化，这有利于我们做出的产品是基于客观事实，而不是基于自己不切实际的想法。

不可能自己乱给倚天屠龙记加剧情，这样会导致整个的剧情的走向错误，比如自己突发奇想，让张无忌继承武当掌门，或者让张无忌去找六大派寻仇。

用户故事的目的
用户故事地图的目的就是缩短开发周期，把故事的情节给压缩，找到关键情节，这个怎么理解就是让我们把电视剧拍成电影。把金庸的小说压缩成52集电视剧，把52集电视剧压缩成电影，这样就算是只有90分钟的电影，也能体现主要的情节。

用户故事的取舍
当我们整理出故事的详细情节后，我们发现需要做的故事实在是太多了，如果要全部做完可能要花很长的时间，这个时候就需要有所取舍，找到我们的核心的要素和情节。

拿倚天屠龙记来说，所有故事的铺垫都是走向一个结局，所以我们可以先把用户故事的结果写出来，然后基于结局去写剧本的关键点。

根据用户的目的做出取舍和优先级排序
拿用户故事来说，所有的用户故事都有一个或多个的用户目的，我们要紧密围绕用户目的去找出关键的故事点，把核心关键要素去完成它。

用户故事整理出来之后，要根据故事的优先顺序，对故事进行切割划分，这样就可以得出第一版、第二版、第三版的故事。

其目的就是聚焦于成果，让发布后的产品能够让用户使用达到他们的目的。这个就是需求排优先级的秘密。

一切优先级的目的都是帮助用户达成他的目标。这样在达成目标的过程中，有一些功能是可以延后甚至是不用做的。

这个就可以这样理解，用户为了达成他的目标，他需要做123456，其中123是必须做的。比如目标是让张无忌学会乾坤大挪移，那么就必须设定以下情节，要先学会九阳神功（这样才能更快的习得）、然后张无忌要遇到小昭（关键条件）、去明教总坛昆仑山光明顶、得知元真就是杀害义父仇人，擒拿圆真，被困密道，发现总教头，小昭磕头触发机关，小昭懂波斯语翻译给张无忌，修炼乾坤大挪移。

这章节中提到一个词语叫MVP
MVP就是最小可行性产品的英文简称，这里的关键就是两个条件，最小，可行性。
拿我之前提到的张无忌如何学会乾坤大挪移，如果不用MVP剧情会很长，如果用了MVP就必须达到结果，所以要设计这里面的关键因素，前面的所有情节都是MVP的一部分，最小就是单位时间内的最小，具体看企业的时间成本，如果时间特别短就去掉一些不必要的条件，这个故事也照样能讲得通。
比如去掉小昭和张无忌，肯定不行，去掉擒拿园真那个是不影响整体情节，但是被困密室就不能去掉，这是核心要素。

第3章 计划为了更快学习

产品经理不应该全靠自己的创意来工作，而是要会运用好资源，收集大家的想法和创意，然后去判断去验证想法是否可行。
对产品故事进行首次讨论，应该聚焦于如何让故事具象化。通过这类问题能够让大家达成共识，就算不能达成共识也能让大家的交流想法，头脑风暴，深度思考，而不是只聚焦于我们该做什么功能和怎么做上。
一个经典的讨论模板
1. 这个想法是什么？What
2. 客户是谁，谁会买？Who
3. 用户是谁？企业购买之后，哪些用户会使用？Who
4. 能解决用户什么问题？What
5. 购买和使用的动机是什么？Why
6. 解决了哪些客户和用户之前不能解决的问题？使用之后收益如何？How
7. 为什么要开发这款产品？Why
8. 如果开发的产品成功了，我们的公司能到哪些收益？How
如何验证问题
想法太多，可行的想法才是王道，如何去验证呢？
做产品之前要用最低成本去验证下，我们要解决的客户问题是否存在
这个时候就需要找客户和用户沟通和调研，了解的信息越多，就越不会做出异想天开的决策。沟通之后，把沟通的内容记录下来，形成用户故事，再根据故事形成开发待办事项，再根据优先级做产品原型设计，拿产品原型去找用户验证，可行就进行开发。如果能在原型阶段，就能验证产品的解决方案是否可用，就能给开发节约一大笔成本。
精益创业的思想
开发-度量-认知
把精益创业的思想运用到产品设计中

第4章 计划，为了按时发布

用户故事的三个层次
1. 跑通整个流程，每个功能开发完之后，可以看到端到端的可用软件
2. 团队进一步对产品完善，使其接近于可发表的标准
3. 进一步打磨特性，使其接近于完美
开发时间估算与度量
如果不能估算，就去记录过去开发模块所花费的时间，然后再根据过去的经验去估算时间，这是能控制研发的成本。
如果时间不够的情况下，这个时候就需要通过两种方式解决，1砍需求，只保留最重要的核心功能 2,劳动力外包，现有人力不足的情况下让外包去做当前时间内团队无法完成的
伟大的作品永远都没有完成一回事，只有放弃。——达芬奇
画家们画画的流程一般是，勾勒框架-打稿-完善细节-润色
没有谁画画是像图片加载那样，先加载前1/5，再加载2/5。

第5章 如何创建用户故事地图

任务是描述人们做什么事情的动词短语
任务有不同的目标层级
故事地图中的任务被布置在从左往右的叙事主线中
故事的深度包含变化性和替代性任务
通过故事地图顶部的活动将各个任务组织到一起
活动构成了故事地图的主干
通过切分地图找出达到一个具体结果要完成的任务
故事地图六步法
1. 厘清问题，用户是谁？带来什么价值
2. 构建全景图，广度优先，而非深度。
3. 探索。向深度拓展，讨论其他类型用户，这些人又要做什么？哪些环节会出问题。
4. 制定发布策略。果断砍掉对公司和用户无助的东西
5. 制定学习策略，通过学习找到真正对用户有价值的东西
6. 制定开发策略，聚焦关键技术问题和开发风险

用户故事最佳实践
1. 从产品愿景开始
2. 用户洞察，研究用户产出用户角色和用户画像
3. 使用层级法定义用户故事
（1） 高等级的使用步骤（2）步骤分解，每个用户角色对应的活动（3）将活动细分具体的用户故事，格式为“作为<角色>，我想要<功能>，使得<价值>”

第6章 用户故事的故事

过去我们使用精确的文档来描述用户需求， 让开发和设计人员理解。但是每个人的背景和知识不一样，从文档中阅读到的内容不一样。
文档只写了需要做什么，但是很少提及为什么这么做，给用户解决的是什么问题。让开发工程师知道为什么，他们会产生新的想法和解决方案。也许比产品经理的方案更具有建设性。因为解决一个问题，是需要大家的集体智慧，让解决问题的人彼此协作，才能做的更好。
否则工程师就变成了按需求开发的程序员，这样就跟外包公司没有什么区别了。
因此需要大家在一起讨论用户故事，力求对要解决的问题达成一致理解，并努力找到可以解决问题的最佳方案。
极限编程的3C原则
卡片（Card）在一堆卡片写上你期望的软件特性
交谈（Conversation）聚在一起对要开发的软件进行深入的讨论
确认（Confirmation）对完工条件进行确认
心理学家Jerome Bruner通过研究发现，用户故事的方式来称述事实，给人留下的深刻印象程度比单独称述事实本身高出20倍。
这个我深有体会，比起朋友或同事写的文章，我记忆更深刻的还是跟朋友一起玩的情景，因为我能回忆起很多线索。
这个章节结尾说，传统的开发模式只讨论标准的需求文档。讨论过程非常痛苦，因为大部分时间都是对通过沟通确认和理解这些文档中所表达的意思，感觉就是开发人员给文档找茬一样。
这种情况其实就是说，开发一款产品，产品经理总是觉得把需求弄出来，然后让开发人员在技术上评审下需求能否实现，而对于产品是否能给用户解决问题的讨论实在是太少了。我之前犯过一个错误，同事做了一个功能，我说这个功能不好，然后评审的时候，我说就要按我提的做，这时候他发怒了，说如果是这样就没有必要评审了，按文档做的就行。
还有一次是一个产品做了一个看似很炫酷的工具，开发人员说没有用意义，然后现场就崩溃了。总之这些问题根源就是没有把整个团队的目标对齐，大家都只是站在自己的角度表达问题，如果有异议更应该讨论为什么要这么做，给用户带来的价值是什么，而不是怎么做上。

第7章

提升讨论效果检查单
讨论用户角色
讨论要做的功能
讨论为什么
讨论软件之外的东西
讨论异常情况
讨论问题和假设
讨论更好的解决方案
讨论方案如何实现
讨论开发周期

第8章 不要把所有内容写在卡片上

通常一个团队有项目经理、产品经理、业务分析师、测试工程师、用户体验设计师和开发工程师等角色。
每个人的关注点和沟通视角是不一样的
产品负责人
对产品的成败负责，就需要对目标市场有更多的了解，因此需要拟定一些假设，比如有多少用户会购买或使用我们的产品，产品会对公司的收入带来哪些影响。
业务分析师
需要关注非常多的细节，所以我需要理解用户界面的变化以及在用户界面背后的商业规则
测试人员
需要考虑软件哪里容易出现问题，我需要和各个角色沟通，力求制定一个合理的测试计划
每个用户故事，也包含各个角色之间进行的各种各样的讨论
把跟同事之间的讨论以卡片或信息化的管理方式存放起来，以便后续回顾和沟通

第9章 卡片只是个开始

敏捷宣言中有一句话叫，可以工作的软件胜过面面俱到的文档，这句话的意思就是做软件的目的不是为了写出多优秀的文档，而是做出优秀的软件解决用户的问题
Card是3C原则中的第一个C
软件开发的闭环
提出卡片-团队讨论-确认结论-开发设计-产品演示
这个模式就是让团队所有成员都参与其中，而不是让前三个环节都让产品去拍板了
前面三个环节的目的就是让大家达成共识，虽然说有产品评审机制，但是目前的产品评审都是针对一个完整的需求文档才有评审。评审中的主要讲还是产品。很多时候产品觉得需求很清晰，是因为他对所有的细节都了如指掌。但是把文档给别人看，文档里面就有很多语境和没有写下来的内容。查看文档的人无法获得产品同等信息。
把故事的所有细节交接给开发人员，以这种方式组织开发工作的做法是行不通的，千万不要这么做
不是让所有的人参与讨论，人数最好控制在5人以内，一起讨论作出决定，然后把沟通过程的结论分享给所有人
软件开发完成之后，要做一个功能演示，功能演示的好处
评估下软件是否达到当前讨论的目的，然后看看在用户体验和产品质量上如何。
功能演示要有两种人群
1. 公司内部成员
2. 用户
前面写的只是针对公司的内部成员，对用户的演示更加的重要，因为我们并不是用户，并不能代表用户的所思所想。让用户使用，我们站在一边看看用户的使用情况，然后记录下来，发现改进的机会。
开发就是学习的过程，我们不可能一开始就做正确，要不断的去修正和改进。
最后一句话
验证性的学习胜过可以工作的软件（或者面面俱到的文档）

第10章 做产品好比烤蛋糕

如果故事的描述方案过于昂贵，就应该考虑替代方案
如果故事的方案符合预算，但是仍然很大，那么切分成小块可以帮助你更及时的评估产品的和把控进度
不要把大故事切到大计划中
把大故事切小，做小计划中。

第11章 碎石行动

从用户的角度来看，大小规模恰当的故事，是一个可以满足某一种需要的故事
从开发团队角度看，大小规模适当的故事，是一个只需要几天时间就可以完成开发和测试的故事。
从业务角度看，大小规模适当的故事，是一个有助于实现业务目标的故事。
对话是拆分故事的最好工具之一
如何拆分故事，通过团队成员之间的对话。
故事的拆分层级
Epic 史诗 是一个我们觉得它的个头有点大，因而需要进一步拆分的故事

使用机会探讨达成问题是否值得解决的共识，最终做出继续进行或取消的决策

对话的3W方法，（who-what-why）
探索阶段的提问
1. 你认为哪些用户和客户会使用你的方案
2. 没有你的方案时，他们如何满足自己的需求
3. 有了你的方案之后，他们的世界会发生怎样的变化
4. 你的方案看起来怎样？它是如何发生作用的？
5. 你的方案需要多长时间开发？
通过探索和对话，力求找到最小，可行性的方案，然后拆分故事，并且对我们要开发的内容达成共识。
产品正在的开发的时候，也需要通过对话给正在开发的软件给出反馈
拿出有意义的的工作软件模块去测试客户和用户，并从中学习
运用度量和直接接触用户来真正了解结果是否达到预期

经常反思产品质量，工作计划以及工作方式
1. 计划如期达成了吗，延期了，或提前了
2. 和预期的产出一致吗
3. 好好讨论一下交付机器的工作情况
软件交付之后可以去找用户做可用性测试，让业务人员也使用一下，获得内部和外部人员的反馈
对组织内的干系人而言，项目进度和完成质量要保持持续可见。
这个是需要做两个工作
1. 持续的发布当前的开发进度，如新的产品需求计划，接下来需要做什么开发工作
2. 产品开发出来之后要公布出来让大家体验新特性新功能或功能改进

第12章 谁是碎石负责人

产品的生命周期开始于交付之后
为什么产品的所有故事和对话，不能让产品经理一个人承担所有的工作
理由1
一个人肯定搞定不了所有的故事和对话，因为如果让一个做很快这个人就容易成为团队的瓶颈。我现在就成了团队的瓶颈
理由2
一个人的知识和视野有限，做不到跨学科和多样化。因此无法应付所有这些对话的解决方案，这就是为什么需要头脑风暴的原因。

要求一个产品负责人来写所有故事和开展所有故事对话，显然是行不通的

有价值的-可用的-可行的

一个由产品负责人带领的小团队、跨功能的团队来精心安排产品的探索工作

组建一个核心团队来协助产品负责人，包括用户体验专家，设计专家，和技术专家。

**

一个成功的探索团队需要更多的人参与

似乎作为我产品经理，就包揽了很多工作，用户体验设计，交互设计，业务分析，项目管理，产品负责人。想要做好各个方面肯定是不现实的。
这也说明了一个观点，产品负责人（产品经理）并不是设计师，而是一个协调资源完成目标的人。他会做什么重要的决策，确定产品的愿景，对齐大家的工作目标，然后朝着一个方向把产品做好交付市场，并且持续去优化产品的人。

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

第13章 从机会开始

想法、故事、 史诗 其实这些都是机会
所有的想法都可以看做是一个机会，我们要去审视这些机会，来确定这些机会是否值得只做

针对机会展开对话

讨论机会的5个层面

1. 他们的对象是谁？
2. 我们正在解决什么问题？
3. 我们的构思是什么？
4. 为什么？
5. 大小

深入挖掘机会，丢弃机会或思考机会

讨论完成之后就开始深入挖掘，决定这个机会是丢弃还是进一步思考
机会画布
1. 问题和解决方案
2. 用户和客户
3. 当下的解决方案
4. 用户价值
5. 用户度量
6.接受策略图
7. 商业问题
8. 商业度量
9.预算
老外写的书太啰嗦了

机会不应该是一种委婉的说法

故事地图和机会
通过重绘旅程地图来挑战假设

1. 一份容纳所有内容的地图
2. 对每件事提出问题
3. 设定场景
4. 排练
5. 重建地图
6. 痛点收获
7. 观察
8. 收获

第14章 通过探索建立共识

探索不是开发软件

这本书里反复出现的提问
1. 我们正在解决的问题是什么？
2. 什么解决方案对公司有价值？对客户购买和接受产品有价值?
3. 有用的解决方案看起来是什么样的？
4. 在时间和资源有限的情况下，开发哪些是可行的？

如果在理解一个大的、模棱两可的机会时，唯一的成果是只分解得出小的故事，则说明你可能做错了

探索的4个核心步骤

1. 从业务的角度出发组织想法

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

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

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

决策的原则
对商业策略、目标客户和用户都是成功的
制定优先级的秘诀
制定优先级的秘诀就是不是去制定功能的优先级的
按业务价值为故事排优先级
为特定的目标、客户和用户确定优先级，然后再为他们的目标确定优先级，最后才是功能
很多人还在犯错，总认为交付的产品和功能越多，价值就越大，实际上这个是错的。
探索阶段的一些工作内容
组织想法
你正在解决的业务问题
受影响的具体业务指标
具体客户和用户的简短列表
度量人们是否使用和喜欢某个新功能的指标
大的风险和假设
与业务干系人和相关领域专家进行讨论
理解客户和用户
用户角色和描述列表
简单的用户画像或人物素描
简单的组织画像或orgzona
故事地图以及人们目前的工作方式，也称“用户旅程地图”
用以弥补未知用户的研究和观察
将解决方案表现出来
故事地图
用户和用户场景
UI架构和故事版
UI原型
架构和技术设计框架
架构或技术原型
与团队成员、用户、客户、干系人以及相关领域专家广泛合作
简化和计划
有待细化的故事地图
为设定开发预算而进行的评估
设计思维
同理-聚焦-形成想法-制作原型-测试
同理Empathize：直接与客户和用户交谈，亲身体验你帮助他们解决的困难
聚焦Define：实际聚焦与一个或多个问题并加以阐述
形成想法：下意识地构思针对客户和用户问题的若干个可能解决方案
制作原型：制作简单的原型进行探索，得出最好的解决方案。制定有一定保真度的原型，让用户和客户可以评价解决方案是否真的可以解决他们的问题。
测试：将解决方案拿给可能购买或使用产品的人看，不要期望他们一开始就取得成功，不断加以迭代和完善。

把产品搞糟的原因
1、没有思考业务需和目标客户
2、没有设定截止时间，研究的太全面
3、不花时间与客户和用户交流
4、解决方案不聚焦，贪大贪多
5、解决方案只是产品或设计师出的
6、不多出几个方案PK，总觉得自己的方案是完美的
7、原型做的太高保真，忘记了做原型的目的
8、太过于相信自己的解决方案
9、不关心开发成本
10、不关注最终结果，而只是关注环节的问题
创业公司开发的不是产品而是客户，找到客户比做出一款产品更重要
精益创业的内涵，就说减少学习的时间和成本，因为创业公司的资源是有限的
开发-度量-认知
在精益创业中，学不到东西通常才是最大的失败
什么叫学到东西
就是知道做事情，是对的还是错的。加速他
大部分想法可能是失败的
故事工作坊——提炼理解和具体定义开发团队要开发什么
人数3-5人
1. 理解用户界面的人，产品、交互、业务分析师
2. 熟悉代码的工程师
3、测试人员
挖掘可选方案的对话
用户是谁
我们认为他们会如何使用产品
产品看起来怎么样，或者用户界面怎样
用户界面之后，软件的工作原理是什么
开发周期需要多久
我们需要检查什么确认软件已经完成
一起评审软件，应该如何展示
故事工作坊的效果
只有一个人再说
只关注验收标准，不讲3W故事
不从功能角度和技术的度量来考虑各种方案
开发软件就像写书，先放初稿，然后补充图片和内容，最后精简内容，对内容润色，这是一个持续打磨的过程。
每个阶段和版本的验收标准真的很重要，明确了验收标准，开发起来就没有那么多费劲和耗时了。
正好-更好-最好
为产品建立度量指标，追踪新功能的使用情况
在用户使用新产品时安排时间对他们进行观察
软件从来没有被真正完成
软件的结果从来没有保证
发布之后的改进最有价值