产品经理们,今天我们讲“故事”(上)

对于所有的产品经理来说,把市场的问题,导出为需求,并进一步把需求形成有价值的产品特征,最后把这些特征形成可供其它业务团队参考和执行的说明,这个工作最终会以需求文档的形式的呈现出来。

而这类文档通常就是我们所说的产品需求文档(PRD,Product Requirement Document),其实PRD只是我们呈现产品需求的一种文档形式,除此之外,还有用户故事(User Stories,采用了align开发模式的朋友可能对这个比较熟)和工作故事(Job Stories)这两种形式。

那么,为什么同样都是为了说明需求和特征,而有这三种不同的表现形式呢?

这就得从每种形式所具有的优势和不足来说明了。

1、传统形式:PRD

先来看PRD,国外把这种形式称为是“传统需求模式(traditional requirements)”,这种形式应该是最早出现的,从根上说,是基于IEEE的定义制定的。

IEEE认为,需求是一种声明,它识别了一个能力、物理特性或质量因素,这些因素限定了要追踪的一个产品或过程的问题(a requirement is a statement identifying a capability, physical characteristic, or quality factor that bounds a product or process problem for which a solution will be pursued.)。

不过在IEEE的定义中,他们认为一个产品的需求类型说明只应该包括5个方面,分别是:功能;性能;约束条件;接口;安全。

但是对于一个产品来说,事实上涉及到的需求并不限于此,因此,还有8个非IEEE认可的需求部分需要进行说明,这样算下来,一个完整的PRD其实是应该含有13个部分的,见下图:

关于这类PRD的撰写,大家可以参看《【模板】手把手教 · 如何写一份更神的 · PRD》这篇文章。

但是,这种形式的PRD有一些不足,主要有三点:

1、PRD更多的是说明了产品要实现的能力;

2、PRD无法让相关执行团队清楚的知道目标客户到底希望解决什么问题;

3、PRD通常篇幅会非常大,相关团队很少有耐心认真阅读。

总之一句话,PRD是基于“产品”的角度,而非“客户”的角度的一种需求说明形式。

有朋友会问了,我有其它的文档对目标客户有说明啊,没错,你是有,但是开发团队会看吗,并且最为关键的一点是,如果分为多个文档,对于产品经理来说不是问题,但是对于开发团队来说,就是问题了,他们是不太会有耐心去把客户细分、客户问题、需求说明、产品规格等独立的文档整合起来去看的,并且还涉及到一个文档保密级别的情况。

同时呢,PRD还有一个先天的缺陷,就是因为它是IEEE定义的,因此,它更多的是适用在IT、电子行业,而几乎无法在其它行业应用。

但是,随着现在很多企业开始越来越倾向于“市场驱动”的产品发展模式,以及希望越来越快,越来越准确的推出产品,让产品团队中更多的成员了解我们的客户和他们的问题,从而能够更到位的设计出解决方案,因此,需求的呈现就出现了“用户故事”这种形式。

2、用户故事

先来简单介绍一下这种形式的诞生,这是由麦克.科恩在《User Stories Applied》这本书中推出的一种需求呈现形式,他的核心观点就是,要将“客户”作为主导,而不是“产品”。

为什么他会提出这种形式呢,其实和他的背景有关系,他一直是从事技术工作的,很大可能是受不了传统PRD那种大篇幅的说明,以及一旦需求不准确,开发就要返工的状态,因此就琢磨着怎么能够改变这种情况,因此,用户故事的形式就出现了,并且这位老兄还是敏捷联盟的创始人之一,这就是为什么在敏捷开发中,用户故事是必备的。

用户故事的形式其实很简单,基本上就是如下格式:

As a [role] I want to [do something] so I can [achieve a benefit]

翻译过来,就是:作为一个【角色】,想【做什么】,从而我能够【获得什么利益】。

举例如下:

作为一个【普通用户】,希望【微信能够对好友分组】,这样我就能【更高效的管理我的朋友】。

用户故事的形式看起来是简单,简短的,但是却可以表明三个可能对开发团队来说比较重要的信息:

1、目标用户是谁:普通用户

2、要解决的问题:微信好友不能分组

3、获得的收益:更高效

一旦开发团队明确了这三个信息,其实就可以从技术实现的角度评估如何实现高效的管理好友这个功能。

用户故事的好处在于它能够从各个级别来进行需求的说明,也就是说,我们既可以用一个用户故事来说明一个产品要实现的需求,这个被称为是epic,也就是大型的用户故事,也可以说明一个产品中很小的一个需求,也即是基于epic分解出来的小的用户故事。

比方说:

作为一个【普通用户】,我希望【微信能有和QQ一样的使用体验】,这样可以【符合我的使用习惯】。

这就是一个很高级别的用户故事。

而上面提到的分组就是一个低级别的用户故事。

此外,用户故事的好处还有一个,就是它可以应用到几乎所有的行业,因为它不是基于某类产品的,而是基于目标客户的。

比方说:

作为一个【注重健康的消费者】,我希望【当前的慕斯蛋糕能降低含糖量】,这样能够【让我在享受美食的时候不用担心身体发胖】

作为一个【糖尿病患者】,我希望【血糖仪的试纸能够通用】,这样可以【让我更方便的购买】

作为一个【孩子的父母】,我希望【卷笔刀的刀片能够方便更换,就像手动剃须刀那样】,这样可以【让我减少更换卷笔刀的成本】

作为一个【家用车的车主】,我希望【家用车能够有更多的储存空间】,这样可以【让我在车上存放更多的小物品】

……

有些朋友如果听过老汤的课,可能会想起,咱们产品经理在有了客户问题的时候,会做一个工作,叫问题分析矩阵,想一想,这个思路是不是很类似啊:

问题是什么->我们的解决思路是什么->我们的解决思路的特征是什么->我们的这个解决思路能够给客户带来什么样的收益

其实就是这个原则,只不过问题分析矩阵是独立管理的一个文档,也没必要完全展示给相关团队,因此,用户故事就成了一种不错的呈现给团队的需求形式。

但是,这样不错的形式,还是有人提出了意见,而他建议的形式被称为是“工作故事(Job Stories)”。

3、工作故事

谁对用户故事有意见呢,不是我,是一个叫艾伦.克莱门特的老兄,他就指出,用户故事有三个问题:

1、They use Personas.使用原型

2、They couple implementation with motivations and outcomes. 他们将动机和结果的实施结合在一起。

3、They ignore context, situations, and anxieties. 他们忽视了环境、状况和焦虑。

为了更好的阐明他的观点,他做了一张图来说明用户故事的问题:

先来看第一个问题,这位老兄提出了一点,原型在什么情况下有意义,就是当客户和产品团队存在距离的时候,但是现在随着沟通技术的发展,这种距离越来越小,因此,他认为原型存在的价值已经不大了。

同时,他还指出在很多时候,我们所谓的原型其实是按照人口统计(某人的年龄、性别、种族和周末习惯)进行确定的,这样就无法让团队理解到底谁是消费者,谁不是消费者。

比方说,某人花30秒的时间买了一个面包,并花30分钟的时间吃了它,但是为什么要吃它,这个动机是在用户故事里体现不出来的。

因此,他认为在用户故事中,原型很大概率上是没有办法说明用户动机的,也就是说,到底是哪些人真正需要我们的产品?原型很大程度上体现的是一群事实上和产品并不相干的人。

再来看第二个问题,这位老兄认为结果和动机在用户故事中是混为一体的,比方说刚才那个面包的例子,吃是结果,但在用户故事中,并没有体现出动机,或许是为了充饥,也或许是为了尝鲜,还或许是因为嘴馋。

因此,他认为应该进行明确的区分,而不是取决于我们的假设。

第三个问题,这位老兄认为所有动机的产生可能会受到环境的影响、所处的现实状况,以及客户内心深处的焦虑(现在不是流行贩卖焦虑吗,估计就是从这里来的),比方说人云亦云,爱面子,虚荣,安全感、归属感、圈子文化等,都会对动机造成影响。

最终,他提出,应该用工作故事来进行一个需求的说明,基本格式如下:

When [    ], I want to[    ] , so I can [    ] .

翻译过来,就是:当【在什么样的情况下】,我会【产生什么样的动机】,为的是我能【得到什么】。

第一个括号处填写的是situation,也就是环境、情形、情况,第二括号处填写的是motivation,也就是动机,第三个括号处填写的是expected outcome,也就是预计结果

举例如下:

当【在陌生人居多的情况下,需要填写个人资料的时候】,我希望【能够有效和陌生人区隔】,这样我就能【无须担心个人隐私的泄露】。

关于工作故事的详细思路,咱们有时间再说,这里只简单提一下。

尽管用户故事和工作故事,都包含有“故事”二字,猛一看起来,似乎两者完全不一样,但是如果仔细分析后,我们就会发现,其实PRD、US、JS,只不过是在从不同的角度在说明需求罢了,具体区别见下图:

我们(也就是图中的企业/产品团队)通过产品和客户产生关系,那么,需求也是在这样的流程中循环的,因此,从流程中的任何一个点都可以对需求进行说明。

PRD和用户故事、工作故事之间的区别好理解,它就是从产品这个点进行说明的。

主要是用户故事和工作故事稍微有些不太好理解,简单点说吧,两者都是基于客户的角度来描述需求,但是用户故事是以“你们(我们分析出的客户)想要什么”的视角来描述需求,而工作故事则是以“我(客户自己)想要什么”的视角来描述需求,可以理解为是一只手的正反面。

好,关于需求的三种表现形式就先谈到这里,尽管讲了这么多,但是我的本意可不是要讲如何来用这三种形式去描述需求,而是我在看了这么多相关的资料后,发现一个有趣的现象,就是所有的这些需求表现形式,没有一个是产品经理提出来的,不是技术背景的,就是UX背景的,不过这也正常,对于他们来说,咱们写的无论是哪种形式的需求,他们都是读者,读者自然要对作者的文风、文笔、形式提出自己的想法了。

但是,作为作者的我们,是否真的认真思考过如何才能把客户的需求,通过团队最愿意、最习惯接受的形式传达到位呢?或者再大点说,我们如何才能保证我们提供的每一个需求是真实且有序的呢?

关于这一点,我会在下一篇文章中进行说明。

最后,咱们一起来做个小调查,看看大家目前需求说明的形式都是什么情况。(只在微信公众号进行,可以加公众号阅读本文参加,公众号二维码见下图



分享到QQ 分享到微信 分享到微博

1 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址
  1. #1
    沙发