「用户故事地图」- 通过探索和学习打造产品
如果要深入了解敏捷开发,特别是其中的用户故事,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方式的内容所构成的。
用户故事地图,并不是一次构建好,就能解决掉所有问题。用户故事地图是在产品的整个生命周期中,都需要使用,且能创造价值的。使用用户故事地图,在产品的研发过程中,也是有五个周期。
1、从机会开始。
2、通过探索建立共识。
3、通过探索来进行验证性学习。
4、交付可行的产品。
5、产品上线后复盘学习。
这个五个阶段是依次发生,不断首尾循环的。这个五个阶段过程中,用户故事地图会不断的发生变化和更新。在这个过程中,产品会逐渐成为一个有价值的、可用且可行的产品。
使用用户故事地图的时候,不能仅仅把它看成一种固定的方法,机械的使用。我们要理解它的核心思想。用户故事地图的创建是探索和学习的过程。过程中学习、阶段性完成后的复盘学习、基于验证的学习。
用户故事地图方法中,强调沟通是好过文档的。在用户故事的建立过程中,沟通是好过文档的,甚至于卡片。但是,个人认为这也是有适用场景的。在进行探索的过程,沟通是优于文档的。但一旦建立用户故事地图,将需求从功能需求转化为产品需求时,文档更为有效。文档在产品经理和技术间传递,能保持信息的一致性,而且还能追踪变化过程。
用户故事地图的书中,有很大的篇幅在讨论 MVP。MVP 不是发布的拙劣的快速开发的产品。MVP 是指最小可以产生预期成果的最小可行性方案。因为 MVP 是验证和学习和学习的基础。所以,最小可行性方案就是为验证假设而做的最小规模的实验。最小规模的指的是投入规模。
因此,在用户故事地图中,MVP 就是在用户故事地图主干中,寻找可以验证假设的最小的一组主干故事。
尽管使用用户故事地图的目的之一是,尽可能的达成共识。但这个共识,并不是人人都可以选择的民主。最终还是由产品负责人决策。产品上的民主并不明智。
在设计好用户故事地图后,还要对投入的时间进行评估。用户故事地图可以帮助工程师,真正理解自己在估算什么。在评估时间后,通常会超出我们的预期。那么,就需要制定可逐步达到的开发计划。这里有两个原则。运用迭代思维持续评估和打磨作派。运用增量思维对产品做加法。评估时间的最终目的是保障准时发布。
用户故事地图的核心原则之一是,人人参与。通过人人参与,来共用大家的知识和经验,寻找一个最优解。但是,人人参与并不是每个环节都要人人参与。而是,合适的环节合适的人参与。
用户故事地图融合了精益创业的思想。他们都是在寻找一套,让猜想变为现实的产品设计方法。
在国内做产品经理做产品经理,会发现一个有趣的现象。虽然产品经理设计的是软件产品,但是很多产品并不懂软件的开发或者研发过程。很多时候,某些产品经理会自诩为互联网产品经理。
所以,诸如此类敏捷等工程方法,并不流行。但是这些工程方法,是前人的经验总结,是很多年的成果经验。如果能借鉴,会少走很多弯路。要知道产品经理的职责从来都不是,完成蓝图设计就行了。而是要把猜想变为落地的产品。
如果是一个小型团队,用户故事地图可能并不太适用。因为小型团队的需求,并不一定规模很庞大。如果是简单的需求,那么直接做验证,会更高效。用户地图故事,需要更全面的沟通和探索。当然,它会带来更趋近成功的几率。
要正确的使用用户故事地图,也是一件并不轻松的事情。它需要团队具备敏捷思维,成员掌握高效的沟通方式,能够快速的达成共识。同时,这种方法并不一定受所有人欢迎。因为,这会要求团队成员,参与到更多的产品研发环节中。
以上就是“「用户故事地图」- 通过探索和学习打造产品”的内容了,如果你还想了解其他相关内容,可以来 产品壹佰 官方网站。
对于产品经理,「用户故事地图」也是非常值得阅读的。尽管对于大部分产品经理,它读起来很困难。敏捷开发,现在越来越流行。而产品经理作为敏捷开发中的重要角色,这也是基础技能。用户故事这种需求的表达形式,不仅在工作方式上有很大价值;同时,对于产品经理针对需求的思考和分析过程,也是非常值得借鉴的。而且,在「用户故事地图」一书中,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方式的内容所构成的。
用户故事地图,并不是一次构建好,就能解决掉所有问题。用户故事地图是在产品的整个生命周期中,都需要使用,且能创造价值的。使用用户故事地图,在产品的研发过程中,也是有五个周期。
1、从机会开始。
2、通过探索建立共识。
3、通过探索来进行验证性学习。
4、交付可行的产品。
5、产品上线后复盘学习。
这个五个阶段是依次发生,不断首尾循环的。这个五个阶段过程中,用户故事地图会不断的发生变化和更新。在这个过程中,产品会逐渐成为一个有价值的、可用且可行的产品。
书中学到的经验
使用用户故事地图的时候,不能仅仅把它看成一种固定的方法,机械的使用。我们要理解它的核心思想。用户故事地图的创建是探索和学习的过程。过程中学习、阶段性完成后的复盘学习、基于验证的学习。
用户故事地图方法中,强调沟通是好过文档的。在用户故事的建立过程中,沟通是好过文档的,甚至于卡片。但是,个人认为这也是有适用场景的。在进行探索的过程,沟通是优于文档的。但一旦建立用户故事地图,将需求从功能需求转化为产品需求时,文档更为有效。文档在产品经理和技术间传递,能保持信息的一致性,而且还能追踪变化过程。
用户故事地图的书中,有很大的篇幅在讨论 MVP。MVP 不是发布的拙劣的快速开发的产品。MVP 是指最小可以产生预期成果的最小可行性方案。因为 MVP 是验证和学习和学习的基础。所以,最小可行性方案就是为验证假设而做的最小规模的实验。最小规模的指的是投入规模。
因此,在用户故事地图中,MVP 就是在用户故事地图主干中,寻找可以验证假设的最小的一组主干故事。
尽管使用用户故事地图的目的之一是,尽可能的达成共识。但这个共识,并不是人人都可以选择的民主。最终还是由产品负责人决策。产品上的民主并不明智。
在设计好用户故事地图后,还要对投入的时间进行评估。用户故事地图可以帮助工程师,真正理解自己在估算什么。在评估时间后,通常会超出我们的预期。那么,就需要制定可逐步达到的开发计划。这里有两个原则。运用迭代思维持续评估和打磨作派。运用增量思维对产品做加法。评估时间的最终目的是保障准时发布。
用户故事地图的核心原则之一是,人人参与。通过人人参与,来共用大家的知识和经验,寻找一个最优解。但是,人人参与并不是每个环节都要人人参与。而是,合适的环节合适的人参与。
用户故事地图融合了精益创业的思想。他们都是在寻找一套,让猜想变为现实的产品设计方法。
思考
在国内做产品经理做产品经理,会发现一个有趣的现象。虽然产品经理设计的是软件产品,但是很多产品并不懂软件的开发或者研发过程。很多时候,某些产品经理会自诩为互联网产品经理。
所以,诸如此类敏捷等工程方法,并不流行。但是这些工程方法,是前人的经验总结,是很多年的成果经验。如果能借鉴,会少走很多弯路。要知道产品经理的职责从来都不是,完成蓝图设计就行了。而是要把猜想变为落地的产品。
如果是一个小型团队,用户故事地图可能并不太适用。因为小型团队的需求,并不一定规模很庞大。如果是简单的需求,那么直接做验证,会更高效。用户地图故事,需要更全面的沟通和探索。当然,它会带来更趋近成功的几率。
要正确的使用用户故事地图,也是一件并不轻松的事情。它需要团队具备敏捷思维,成员掌握高效的沟通方式,能够快速的达成共识。同时,这种方法并不一定受所有人欢迎。因为,这会要求团队成员,参与到更多的产品研发环节中。
以上就是“「用户故事地图」- 通过探索和学习打造产品”的内容了,如果你还想了解其他相关内容,可以来 产品壹佰 官方网站。