写点什么

为什么我推荐用户故事地图?

  • 2022-11-30
    山西
  • 本文字数:3294 字

    阅读完需:约 11 分钟

为什么我推荐用户故事地图?

最近在给几个客户的培训和辅导中,都用到了用户故事地图(User Story Mapping or USM),越来越发现 USM 是一个强大的工具。USM 有它特殊的妙用之处和适用范围,我们不用指望 USM 能解决多的问题,比如产品架构和用户体验旅程就不在 USM 的范围。我还是有一种强烈的意愿想把用户故事地图 USM 推荐给 PO 和 SM 或敏捷教练,静下心来写一篇短文,与大家共勉。


记得早在 2016 年 11 月,清华出版社准备发布 Jeff Patton 的《用户故事地图》中文一书之前,文开琪老师和上海敏捷社区的核心成员组织了一场工作坊,译者李涛分享了本书的精华,大家都觉得 USM 很实用。后来我的 CSPO 课件加上了 USM 演练,学员敏捷工具箱里多了一个工具。

我认为,用户故事地图最重要的贡献,就是把 Scrum 框架下的最重要的工件,一维的产品待办列表变成了二维,原来的产品待办列表(flat product backlog)只见树木,不见森林。


用户故事地图到底是什么?用户故事地图是从一个典型用户的视角开始,围绕一个大的目标,从左到右列出用户为达到目标需要实施的每个步骤(steps),多个步骤聚集成一个活动(Activity)。

参考下图电商平台系统所示:



用户活动就是主干(backbone),USM 的一些术语定义如下。

这些定义和术语并不重要,也不用太纠结和区分,实际上就是考虑两个维度:任务的宽度和深度,宽度是不同功能的排列。首先要识别基本的功能,不要忽略或漏掉,先专注宽度的讨论,引用 Jeff 的原话“go a kilometer wide and a centimeter deep”。USM 的一个好处是对于某特定的用户,保证功能完整不缺失。深度是对一个功能的细化和优先级排序,包括用户任务或子任务的多个变化的实现,替换方法,异常情况等细节。通常情况下,我们会习惯花费很多时间在这个维度上讨论,过于细节化,反而会忽视横向基本功能是否完整。当然,有时候要用便签标注“需要研究“,“开口问题”或“有差异”。以避免讨论走的太远,能够刹车。后续可安排 follow-up session,邀请相关人员讨论细节。比如产品待办列表的梳理(PBR)活动,估算大小,分解细节,Kano 方法投票优先级等等 。

 

USM 是规模化敏捷(Scaling)的一个非常有效的工具,它把业务,开发,干系人拉在一起,做半天或一天的工作坊,正是多团队的参与,相互检查,避免出现功能漏洞(hole),包括第三方单位的协作和支持。横向维度的步骤,不同功能的依赖关系容易看出来,但团队之间的依赖需要讨论,识别并在用户故事地图上可视化出来。

 

用户故事地图的工作坊设计,有经验的引导师引导,控制对细节的力度,同时要做好充分的准备工作。

 

用户故事地图能解决哪些产品开发中经常碰到的问题?有哪些好处?

(1)系统思考,展示一个大全貌(A Big whole picture)。

传统开发团队成员面临最大的一个困境是,每天疲于埋头开发功能和完成任务,抱怨看不到一个产品或项目整体的全貌和架构,工作没有尽头和动力,即没有目标感和成就感。


那些还没有被“麻木”的工程师,即不被业务人员强势所左右,不被商业合同所束缚的新生一代,开始寻思:这些无休止加班加点开发的或即将开发的功能,客户真的会用吗?反问业务,要开发什么?为谁,为什么?这几年人们炒得很火频度很高的一个词汇---“价值”,开发以目标为导向,客户为中心。


USM 从产品愿景出发,框定问题,是给谁的?我们为什么要构造它?特别是对复杂的产品,系统或服务。我们都熟悉规模化敏捷的框架,比如 SAFe 或 LeSS,但涉及到多团队参与的敏捷开发,如何去创建一个发布计划,Scrum 指南也没有描述。USM 让每一个开发人员开始关注和理解业务,在项目初期看到一个高阶计划和一个全貌图;PO 把握产品方向和目标,SM 利用 USM 工具引导实践落地。实际操作中,也可以先做设计思维(DT),再做 USM 的练习,然后是产品待办列表的梳理活动(PBR)。


如果你有机会观看 TED 视频“如何烤土司(how to make a toast)”,用户故事地图的活动背后是系统思考的过程。一群人,不同的背景,围绕一个目标和问题,针对某一类典型用户,头脑风暴讨论解决方案。对话的发生和思想火花的碰撞是 USM 的核心。卡片的形式,简洁方便,挪动灵活。


(2)增量式的发布计划,使需求范围管理可控。

我们发现一个不争事实,比起有限的人力资源、时间或金钱,人们总是期待有更多的东西开发构建。我们过多关注功能的开发(output),忽视目标或成果(outcome),用户故事地图的“横向切一刀”的策略(见下图灰色胶带),是非常聪明的一步。



这一“刀”,帮助我们解决了以下问题:

  • MVP 概念在 USM 中妥妥落地了。MVP 帮助我们识别最大的假设和风险,花最低的成本和最短的时间去实验或测试产品的想法,以期达到学习的目的。MVP 与 USM 的第一级用户故事不谋而合,它们组成了用户故事地图发布版本 1 的第一次切片(slice) -- “行走的骨架” (functional walking skeleton),检测系统基本功能是否工作,就是 MVP 的具体应用。 

  • 增量式的发布策略和预算管理。(参见我的敏捷发布和预算一文)。即使是只有一个官方版本的发布,也要有开局(open game),中盘(middle game),收尾(close game)的开发策略。开局部分多关注风险和技术挑战。

  • 产品路线图,每个发布的目标是对产品目标的分解和分步实现,敏捷产品的路线图与传统的产品路线图有非常大的不同,这里暂不讨论。

  • 需求范围可控,参与 USM 讨论的成员都非常清晰,我们在不同的发布层面上聊眼前的或是未来的需求,不用担心需求丢失或被忽视。要注意的是,USM 只是一个时间点的快照(snapshot),它在不停演进和更新,并不是一成不变。


总之,尽管 Scrum 框架没有提及发布计划的具体操作,USM 作为一个模式语言(Pattern)正好给与补充。  

(3)“共创”的过程,人人都参与。

一个优秀产品的打造,过程要重于结果。USM 这个工具,提供我们一个非常可操作的步骤“支撑”这个过程。回到现实,组织中的研发和业务通常有部门墙,两张“皮”,貌合神离,互相扯皮。在时机和勇气不具备对组织架构做“手术”的情况下,部门墙存在和甲乙方不平等的关系,USM 或许是”Bring People Together”最好的方式之一。不同的产品,USM 活动通常一个季度做一次,不需要每周都做。


这让我想起了几年前做过一天 USM 的工作坊,业务人员在广州,交付的外包团队在上海,甲方的项目经理是一个“光杆司令”。当时把业务人员请到上海,成本确实很高,用他们的话说,这样做“太奢侈”了。这个外包团队签的是固定报价合同,人员不稳定,合作三年,业务和研发外包团队从来没有见过面。这一次 USM 工作坊算是破天荒,下了决心,停工一天,没有一行代码输出,但结果非常让人兴奋:特别是外包交付团队,终于有机会与业务面对面的对话,不像过去,要么靠文档传递需求,要么依赖项目经理的理解来解读,要么就由开发人员“猜测”。可以想象,这里面有多少误解,有多少返工和浪费,一天的差旅成本是容易度量的;没有人算这个账,产品开发过程中开发对业务理解的不对称会带来更大的浪费。就其原由,根因是大家只看自己碗里的东西,没有一个共同的目标对齐和驱动,这个目标就是产品的目标。


USM 正好补缺了在传统组织架构下人们沟通和做事的方式,工作坊的形式事件(event)优于传统的会议(meeting)和报告。



研发通过对话理解业务需求和场景,业务确认研发对需求的验收标准。USM 中的用户故事卡片,就是围绕 USM 最上面活动的目标,分解成不同的子任务(sub-task)去实现。对话的过程就是双方对需求理解达成共识的过程,也是共创的过程。这种工作氛围下,双方是平等和开放的对话。从不同的维度和视角,依据自己的理解,贡献自己的想法, 包括:市场和销售,业务,开发,测试,架构,UI/UX,用户和客户,IT 和运维,人人都参与,大家都是产品团队的一员,这才是现代的工作方式,也是我们倡导和追求的。


写此短文,只是对 USM 话题开个引子,欢迎大家讨论。如何具体通过工作坊的形式去组织和引导 USM,我邀请大家参加近期的 CSPO 课程体验 USM,期待后续有机会在企业内部实操,围绕一个产品来让团队实际演练,熟悉和掌握 USM 的精髓,使敏捷企业早早受益。 


Jim Wang 王军 

写于 2022 年 11 月 25 日


参考资料:

(1) CSPO 教材

(2) 《User Story Mapping》by Jeff Patton

(3) http://winnipegagilist.blogspot.jp/2012/03/how-to-create-user-story-map.html


课程报名联系

Toby 171 5214 1688 {电话/微信同号}

发布于: 2022-11-30阅读数: 3
用户头像

还未添加个人签名 2022-05-24 加入

还未添加个人简介

评论

发布
暂无评论
为什么我推荐用户故事地图?_Scrum_ShineScrum捷行_InfoQ写作社区