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

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”开始，那你一定能少走很多弯路。

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

作为一个系统管理员我希望可以删除账户信息，以避免账户被非法利用.

作为一个繁忙的每天处理上百个账户变动请求的系统管理员,我希望可以删除账户信息，以避免账户被非法利用

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

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

Scrum和Sprint名词的历史和误区

教练成长之路(PCMP辅导项目)

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

admin

相关文章

敏捷教练的新挑战：用数据驱动团队效能

Sprint回顾：连接过去与未来的敏捷桥梁

定价策略揭秘，10种模型助力制胜市场