为什么要写PRD产品需求文档?别把自己绕进去了

当年刚到携程做产品,一心以原型为大,结果导致立项会上产品漏洞百出,没有通过。

产品团队,通常会输出一套经过确认的全家桶,内含:

一份《交互原型稿》(可迭代),

一份《产品需求说明文档》(PRD,可迭代),

一份《功能开发清单列表》。

研发人员通过这些文档,就能够很清晰的了解产品的从宏观到细节。

一份好的产品需求文档,能够让产品人员全面的从整体到细节的,再次梳理和确认产品的重要步骤;

也能够让研发人员非常清楚的了解,项目的背景、预期、以及产品的细节,尽可能全面的把产品各方面实现的,可能存在的问题都列举做出说明,提高开发效率,节省不必要的频繁沟通。

刚开始做产品时,我总是以为只要原型一画,和大家开个会一说,然后研发们就开始搞起吧。结果你会发现,这之后你每天都陷入各种答疑解惑的忙碌之中(临时召集研发开会做说明,指望他们能在两三个小时里把所有细节都记住?别做梦了)。

有些开发也不好意思频繁的找你,就直接按照自己的思路做了,然后你就坐等验收的时候各种吐槽,提bug打回修改。

时间花了,还没达到你想要的效果,你不开心,开发也不开心。何不想想该如何解决呢?这时候,PRD文档的重要性就显现出来了。

PRD文档

文档的基本格式我在这就不描述了,网上一搜一大片,两点我重点说下:

一、文档具备可迭代性

铁打的文档流水的兵,一个好的需求文档就像一锅好卤,是越熬越香。

不论谁来接手正在进行中的项目,都能够一目了然的知道项目的前因后果:什么背景啊,每次调整都是为啥啊,哪个产品什么时间主导的啊……就像一份更新日志,记录着项目需求变更的每一次变化。

二、文档说明要尽可能的细致

产品模块以及细节介绍的部分,需要根据已有的原型稿有图有字的做出说明。文字部分主要针对某个模块或者界面详细的做出标注和说明。

如果描述性文字不足以理解,这里需要举几个例子给研发做出形象化的解释。

举一个我自己经历的反面例子:

当年刚到携程做产品,一心以原型为大。仿佛只要原型搞定了就没啥事了,结果导致立项会上产品由于严重缺乏全面思考,漏洞百出,没有通过。

这段经历给故作聪明的自己当头一棒,经过和同事的交流,我发现自己在产品的细节打磨和思考上没有不足够的深入。对于不熟悉的新业务:

流程上有没有明显的逻辑性错误?

每个界面的数据哪里来?什么接口获取?

接口有没有通?是否能够拿到产品所需的数据?

规则性限制是否已经考虑全面?…

这些基础工作是你在编写PRD文档之后第一个要去一一验证的事情,如果顺利才可以按照这个确认的需求下发开发。

另外说一点,要考虑到从客服、市场、运营等岗位角度对产品进行解释,以及他们在这个产品中需要注意的一些要求。(使用方和服务方都要全面考虑)

最后,文档毕竟是文档,虽然做到了迭代,但在实际工作中还是会出现各种难以理解的部分。这个时候就需要产品们及时和研发当面做出沟通和说明工作,积极推进产品研发进度。

文/山贼,一个带有完美主义情节的产品经理,新浪微博 @山贼95270。

2条评论 添加新讨论

2017年11月15日评论

额,冒昧问一句,你们的PRD都不需要考虑边界值,多重状态等等么??还是我想多了?

回复
2017年11月07日评论

很不错的文章 学习了

回复
登录后参与讨论
Ctrl+Enter 发表