Day Vision

Reading Everyday,Extending Vision

User Story Maps: Gain insights into needs, enhance collaboration, and polish your products

2022-09-16 07:13:11


However, when the team does not reach a consensus, it is likely that a function, some people will take it as a basic function, some people will treat it as a differentiated function, this is the user map and the priority model can bring changes to the team, so that everyone can agree on the division of priorities (9) The priority model book also details a use of the user story of the original


Read the overview

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

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

用户故事地图 - Jeff Patton

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

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

用户故事地图

敏捷教练建议团队把所有的用户故事都写在小标签上(黄色),而用户故事呢,就是描述谁要完成什么行为,这个行为有什么价值?打个比方说,用户故事对于我们UU来说可以是:

大型用户故事地图

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

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

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

The blue line of the above figure clearly marks what kind of functions we should implement in each version.The above functions, a total of three large versions, then how to sort the priority of these functions, we should be sorted according to the results of the implementation of it, some very large functions, if in fact we only need to implement a small part of the can get good results, then it is completely possible to take this small function out of advance implementation.For example, the above search function covers a variety of search scenarios, but the most important thing is keyword search, so it is placed in the first cycle.(8)

Another prioritization reference criterion is to clarify among team members what type of function this function is.We have such a simple priority model, which is mainly four levels, at the bottom and the most core is the basic function, and then the cost reduction function, the disruptor function and the differentiation function.However, when the team does not reach a consensus, it is likely that a function, some people will take it as a basic function, some people will treat him as a differentiated function, this is the user map and the priority model can bring changes to the team, so that everyone can agree on the division of priorities (9)

优先级模型

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

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

Version release principles