关于产品经理的三个文档（PRD）
第三篇：产品需求文档（PRD）
在前面两篇文章《关于产品经理的三个文档（BRD）》和《关于产品经理的三个文档（MRD）》中我把自己对商业需求文档（BRD）和市场需求文档（MRD）理解做了阐述。这一篇我再来说说产品需求文档（PRD）的撰写。
不过说文档的撰写之前，我需要先插一些内容。
上面这句话的后面半句又让我想起之前的一个领导，他总喜欢打断别人说话时这么说：“你等会儿，我先插你一下…”，每次都搞得我好拘（菊）谨（紧）。
同学甲：我艹，小楼老师又开车了！
同学乙：小楼老师，不是说好不污的吗？
同学丙：污皇，万岁，万万岁！
读者：一脸懵逼……
好了，以上纯属扯淡！咱们继续正经分析，我要插点什么进来！
我要插进来的内容是：产品原型。
经常有人说产品原型是产品需求文档的另一种形式。
这种说法没有什么问题。
但是，我更倾向于产品原型是市场需求文档与产品需求文档的过渡。
在市场需求文档中，我就在功能概况部分插入了原型图。
也就是说，当我们在尚未决定产品研发之前的决策阶段，就应该有原型参与进来，帮助我们决策。
那么，决策完毕之后呢？
这个时候，原型图则要承担以下责任：
- 线框原型：确定产品结构、布局、功能、模块关系、操作流程。
- 交互原型：功能可用性测试、用户体验测试。
也就是说，在撰写产品需求文档之前，我们应该已经对产品进行了评审，确保了功能完整、可用且体验良好。在此基础上我们再梳理产品需求文档，则会变得更加容易，也能够避免疏漏与错误。
接下来，再说产品需求文档。
产品需求文档其实我们只需要基于商业需求文档、市场需求文档以及产品原型做详实的叙述就可以了。
在下面大家能够看到文档的结构，其中背景、定位、用户群体等均来自商业需求文档和市场需求文档，而结构与功能来自产品原型。只有产品安全与时间进度等需求是补充的产品需求。
有的同学可能有疑问：有没有把产品背景、定位这些在每个文档里都写出来？
这是有必要的！
因为，每个文档的阅读对象是不一样的，作为产品经理有责任、有义务让每一个参与者知道并理解产品的背景、环境、定位目标、文化理念与价值观念。这样才能让每一位参与者都有明确的方向，形成一致的思想，促进产品的生产进程，避免人为障碍。
之前，我提到产品需求文档时，是这么描述的：
产品需求文档（PRD）：用什么赚？怎么多赚？
- 用什么赚？
这里指的就是产品需要具备哪些功能？如何设计这些功能？
比如：产品的结构、组成、流程、用户权限等。
- 怎么多赚？
这一点有两个角度，一方面是产品设计，另一方面是产品安全。
（1）产品设计需要考虑用户的爱好、习惯等方方面面，在完善基础功能的同时，还要考虑中如何能够盈利最大化。在满足用户的需求同时，挖掘潜在需求以及扩大用户规模，都是盈利最大化需要考虑的内容。例如网络游戏从最初的的点卡收费到道具收费，还有互联网产品的分享功能，金融工具的收费分析功能，都是基于盈利最大化的设计。
（2）产品安全对产品是非常重要的，特别是互联网产品！政策管控、环境变化、黑客攻击、抄袭复制、访问压力、开发延期、不可抗力等等，方方面面可能对产品造成的风险都是产品经理需要考虑的。避免风险带来的损失也是赚的一种。
那么，既然知道了写这篇文档的目的，接下来，我们来说一下这个文档要包含的内容。
一、文档属性
- 文档名称：XXX产品需求文档（或说明书）
- 版本号：0
- 撰写人：小楼
- 阅读人：开发部、测试部、市场部、营运部
- 首次发布时间：2017年1月28日
- 预计上线时间：2017年6月28日
二、修订记录
（1）修订时间：2017年2月12日
（2）修订内容：XXX页面/XXX模块/XXX用例，添加/删除/修改了XXX内容。
（3）修订人：小楼
三、产品概况
（1）背景：参照商务需求文档。
（2）定位：参照商务需求文档。
（3）用户：参照市场需求文档。
四、用户角色
写明不同的用户类型，例如：游客、注册用户、匿名用户、Vip用户、管理员等。
五、产品结构
- 产品结构图：参照前文。
- 产品信息图：这张图是在产品结构图的基础之上细化它的组成，包括模块与元素。
- 用例图：可以理解为不同的用户角色能够使用的功能。（图片来自网络）
- 业务流程图
不同角色行为形成的对产品功能的操作流程，给出相应的流程图。下面以用户评论为例。
六、产品功能
（一）、用例编号
登录账号：XXX-001
注册账号：XXX-002
浏览资讯：XXX-003
……
（二）、用例说明（以发布评论为例）
（1）用例名称：发布评论
（2）用例编号：XXX-019 （编号格式各公司有不同规范，此处是XXX是产品名称简写。）
（3）角色：注册用户
（4）用例描述：用户浏览咨询时发布评论。
（5）前置条件：登录账号、浏览评论
（6）基本事件：
- 在评论页点击评论按钮，进入评论界面；
- 在评论编辑区中输入内容，点击发布按钮发布评论。
（7）分支事件：点击清空按钮清空输入的评论内容。
（8）约束条件：评论内容必须超过10个字符。
（9）异常事件：未输入内容时或输入不符合要求时给予提示。
（10）后置条件：编辑评论、删除评论（后置条件是指完成此用例才可执行的用例，即本用例是后置条件中所述用例的前置条件。）
（11）流程图/场景图：
- 流程图
- 场景图
六、产品安全
所有对于产品安全有威胁的风险均要考虑，并分类整理，提出对应的解决方案。例如：原创资讯内容的图片要加上水印或标记避免恶意抄袭复制行为；视频类产品可以通过随机时间与位置的唯一用户标识水印，震慑某些用户盗录传播的行为。
七、时间进度
（1）研发进度
这一块需要与技术负责人确定任务的划分和完成的时间节点，通过甘特图进行管理控制。
（2）优先级
一些产品的功能并非同期上线，在此可以根据上线优先级规划每一部分产品功能的上线时间与研发进度。
以上内容是本人对产品需求文档撰写的理解，分享给大家。如有问题欢迎指正！
用了三天时间终于把《关于产品经理的三个文档》全部写完了，期间也受到了很多朋友的帮助与鼓励，我也希望我写的这些内容能够给更多的人以帮助！如果觉得我写的文章有帮助，请在下面多顶我几下，让我更兴奋的做下去。觉得那篇文章有用就收藏分享，但是别忘了喜欢！
感谢每一位支持小楼的朋友！
~~~~~~~~~~~~ 正文结束 下面没了 ~~~~~~~~~~~~
小楼老师再出新作，倾力打造Axure RP 8精品课程系列，以最短的时间高效完成学习目标，入门进阶与实战案例并重，是0基础的新手从入门到精通的必备课程。
《AxureRP 8 入门与实战 - 入门篇》------从零入门进阶的最佳课程------【点此查看详情】
《AxureRP 8 入门与实战 - 案例篇》------实战手册图书的同步视频------【点此查看详情】
转载请注明：Axure原创教程网 » 关于产品经理的三个文档（PRD）