99%的用户故事,写的都是渣

scrum-rugby
Scrum和Sprint名词的历史和误区
2019年8月18日
教练成长之路(PCMP辅导项目)
2019年9月6日

前言

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描写则可适当简化。

评论关闭了。