【UXRen译#07】告诉产品经理，用户故事(User Story)远胜过产品需求文档(PRD)
在上一篇文章中，我们关注的是产品经理如何和工程师分享客户知识。我们讨论了用户角色对于讲述客户故事来说是一个多么有效的方式。我们也审视了一些团队如何通过可用性测试获得的成果（视频、音频、书面报告）来交流产品，以促进对客户痛点的沟通。但是，对于产品经理如何和工程师分享客户知识，我遗漏了的一个关键的途径——用户故事。
以前（比如互联网出现之前），产品团队撰写产品需求文档，长长的文档概述了产品的方方面面。仍有一些团队还在沿用这一工作方式。但是很多团队已经转变成以用户故事的方式撰写产品需求了。用户故事的形式如下：
- 作为某个角色，可以为了某种价值而进行某些活动
让我们依次看一下每个部分。首先，角色。我发现用户故事往往会从“作为一个用户……”开始，这是毫无意义的。角色的关键是要获取一个视角。举个例子，比如我在为一个与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 条回复
[…] 译者：金步摇 ;审校：Fly […]