【UXRen译#07】告诉产品经理,用户故事(User Story)远胜过产品需求文档(PRD)

story_on-index-card

在上一篇文章中,我们关注的是产品经理如何和工程师分享客户知识。我们讨论了用户角色对于讲述客户故事来说是一个多么有效的方式。我们也审视了一些团队如何通过可用性测试获得的成果(视频、音频、书面报告)来交流产品,以促进对客户痛点的沟通。但是,对于产品经理如何和工程师分享客户知识,我遗漏了的一个关键的途径——用户故事。

以前(比如互联网出现之前),产品团队撰写产品需求文档,长长的文档概述了产品的方方面面。仍有一些团队还在沿用这一工作方式。但是很多团队已经转变成以用户故事的方式撰写产品需求了。用户故事的形式如下:

  • 作为某个角色,可以为了某种价值而进行某些活动

让我们依次看一下每个部分。首先,角色。我发现用户故事往往会从“作为一个用户……”开始,这是毫无意义的。角色的关键是要获取一个视角。举个例子,比如我在为一个与eVite或Facebook events类似的活动网站写用户故事,我会这样开始:

  • 作为活动的主办者……
  • 作为活动的被邀请者……
  • 作为活动的参与者……
  • 作为不能参加活动的人……

这告诉工程师谁将会使用这个功能。它看上去似乎有些微不足道,但我无法告诉你由于角色被误解导致了多少次错误功能的开发。

 

接下来,让我们看一下“……进行xxx活动……”,这是用户故事中最像产品需求文档的部分。对于同一活动网站,我们会:

  • 我可以邀请朋友参加活动
  • 我可以答复活动邀请
  • 我可以查找活动地址
  • 我可以查看活动照片

这确切地告诉工程师需要什么新功能。最后,让我们看一下“……为了xxx价值……”。我发现用户故事的这个部分多半被去掉了。真的,从技术上讲你不需要知道要开发的是什么。但是去掉它,你错过的是所有的背景信息,即为什么你现在要开发正在开发的功能。继续拿我们的活动网站举例,我们会获得接下来的价值:

  • 以便我容易管理参加者
  • 以便让举办者知道我是否会参加
  • 以便我容易到达活动地点
  • 以便我可以和真正参加了活动的人一样感同身受

这个活动网站的例子十分简单。但在更复杂的产品中,价值通常可以消除对于为什么要开发特定功能的误解。它也有助于将关注点放在角色身上。不能说你在开发功能,因为你只是为了满足产品需求而开发的。

用户故事并不仅仅告诉工程师要开发什么,还告诉为什么(要开发)。与产品需求文档相比,这是用户故事独特的优势。当然,没有什么可以阻止你把为什么写在产品需求文档里。而且确实,很多人把用户故事写得很烂,忘记清楚界定角色或者完全将价值遗漏了。但是,作为产品经理,让我们关注一下什么是我们可以控制的。

设想一下我写了一个很棒的产品需求文档。它不只说明了工程师要开发什么,而且还提供了所有必要的客户知识来说明开发此功能的背景(原因)。比如它有15页。我把它提交给我的工程师。会发生什么呢?

他们也许会从头到尾看一遍。之后,他们可能会参考截图,或者当他们开发的时候略读一下寻找技术相关的内容。他们忽视了什么呢?所有(关于开发这些功能)的原因。

现在让我们猜想一下,我写的是50个用户故事,而不是15页的产品需求文档。我把他们提交给工程师。会发生什么?他们也许会从头到尾读一遍50个用户故事的清单。那还不错!因为接下来发生的事情,他们从第一个用户故事开始着手而忽视了剩下的。但是,当工程师实现每一个故事的时候,这些故事的前面就正好有原因,说明角色信息、阐释渴望的行为和价值。他们绝不会忽视那些内容,即他们为什么正在开发他们正在开发的。

回顾前两篇帖子中讨论的一些概念,用户故事是一个很好的媒介。通过这个媒介,两个不同知识领域的团队之间可以进行知识共享。产品经理有丰富的客户知识,工程师有丰富的技术方面的专业知识,用户故事使得产品经理在他们共同致力的功能开发的范畴内,和工程师沟通与客户相关的少量知识。

人人皆赢。

文章的要旨:写好的用户故事,明确界定角色,同时要格外关注价值。

 

译者:金步摇 ;审校:Fly 
原文作者: Teresa Torres; 发表时间: April 24, 2012
原文链接:http://teresatorres.com/producttalk/2012/04/user-stories-are-better-than-prds/
顶部图片来源:www.agiletesting.info
版权所有:UXRen翻译组 (转载请注明出处!)
 
 

1 条回复

发表评论

您的电子邮箱地址不会被公开。