PRD文档范例，千万收藏的产品经理写作手册

写在前面：
对产品经理来说，PRD是一个很基础的工作，也可以说是产品经理用来沟通的重要桥梁。一份好的PRD文档，可以极大地降低沟通成本，为项目新人提供方向指南，还能给予测试验收标准依据。

你是否遇到过这样的问题？

• PRD里关键需求描述不准确，研发过程中不断修改，导致项目延期；
• 产品总监、项目经理、研发、测试总是不断挑刺，信誉度降低，自信心受打击；
• 到新公司负责新项目，前任产品经理留下的文档晦涩难懂，不知所云。

如果遇到以上一个或多个问题，那么你可能需要反思，自己写PRD的思路是不是有问题？

动手之前，先思考这几个问题

1.解决什么问题？解决用户什么问题？发现问题比解决方案更重要。给公司能否带来收益？相关干系人的需求是什么？是不是老板说这样做的？是不是“他们”说这样做的？他们是谁？真正的问题是他们说的那样吗？
2.怎么衡量？不同的干系人，通过什么指标去衡量问题是否已解决？有没有埋点？有没有业务数据？谁来运营？
3.需要多少资源？为了实现这个解决方案，需要多少资源、多少人？能大致评估吗?
4.会不会太复杂？这个解决方案会不会太复杂？复杂是产品的坟墓。有没有性价比更高的解决方案？会不会影响现有的业务？会不会影响历史数据？
5.有风险吗？这个方案会有风险吗?有没有违法？相关政策是什么？尤其是金融、游戏领域，国家监管比较严，有可能上不了应用市场，有可能三方服务商不会提供服务。
6.有创新吗？有更创新的解决方案吗?竞品怎么做的，有没有调研3个以上的竞品方案。
7.用户怎么说？需求真的是提交人说的那样吗?有亲身体验过场景吗？有跟用户面对面交流吗？熟悉相关领域的基本知识吗？有看不懂的名词吗？
动手写文档或做设计方案之前，一定要问问自己以上几个问题，想清楚了在动手，任何一个问题没想清楚，都不要进行下一步。

写PRD的基本步骤

搭框架、定流程、扣细节，这是从一名产品前辈那了解到的产品设计流程，写PRD，也可以按照这个思路。
1.搭框架
首先遍历出所有用户角色，再针对每个角色，提供相应的系统/功能，然后按照某种维度进行结构划分。
这个步骤完成后，就可以输出产品的系统架构图及系统的功能结构图。

                 ——产品架构图，出自《电商产品设计全攻略》

——更细化的功能结构图

产品由一个个功能组成，功能是逻辑结构，一个完整的功能具备输入、处理、输出三大特性。
从大到小的划分是：系统>功能模块>功能，用户+功能组成了用例，用例是PRD文档里描述占比70%以上的内容，所以合理的功能结构，是写好PRD的前提。
2.定流程
每个产品都有一个核心业务流程，这个核心业务流程涉及多个角色，这个步骤就是把各个角色和功能联系起来。
通过核心业务流程，阅读者可以了解产品全貌，对产品有个宏观的认识。
此外，每个系统也有各自的核心业务流程，全业务流程+子系统业务流程，可以概括产品的业务逻辑。这个步骤输出产品核心业务流程图，子系统核心业务流程图，活动图，状态机图，与外部系统交互可能还有时序图。
3.抠细节
这一步的核心的画原型和功能设计，通过原型表达产品的界面和交互。功能设计主要是从输入处理输出三个方面去考虑，用户执行输入指令后，系统会进行逻辑处理，然后输出结果。
此外，还要考虑功能涉及到哪些数据，表结构怎样设计，这些会涉及大量细节，PRD大部分内容，都是在描述这些细节。
步骤1和步骤2没有严格的顺序，也可以先梳理业务流程，再根据流程中的具体场景梳理出实际功能或系统结构。

文档的组成部分

1.修订记录
记录每次文档更新的时间、作者、修订内容，便于追溯历史变动；
2.全局说明
包括名词解释、统一异常处理、列表默认数据规则等。
名词解释：每个行业都有专业术语，可以提前将晦涩难懂的术语提前做好解释，便于达成共识，更好沟通；
统一异常处理：网络异常、后台服务异常的交互逻辑；列表默认数据规则：
默认列表的排序方式，默认显示条数，超过多少条翻页，缺省值展现方式；
所有涉及全局的描述，都可以罗列在这里。
3.项目背景
每个产品，都有一套价值模型。
以信贷产品为例，针对用户的价值指标有放款额、审批时长、是否上征信等；针对后台业务人员，有审批时效、通过率、放款率、坏账率等指标；针对老板，有投资回报比、员工成本、净利润等价值指标，每一个需求，应该都是围绕某个价值指标展开。
背景从现状、方案、目标3方面描述
现状：描述当前需求方遇到的问题，最好能跟价值模型关联；
方案：针对这个问题，所提供的解决方案概述；
目标：期望获得多少价值指标提升；通过项目背景的描述，可以让项目参与者感受到自己的工作价值。
4.项目范围
项目范围对应搭框架部分，将功能结构图在此处罗列；
5.业务流程
业务流程对应定流程部分，将核心业务流程、子系统业务流程在此处罗列；
6.功能需求
这个部分在PRD中占比最大，搭框架部分，已经将产品功能点全部梳理出来了，这部分就是对功能点进行逐一描述。
功能是从系统的角度来看，我们还要考虑用户角度，所有我们采用用户+功能的方式来描述需求，这就是用例。
完整用例名称一定是动宾结构，如添加文章、删除文章、修改文章、查看文章列表。
一个完整的用例包含：

• 描述（非必须）
• 前置条件
• 后置条件
• 界面交互
• 业务流程
• 异常和分支流程
• 数据字典（非必须）

描述：功能的简要描述。
前置条件：要操作此功能，需要具备什么角色、权限或状态。
后置条件：执行完这个用例后，关联的数据会有什么变化，页面怎么跳转。
界面：每个界面都可以拆分成多个元素，如表单、文本、链接、图片等；
表单的每个元素要描述是否可为空、是否有初始内容、是否默认选中、是否有字数限制等，还有对应的错误提示；文本要考虑最大显示长度，超过怎么处理；链接一定要指定点击后跳转到哪个页面；图片要考虑显示的比例，如果未加载出来该显示什么；还要考虑界面的内容是写死还是通过后台配置；

界面元素：

业务流程：当用户完成输入并提交时，后端应该做什么校验，不同输入该怎么处理，不同结果该返回什么值，最好通过业务流程图+文字来描述，确保逻辑完整。

示例：

文字版：

异常和分支流程：异常流程如网络错误、接口返回异常、服务器内部错误等；以登录为例，分支流程包括找回密码、密码登录等，分支流程非必须，简单的分支流程可以直接通过主流程体现，具体可以视情况按照一定颗粒度进行拆分。数据字典：这个用例涉及哪些数据，可以通过数据字典描述，这一步非必须，最终表结构也不一定就是这样，只是给开发一个参考。有技术背景的产品，也可以做得更细。以注册功能涉及的用户表为例：

产品经理一定要懂基本的数据库知识，程序=数据结构+算法.
用户使用产品时，本质上是在和数据进行交互，只是在用户和数据之间，加了一些列算法。
7.非功能需求数据需求。
常见的就是数据埋点，产品经理需要梳理出埋点事件表，告知开发，让开发在编码过程中进行埋点。
监控需求：需要监控某个接口或某些服务，当出现异常时，可以发送报警信息至相关人员。
性能需求：需要支撑多大的并发，运维人员可以提前准备部署方案。