一份优秀的PRD能够帮助你获取资源，有效推进项目，获得团队成员的信任。 今天就和大家聊聊如何写好一篇PRD，希望能够提供给大家一些干货。
一、什么是PRD
PRD全称Product Requirement Document，中文名产品需求文档，历史上第一份PRD据推测应该是诞生于宝洁这家公司，因为据史料记载，宝洁在二十世纪二三十年代第一次提出了产品经理的概念，并诞生了第一位产品经理，所以通过合理的逻辑推理，应该也诞生了第一份PRD，只是因时间久远且没有更多的细节资料而无从考证。
随着互联网行业的发展，产品经理岗位的发展成熟，产品经理的工作职责逐渐的清晰明了，PRD也终于在历史长河的演变过程中，慢慢形成了产品工作流程当中不可缺少的一环，那么到底什么是PRD呢?
可以概括为，PRD是对产品需求以实际可落地方式进行细化描述的文档。
这里面有个关键词“实际可落地”，也就意味着阅读者通过查看PRD能够大致知道需求会最终以什么样的实际形态或方式被呈现出来，而不是说看完了PRD以后，依然不知道需求会被做成什么样或者说感觉需求还只是停留在一种概念性的层面。
那怎样去实际落地，这里就涉及到另外一个问题，就是PRD是给谁看的。
PRD的查看对象
一般来说，PRD是写给以下几种人看的：
1.产品同事
2.运营
3.设计师
4.开发工程师
5.其他需求方(相关业务部门等)
二、围绕用户体验要素的PRD编写
为什么要说围绕用户体验要素来编写PRD，因为产品的设计是围绕着这个经典的框架来的，那写PRD的任务当然是要把这个内容向大家表述清楚。
第一部分：需求概述
其实不仅仅是做产品，任何事情，第一步肯定是要想清楚要做什么，为什么要做，也就是把战略层描述清楚，PRD的第一部分就是要把这块内容说清楚，回答出下面的问题。
1）用户要获得什么？—— 用户痛点、需求
建议这块内容，说清楚整体的问题痛点，同时也要举具体case，列举数字，如用户的使用频次，现在的花费等等。
2）用户是谁？—— 用户细分、用户数量、画像
用户是谁，并不是如“商家用户”这种粗线条的描述，要说清楚对于当前的功能，是哪类用户在什么场景下的需求，用户的量级是怎样的，有一个相对具体的画像。
3）用户能通过这个得到什么？ —— 用户收益
这里面补充个内容，俞军老师曾说过，用户净收益=新体验-旧体验-替换成本，替换成本可能是获取成本、认知成本、资金等等， 虽然这些内容并不是真正可衡量的，但在做一款新产品评估其价值时，可以从这几个角度进行思考。
4）我们能得到什么？—— 对企业能带来什么收益
这点很重要，做任何产品，给用户赋能，给用户带来价值，其主要目的还是企业自身能够盈利，这点想清楚才能说服老板提供资源呀。
模板： 1.需求背景 描述目前存在的问题，业务痛点或用户痛点（建议有具体数字、案例） 2.目标用户（为谁解决问题，用户画像越具象，问题会描述地越清楚） 3.需求目标（要解决什么问题） 4.需求收益（解决问题后能产生什么收益，衡量标准）
第二部分：产品规划
最抽象的战略层说清楚了，下一步就要大体说下为了实现上面列举的各种想法目标，要一步一步怎么做了，也就是说清范围层的内容。
1）功能&信息结构图
范围层，就是要说清楚，为了实现战略做什么事情，什么功能，提供什么内容。这块一般会通过脑图或者框架图来展现，说清楚我们需要哪些数据，做哪些功能，各个功能与功能之间的关系。
要注意，这部分需要在长远角度，解决这个问题地整条路线进行思考。举个例子吧，比如要做个评论功能，让用户对产品更了解，并带来更多销量。那第一步先增加评论功能，之后可以对评论进行分析，为用户推荐高质量的产品，发现问题产品保证平台产品质量等等。类似这样，出一个整体的规划蓝图。
2）路线规划
蓝图出来了，还是要落地的。所以这一步要把刚才地蓝图，切成一块一块，每一步要做什么，多长时间，这个阶段解决怎么的问题，为后面提供什么铺垫。有些内容，也可以出一个简易的DEMO图，能描述清楚即可。
模板： 1.功能结构图、信息结构图（脑图、框架图） 要从长远的考虑去思考产品的形态 2.路线规划 没一起完成的内容，解决的问题以及期望上线的时间
第三部分：功能概述
这一部分是对当前这一期要做的内容的详细描述了。这部分面向的主要用户是UI、交互、开发、测试同学，具体到做事情上，就是把大家的认知拉齐。
1）产品流程图
通过图的方式，可以快速、方便地告知PRD的每个用户这个功能的思路流程。这里最开始放的是比较粗线条的流程图，比如买家购买商品，加入购物车->付款->商家发货->确认收货。而一些细节，比如买家超时未付款，或者卖家修改价钱等等，可以到具体写到这个功能点地时候再出一个细化的流程图。
2）DEMO，原型制作，这个就不用多说。
3）UI稿，这块是UI同学完成后，放上来，统一相关资料的获取入口。
4）产品功能点，后面来细说。
产品功能细化说明
这块就是要把功能说得足够细，但也是有一些技巧。
1）更新说明
首先，我一般会在功能最上方，列出更新的清单，一般记录有：调整时间、调整功能块、详细说明。
2）全局说明
每期功能可能会有多个页面多个功能块，但有一些想通的地方，比如对于数据产品，数字的展现形式，保留2位小数，增加三分位符号等；对于移动端产品，一些操作方式等。这个适用于各个块，不用分别在每个中单独说明，而且后续做其他功能都是可以复用的，可以先列出来说清楚。
3）具体每个块的功能说明
- 前置条件：有些功能可能会有这个内容，在什么情况触发这个功能，比如在用户购买什么商品后提供某个功能；
- 主体功能说明
- 流程描述：主流程、分支流程，这个就可以使用上面介绍的UML图，把主线条描述清楚；
- 界面描述：操作、文案，文案建议其他颜色标注出来，防止和描述弄混；
- 业务规则：这个是在界面看不到的，比如限制条件、表格的排序规则、需要记录的数据、还有一些数字的计算公式等等；
- 异常描述：这个不能忽略，尤其是C端产品，考虑需要更为全面，因为很可能就是一个小异常，就导致用户使用不爽而流失，比如上传文件没有考虑超出大小怎么办，用户上传后一直没反应，就会认为这个产品不好用，转而使用其他产品，所以，异常地考虑很重要。列几个常见的异常：如未输入、输入错误、无数据，无网络，长时间未操作，异常退出等等。
最后说下写这块内容的原则
- 完整：足够细，考虑足够周全；
- 无歧义：RD同学是拿着这个文档真真切切写代码，所以说得内容，要能够落到代码上，比如用户一段时间未操作则提示。。。，等待多长时间，要写清楚；
- 有条理：这文档是有人看的，所以序号、符号都适当的用上，让你的文档容易阅读；
- 及时更新：功能、DEMO的调整，都需要落到PRD上。
第四部分：数据需求
因为我本人是数据产品的产品经理，所以这一部分对于我们很重要，需要哪些维度、哪些指标，指标的来源库表字段、计算口径是什么，这些都要清晰地记录下来。
除此之后，有个内容可能经常会被忽略，就是数据的整理。以某宝的搜索结果页为例，一般会展示图片、标题、价格、销量、卖家名称、包邮会标记出来，这些RD通过UI稿可能会查看到，但有一些比如鼠标移入显示信息，点击操作、是否购买过，都在商品展示时体现出来。
这些内容，我们可不能指望RD同学从UI稿中一点点发现。所以列出这样的表格，把你认为需要的类及其属性列清楚，有点类似我们上面类图中对象属性要描述的内容，目的是让开发同学对照这个来进行库表设计，不要遗漏某些点。
第五部分：数据埋点
包括按钮的埋点&内容的埋点，可以通过截图 表格说明的方式，截图标明需要埋点哪些控件，表格说明对应控件的什么信息，如操作PV、UV、输入内容等。
第六部分：效果评估方案及上线安排
对于C端产品，这块内容会更加重要，一般会有个灰度发布过程，因此需要说清楚灰度发布的方式，放量安排、节奏，需要关注的指标，这个指标如何进行评估，达到什么样程度可以全部上线。
第七部分：人员排期
OK，大功告成了。
三、PRD的承载
最后说一点：PRD的存放。
我尝试过几种方式，之前就在axure中完成，在DEMO的右侧进行说明，但这个不好的是：在进行更新后，还要发送给大家，各个版本的存放加上axure本身下载解压就比较麻烦，所以并不是最佳方案。
可以用知识库来完成，这里推荐Baklib来搭建知识库。只要一个链接，更新后只要告知大家同步下信息就好，就是在写功能时候，需要把DEMO对应图贴上去，RD能够比较方便知道是对哪块内容的描述。
对于上述内容，可以使用Baklib创建2个站点进行记录，一个记录需求概述和产品规划部分内容；一个记录产品功能及之后的内容，这个是当前这期的事情。一个总分的结构。
希望这篇写PRD的一些经验总结对大家有帮助。不过，这个PRD的编写并不适于所有公司，一份完善的PRD需要花费比较多的时间，对大公司来说，对接方比较多，很有必要这样一份文档统一各方的认知；而对于创业公司，将产品快速落地投放市场进行验证更为重要，所以这个时候千万不要把时间花费到PRD上面。
