当进行敏捷开发时,你的PRD应该怎么写?

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

敏捷开发,并不意味着产品经理在写PRD的时候就可以偷工减料,相反,这更考验产品经理的功力,因为产品经理需要精简信息,将真正的有效信息简单且清晰地传达给PRD阅读者,从而真正达到敏捷开发的目的。

mingjiekaifadsd

敏捷开发这个词越来越为大家所熟知了。简单来说,敏捷开发就是以用户需求为导向,通过快速开发将产品投入市场,获取市场反馈,从而快速迭代、优化升级、循序渐进的开发方法。

我们不去片面评价敏捷开发的好坏,毕竟事物都具有两面性,任何事物都有各自的优劣。但在创业团队建立的前期,在产品还处于一个idea状态、开发人员并不多的场景下,敏捷开发还有具有一定的优势的。

敏捷开发,其中一个重要原则就是“多沟通,尽量减少文档”。因此,敏捷开发中,产品经理在撰写PRD时,应该尽量做到精简。注意,此处用词是“精简”,而非“简化”。那么,撰写一份精简的PRD,产品经理具体要怎么做呢?

1 直接将PRD在原型上标注

如今,越来越多的产品经理已经摒弃了word冗长的产品需求文档,直接在产品原型上通过备注的形式来说明需求和描述功能点(造成这个现象的原因很大程度上是由于PRD的最重要用户——程序员更偏向于直接看着原型进行开发,经常直接忽略word格式的PRD)。那么,遵循敏捷开发的“尽量减少文档”原则,在形式上,我们更提倡直接将产品需求文档内容标注在原型图上。我想,这对于PM和RD都是一种减少工作量的好方式。当然,前提是你的PRD需求完整且逻辑清晰。

详细的教程请阅读干货:

http://www.woshipm.com/rp/211554.html

http://www.woshipm.com/rp/389092.html

2 产品全局结构图和重要流程的图示不可省略

再精简的PRD仍旧不可或缺结构图和流程图。

首先,全局结构图,作为整个PRD的骨架,可以让PRD阅读者对产品的总体功能构成一目了然,这样在接下来继续阅读每个部分的原型图和对应的说明文档时,思路能够更加清晰。就像每本书都会有目录一样,目录是让你最快了解这本书大概的内容的捷径。

其次,一些基础功能的流程图(如登录注册之类),我们是可以有选择性地不将其呈现在PRD里的;而那些实现重要业务需求的功能流程,我们还是必须将其用流程图清晰展示出来的。这样即使在需求会议后,程序员对某个流程比较模糊了,也可以翻一翻PRD来确认。

所以,重要功能的流程图,可以说是一份PRD的灵魂,是千万不可以省略的(为了避免全是文字,产生视觉疲劳,以用户端的优惠券功能为例,特附优惠券总体结构图和优惠券功能下的一个流程图)。

structure

(优惠券功能总体结构图)

process pic

(获取优惠券方式: “摇一摇”流程)

3 重要名词需要有清晰简洁的定义

并不是每个名词都需要写解释、下定义!

我记得刚入行时,第一次写产品说明文档,我甚至还写了“用户”二字的定义。当时的PRD是直接参照公司产品前辈的,他之前写了“用户”的名词解释,于是我也照抄了过来。

n.

(反例:曾经我写的名词解释)

现在想想觉得略为搞笑。因为这个词的定义在APP 1.0版本的时候已经确认过了。而且,这个名词应该属于比较容易理解、不容易产生歧义的范畴。所以我相信,像类似这样的词的解释,对于PRD阅读者来说就是一个无用信息。

好吧。说正事。那么什么时候你需要写名词解释呢?什么词才是重要的词呢?

这个名词在产品设计中第一次出现且是业务需求的重点

例如,当你在设计优惠券功能时,那么“优惠券”这个名词就是一个重要名词。可能大家会说:“不对啊,优惠券不是很好理解吗?需要名词解释吗?”我可以明确告诉你,在这个场景下,需要!这是我之前在一家O2O公司工作时,曾写过的定义:“优惠券是指由xxx平台发行的,用户使用XXX APP 结账时,用于抵扣订单金额的电子券”。这个定义指出了几点关键信息,一优惠券的发行方,仅仅可以使平台,不能是平台的商家;二使用场景是用户在结账时;三作用是抵扣订单金额;四优惠券非实体券,是电子券。

容易混淆的名词

让我们再来举个例子。比如,“连锁店”这个词已经在之前的设计中出现过,也解释过了。但是在你当前的产品设计中,有了一个“商户组”的概念。乍看之下,真的会让人云里雾里,有点懵。光从字面理解,好像都是指代一组商户,具体的区别并不是那么清楚。那么这个时候,你需要将两个概念最好放在同一个页面中以对比的方式解释清楚,以免造成程序员的大脑短路。

comparison

(对比方式的名词解释)

为了能真正实现敏捷开发,请提前过滤掉不重要的名词解释,把页面的位置留给那些重要的名词吧!

4 你还需要把规则以及异常情况都写上

看到这里,是不是觉得,其实还是要写挺多东西的呢?没办法,规则和异常情况这二者都是非常重要、不可省略的。其实产品经理的PRD把规则和异常情况写得越清晰,程序员在开发时,就能越顺利。在你把PRD交给技术同学后,你总不希望他们三不五时的来问你“这个列表具体一次加载多少个商户”“如果没有匹配的信息,需要给什么样的反馈呢”之类的问题吧?这样首先拖慢了开发的进度,其次也会显得你作为一个PM非常的不专业!

规则说起来,其实是比较繁杂的一个东西,除了刚刚举例的“商列表页一次加载多少商户”,你可能还要写许多细致的规则如,订单编号的规则是什么、默认排序的规则是什么等等。这里就不一一举例了。相信每个做产品的同学都是明白的,如果一开始规则没写清楚,需求评审会时,就容易被问得哑口无言。

那么异常情况呢,这个更是关键。千万不要小看了异常情况。一个异常情况下(特别是用户端),如果没有友好的指引,你的用户很快就能流失殆尽。举个非常惨痛的例子,还是之前做O2O的公司。用户在支付完成以后,由于APP没有收到某支付平台的回调信息,所以用户看到的界面仍旧还是未完成支付的订单提交页面。但是用户的手机确实能查询到扣款信息。这个时候,那就是非常尴尬了!页面一动不动,也没有任何反馈。那究竟用户算不算付款了呢?这就是由于在产品设计中,没有考虑到支付接口回调异常这个问题,而漏掉了与此相关的产品设计。据当时地推的同事反馈,因为用户无法取消订单,而页面又没有任何反馈,用户不得不在商户那里多呆了半个小时,就为了等支付回调。

我已经用血和泪的教训告诉了大家,敏捷开发中,切记要把规则以及异常情况都写上!!!

5 记录下你的PRD变更

最后一点,简单提一下就可以了。如果提交的原型和对应的PRD更新了,记住把变更的内容写上。嗯,就是我们常说的,版本修改信息。需要的字段有:修改时间、修改内容、备注、修改人。以及,把版本修改信息放在你原型的第一页。

总而言之,敏捷开发,并不意味着产品经理在写PRD的时候就可以偷工减料,相反,这更考验产品经理的功力,因为产品经理需要精简信息,将真正的有效信息简单且清晰地传达给PRD阅读者,从而真正达到敏捷开发的目的。

P.S:我也是正在学习中的产品,以上仅为个人经验,若有错误的地方,欢迎指正。

 

本文由 @Mika 原创发布于人人都是产品经理。未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 3

登录后参与评论
  1. 我表示刚开始的链接没有“_blank”,老跳转,体验真的很差。

    回复
  2. 方便加微信吗?主要是平时可沟通交流

    回复
  3. 平凡之路

    回复
加载中