《用户故事地图》读书笔记:产品经理必须掌握的分析利器

在产品工作中,有时候会遇到这样一些问题:

1、做产品规划时,会漏掉一些关键功能,没有很好的需求分析方法论;

2、版本迭代时,只见树木,不见森林,不停的做功能需求,却忽略了产品全景;

3、研发拿到的是产品提交的功能需求,却没有弄清楚真实的用户需求,开发出来的功能达不到预期。

最近读到《用户故事地图》,利用“用户故事地图”,就可以解决以上问题。

01. 用户故事

在讲用户故事地图之前,先来说下用户故事。

用户故事,最早由Kent Beck提出,Kent Beck是敏捷开发创始人,提出用户故事的本意,是想解决共识的问题。

用户基于某个场景,提出了自己的需求,产品经理基于用户的需求提出解决方案,将其转为功能需求,研发基于产品的功能需求文档进行开发, 最终发现开发出来的功能根本就不是用户想要的。

或者本来可以有更好的实现方案,但是因为只看到功能需求,而没了解到用户需求,所以没机会把更好的方案做出来。

新知达人, 读书笔记|用户故事地图,产品经理必须掌握的分析利器

产品在产品的认知范围内做决策,研发基于研发的认知做决策,而产品的认知和研发的认知却不一样。

产品经理不断的细化需求文档,写得越来越标准,但不同的人,对相同的文档,理解不一样,共识问题想完全靠文档解决,是不现实的。

那如果让研发能知道用户的真实需求,是不是就能解决这个问题呢?

于是Kent Beck 就提出用户故事这个方法,大家都喜欢听故事,从一开始,就只说用户故事,而不是只说功能需求。

这样,产品和研发对用户需求的理解是一致的,能更好的达成共识。

02. 用户故事怎么写?

一个完整的用户故事,应该包含三部分内容:用户、功能、价值。

-用户:是谁要用这个功能;

-功能:具体是什么功能;

-价值:通过这个功能,用户能获得什么价值;

通常用这样的格式表达:作为一个<用户>,我想要<功能>,以便于<价值>

例如:作为一个<在外务工的农民工>,我想要<一匹马>,以便我<春节可以回家过年,与亲人团聚>。对于这个用户故事,由于产品经理没见过车,也不知道有车的东西,于是提供了马这个解决方案,但是开发人员知道有车,就会提出车这个更好的解决方案。

写用户故事地图,应该遵循几个原则:

1、独立的,如果两个故事有依赖,则合并为一个大的故事

2、可讨论的,故事本身就是一个沟通的工具,用户故事不是合同,不需要写的过于详细;

3、有价值的,这是用户故事最重要的一条,要是没有价值,还做他干什么呢?价值让研发不仅做,还要知道为什么做;

4、可估算的,估算用户故事,可以帮我们更好的判断工期,评估是否有足够的资源,有多少人办多少事,如果不能估算,可能有几种原因:①研发不了解业务;②研发缺少技术知识;③故事太大;

5、颗粒度小的,过大的用户故事不便于评估,如果双周迭代,3-5天的颗粒度是合适的;

6、可测试的,如果故事不可测试,就无法衡量是否达到预期,是没有评判标准的;

03. 用户故事地图

上面说了用户故事,再来说下用户故事地图。

用户故事地图,是由用户故事组成的全景图,用户故事由活动和用户故事组成,活动是完成用户目标的核心步骤,用户故事是根据核心步骤拆分出来的小任务。

例如,用户在电商产品,核心步骤可以分为:浏览商品——下单——付款——收货——评价,在浏览商品这个步骤里,可以分为更细的任务,如查看首页、搜索、对比、查看详情、查看评论等。

用户故事地图,有这样几个作用:

1、和业务、研发,甚至用户一起梳理需求, 不遗漏关键功能;

2、在团队内达成共识,让项目成员 有全局感,既见树木,又见森林 ;

3、更好的规划版本,每次新迭代,都是做的当前最重要的功能, 不浪费研发资源;

04. 用户故事地图的创建方法

绘制用户故事地图,需要 召开一次用户故事会议 ,参与会议的人必须是各岗位关键角色,包括产品负责人、项目负责人、业务负责人、技术和老板,人数控制在7人以内,但不要少于3人。这些人都代表了平台建设中的主要角色的看法。

同时, 要提前准备材料 。和WorkShop一样,我们在开始之前,要准备一个白板、不同颜色的便利贴、胶带等等。同时还要明确产品目标,要解决的用户问题以及或许有的收益等等。

新知达人, 读书笔记|用户故事地图,产品经理必须掌握的分析利器

1、第一步,进行产品定义。 我们要确定我们的用户是谁?解决什么问题?用户目标是什么?产品目标是什么?通过这些问题,可以基本框定整体的范围。

2、第二步,梳理骨干故事。 梳理故事要确定好一级故事、二级故事,保证故事的完整性,同时要广度优先,而非深度。最后的效果就是看到故事群。

3、第三步,拆分故事。 在刚刚梳理的每一个二级故事下面做停留,去拆分二级故事获取更多细节内容。项目组会围绕这个故事写出很多细节来。

在这个过程中,先让大家在一定时间内按照自己的想法写出来,每一条写在一张卡片上,做到相互不干扰,然后每个人出声说出自己的卡片内容,让所有人了解并贴在墙上。

项目组人在写想法的时候,相当于脑暴的过程,这时可以通过一些问题来刺激大家脑暴出更多的内容,比如:

– 用户在这步具体做什么?

– 用户还有其他选择么?

– 用户怎么做才能更爽?

– 出现问题如何处理?

在真实业务当中,发生特殊情况该怎么办?所以这一步我们将尽量多的关注到所有场景的故事。做完这步,我们已经获取到了足够多的细节信息,整个项目组都会做到对产品又见森林又见树木的状态。

4、第四步,沟通确认。 这一步是将前面丰满而又臃肿的故事,通过对标标题、充分讨论,把公认的留下来,无用的剔除掉,同时区分要做的故事细节的优先级。完成所有故事梳理后,就出现了下面这张图:用户故事地图。

新知达人, 读书笔记|用户故事地图,产品经理必须掌握的分析利器

05. 写在最后

用户故事是方便达成共识的一种沟通工具,用户故事包含3个要素:

用户、功能、价值。

写用户故事,应该遵循6个原则:独立的、可讨论的、有价值的、颗粒度小的、可估算的、可验证(测试)的。

用户故事地图是由用户故事组成,通过用户故事地图,可以更好的分析需求、版本规划,做到既见树木又见森林,创建用户故事地图,分为四步:产品定义、梳理骨干、拆分故事、沟通确认。

用户故事是敏捷开发的起始点,如果团队在用敏捷开发,而又不知道用户故事,那就不是敏捷开发,利用好用户故事和用户故事地图这2个工具,可以更好的践行敏捷开发。

本文经授权发布,不代表增长黑客立场,如若转载,请注明出处:https://www.growthhk.cn/cgo/product/53700.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2021-12-21 11:28
下一篇 2021-12-21 11:37

增长黑客Growthhk.cn荐读更多>>

发表回复

登录后才能评论
特别提示:登陆使用搜索/分类/最新内容推送等功能 >>