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篇文章。
备注：这个有就写没有就不用写。
五、非功能类需求
这个有很多了，每个公司都不同，比如统计类的需求、一些策划类的需求，很多公司用户产品经理和策划产品经理是不做区分的，所以如果都是一个人做，那么就文档统一管理。
到此一个完整的需求文档的结构就写完了，补充一点每个版本迭代都另存一份文档，不要在一个文档里无限的加，这样方便追溯，也方便别人查看，其实这需求文档说说挺容易的，真正做起来做的好的，是需要花费挺长时间的。
在文章的结尾给自己打一个求职广告：
1、坐标深圳，性别男，年龄30
2、三年的产品经理经验（to c的产品）
3、主导两个从0-1的产品，其中一个挂掉了，另一个产品即将上线；一个线上产品的优化。
4、擅长需求分析、文档撰写、项目管理、产品架构等，熟悉数据分析、产品运营；除了产品经理之外我还是一名UI设计师，现在在学前端开发。
5、如果对我感兴趣欢迎联系我，
邮箱：pmshutao@gmail.com
微信：18358047213 二维码如下
