用户故事地图读书笔记



《用户故事地图》这本书从去年买来就没有翻动过,这周花了点时间匆匆刷了一遍。感觉还是有挺多收获的,所以记录之。

概要

在敏捷软件开发中,大型需求往往需要进行拆分的,拆分后的需求我们称之为“故事 story”,故事的使用使得软件开发项目的过程进一步可视化。

但是暴力的进行需求拆分很容易丢失软件系统的全景图,导致最后得到一堆无法拼接在一起的需求碎片,或者过度陷入需求细节,而忽略了用户诉求的本质。

首先假设现在有这么一个情景:

老板 A:B,C,D 你们仨明天去上海出个差。

员工 B:好的,那我们坐火车去。

员工 C:好的,那我们坐汽车去。

员工 D:好的,那我们坐飞机去。

上面这种情景,员工B,C,D对老板给的同一份出差任务都有自己的交通工具选择。这像极了传统软件开发中,对于同一份(需求)文档,每个人的理解会有或多或少的出入,这就会导致在交付产品的时候,可能会出现功能缺少,功能冗余,功能不正确等等各种各样的问题出现。使用用户故事地图技术目的就是为了达成各方的共识(用户故事之所以流行,就是因为其鼓励在敏捷开发中人与人之间的沟通,而不是只写下故事,当然记录故事也是必不可少的,你可以拍照,视频,文字等方式来记录讨论结果)。

关于 output 和 outcome

在创意“ideas”和发布之间,所有的东西都可以叫做“输出”output,输出就是我们开发出来的东西,在开发过程中,我们可能会关注开发成本,开发速度。然而我们(老板)并不会那么关注输出,我们最关注的是这些输出所产生的“成果”outcome,成果只有在事情完成之后才能看到,但是成果的影响需要一定的时间累加,数量累加才能显现出来。

99% 的公司都是关注成果影响而不是输出的。这对绩效与业务挂钩的研发人员有利也有弊,可能你辛辛苦苦用了各种酷炫的技术加班加点完成了开发,结果这个功能需要经历 n 年时间才能出实际效果,这就非常难受了。还有一种就是你啥也不用做,通过行政手段搞定了业务需求,嘿嘿,这就是躺着把绩效升上去了,舒坦!。虽然成果只有一个度量标准,即软件给用户解决问题的方式带来了什么样的变化,但是,作为有追求的你来说,应该有着更高的理想:“你的软件是否使这个世界变得更好!”(还是先看看这个软件有没有让我挣钱吧)。

只有满足顾客和用户的需要,公司才能实现自己的诉求

大抵是从乔布斯的第一次 iPhone 发布会开始,有了“用户体验”这个词,注重用户体验就是一种关注用户的体现,但是在如今,街角那家连门都没有的黄焖鸡都喊着他们有高质量的“用户体验”,那么凭什么你的用户体验就更好呢?所以仅仅关注用户还是不够的,还要特别关注特定的顾客或者用户群,改善软件。

公司为员工发薪水,员工的目标肯定是帮公司获得更多的收入,保护现有市场,拓展新市场,提高运营效率等。这样就是良性循环,可持续发展的。如果公司不健康,员工没有充分资源可以帮助用户,而公司又没有及时调整该舍弃部分用户,重点关注能产生收益的用户群体,那么就容易很容易造成人员快速流失,软件质量低,用户群体流失等恶性循环。

产品全景图

在刚入职的时候,记得那时还没有使用用户故事地图技术来分析需求,那时应该是比较纯粹的“敏捷开发”,每隔几周就能发一个版本,确实很“敏捷”,就是有种拧螺丝的感觉,知道这种感觉吗?就是那种你知道要这么做,但是却不知道为什么要这么做,你不知道手里做的这个需求对整体项目而言有何具体影响,对用户会带来哪些便利或者收益。

后来用户故事地图在组内流行开了,几乎所有项目都会采用用户故事地图来分析,这样团队的所有成员都能对项目达成一致的理解,同时也能将比较大的用户故事拆分成小故事。

好的用户故事应该讨论什么

  • 做什么
  • 为谁而做
  • 为什么做

所有的软件开发目标从来不是开发出所有功能,而是开发尽可能少的功能(为什么是尽可能少的功能,后续会说明),所以我们就需要明确哪些用户是我们真正关注的,哪些需求是能让利益最大化的。

过用户故事地图的时候需要参与人员做什么?

思考---》记录---》讲解---》摆放

不是所有的故事/需求里只对应一个用户(嗐!刚接触用户故事的时候,天真的以为一个故事对应一个用户来着。)所以在思考阶段,我们通常会把参与的小伙伴分配以故事里的不同用户角色,每个小伙伴都以各自的角色思考在这个故事里“具体要做什么,为什么要做,做这个带来什么影响等”,然后将其记录于小纸片上。在思考完之后,所有小伙伴都要说明一下自己的想法,并将小卡片按故事顺序(时间,权重等方式)贴在玻璃墙上。

当完成了所有故事之后,我们接下来要做的就是对细节进行优化了,比如 老板 A 说去上海出差,那么这里就可以引申出“出差具体要在几点带什么东西去见什么客户完成什么任务?去上海除了海陆空还有什么其它交通方式吗?有没有什么办法不用出差也能完成老板的任务呢?如果出差过程中出现了问题该怎么处理?等”

注意:探索细节是在所有故事框架都已经完成的情况下才做的,千万不要在还在思考单个用户故事的时候就钻牛角尖。(个人的亲身体验告诉你,如果思考单个用户故事阶段就钻牛角尖的话,你的思想可能会进入死循环,更有甚者带领着整个团队剑走偏锋“剑走偏锋”,3分钟的思考,硬生生思考了 30 分钟,到最后还是无解。所以在故事宽度还没完成的时候先放过细节,如果你真的觉得很重要,那也请先把你的想法记录下来,到后面再和所有小伙伴讨论。)

计划,为了更少的开发

你有没有这样的经历,我私心里喜欢称之为“呵呵哒”。

通常的 呵呵哒 经历:有时候 PM 想要开发功能,总是超出你所拥有的“资源池”范围?(“资源池”:时间,人员,技术,精力等等)

如果你也被 呵呵哒 了,那要要怎么做?

跑!(嘿!如果跑不掉,那就把自己当作一个产品经理,把 他/她 教会。真 TMD 的心累,幸运的是我还没遇到这种情况。)

所以如何才能在尽可能避免 呵呵哒 呢?

聚焦于系统外的预期成果来决定系统内需要什么功能。(用户说要一瓶矿泉水来解渴,你别故作聪明的递上满满一盆 99.9 度的开水,还美其名曰“送温暖,送到客户心里”,相信我,用户只会觉得你把这矿泉水都倒进自己脑子里了。)

划分 MVP(最小可行产品) 发布计划

为成果排列优先级,规划好发布路线图。一般情况下第一期都是会以 MVP 发布的,第二期优化一下,第三期锦上添花,等等。

这个 MVP 其实也是比较讲究的,你需要统筹各方需求,寻找一个最小的可用可发布集,难!但是 值!。

为什么第一期一般要以 MVP 发布?

我可以举个不那么友好但是却很生动的例子:如何让一个人快速增重。如果你马上就端来各种甜品,牛,羊,鸡,鸭,鱼,鹅。估计所有人都只吃那么几口就罢了。那么如果我们先上(MVP)分量比较少的甜品,外加品相比较朴素但是味道还可以的肉,相比没有人会拒绝吧。然后第二餐在把品相较好的肉端上来,这一餐也没有人能拒绝吧。第三餐,摆盘搞起来,前菜上点酸的开胃,正菜辅以烤,煎,炸,辅以各种沙拉。嘿,这么三餐下来,基本上就是量变产生质变了。(所以什么 MVP 是第一期,就是为什么第一餐要这么选甜品和朴素的菜了)

划分 MVP 很重要的一点就是:最小化输出,最大化成果和影响。

该书中还有很多方法论,像大故事如何拆分为更小多故事,如何按时发布等,这里就不再一一总结了,有时候只有通过实践来总结,远比看书总结效果好的多。

当然或许有时间......也不会再进行补充了。

Comments
Write a Comment