如何让开发、测试一致称赞你的PRD?

代码笔记   2018-04-23 17:37:04

稍微有点经验的产品经理,基本上都会写好一份PRD,那到底要具备哪些特点,才能让开发、测试一致称赞你的PRD?

如果你去采访几个周围稍微有点经验的产品经理:“你认为你写的PRD是一份好PRD吗?”

答案可能会高度统一:“Yes,it is!”

在产品经理岗位上耕耘这些年,我的PRD收到了来自开发GG和测试MM的不计其数的建(pi)议(dou),终于收获了长足的进步,最近一年写的PRD在开发、测试团队中获得了一致的认可。所以如果你要问我这个问题,我的答案也会是:“Yes,it is!”

但如果再追问一下:“你认为什么样的PRD是一份好的PRD呢?“

这个时候答案就会千奇百怪了,“思路清晰,排版整齐……”每个人可能都巴拉巴拉列举一大堆的特征。

在我看来,在一个真正的产品经理眼里,世间万物,只要是人造出来的,都是产品。产品上市之前,PRD就是产品经理交付的第一个产品。对这个产品经理交付的第一个“产品”,至少应该具备以下4个特点,才能算是一个好的产品(PRD),即:价值明确、考虑全面、可读性强、修订留痕。

一、价值要明确

能帮助用户解决问题,则产品是有价值的;而有价值,是一个产品诞生的原点。产品是为了解决用户问题的,PRD是为了打造帮用户解决问题的这个产品而编制的。

那么,你的产品最终要解决的是用户在什么场景下的什么问题?要实现的定性目标是什么?定量目标是什么?

在你的PRD当中把这些内容写清楚,一方面,可以让自己更加清晰地理解和审视项目价值;另一方面,也让开发、测试同学知道自己要做的工作是有价值的。

这有什么意义? 这么说吧:

  • 有工资拿,我做到朝九晚五;
  • 有价值感,我自愿朝九晚九。

让团队知道他们做的工作是有价值的,并且让他们知道能实现什么样的价值,是凝结一个团队克服重重困难,滚滚向前的最为重要的力量。因此,一份好的PRD,一定会有关于它的项目价值的清晰描述。

二、考虑要全面

衡量一个产品经理PRD功力的最为关键的指标,就是看他是否考虑得足够全面。我将产品经理考虑全面的功力分成三个段位:

第一级:模块内全面

在这个段位上,产品经理能考虑到在正常情况下,所设计模块当中可能的应用场景,每个场景下有哪些分支流程和处理逻辑。

比如:在下单流程中,能考虑到针对接口返回成功、失败的各种场景的处理逻辑;同时,也能考虑到在正常场景或流程之外,有哪些异常场景,并设计对应的处理方式。比如:下单流程中,接口响应超时场景怎么处理。

第二级:模块外全面

这个段位上的产品经理,不仅能考虑到所设计模块的各种正常、异常场景,还能考虑到这个模块的调整会影响到的其他系统模块,并在PRD当中给出相应的应对策略。

比如:当你在门票的下单流程中调整了游玩人信息的处理逻辑,你能否考虑到对酒店品类的下单流程的影响。

第三极:扩展性全面

到了这个段位上的产品经理,不仅能对当下的模块内容的场景考虑全面,还能考虑到未来三到五个迭代版本之后可能的产品形态。

他在自己的设计方案中预留产品扩展空间的同时,也在前期PRD当中对可能的扩展需求进行标注,以提醒开发人员在代码层、数据结构层预留充分的扩展空间。

比如:你负责了一个旅游平台订单重构的项目。在第一个版本中,你只对门票的下单流程进行了重构,但你在前期的方案设计阶段,除了对现阶段门票订单的重构方案进行全面的设计,还能考虑到未来1年之中,对酒店、线路品类进行重构时的主要场景需求,并在产品方案中预留出扩展空间以供未来扩展。

三、可读性要强

这一点应该很好理解,PRD全称Product Requirement Document,即产品需求文档。因此,它的本质还是一份文档,对于开发、测试团队成员来说,还是一份需要仔细研读的文档。对于需要研读的团队成员而言,一份可读性强的PRD可以节省大量的时间,有效提高开发和测试的工作效率。

那么,啥叫可读性强?

我认为可读性强的PRD包括三个特点:

1. 一个文档覆盖完整需求

这是对于文档可读性的最基本的要求,刚做产品那会儿,沉迷于各种所谓的PRD模板和绘图工具,大致就是用Xmind画脑图、用Axure画原型,用visio画流程图,然后再用word写PRD。

尽管也会在PRD中把重要的界面原型截图放进去,但有时候,Word无法很好地呈现一些交互效果,或者比较大的visio图在word里面看不清的时候,开发、测试团队就需要html原型文件、word、visio几个文档一起看,并进行来回切换。有时候也会出现开发人员嫌来回切换麻烦,干脆直接就简单看看原型图,之后就按照自己的想法开始coding了。

很显然,从阅读体验来看,用word来写的PRD很难一个文档覆盖完整需求,也不是一份可读性很强的PRD文档。

那么,有没有什么方式是可以实现一个PRD文档覆盖所有需求的呢?

在这里推荐一个比较好的写PRD的方式——直接在Axure原型中撰写PRD,这也是目前我所在公司撰写PRD的方式。自从在Axure中写PRD之后,原型、流程图、需求说明都被写在了一个原型文档当中,开发、测试再也不用几个文档来回切换着看了。

另外,除了便于团队成员在一个文档中查看完整需求之外,对于产品经理而言也有诸多便利。比如:多文档无需来回腾挪,调整时只需维护一个文档即可,无需担心漏了某个文档,可以按照页面撰写,伸缩性强等等。因此,如果你还在用word写PRD,建议你赶紧抛弃word,拥抱Axure吧。

2. 文档有清晰的框架结构

一两页就能写完的小需求PRD,框架结构对可读性的影响自是不大,但是对于超过10页的PRD文档来说,框架结构对于可读性的影响就比较大了。

经过我多年实战经验,化繁为简,一个好的文档框架大致是如下一个结构:

  • 封面:需求名称、版本、更新日期、作者等;
  • 修订记录:修订时间、修订人、修订位置、修订内容、修订原因、审核人等;
  • 文档说明:需求背景、解决方案、项目目标、产品范围等;
  • 总体流程/架构:产品架构、主流程、主要功能模块简述等;
  • 模块一:模块名称、用户场景、产品用例等;
  • 模块二:模块名称、用户场景、产品用例等;
  • 迭代版本1:版本名称、时间等;
  • 迭代版本2:版本名称、时间等;
  • 附录:会议纪要、遗留问题等。

3. 排版清爽、条理清晰、图文并茂

好比是人不能只有骨骼没有血肉,PRD光有一个清晰的框架结构还远远不够,因为开发、测试团队看得最多还是具体的细化的功能需求,而这些细碎具体的需求内容实际上也是最应该考虑可读性的地方。

如何提高内容的可读性?尽可能让你的需求描述具有清晰的条理和清爽的布局。

几个提高内容可读性的小技巧分享给大家:

  • 需求描述和原型一一对应,且不宜相隔太远;
  • 图文并茂,尽量避免整版整版的文字;
  • 能用图描述的,就不要用干巴巴的文字;
  • 的确需要大段文字描述的内容,分拆成一个一个的小点描述。

总而言之就是一个原则:让用户看起来不那么累。

四、修订要留痕

需求变更对于产品经理而言是难以避免的,在项目进入开发阶段之后,对PRD所做的所有变更一定要留下痕迹,这些修订痕迹包括两种:修订记录及修订标注。

1. 修订记录

通常情况下,一份合格的PRD里面一般都会标配一个如下图所示的修订记录,这是一份PRD最基本的修订痕迹。

据我观察:即便是在我目前这样一家相对成熟的互联网公司当中,依然存在大量的修订记录形同虚设的情况。要改什么内容,产品经理直接跟开发测试说一下就改掉了。

为什么会这样?

有的时候可能是因为忙,忘记了;有的可能是因为懒,懒得改;而最主要的原因还是在于产品经理缺少修订留痕的意识,认为这种细碎的工作没必要。

实际上这个修订痕迹是非常重要的,他直接反映了PRD文档的变迁史,也让开发、测试团队对PRD的变化做到同步更新,避免团队做无用功,避免不必要的扯皮。

由于没有修订记录,跟开发和测试扯皮自然难以避免,即便没有扯皮,产品最终上线之后的实际情况与PRD有诸多不符,也会逐渐就演变成了给后人挖的一个接一个的坑。有良心的产品经理,不给后人挖坑。

2. 修订标注

当然,有了修订记录痕迹,如果你能秉持着心中的用户思维,产品思维来对待,你会认为这是不够的,为什么?

因为开发测试要从你洋洋洒洒十几页的PRD当中,找出你改动的那两段文字依然是一件很困难的事情。

怎么解决开(yong)发(hu)的这个痛点?

对于一名产品经理而言,要解决这个问题实在太容易了,把修订内容标注出来不就可以了嘛。如果你是用Word写PRD,解决这个问题简直soeasy,直接在“修订”模式下编辑文档就可以了;如果你是用Axure写PRD,也不难,只需要把你改动的位置用其他颜色标记一下就可以了。

在这里分享几个火山的PRD中的一些修订痕迹:

Word修订模式标注留痕:

Axure橙色字体留痕:

流程图橙色填充留痕:

这样的PRD痕迹可以给开发、测试小伙伴带来巨大的便利,做起来很容易,也花不了太多时间,当然,要做到前文描述的所有要求其实也都不难,关键取决于你是否有这个意识这样去做而已。

从根本上来说,其实是取决于你是否把你写的PRD看做是你的一个产品,是否把你的开发、测试搭档看做是你的用户。

三、总结

PRD没有标准,所以什么样的PRD是一份好的PRD,这实际上是一个仁者见仁智者见智的问题。本文阐述的好PRD的4个特点也仅代表一家之言。

那么,这个问题谁最有发言权?它的读(yong)者(hu)。

PRD文档的读者是谁?UED、开发、测试、业务需求方以及未来要接手你工作的其他产品经理,都会成为它的用户。

产品好不好,产品经理说了不算,用户说了才算。所以,回到文章开头的问题,如果你也认为自己的PRD写得很好,不妨再找几个搭档的开发、测试同学问一下,看看结果会是怎样……

打赏