用户故事地图,通过探索和学习打造产品

如果要深入了解敏捷开发,特别是其中的用户故事,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 就是在用户故事地图主干中,寻找可以验证假设的最小的一组主干故事。

尽管使用用户故事地图的目的之一是,尽可能的达成共识。但这个共识,并不是人人都可以选择的民主。最终还是由产品负责人决策。产品上的民主并不明智。

在设计好用户故事地图后,还要对投入的时间进行评估。用户故事地图可以帮助工程师,真正理解自己在估算什么。在评估时间后,通常会超出我们的预期。那么,就需要制定可逐步达到的开发计划。这里有两个原则。运用迭代思维持续评估和打磨作派。运用增量思维对产品做加法。评估时间的最终目的是保障准时发布。

用户故事地图的核心原则之一是,人人参与。通过人人参与,来共用大家的知识和经验,寻找一个最优解。但是,人人参与并不是每个环节都要人人参与。而是,合适的环节合适的人参与。

用户故事地图融合了精益创业的思想。他们都是在寻找一套,让猜想变为现实的产品设计方法。

思考

在国内做产品经理做产品经理,会发现一个有趣的现象。虽然产品经理设计的是软件产品,但是很多产品并不懂软件的开发或者研发过程。很多时候,某些产品经理会自诩为互联网产品经理

所以,诸如此类敏捷等工程方法,并不流行。但是这些工程方法,是前人的经验总结,是很多年的成果经验。如果能借鉴,会少走很多弯路。要知道产品经理的职责从来都不是,完成蓝图设计就行了。而是要把猜想变为落地的产品。

如果是一个小型团队,用户故事地图可能并不太适用。因为小型团队的需求,并不一定规模很庞大。如果是简单的需求,那么直接做验证,会更高效。用户地图故事,需要更全面的沟通和探索。当然,它会带来更趋近成功的几率。

要正确的使用用户故事地图,也是一件并不轻松的事情。它需要团队具备敏捷思维,成员掌握高效的沟通方式,能够快速的达成共识。同时,这种方法并不一定受所有人欢迎。因为,这会要求团队成员,参与到更多的产品研发环节中。

本文由 新媒体之家 作者: 产品小思考 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
1

发表评论