在产品工作中,有时候会遇到这样一些问题:
1、做产品规划时,会漏掉一些关键功能,没有很好的需求分析方法论;
2、版本迭代时,只见树木,不见森林,不停的做功能需求,却忽略了产品全景;
3、研发拿到的是产品提交的功能需求,却没有弄清楚真实的用户需求,开发出来的功能达不到预期。
最近get到一个新技能,用户故事地图,利用用户故事地图,就可以解决以上问题。
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.uisdc.com/user-maps-design-ali-case
如果你喜欢这篇文章,欢迎关注上面的公众号
最后,我建立了各大城市的产品交流群,想进群小伙伴加微信:yw5201a1 我拉你进群。
关注微信公众号:产品刘 可领取大礼包一份。
··················END··················
今日研报:36氪研究院发布《2021年中国独角兽企业发展研究报告》,公众号后台回复“ 独角兽”,即可下载完整PDF文件。
申明:报告版权归 36氪 独家所有,此处仅限分享学习使用,如有侵权,请联系小编做删除处理。
RECOMMEND
推荐阅读
点击“阅读原文”
查看更多干货