PRD文档如何撰写

写在前面的话

好久没有写文章了，一方面是因为最近的工作比较忙，另一方面还在不断的学习一些新知识，今天给大家聊一聊产品经理的基本功之一的需求文档，江湖俗称PRD，其实这类的文章和资料很多，这里我仅分享我个人工作中的心得，希望对大家有所帮助。

一、撰写PRD的目的

说起这个话题要牢骚几句，因为自己也在一些群里，经常会看到一些人聊起这样的话题，我到了这家公司，老板让我做产品优化，但是不知道从哪里下手，我说你把需求文档找出来，看看这个需求当时是怎么产生的，用户、场景、需求、和解决方案，后续对这个需求的考核、效果如何，很多时候得到的答案就是没有需求文档。 还有一种场景也比较常见，你做一个功能，吧啦吧啦和设计、开发说了一堆画了个草图，高高兴兴的等着团队人员给你做出来，发现第二天开发过来问你各种问题，设计过来问你各种问题，好不容易搞出来了，发现做出来的东西跟你想的压根不是一个东西，领导过来问怎么回事，开发和设计说按照你的说法做的，这些情况发生的太多了。

所以不难看出需求文档的重要性，那么撰写需求文档的目的是什么呢？ 我认为核心的有两个目的

第一：团队成员对产品达成共识统一思想，并准确的落地。

第二：存档，现在互联网人员流动性挺大的，如果没有记录的文档，当下一任接你工作的时候，需要花费大量的时间去反推这个需求，顺便骂娘，跟开发不写注释的感觉一样的。

二、撰写PRD的工具

Word、WiKi 、Axure、PPT都行，主要看目的，如果说拿去宣讲，那肯定是PPT比较好，如果给开发、设计、运营看肯定是Word和Axure比较好，这里用产品的思维去考虑，用户、场景、需求对应用不同的工具产出就好了，其实从一个工具转移到另一个工具也不麻烦，所以关于工具视自己的团队和使用场景去选择，当然也可以产出多份（如果有需要）。

三、PRD的结构

前面啰嗦了一大堆，也不能说没用，一切事情有因才有果。下面说下一份PRD的结构大概有哪些内容，这里强调下，这个结构不是固定的，根据自己团队的实际情况添加或删减内容都是可以的。

1、文档名

格式：[PRD]+产品名+产品版本 例子：[PRD] 好奇心日报App v1.0 解释下为为什么要如此命名：因为产品经理会有许多文档，比如需求收集文档、用户用例文档、还有一些非需求的文档等等，一般我们会把文档放在一个产品文件夹下面，以[PRD]这个文件头命名是方便索引。

2、修订记录

格式：文档版本+修订日期+（文档模块）修订内容+修订人

例子：

修改记录是为了方便团队成员快速索引，到哪里添加或变更了需求，所以最好把对应的功能模块的编号或者名称写在修改描述里面，还是那句话本身需求文档也是一个产品，要考虑用户能有更好的阅读体验。

3、文档目录

这个跟书的目录是相同的，第一章是什么、第二章是什么等等，以此类推下去就可以了，为了让看文档的人对文档有个概览，如同我们读一本书一样，看下目录大概了解下这本书讲的是什么内容。

4、产品概述

这里面包括三个点要阐述清楚 （1）、产品背景-->为什么要做这个产品? 这个部分可以从几个点去写：生态+需求可靠性+价值+成本 生态：这点从第三方报告或者老板的描述中获取，比如某某市场空间巨大，最近几年一直成上升趋势。

需求可靠性：这个比如我们在产品前期有做过MVP验证，产品的思路得以验证。

价值：主要就是指产品的变现方式，比如通过广告产生收益。

成本：比如我们团队拥有什么什么资源，技术或者渠道有一定的成本优势。

（2）、用户定位-->我们产品的用户是谁? 这个部分以：用户定位+使用场景+需求 以流利说为例： 用户定位：想提升口语水平的白领和大学生 使用场景：哑巴英语，英语学习的过程中只能做题，无法开口，很难找到专业的老师对自己的发音评判纠正，想解决这个问题，需要线下报班学习，解决方案的成本过高。 需求：低成本解决白领和大学生学习英语发音问题。 （3）、产品目标-->我们要做到什么程度? 这个算是一个大家为之共同努力的愿景吧，就是我们做这个产品希望达到什么程度，比如我如果做社交的，我希望做成什么什么样，当然这里根据实际情况去写，你总不能说我超越微信，怎么怎么样。

其实很多产品经理在写需求文档的时候是不写上面内容的，这些内容我认为是很有必要的，就是你做一个产品只知道做功能，都不知道给谁做，为什么做，那么久而久之团队的凝聚力就没了，大家只知道做功能。所以强烈建议把这部分写上。

5、功能性需求

这个部分是PRD的核心，我们团队的成员大部分时间也是看这部分，这一大模块主要包含几个部分，分别是：

一、产品架构

在网上找的，就是用思维导图把产品的架构梳理出来，这个图就是让参与者知道我们这个产品大概的样子，是如何架构的。

制作工具：xmind 免费版的足够用了，或者在线的百度脑图，根据团队和需求选择。

二、业务流程图!

网上找的图，关于如何做业务流程图的思路我前面的文章有写过，这里用一句话再简单复述一遍：“就是目标用户，用我这个产品怎么实现他的需求”，这里以开发的视角来绘制，清晰表达用户流和数据流向。其实这个总的业务流程图一般产品经理接触不到，原因是很多产品经理接触的产品都不是从零开始的，笔者比较幸运，做了两个从零到一的产品。 制作工具：Visio、Axure、ProcessOn(在线工具)，我习惯上用Axure,包括整个文档都用Axure编写，这个还是看实际情况，没有最好只有那个更合适。

三、功能总表

结构是：模块+功能名+功能简介+优先级

四、交互原型图 关于交互原型图，网上有很多做法，这里介绍我的方法。 （1）模块的索引：编号+模块名称

这样写的目的就是在“修订记录”的部分可以把“编号+索引”写在修改描述一栏中，看文档的人就很容易看到你增添或修改了哪个模块的需求，并且能够迅速跳转到相应的位置查看具体的变更细节。

修订记录

交互原型

比如上图，当开发、设计等相关人员看文档的时候，看修改内容对应的编号+模块名称，就可以直接跳转到对应的模块部分去查看了。 （2）具体的页面内容

第一部分：模块的业务流程图

上面有了个总的业务流程图，总的业务流程图相当于一个概览，一般总的业务流程图会梳理一些参与的角色、核心业务的走向等，不会很详细，所以对应模块就要把每个功能的流程图梳理出来，梳理流程图的好处，就是让自己在画原型的时候思路很清晰、不会有太多遗漏的点，我有尝试过在总的业务流程图下面把相应的模块流程图罗列出来，但是开发不看或者选择性看不到，坦白讲从我们的视角来看确实总的流程图下面加上每个模块的流程图条理更加清晰，但我们文档的用户是开发，他如果这面看一下再切换回来本身体验就不是很好，所以我后来干脆把模块的流程图放在原型里面了，发现效果还不错，也一直用到现在。

第二部分：高保真原型图

这个我个人的习惯，先在纸上把业务流程图梳理好，原型图画好，之后软件画高保真原型图，包括一些异常页面，都一张一张的画出来，这里不加各种跳转，跳转的方法我用过，结果就是设计、开发可能会漏点，而且跳来跳去很麻烦，还是踏踏实实的把每个页面展示出来比较直观，这也是算事经验总结吧，还有一点就是为什么直接出高保真，而不是先设计，之后贴图标注。就我的工作环境而言，项目很急一般我都是丢出高保真后设计和开发同步做的，最后这点看自己公司的实际情况。

第三部分：界面描述

我采用的方式是以表格的形式呈现，由元素名称+热区范围+跳转关系+元素说明

首先这样写条理清晰，且不容易遗漏，其次有多少个元素也很清晰，后台开发可以根据相应的元素提供对应的接口。

五、用户用例

这个模块也一定要有，先说下这个模块主要干嘛用的，首先这个模块可以把用户正常使用的流程梳理一遍，核对自己先前做的流程是否有遗漏，其次第二点就是这个可以和测试人员核对，测试用例也是基于此的，我在工作中这个部分是做为验收的一个重要的部分的。 解释下每个模块： 模块名：这个还是老规矩编号+功能名称，便于快速索引到对应的模块的，无论是团队的其他人查看还是测试查看，都能快速定位。 功能名：前面的功能模块已经罗列出来了，一一对应就可以了。

角色：就是目标用户的扮演者，比如注册了的用户。 功能描述：前面的功能总表中也有，是一样的内容。 优先级：前面的功能模块也有。 前置条件：比如测试某个功能，有些功能是注册用户的功能，有些功能是非注册用户的功能，其流程是不同的，那么这两种情况都要写全，所以有这个前置条件。 基本流程：就是用户的正常使用流程，用户的部分比如输入手机号-获取验证码-填写验证码，系统的部分比如填写验证码成功，系统要给个反馈：“注册成功”。 备选流程：比更改用户名，正常流程更改-保存，但是用户输入完了，点击返回了。 异常流程：比如输入手机号，手机号位数少于11位。 后置条件：比如内容类的产品，发布内容，后置条件就是要审核，那么后置条件就是正在审核。 业务规则：还是拿内容类产品来举例，比如限定一个用户一天内只能发布5篇文章。 备注：这个有就写没有就不用写。 五、非功能类需求 这个有很多了，每个公司都不同，比如统计类的需求、一些策划类的需求，很多公司用户产品经理和策划产品经理是不做区分的，所以如果都是一个人做，那么就文档统一管理。

到此一个完整的需求文档的结构就写完了，补充一点每个版本迭代都另存一份文档，不要在一个文档里无限的加，这样方便追溯，也方便别人查看，其实这需求文档说说挺容易的，真正做起来做的好的，是需要花费挺长时间的。