如何对产品编写一个完整的用户故事?

初一
2018-01-08 看过
在工作中,多数人都只是一个被动的执行者。比如,现在让你调查北京市近期卖了多少小龙虾,没有人告诉你为什么要做这件事,你可能会理解偏差,以至于提供错误的数据,甚至对于领导指派给你这种“毫无意义”的工作感到不满。

如果换个说法:作为水产供应商,我想要了解近三个月北京市小龙虾的销售情况,以便安排后期的货源。这种说法是不是明确多了?

工作中无谓的消耗时间是最可怕的。往往员工没有得到足够的信息,而上司也没有为下属提供足够的信息。要知道,人们习惯于用情节、故事去思考问题。大家都是这样来理解世界的。我们比较容易掌握人物、欲望及动机等,当我们试图把个别片段从主线中剥离出来,脱离具体语境去理解它们时,就会出现问题。

“Scrum之父”萨瑟兰博士在《敏捷革命》中,提倡要学会写 “用户故事”。用户故事是从用户的角度来描述用户渴望得到的功能,这种方法不仅仅可以用在产品设计上,也可以用在每一个人的工作中,它能帮你确定目标,完成意志、动机、决心的统一和实践,避免徒劳无功的浪费。

 
不要盲目执行,要学会写用户故事

当你面对一项任务时,要学会从用户的角度来描述用户渴望得到的功能,也就是要学会写“用户故事”,比如作为X,我想要Y,所以Z。

一个好的用故事包括三个要素:

第一个要素是角色,包括顾客、读者、员工、老板等,这就要求我们思考:谁要使用这个功能?这项任务是为“谁”而做的?打造这样东西、做这项决策、提交这项成果,我们应该从谁的角度出发?

第二个要素是活动,要求我们思考我们要完成什么样的功能。这通常是我们的出发点,也是落脚点。

第三个要素是商业价值,或者说动机。要求我们思考客户为什么需要这个功能,以及这个功能如何才能给客户创造价值。从某种角度来看,这是最重要的一步。动机重于一切。

需求往往会因为人物的不同而改变。比如,一则故事的后半部分是: “……我想要一辆车,以便开车上班。”假如这则故事的前半部分有两个版本:一个是“我是住在郊区的通勤族”,另一个是“我是居住在南达科他州荒芜之地的农民”,那么,你对于这个人心目中理想的车型,就会有截然不同的解读。

因此,在确定待办事项的优先顺序之前,必须先考虑一下有关的人物、使用者或客户,也就是说你的劳动成果将由谁来使用。你要了解他们的喜好、厌恶、激情、热情、沮丧及喜悦是什么,他们的使用动机是什么,以及用户类型对于自身需求的影响。他们为什么需要汽车?他们用舰长日志做什么?这也会影响你对事情的评估。比如,如果他们需要的只是一般日历功能,那就简单了,如果他们需要的是可用于法律目的的、不容更改的日历功能,那就有点棘手了。

用户故事宜短不宜长

用户故事宜短不宜长,以便于对其进行评估。试想一下,如果亚马逊让你设计产品,你会怎样撰写它的用户故事。你可能会写道: “用户想要一家全球最大的在线书店,这样用户随时都能买到想要的书。”这个用户故事的确概括了亚马逊的情况,但太宽泛,不具有指导意义,必须分解成小故事。

• 客户希望能按照类别浏览书籍,以便轻松找到自己喜欢的那一类书。
• 客户希望能够先把书放进购物车里,以便在之后某个时间购买。
• 亚马逊的产品经理希望能追踪客户的购买记录,以便有向客户推荐特定的书籍。

上述这 3 个用户故事都是非常明确和具体的,用户故事必须细化,能够对具体实践提供指导,但是不要预先制订落实方案。切记,工作如何执行必须由团队自行决定,至于成果该是什么,则取决于商业价值。如果把线上书店的所有因素都拼凑到一起,写成用户故事,那么这种用户故事常常可以合称为“长篇故事”,通常是很宽泛的,无法指导具体行动,但可以将其分解为多个具体的小故事。

当你开始写用户故事时,你就知道自己必须从某件事开始做起,写完用户故事,你会知道用什么来支撑自己的目标,接下来用户故事会指导你进行冲刺。


用户故事必须完整,任务必须彻底完成

在你撰写用户故事或列出待办事项清单时,有两个问题很重要:用户故事够完整吗?你如何才能知道自己已经完成了任务?

比如,我们看看一位朋友写的用户故事:“作为军队的医生,我必须为学生们传授基本的生理学知识,这样他们才能了解人体构造。”

关于一则用户故事是否完整,我经常用一套标准来衡量。一个好的用户故事应该满足以下标准:

独立性——尽可能让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制订计划、确定优先级和工作量评估都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性——用户故事的内容要是可以协商的,用户故事不是合同。一张用户故事卡片上只是一个简短的描述,不包括太多的细节。具体的细节在沟通阶段提出。如果一张用户故事卡片带有太多的细节,实际上会限制和用户的沟通。

有价值——每个用户故事必须对客户具有价值。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事,并不是一个契约,而且可以进行协商的时候,他们将非常乐意写下故事。

可评估——开发团队需要衡量用户故事,以便确定优先级和工作量,并便于安排工作计划。

规模小——一个好的故事要尽量维持小规模,至少要确保在一个冲刺周期中能够完成。用户故事越大,在安排计划、工作量评估等方面的风险就会越大。
  
可测试——一个用户故事要可以测试,以便确定它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。

这位朋友的的故事是独立的,因为他的学生们都在同一个城市,他不必考虑学生们在路程上的损耗,他能够独立完成任务。他的故事是可修改的,因为虽然他一开始打算为学生们传授基本的生理学知识,但如果他发现学生们已经具备这样的知识,或是已经有了一定的了解,那么他有其他的教学方法可以用。他的故事有价值:学生们学到人体知识之后,可以派得上用场。他的故事规模小:他只给学生们传授基本的解剖学知识,而不是教他们运用这些知识去开展外科手术。他的故事可测试:他很清楚自己想要传递的信息,也可以 对学生开展一些小的测试,以便确认他们是否真的吸收了这些信息。

每个有待落实的用户故事都应该要有“完整”的定义。在现实中,我们发现,如果用户故事足够完整,那么团队在落实项目的过程中速度就会加快一倍。此外,如果一个阶段的冲刺完成了相应的用户故事,那么,这个团队的速度会再次加快一倍。这就是我们能够达到事半功倍之效的一个原因。
0 有用
0 没用

查看更多豆瓣高分好书

评论 0条

添加回应

敏捷革命:提升个人创造力与企业效率的全新协作模式的更多书评

推荐敏捷革命:提升个人创造力与企业效率的全新协作模式的豆列

了解更多图书信息

豆瓣
免费下载 iOS / Android 版客户端