Day Vision

Reading Everyday,Extending Vision

用户故事地图:洞察需求,增强协作,打磨产品

2022-09-16 07:08:20


然而当团队没有达成共识的时候,很可能一个功能,有的人会把它当作基础功能,有的人又把他当作一个差异化的功能,这就是用户地图和优先级模型可以给团队带来的变化,使大家对优先级的划分达成一致的理解(9)优先级模型书里还详细介绍了一个使用用户故事的原


阅读概述

说我是UU的产品策划 - 李彦晨,主要负责移动端的需求分析和具体方案执行。最近正好阅读了助教推荐的这本用户故事地图,所以今天借这个机会就和大家分享一下我对这本书粗浅的认识。(1)

这本书是由OReilly出版社出版的,OReilly发行了非常著名的动物封面系列丛书,在软件行业的专业性毋庸置疑。这本用户故事地图是有关软件开发流程和用户体验设计的。作者Jeff Patton拥有十几年的产品经验,做过线上飞机零件预订、电子病历卡等业务,涉足非常广泛。他目前的身份是咨询师,敏捷过程教练和产品设计过程教练。简单来说就是自己成立一个考试协会,负责培训和考核Scrum Master(敏捷项目管理),所以这本书呢也是比较适合产品经理和产品负责人去阅读(2)

用户故事地图 - Jeff Patton

这本书总体感觉是比较难读的,因为他想传达的理念非常多,也的确都具有很高的价值。书的思想是团队成员之间应该如何用讲故事来指导功能规划,需求拆解和版本迭代。当需求特别零散的时候,每个用户故事会非常的独立,如果团队自身都不够理解,那开发出来的产品好像是由不匹配的部分拼凑出来的。这样在用户看来,这样产品就像“科学怪人”。所以书的内容是希望团队能够把故事都串联起来,功能协调的更加紧密,团队的发展目光更为一致。(3)

那到底什么是用户故事和用户故事地图呢?

用户故事地图

敏捷教练建议团队把所有的用户故事都写在小标签上(黄色),而用户故事呢,就是描述谁要完成什么行为,这个行为有什么价值?打个比方说,用户故事对于我们UU来说可以是: 用户想在UU移动端内下载外服游戏,因为他只有先下载了外服游戏才能进行加速。 这样一个故事呢,就是Who, What, Why,这三个要素都比较完整。(4)

大型用户故事地图

怎么样把用户故事都拼接在一起呢,敏捷教练建议团队每两周作为一个讨论和开发周期(Sprint),所有成员围着一张圆桌坐下来,不管是产品经理、还是工程师、QA、设计师都用一张便签把自己想到的用户故事贴上去。最上面的蓝色标签是故事的主干。主干可以分为两级,在上面这个邮箱软件的例子当中呢,第一级就是 整理邮件、管理邮件、管理日历和管理联系人。每个故事主干呢有都有下一个层级的细分,比如说,搜索邮件啊、邮件归类啊、阅读和删除邮件。其实我们完全可以用一个层级来表述,只有当一个层级太长的时候,划分成两级才更有意义,区别只有颗粒度不同而已。(5)

这样的故事地图呢,很像动物的脊柱,脊柱下面长着长长的肋骨。这些肋骨呢,都是在帮助实现这些用户故事。同样在每周的会议上,成员们应该多去脑暴,或者说用HMW的方法,去实现这些场景下用户的问题。对于已经实现的功能呢,我们给他贴上一个小标签(done),还在实现过程中的呢,另一个种小标签(WIP)。这样一个完整的地图呢,可以让产品团队的所有成员对需求的优先级和连贯性有一个完整的认识,而不是说产品策划只知道我手上的功能,工程师只知道我手上的开发项目。(6)

有了这样一个地图呢,我们就会发现,要做的总是太多,如果要完成地图上所有的事情,可能需要大概两年的时间吧。而且工程师们和设计师们往往都会非常理想,认为这个产品要交付了,所有这些都应该全部完成再交付。然而,作为产品负责人呢,作为CEO呢,最关心的应该是我怎么样能够把一个基础功能没有问题,可以满足需求的产品尽快的推出,去抢占这个市场。这也就是我们为什么要划分MVP发布计划,和发布路线路。(7)

上面这个图的蓝线,就是清楚的标注了每一个版本我们应该去实现什么样的功能。上面的这些功能,总共排了三个大版本,那这些功能的优先级是如何排序的呢,我们应该按照实现它的成果来排序,一些很大的功能,如果实际上我们只要实现很小一部分就能获得不错的成果,那么完全可以把这个小的功能拆出来提前实现。比如上面这个搜索功能,涵盖的就有各种搜索场景,但是最重要的是什么呢,就是关键词搜索,因此它被放在了第一个周期里面。(8)

另外一个排优先级的参考标准呢,是团队成员间明确这个功能是什么类型的功能。我们大致有这样一个简单的优先级模型,这里面主要是四个层级,处于最底层也是最核心的是基础功能、然后依次是降成本功能、搅局功能和差异化功能。然而当团队没有达成共识的时候,很可能一个功能,有的人会把它当作基础功能,有的人又把他当作一个差异化的功能,这就是用户地图和优先级模型可以给团队带来的变化,使大家对优先级的划分达成一致的理解(9)

优先级模型

书里还详细介绍了一个使用用户故事的原则,就是3C原则, Card:在一堆卡片上写下你期望的软件性能;Conversation:聚在一起对要开发的软件进行深入讨论;以及Confirmation, 对完工条件进行确认。Card就代表了一个有待商榷的需求池,但是因为有故事,更加生动;但是呢,不是所有的故事信息可以用卡片来记录的,因此,conversation完成了第二部。在传统的软件开发流程中,需求分析人员是准确描述需求并把它写入文档,软件开发人则需要正确理解文档所传达的意思。而在这样故事驱动的流程中呢,需求分析人员和软件开发人员一起工作,对需要通过软件接决的问题达成一致,并努力找到解决问题的最佳方案。下面这句话或许是整本书最为关键的一点吧:“我们在一起讨论用户故事,力求对要解决的问题达成一致理解,并努力找到可以解决问题的最佳方案。”(10)

今天的分享就聊到这里,如果大家对这本书,可以到我这里来解决,在分享一张比较有趣的图:(11)

版本发布原则