如果要深入了解敏捷开发，特别是其中的用户故事，Jeff Patton 的书籍「用户故事地图」，必然是不能错过的。这是入门敏捷开发的经典教材之一，在互联网行业备受赞誉。「用户故事地图」是 Jeff Patton 和他的朋友们，过去多年对软件产品开发和协作的思考和经验沉淀。
对于产品经理，「用户故事地图」也是非常值得阅读的。尽管对于大部分产品经理，它读起来很困难。敏捷开发，现在越来越流行。而产品经理作为敏捷开发中的重要角色，这也是基础技能。用户故事这种需求的表达形式，不仅在工作方式上有很大价值；同时，对于产品经理针对需求的思考和分析过程，也是非常值得借鉴的。而且，在「用户故事地图」一书中，Jeff Patton 对现行的的 MVP，进行了非常深度的思考。这是每个产品经理，都不能错过的知识点。
我读这本书，主要有三个原因。首先，是深入学习敏捷开发和用户故事地图。在我过去的产品经历中，从来没有经历过敏捷开发。但是，对于敏捷开发闻名已久。再则，一直有一个疑惑，尽管敏捷越来越流行，但是在国内知名互联网研发团队中，采用的却不多。所以，我希望能搞清楚其中缘由，以及敏捷的优缺点和适用环境。最后，我一直在思考产品经理对于需求分析的定式方法。也许用户故事地图，这种方法能给我带来，方法上的很多思考。
什么是用户故事地图？
用户故事是需求的表达形式。表达形式这种词汇，通常代表着多样性。但是，用户故事是确定形式的表达形式。即以「3W」来对需求进行描述。
3W，指的是 who、what、why。who 代表「用户是谁？」，这是人；what 代表「用户要做什么？要用什么功能？等」，这是事情；why 代表代表「为什么用户产生这个需求？为什么要用这个功能？」，这是原因。人 + 事 + 原因，就构成了对需求的简短而全面的描述。
如果要写出一个好的用户故事，需要满足 3C 原则。卡片(Card)、交谈(Conversation)和确认(Confirmation)。用卡片(Card)来简要描述软件特性或改进点；通过与Product Owner(或客户)交谈来明确细节；每个故事应具有验收标准(验收条件)，能够确认被正确完成。
用户故事地图是 Jeff Patton 发明的一种组织和管理用户故事的方法。即以地图产品从开始到达成预期目的预设路线，将用户故事组织成地图。
通过构建简单的故事地图，来使产品的使用过程中的用户体验图形化和可视化。从而提升团队的效率。
对于产品经理的意义？
对于很多产品经理，可能会有所疑惑。用户故事地图对于产品经理，到底具备什么价值？听起来。更像是传统软件开发中，项目经理的职能。
用户故事地图是敏捷开发中重要的一环。在敏捷开发的工作模式下，所有的项目角色都需要参与到敏捷开发中。产品经理，在其中通常就负责用户故事的构建。所以，在敏捷开发中，用户故事地图就是产品经理工作后产出的成果。
使用用户故事地图，还能帮助产品经理达成共识。达成共识，并不仅限于产品经理之间。还在于与客户、研发人员、其它部门等。用户故事地图，可以建立一个统一的全景。使孤立的个体或者部门，从一个统一的视角去制定计划，寻找相互之间的依赖。
通过用户故事地图，产品经理可以探索产品实现的最佳路径，甚至是产品方向。用户故事地图主要从四个方面来达到这一目的。
- 从业务的角度组织想法。理解清楚客户和用户，搞清楚他们想要什么，怎么才能帮助他们。
- 把自己的解决方案呈现出来。
- 简化并计划找到最小化的可行方案及具体的开发实现路径。
- 用户故事地图，核心是一种实现产品的路线图和计划。用户故事地图设计计划的原则之一，是减少开发。所以，使用用户故事地图，在排列需求优先级时，需要按照成果来排列，而非功能。
使用用户故事地图，可以帮助产品自迭代的进行学习。学习主要是两方面。一是从验证和探索过程中学习。用户故事地图和 MVP 是紧密相关的。从 MVP 可以基于验证思考和探索想法的角度，沉淀产品经验。再则用户故事地图的建立过程，可以帮助从别人学习。通过有效的沟通，可以聚焦所人参与人员与外部人员的想法，学习大家的经验。
正因为以上这些原因，用户故事地图的使用，可以避免产品经理思想僵化，过于理想化。从而打造一个有价值的、可用且可行的产品。
从产品经理的角度使用
产品经理构建用户故事地图，需要经理五个步骤。写出故事、组织剧情、探索可行的故事、梳理主干和剔除低价值的故事。这五个步骤，是用户故事地图构建并呈现出来的路径。这个五个步骤，并不是用户故事方法体系的全部。要构建出合格的用户故事地图，还需要使用很多的方法，注意很多的细节。比如，如何进行沟通，如何检视产出。
1.写出故事
构建用户故事地图的第一步，当然是构建用户故事。所以，首先需要写出故事，而且是写到故事卡片上。写用户故事时，需要使用上文所提到的3W方法。如果一个故事太大，可以分步骤分层级写。也就时一个故事可以有多个卡片。写出的用户故事，需要以用户任务作为基础模块。任务就是我们需要做的事情，然后更注重细节而已。
2.组织剧情
将写出的任务卡片，按应该发生的先后顺序，从左至右排列。这种从左到右的自然叙事顺序，就构成了故事的主体。
3.探索可行的故事
我们的任务会从左到右发生。但万一某一个任务不发生怎么办？所以，我们需要尽量查找每个故事，可能的替代任务。这些替换任务的角色，并不是故事的备胎。它们代表的是一种故事发生的可能性。
4.梳理主干
如果对整体的任务进行梳理，会发现一些具有关联性的任务，能同时执行的任务。这些任务可以使用统一的卡片来进行描述，这就是用户故事地图方法中所谓的活动。这些活动就构成了故事的主干。
5.剔除低价值的故事
在最后的环节中，还要梳理出对于故事主线完成，价值高的故事。反之，也就要要降低那些可有可无的故事的层级。在这个过程中，我们要明确这些故事，都是需要为我们达成核心目标服务。
这里还要强调，这五个步骤并不是用户故事地图的全部方法。这仅仅是在各种方法的工作下，结果的呈现方式。在用户故事地图的这个五个步骤，使用时是一定不能脱离卡片的。无论是实体还是虚拟的。
虽然任务和待办事项，看来很类似。但是任务要丰满很多，是由3W方式的内容所构成的。
用户故事地图，并不是一次构建好，就能解决掉所有问题。用户故事地图实在产品的整个生命周期中，都需要使用，且能创造价值的。使用用户故事地图，在产品的研发过程中，也是有五个周期。
- 从机会开始。
- 通过探索建立共识。
- 通过探索来进行验证性学习。
- 交付可行的产品。
- 产品上线后复盘学习。
这个五个阶段是依次发生，不断首尾循环的。这个五个阶段过程中，用户故事地图会不断的发生变化和更新。在这个过程中，产品会逐渐成为一个有价值的、可用且可行的产品。
书中学到的经验
使用用户故事地图的时候，不能仅仅把它看成一种固定的方法，机械的使用。我们要理解它的核心思想。用户故事地图的创建是探索和学习的过程。过程中学习、阶段性完成后的复盘学习、基于验证的学习。
用户故事地图方法中，强调沟通是好过文档的。在用户故事的建立过程中，沟通是好过文档的，甚至于卡片。但是，个人认为这也是有适用场景的。在进行探索的过程，沟通是由于文档的。但一旦建立用户故事地图，将需求从功能需求转化为产品需求时，文档更为有效。文档在产品经理和技术间传递，能保持信息的一致性，而且还能追踪变化过程。
用户故事地图的书中，有很大的篇幅在讨论 MVP。MVP 不是发布的拙劣的快速开发的产品。MVP 是指最小可以产生预期成果的最小可行性方案。因为 MVP 是验证和学习和学习的基础。所以，最小可行性方案就是为验证假设而做的最小规模的实验。最小规模的指的是投入规模。
因此，在用户故事地图中，MVP 就是在用户故事地图主干中，寻找可以验证假设的最小的一组主干故事。
尽管使用用户故事地图的目的之一是，尽可能的达成共识。但这个共识，并不是人人都可以选择的民主。最终还是由产品负责人决策。产品上的民主并不明智。
在设计好用户故事地图后，还要对投入的时间进行评估。用户故事地图可以帮助工程师，真正理解自己在估算什么。在评估时间后，通常会超出我们的预期。那么，就需要制定可逐步达到的开发计划。这里有两个原则。运用迭代思维持续评估和打磨作派。运用增量思维对产品做加法。评估时间的最终目的是保障准时发布。
用户故事地图的核心原则之一是，人人参与。通过人人参与，来共用大家的知识和经验，寻找一个最优解。但是，人人参与并不是每个环节都要人人参与。而是，合适的环节合适的人参与。
用户故事地图融合了精益创业的思想。他们都是在寻找一套，让猜想变为现实的产品设计方法。
思考
在国内做产品经理做产品经理，会发现一个有趣的现象。虽然产品经理设计的是软件产品，但是很多产品并不懂软件的开发或者研发过程。很多时候，某些产品经理会自诩为互联网产品经理。
所以，诸如此类敏捷等工程方法，并不流行。但是这些工程方法，是前人的经验总结，是很多年的成果经验。如果能借鉴，会少走很多弯路。要知道产品经理的职责从来都不是，完成蓝图设计就行了。而是要把猜想变为落地的产品。
如果是一个小型团队，用户故事地图可能并不太适用。因为小型团队的需求，并不一定规模很庞大。如果是简单的需求，那么直接做验证，会更高效。用户地图故事，需要更全面的沟通和探索。当然，它会带来更趋近成功的几率。
要正确的使用用户故事地图，也是一件并不轻松的事情。它需要团队具备敏捷思维，成员掌握高效的沟通方式，能够快速的达成共识。同时，这种方法并不一定受所有人欢迎。因为，这会要求团队成员，参与到更多的产品研发环节中。
