如何写一份思路清晰的PRD文档?

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

市场、运营或用户反馈,我们需要这样,需要那样的产品改进或产品设计。需求审核也已经通过了。然后产品经理理完思路,进行流程设计,产品设计也随之做好了。一脸蒙蔽,这些产品设计和设计的细节全部在产品经理的脑海里呀,怎么办?总不能天天跑到技术哪里,我需要技术实现这样的产品需求,需要实现那样的设计效果,每天口头一遍一遍的交流吧?嗯?作为产品,有这样的需求或则有这样的疑惑。对头,PRD就是为这样的需求或则这样的疑惑而生的。PRD的作用就是,把需求白字黑字外加图像的生动明确的表示出啦,便于技术开发;便于需求更改,便于需求记录;便于需求沟通……等等。有了PRD,需求沟通时的撕逼大大减少。

prd

如果市场分析、用户研究、用户需求分析是用户、市场告诉我们需要什么的产品,那么PRD文档就是把产品需求告知给技术实现的直接方式。PRD是这样的存在:

IMG_2031

避免出下如下图的悲剧,保证产品人员的人身安全。我们有必要认真好好探究探究,PRD应该怎么样写?怎么样才能写出一份合格的需求文档。

IMG_2032

一份合格的需求文档应该包含这些内容。

一、PRD文档头

文档名称、作者或则撰写人、文档编写日期、版本纪录、目录。

写个需求文档,你的告诉人家这是什么吧?这是什么文档,不然人家技术还以为你是给人家发的什么少儿不宜的文档呢。有了文档名称的告诉人家是谁写的吧。人家要拿显示器砸你应该找到人对号入座,不然会殃及无辜的。文档日期也写上,不然人家技术会认为,这需求已经是去年提的需求了。没有版本纪录,鬼知道你这是第几版。目录,清晰的记录文档的脉络结构,让人知道怎么去读你的PRD文档。合格的文档头,应该长这个样子的

IMG_2033

IMG_2034

OK有了一个漂亮的文档头,那下来就到文档里面内容的填充咯。

二、PRD文档内容结构

PRD文档内容结构包括:概述、产品需求说明、产品流程说明、产品结构和功能说明、其他产品需求、上线需求说明。如果需要的话有相关文档,附件说明。

1、概述

从大的方向,讲讲项目的相关背景、有什么目标、有没有竞品对像?而阶段性计划是什么?传递做这个需求的目的是什么?要达到什么样的目标?要达到这个目标阶段性计划是什么?

2、产品需求

落到具体的地方,产品有哪些需求?增加了哪些需求?调整了什么?取消了什么?需不需要其他资源的配合?有什么影响?,从这几个地方说清楚。

3、产品流程说明

讲清楚每个逻辑点,每个地方应该怎么走?应该做什么样的判断?如果进行这个操作返回给用户什么内容?用户触发之后得到什么内容?

常见的流程图:

IMG_2035

泳道图:

IMG_2036

IMG_2037

4、产品结构说明

根据产品的内在逻辑,分解、细化需求,将需求细化说明。针对内在的需求逻辑,考虑到那个需求不同情况的不同反馈,逻辑严密,考虑到每个逻辑分支。如果有和其他产品关联,考虑到对其他产品的影响。在描述的时候,不要用户含糊的词语,“可能”、“也许”之类的词语。如果无法biao表述清楚,可以举个例子说明。

例如:

IMG_2038

必要的时候添加用例说明:

举例:

IMG_2039

5、其他产品需求

涉及到其他产品的产品线时,需要协同多个产品线进行多方面考虑。协同调整,避免出现遗漏,出现不必要的偏差。

6、相关文档

如果一个项目分解成多个团队。多个需求文档协同合作。如一个UGC社区,有PC端社区,有APP端社区。这需要不同的研发团队,Web前端、APP又分为安卓、iOS。所以需求文档会拆分为PC端需求文档和APP端需求文档。

7、上线需求

测试通过的需求,具体的上线时间,具体一些特殊的流程需求等。

8、其他需求、附件

作为需求的一种补充,对一些需求进行补充说明,或者需要的文件说明等。

结语

OK这样一个文档下来,需求明确了,如果要改需求也是有版本纪录,有方向的改进了。不然,作为个产品经理你时不时跑到,跑到技术那边说一嘴,哎呀,哎呀,这个需求不是这样的呀,你做错了,重新改。技术保证打不死你,人家辛辛苦苦做出来,然后你所不是这样。送你大大的一个白眼。写好PRD,真爱生命,远离撕逼。最后,豌侠所说的都是没用的,大家自行体会。

 

作者:豌侠说(微信号:wanxiashuo)

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

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

评论( 11

登录后参与评论
  1. 没错,做为十年来的老程序。从来没看完任何一份PRD。
    但文章值得收藏。

    回复
  2. 回复
  3. 作者公众号应该是(wanxiashuo)吧,上面打错了

    回复
    1. 回复

      :!: 嗯,非常感谢指出错误。谢谢。 :!:

  4. 回复楼上,这个要看具体的功能实现的,,,都不一样,而且我之前看过的一篇prd是极为详细,,,界面每个功能按钮都详细的介绍,甚至是和程序开发内容是结合在一块的。。换句话说,是个程序员都能按照他写的PRD来开发软件

    回复
    1. 回复

      链接发来看看撒

  5. 导语里满屏的“或则”和“白字黑字”……原谅我善意的笑了。

    回复
  6. 大神,可以给我一份完整的需求文档学习研究一下吗?

    回复
    1. 回复

      关注公众号:豌侠说(wanxiashu),有更多总结的产品方法论分享哦。

  7. 确实很牛逼,但我想说的是,有几个程序猿会耐心去看呢?

    回复
    1. 回复

      确实存在这么残酷的现实,哈哈。

加载中