产品经理PRD文档规范

一个好的产品经理肯定是需要写出一手好的需求文档，这样最大限度的帮助开发扫清障碍，并且提高公司的开发效率，少走弯路。所以产品经理也需要经常反思自己的 PRD 文档是否满足当前开发人员的要求，提高他们效率。我从事近 2 年产品职位后对 PRD 文档又有了新的理解，所以现在把这些理解记录下来，帮助自己在每一个阶段进行复盘。

1.PRD 背景描述

PRD 中文名称为产品需求文档，文档的主要作用就是将产品从“概念化”阶段进入到“图纸化”阶段的最重要的一个文档。

PRD 的主要使用对象有：研发、测试、交互设计师以及其他相关业务人员。

• 研发可以根据 PRD 获悉整个产品的逻辑，作为编码的依据。
• 测试可以根据 PRD 编写测试用例，为正式测试做准备。
• 交互设计师可以根据 PRD 设计交互细节。
• 业务人员可以通过 PRD 提交了解产品，为运营和推广做准备。

PRD 是项目启动前，必须经过评审达成共识的最重要的文档，需要反复论证，尽可能的让市场、功能、研发达成平衡。

2.写 PRD 之前，思考几个问题

1.解决了什么问题？

产品经理要发现用户的真实问题，并且反复论证这个问题是不是真的需求。这个功能可以为公司带来多大的价值，考虑这个功能的投入产出比。这个功能老板是怎样考虑的，是否满足用户需要。

产品经理的正确设计思路如下：

这是 PTRA 设计框架，是一种逆向的思维假设，我们需要使用这种思考技巧：假设初始需求都是错误的，我们应该怎样去分析这个需求。不要需求方一提出需求，就开始着手设计，多问几个为什么来了解真正的问题。

2.怎么衡量这些问题？

不同的相关人员，可以通过什么方式来检验问题解决后的用户反馈，需不需要使用数据埋点，有没有业务数据，

3.需要多少资源？

实现这个功能，需要多少资源、人力、物力来解决，可以进行评估吗？

4.会不会太复杂？

这个解决方案是否复杂，有没有性价比更高的可替代方案，能不能使用第三方插件来解决。会不会影响现有的产品业务。

5.有没有风险？

这个方案是否具有重大风险，是否违反相关政策。尤其是金融、游戏，国家监管比较严的，可能因为某个功能而导致下架，承担大量的不确定风险。

6.有新的创新吗？

可以有更创新的解决方案吗，可以分析竞品如何设计的。

7.用户具体需求？

需求是否由提交人所说的那样，有没有亲身体验用用户场景，熟悉相关领域的基本知识吗？

动手写文档之前，一定要问问自己以上几个问题，想清楚的才可以动手，在任何一个位置没有想清楚都将面临不确定风险。

3.文档的组成部分

1.修订记录

记录每次文档的更新时间、作者、修订内容，便于追溯历史变动。

2.全局说明

包括名词解释、统一异常处理、列表默认数据规则等。

• 名词解释：每个行业都会有专业术语，需要提前与相关人员统一好专业术语的含义，并做好解释，以至于更好的沟通。
• 列表默认数据规则：默认列表的排列方式，默认显示条数，超过多少页翻页。
• 所有涉及全局的描述，可以罗列在这里。

3.项目背景

每个产品都有一套自己的价值模型。以 ERP 为例，针对用户的价值指标有生产数量、采购数量、待办事项等，针对于管理层的就是文件审批，数据分析、进度管理等量化指标；针对老板来说，有投资回报比、员工成本、净利润等价值指标，每一个需求都应该围绕着某个价值指标进行。

背景应该从现状、方案、目标三个方面描述：

现状：说明当前需求方遇到的问题，为什么通过系统来解决。

方案：针对于解决方案来讲解。

目标：达到的效果是什么，是否可以降本增效。

通过项目的背景说明，让相关人员可以感受到工作价值。

4.项目范围

首先确定出所有产品角色，再针对每个角色，设计出相应的业务流程、功能模块，然后按照维度进行划分。这个步骤完成后就可以输出产品的系统架构图及系统的功能架构图。

产品是由一个个的小功能组成而来，一个完整的功能具备了输入、处理、输出三大特征。从大到小依次是：系统>功能模块>功能，用户+功能组成了用例，用例是 PRD 文档中最重要的组成部分，所以合理的功能结构是写好 PRD 的关键。

5.业务流程

订流程。每个产品都有一个最主要的流程功能，是为了实现某一个主要功能而产生的产品。这个核心业务涉及到多个角色，这个步骤就是把各个角色和功能串起来。通过核心业务流程，阅读者可以了解产品的全貌，对产品有个宏观认识。

这个步骤产出的由产品核心业务流程图，子系统核心业务流程图，活动图，状态机图，与外部系统交互可能还有时序图。

6.功能需求

这个部分是 PRD 的主要部分，前面简单说明的大体功能，这一部分就是各个功能进行详细描述。一个完整的用例包括：

• 描述（非必须）

  功能的简要描述。

• 前置条件

  操作这个功能，需要具备说明角色、权限或者状态。

• 后置条件

  执行完成后触发什么数据，是否有关联或者变化。

• 界面交互

  页面字段中是否为空、是否有默认值、是否有字数限制等。正确显示什么，错误显示什么？

界面元素

字段(中文)	字段类型及取值	默认值	必输
行程安排
行程单	文本型字段，接口直接给值，只读
行程类型	Many to One 型字段，允许下拉选择，允许创建		是
创建时间	Datetime 型字段，接口直接给值，只读
行程预算	Float 型字段 查询时：接口直接给值，只读； 处理时：接口直接给值，可编辑；	0
目的地	文本型字段 查询时：接口直接给值，只读； 处理时：接口直接给值，可编辑；		是
申请人	Many to One 型字段 查询时：接口直接给值，只读； 处理时：接口直接给值，允许下拉选择；	当前用户	是
申请部门	文本型字段，匹配申请人所在的部门接口直接给默认值，只读。		是
随行人员	Many to One 型字段 查询时：接口直接给值，只读； 处理时：接口直接给值，允许多选；
开始时间	Datetime 型字段 查询时：接口直接给值，只读； 处理时：接口直接给值，允许编辑；	当前时间	是
结束时间	Datetime 型字段 查询时：接口直接给值，只读； 处理时：接口直接给值，允许编辑；	当前时间	是
页签
事由	文本型字段 查询时：接口直接给值，只读； 处理时：接口直接给值，允许编辑；
备注	文本型字段 查询时：接口直接给值，只读； 处理时：接口直接给值，允许编辑；

• 业务流程

  当用户完成输入后，后端应该怎么样去验证，不同输入应该做什么处理，不同结果返回什么值，都是需要描述清除。

  

• 异常和分支流程

  异常流程如网络错误、接口返回异常、服务器错误等。

  以登录为例，分支流程包括找回密码、密码登录，分支流程非必须，简单的分支流程可以直接通过主流程中体现。

• 数据字典（非必须）

  数据字典，可以使开发更专心的写代码，少了文字描述的复杂性，一看就懂。产品只需要须知几种简单的类型即可。如 varchar 文本类型、datetime 时间类型、int 数字类型等，然后写出文本最大长度是否必填，不需要特别复杂。

4.非功能需求

数据需求，最常见的就是数据埋点，产品经理需要了解产品的功能使用情况和功能的欢迎程序，所以需要对功能使用进行统计，这个时候就需要梳理出需要埋点的功能表，告知开发，让开发在编码的过程中进行埋点。

监控需求，需要监控某个接口或者某个服务，出现异常时及时通知相关人员进行处理。

性能需求，需要多大的并发，都需要提前部署方案。