写一份普普通通的PRD

郑重声明：本人讲课的所有资料、内容、图片、文件皆为本人亲自制作，绝对不会拿别人甚至公司的内容来直接宣讲，这是一个职业操守的问题。

先抛个话题：1、很多的产品经理给别人的印象就是开会，写文档，画个图型。2、PRD有没有必要输出，以及如何输出。还是说我们可以直接采用MVP的模式，口头定义需求和界面样式，然后让设计和研发输出。优点是速度快，执行力高，有效输出。缺点是很多事情会即兴而决定，不统一不规范，并且有熟悉的人离开后，新人补缺很难。

那么问题了：明确产品需求文档的目的产品需求文档需要具备以下三种功能： 和团队成员高效沟通，用他们能够看懂的方式清晰地表达你的想法，让他们清楚什么该做什么不该做； 记录之前的问题是如何解决的； 明确列出产品功能的短期目标、长期目标，绘制一个从短期到长期的产品蓝图。

PRD是产品最常用的工作职能之一，另外一个就是原型。那么一份PRD是要写到什么程度，写出来什么内容，写到多少才算是合适的?还一个，合适就好还是优秀好，还是普普通通的就好?

作为一个初/中级产品经理，我的建议就是普普通通的就好。首先，你并没有那么多的时间耗在PRD上，其次需求的变动会导致你的PRD跟不上你变更的频率，最后PRD只是产品最常用的工作职能之一，还有其他的原型，调研，沟通，背锅这些任务需要你去做，不用吃饭呢?不用睡觉啊，不用撩小姐姐啊～

这里说的初/中级的概念是指高级产品经理也用写PRD，但是概要的描述，更多还是做产品规划、执行、未来发展方面的工作。

PRD是功能需求文档，是讲功能内容，尽可能的使用方便理解描述，不要出现拟人词，并尽量用开发者角度去考虑。

那么我们该如何去写一份普普通通的PRD呢？常规我们写PRD有两种方式：WOR写和原型写（以微信来举例）

一、Wor写PRD

Wor写PRD其实是用Wor+截图的方式来完成。常规的产品基本都采用这种方式，至于是不是还需要截图，根据习惯来定（主要是我一般不截图，因为会比较麻烦，一次定义一个栏目，一个栏目最少最3张图，一截图Wor一页就没有了。还一个，我们的屏幕真的没那么大，你的图小了放在上面就是看个轮廓而已）。

先列目录：我一般写PRD包含简介、产品概述、产品说明这三个模块，如果要写到详细我会设定概述、产品综述、功能性需求、非功能性需求、附件五个模块（两个文档中的产品说明和功能性描述是一回事）。既然是写普普通通的PRD那我们就按照简单的来写。

1、简介：

1.1目的：目的很简单，就是告诉观看者，写这篇PRD是要说明什么。微信一个为智能终端提供即时通讯服务的免费应用程序，通过网络快速发送免费（需消耗少量网络流量）语音短信、视频、图片和文字。本文档针对微信V6.6.6版进行前台和后台（模拟）部分功能说明。

本文档清晰、有层次的说明页面各个模块的说明和相关逻辑关系。需交互、设计、前端、后台、测试人员仔细阅读，方便对微信V6.6.版进行完善开发。

1.2范围：说明范围，观看者对应的职责。对APP各页面功能布局，需设计、交互、移动端人员呈现效果，对页面中涉及到的功能点进行说明。文档中包含部分交互和后台功能要求。本文档中加粗、使用非黑色表现的模块需要重点突出，有设定说明的模块是有单独的交互和功能效果。

1.3软件角色分析：这里的角色是指使用软件的角色，不是公司内的岗位角色。

1.4名词解释：在此文档中会有一些词是通用，需要提前说明。例如我们使用C/S架构设计，这里就要说明关于客户端和服务器两部分的一些注意事项，例：客户通过数据请求与服务器，数据库管理系统与客户进行数据互通。功能实现需要后台写接口，移动端负责调用。

2、产品概述：概述我这里一般会用对该版本进行系统的说明表现，通过具体的内容让接触该文档的人能够清楚的明白涉及到的范围。

2.1UML（用例）：用例的方式、方法很多，我这里简要画出来一种，大家理解一下。如果对用例很有兴趣，我可以专门拿这个来讲一次课程。

2.2流程图：流程图一般用的也比较多，这块说明一个整体闭环的对应内容。一般可以用两种方式来保险：业务流程图：

泳道图：

两种图都各自有优点和缺点，还和你的习惯有关系，更和你的领导习惯有关系，转变一下思路而已，并没有什么太难的。我更倾向于业务流程图而已。

2.3功能总览：说明本次PRD都有哪些模块/功能点，分别要做点什么，并且给一个优先级，我在这里还会习惯加一个备注。优先级我一般按照1234来定义，也有按照高中低来划分的这些都没什么太大的关系，看你习惯就好。重要的必须的就是1，重要不紧急的为2，紧急不重要为3，一般的为4。备注这里为特殊说明，就以修改密码为例：功能概述是管理员可在后台修改用户密码，备注是有权限的管理员才可以操作。这里我不单说出了功能，还对功能上赋予了权限内容。

3、产品说明：重中之重的内容来了，一个PRD写的好不好就在此处，甚至说前面都可以没有，只要此模块写好，一切就都很漂亮。以下我们以微信的收藏功能点来举例。

3.1需求名称：收藏功能。写出当前模块/功能点的名字。这里要把模块和功能点做区分，我一般都是按照模块来区分，如果模块下分多个功能，那这里还需要在拆分为二级目录。

3.2需求优先级：4.按照重要的是1，重要不紧急的为2，紧急不重要为3，一般的为4进行划分。

3.3使用渠道：在什么情况下使用。比如微信的收藏功能：别人/其它公众号/朋友圈发布的文字、图片、音视频等内容，用户需要收集在自己的名下。

3.4前置流程：已登录，当前内容允许被操作（收藏别人的内容被删除，该收藏不可见）。在操作这件事情前对应的条件，比如必须要登录（不登录微信也没办法用，这句虽然是废话，但你不写，研发小哥哥真的就不给你做判断）后才可以操作。

3.5业务主要流程：

3.5.1文字、图片：

A、文字和图片已经加载完成后，用户长按弹出提示框，用户点击收藏，页面下方弹出提示框“已收藏”和“添加标签”。已收藏不可点击，只是提醒用户用户该操作已执行完成。点击“添加标签”跳转到编辑标签页面。

C、长按弹出对话框：C.1转发：点击后跳转到聊天选择界面，可搜索/多选/单选给对应人，点击对方弹出发送提示框，可直接发送/取消，发送时可以留言。后退返回收藏页面，同时对话框取消。C.2编辑标签：C.3删除：C.4更多

D、标签（在这里要注意如果标签要单独写的话，这里到跳转就截止了，如果标签是在收藏下面的，那对应的标签内容也应该写出来。）

E、文字、图片被发布者删除后，收藏内也可查看。

3.5.2音视频：音视频在未播放的情况下也可收藏，操作同上。

3.5.3公众号文章：操作同上。

3.5.4朋友圈文章：操作同上。

3.6业务分支流程：业务分支流程是指主要流程以外的关联性内容。收藏的分支可以把上面的标签放在这里。在拿优惠券来举例，分支的流程还要退款、开票方面的内容。

3.7业务规则：只允许当前用户操作自己账号的内容（当前用户指登录后任意角色在手机上的的操作）。

3.8后置流程：收藏的内容在有网络/本地有缓存的情况下可直接查看。后置流程一般是指对应当前操作之后的事情。在比如我们是一个优惠券的模块，那么后置的流程我们还需要有对应前台生成页面。这里的前置和后置不一定是匹配，只是分别对应。

3.9备注：更换机器登录后，收藏内容会保持同步更新。移动端和PC端收藏保持同步。其它：适当的我们还可以在补充一些术语和缩写、参考资料等范围方面的内容，这些具体看自己的需求。

二、原型写PRD原型写PRD其实是用原型+标注的方式来完成。（因为懒，所以借用了产品大牛的模板，这是一个很好的网站，上面有很多别人做好的文件，可以观看有些还提供下载。）

原型写PRD的好处就是你在做好了原型，旁边就说明对应栏目及功能说明内容。

原型-标注

原型-触发效果后

原型-触发效果前

后台原型+备注整体效果