PRD（产品需求文档）在产品开发中起着至关重要的作用，某种意义上，它有着“承前启后”的意义，承载着获取的需求，并引导着下游的落地实现。那么，一份好用、接地气的PRD，该怎么写呢？一起来看看作者的总结。

一、什么是PRD

所谓的PRD，即产品需求文档，英文是“Product Requirements Document”，是详细描述产品架构、页面、功能等全方位需求的输出物。PRD在IT行业里是比较核心的产物，影响着产品产出效果。

二、PRD的价值

既然比较核心，那么PRD的价值自然是举足轻重的。一个产品的开发周期一般会包含以下几个环节：

从上图可以看出，PRD承载了获取的需求，又引导着下游的落地实现。也很容易理解：PRD好比一个说明书，告诉上下游部门这个东西落地后到底是个什么样子。所以如果PRD失水准，研发出来的东西可能就会跟预期相差较大，影响业务的实际效果。

三、如何写一份接地气的PRD

一份接地气的PRD应该是什么样的呢？我以我的总结经验跟大家分享下，对新手同学会比较受用。

1. PRD结构及说明

PRD的结构如下：

1. 修订记录：记录每次PRD更新的内容。
2. 需求价值：主要是需求场景和为什么做这个需求、产品或者项目（下统称“需求”），可以让下游人员更好的理解需求和需求的合理性。
3. 功能清单：描述下这个需求有哪些功能，对这些功能稍微详细描述下。
4. 流程图：分为业务流程图和产品流程图。
5. 名词解释：对文档内某些个性化的名次进行解释说明。
6. 通用组件说明：对于不同的交互、场景所用到的，但是通用型的页面组件进行描述说明，比如toast。
7. 原型图说明：绘制下原型图，然后对原型图和细节进行描述说明。
8. 逻辑说明：对需求的产品逻辑进行详细描述说明。
9. 其他：其他必要的内容。

每个人对PRD结构认知可能都不一样，对于我来说，我更看重 修订记录、功能清单、流程图、原型图说明、逻辑说明，这也是我认为的PRD核心构成。

2. PRD核心构成

1）修订记录

修订记录记录里PRD的更新过程，谁也不敢保证PRD经过评审之后没有任何的改动。那么只要更新了，就在修订记录里把更新的内容标注进去，方便周知、查阅。

修订记录主要包含四个信息：

• 修订版本：我们要给每次修订记录定一个版本号（我个人也会把版本号放到PRD的文档名称中，这个看个人习惯了），可以采用“V1.0”、“V1.1”这种方式来定义。一般大的更新，小数点前面的数字+1；小的更新，小数点后面的数字+1。
• 修订人：当前更新的这个版本PRD是谁写的，就写谁的名字。
• 修订日期：当前这个版本PRD更新完成的日期。
• 修订内容：修订内容分为三种类型：更新、新增、删除。在写更新内容的时候可以写：更新了xxxxx，新增了xxxxx，删除了xxxxx，三种类型区分开来写，方便阅读理解。

修订记录案例如下：

2）功能清单

在功能清单里，要把需求设计到的主要功能陈述下，这里对产品经理的体系化思考能力会有些要求。简单来说，就是要把需求的方方面面都想清楚了，想全乎了！本质上是要求产品经理对这个需求背后的业务逻辑要熟悉和理解。

在梳理功能清单过程中，可以先从这个需求最核心的功能入手，思考核心的功能有哪些；思考完了后，再继续对核心功能进行拆分，即为了支撑这个核心功能，需要有哪些子功能…

那么需要一层层把功能点或需求点拆分到什么颗粒度呢？这里我个人认为没什么特殊的要求，只要你认为能让受阅者理解需求的大体要做什么即可。

对于功能清单，可以描述的内容有：

• 端口：是app还是后台web？
• 模块：是登录还是交易？
• 功能点：即模块下的功能点，有多少写多少。
• 功能描述：每个功能点的大致描述。
• 涉及页面：这个功能会涉及到的页面。
• 字段：有哪些比较重要的字段。
• 备注：有什么需要补充的，就描述下。

功能清单案例如下：

功能清单还是比较考验产品经理思维和需求分析能力的，一定要多思考。可能有人会有疑问，功能清单是分析的过程，为什么要写在PRD里？要知道，功能清单不仅帮助我们整理思路，还可以让受阅者更快速理解需求，提高评审效率和质量。

3）流程图

流程图主要是两种：业务流程图 和 产品流程图。两种流程图都至关重要，在我看来缺一不可！

① 业务流程图

所谓业务流程图，描述的是对应的业务流转途径是怎么样的，反应的是需求背后的业务逻辑。所以产品经理必须要熟知业务，否则做出来的东西很可能是存在偏差的。为什么要画业务流程图，一是验证产品经理对需求的理解程度，二是让下游部门快速理解需求。

业务流程图说清楚业务流是怎么样的即可，案例如下：

② 产品流程图

产品流程图大家应该都比较熟悉了，描述的是在使用这个产品或功能时，用户行为或数据等流转路径，反应的是产品逻辑！这里面可能就会包含各种各样的产品逻辑，其中比较重要的逻辑一定要体现在流程图中，方便研发、测试快速理解需求。

但通常情况下，一个流程图完全不足以描述清楚所有产品逻辑，所以产品经理至少要把核心主流程绘制出来，其他认为比较重要的也可以单独绘制，或者在逻辑梳理部分绘制。

产品流程图案例如下：

在流程图中，不同的流程组件建议标上注释，方便阅读理解。

需要注意的是，功能清单和流程图都是受阅者在阅览详细需求前对需求进行快速整体认知的手段，是非常重要的。当研发、测试通过功能清单和流程图理解需求后，可能会联想到之前做过类似的需求，其中的问题和坑可能也会联想起来，那么在评审的时候可能就会提问相关的细节问题。整体来看会提高评审的质量（当然也并不是所有研发测试都是这样，这里不一概而论，但还是建议要梳理出来功能清单和流程图）。

4）原型图

原型图也叫线框图，可能是每个产品经理第一个接触到并熟练应用的技能，甚至有的产品经理还很热衷于画原型。原型图很重要，但我真的建议不要耗费太多精力在画原型甚至交互上面，能把的原型画出来就好，没必要纠结是否对齐啊，颜色好不好看，交互事情是否ok啊什么的，除非公司有硬性要求（这种公司建议招个交互设计师）。

5）逻辑说明

逻辑说明是整个PRD的重中之重，要投入精力来思考来撰写。整个需求下来会有各种各种的逻辑，比如行为交互逻辑、数据交互逻辑、数据取数逻辑等等，逻辑一旦错误，那么交付的产品极大概率是有问题的。清楚地描述逻辑可以采用纯文字方式（阅读体验感不好），也可以采用页面流程图、产品流程图、表格、文字、图片等多种混合方式。总之，目的只有一个，把逻辑梳理清楚！

一个PRD包含上述5个核心构成基本就差不多了。当然，也并不是所有PRD都要有上述构成，比如报表需求。如果在PRD里加入其他能说明问题的内容当然也是ok的，主要还是看受众、公司想要看什么。

四、总结

最后，关于梳理PRD，有以下几点总结：

1. 理解业务是梳理PRD的前提。
2. PRD的核心是梳理产品逻辑，画原型几乎是个体力活。
3. PRD也是个产品，所以也要考虑你的受众、体验、效果，必要时可量化你的PRD效果，不断总结、提高自己。
4. 写PRD的工具没有什么限制，word、ppt、excel、axure、协作文档等都可以，我个人比较习惯用axure。
5. 还是要根据公司对PRD的要求来写，如果没有要求的话，只要能把需求说清楚，就放飞自我吧。

希望对大家有所帮助，欢迎交流～