99%的用户故事,写的都是渣-敏捷教练 管婷婷

​前言

Preface

前面写了一篇文章,讨论用户故事该怎么写--“用户故事中的Why的两个常见错误”。这篇文章中列出的tips,如果在实践中都能做到,那么写出来的用户故事质量即可超过80%常见的用户故事,但是写对了“Why”的用户故事,仍然可能是个渣故事

很多人觉得用户故事很简单,容易掌握,这个常见的错误印象,归功于其简单的格式:

然而越简单的东西,反而越容易让人放松警惕,自认为已经完全掌握,从而错过进一步探究和学习的机会。

另一个常见的错误印象是,写出高质量用户故事的关键在于是否能写对“Why”,也就是说,是否能够准确描述用户希望获取的价值。这个观点只对了30%。即使“Why”准确的反映了客户所期望的“价值”,这个用户故事仍然可能是个故事。

举个例子,一个餐饮点评网站的用户故事可能是这样的: 

作为一个用户,我希望看到某个地址附近的餐馆的公正的评论,这样可以决定去哪里吃饭

如果你觉得这个用户故事写的还不错,那你就错的离谱了。

什么是“渣故事”?

用户故事本质是另一种格式的需求文档。那么什么是渣需求文档?就是你照着它开发, 做出来的东西客户不接受,发回来重新改,严重的质疑你们的能力。

很多人认为,既然“Why”都写对了,为何客户还不接受?如果你跟我一样,常年需要直面客户,跟他们探讨澄清需求,那么你就知道,千万不要高估两件事,一件是自己的理解能力和表达能力,另一件是客户的理解能力和表达能力

即使我们遇到了最理想的情况---客户看起来准确描述出了他想解决的问题。然而最终解决这个问题却未必就能帮他脱困,因为它可能仅仅是某个根源问题造成的诸多后果之一。

IT项目中,由于需求反复改变而产生的消耗里面,有一半是为交付者的理解表达能力买单,另一半是为客户的理解表达能力买单。

由于这种现象客观存在,导致用户故事中的“Why”的可信任度并不如传说中的那么完美。

有聪明的读者读到这里,可能会说,Why不应该是仅仅来自客户的描述,在PO撰写(或指导团队撰写)Why的时候,应该基于对客户深层需求的了解。这种观点正确,但是还不够

熟悉高质量需求调研流程的人都应该知道, 需求调研是从了解“客户是谁”开始的,有一个工具叫用户画像(Persona)。它列出了客户群体的各种特征,它的作用是帮我们弄清楚产品需要获得什么样的客户的认可和接受。

*将使用者群体的特征抽象成标签

然而大部分的项目中,用户画像只是项目一开始的时候被使用,随着需求的澄清和分解,人们慢慢迷失在具体的工作和无数的细节里,有几个人在分解用户故事的时候,在考虑解决方案的时候,脑子里还能浮现出最初的用户画像来?

想象一下,在设计和交付每一个具体的,最小颗粒度的功能时,都能够参考该功能对应的用户画像,那么开发出为客户所喜爱的功能的机会就会大大增加。用户故事这个工具,其实是提供了解决方案的。 

我们用文章一开始的用户故事来举例,假想一下你是研发团队的成员,当你在迭代计划会议上看到下面三个用户故事时,你脑子里想到的解决方案会有何不同。

作为一个用户,

我希望看到某个地址附近的餐馆的客观的评论

这样可以决定去哪里吃饭

这种格式的用户故事,是“As a user”开头的。那么从交付产品的角度,什么是客观的评论?根据有限的信息,你会联想到的只能是评论是正常发布的,排除水军刷出来的,排除同行故意抹黑的之类的功能点。

作为一个白领订餐用户,

我希望看到某个地址附近的餐馆的客观的评论,

这样可以决定去哪里吃饭

这种格式是“As a role”开头的,而且标注了一点用户的特征--办公室白领群体。比“As a user”似乎具体了一点,然而“客观”这个词对于这个客户群体,又有什么特别的地方呢?我们对需求的想象空间仍然有限。并且只能做一些一般意义上的猜想。

我们看一下另外一种写法:

作为一个在国贸工作,午休时间短,又追求健康饮食的公司白领,我希望看到某个地址附近的餐馆的客观的评论,这样可以决定去哪里吃饭。

这种格式,开头则是“As a persona”开头的。有了persona做参考后,我们知道除了 “客观” 除了评论本身是否造假之外,最好还能体现出食材质量,营养搭配,上菜速度等相关评论是否客观。于是就有下图所示的种解决方案浮现出来:

统计健康,营养类,排队这一类词出现的频率。同一词条,反复出现的可信度自然要高一些,从而给用户提供“客观”一些的参考。

通过上面的对比,我们能明显体验到,使用“As a persona”这种格式来书写用户故事,能够帮助交付团队在探索what的细节时,更容易的站在用户角度思考,从而提升最终交付物为客户喜爱的可能性

你或许觉得这个功能通过其他渠道也最终能探索到。但是如果你从“As a persona”开始,那你一定能少走很多弯路。

我们再通过一个例子感受一下:

作为一个系统管理员

我希望可以删除账户信息,以避免账户被非法利用.

VS

作为一个繁忙的每天处理上百个账户变动请求的系统管理员

我希望可以删除账户信息,以避免账户被非法利用

基于前者,在设计“删除账户信息”功能时,可能只能想到一般意义的删除操作及其相关功能。但是结合操作者是一位“繁忙的,每天处理大量账户请求的”人,那么在设计“删除”功能时,就会浮现出一些需求,例如快速,安全,错误示警,出错后迅速回滚等等,而且它们非常必要

Persona 和Why是一对参考,共同提供了非常有价值的信息。缺少任何一半,都会让你的需求传递不完整。而双剑合璧,则能帮你解决诸如“技术人员不懂客户”,“需求传递的时候理解不一致”之类的亘古难题。

实践Tip

 1:用户画像(Persona)包含的信息比较多,如何写进短小的user story?

在书写具体的User Story的时候,我们只需要从Persona选取几个跟该用户故事相关的几个关键词来加工“As a persona”。

这种操作本质上,是随着需求的分解而分解Persona,从最高级的需求,到最小颗粒度的需求,都有Persona的影子存在,指导我们“做正确的事”。

2: 把Persona挂到你的项目板上。

对于小型的项目,可以直接将Persona挂在项目白板上。

作为稍大型项目,Persona会包含很多种角色, 描述也会变得很复杂。团队可以根据某个Release所要实现的功能,提取功能要服务的Persona,挂在Release板上。

同理,也可以根据Sprint所要实现的功能,提取功能所要服务的Persona,挂在Sprint board上。如果你能够提取Sprint persona,那么具体用户故事中的Persona描写则可适当简化。

下篇预告

最近有个朋友问了我一个问题--

研发团队如何管理琐碎的,突发性的任务。

这个问题我真的被问了无数次了,回答的有点烦了,总结一部降龙十八掌,送给有缘的少年,然后这个话题就此别过吧。

喜欢这篇文章的你一定还喜欢

普通项目文档和敏捷项目文档的差别

敏捷团队怎么做,能让你的PO随叫随到

这么写敏捷文档,让BA/PO不再“瞎”忙!

写好敏捷文档,让需求分析人员(BA)失业

用户故事中“Why”的两个常见错误

关于我

About Me

管婷婷

敏捷|设计思维|领导力

关注公众号阅读更多实践

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,088评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,715评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,361评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,099评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 60,987评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,063评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,486评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,175评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,440评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,518评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,305评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,190评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,550评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,880评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,152评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,451评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,637评论 2 335

推荐阅读更多精彩内容