都说产品经理有3大文档

• BRD
  • 商业需求文档
• MRD
  • 市场需求文档
• PRD
  • 产品需求文档
  • 产品需求文档是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述

日常工作中很多产品早已由领导层定好了方向，所以BRD和MRD的编写机会较少，更常用的是在产品细化阶段所用到的PRD

一、PRD作用

PRD是将产品需求和对应需求解决方案一起呈现的文档。
文档面向项目相关的多方角色，在项目推进中承担了重要作用，比如：

1. 产品：根据PRD进行方案宣讲，并作为最终检验产品实现程度的依据；
2. 设计：根据PRD的原型作为UI设计参考；
3. 开发：根据PRD的系统规则等内容作为研发依据；
4. 测试：根据PRD的规则来编写用例及测试。

根据需求的覆盖情况也会有其他角色参与，如运营、商务、财务等
不管面向谁，最终目的都是为了让团队成员能够理解业务，在产品研发过程中得到更好地执行

二、PRD要求

为了PRD更好地发挥作用，编写文档时需要清晰、完整且容易阅读的方式将复杂抽象的解决方案呈现出来
怎么才能达到这样的效果呢？文档起码需要符合以下要求：

场景完整

需要考虑需求相关的各业务场景，尤其是特殊场景的应对机制。避免场景缺失造成方案漏洞。

框架清晰

提供系统架构、业务模型、功能结构、系统流程等系列框架，帮助成员从全局层面了解系统概况。

逻辑自洽

系统操作涵盖业务的

• 正向流程
• 逆向流程
• 主流程
• 分支流程

形成系统操作闭环且不冲突

规则简明

对

• 系统全局说明
• 功能模块
• 非功能需求

等各项规则进行描述，编写需通俗且完整

设计友好

系统页面的布局、导航、交互、文案等交互动作，设计需要符合尼尔森可用性原则。

结合具体情况，PRD编写时也会存在其他要求。比如非功能性要求（数据指标需求、运营需求……），也要做到对要求的定义明确无异议。

三、PRD编写

知道了PRD的要求，编写时可以向要求靠拢。但是要求只能作为指导思想，却没有告诉我们具体怎么编写，你可能还有这些疑问。

1. PRD要用什么形式呈现？

PRD常见形式有2种——word和原型
2种形式各有优劣

• 比如word版的目录让人更容易总览全局
• 原型版在功能需求描述时表现更灵活。

采用那种方式要先看公司制度，如有相应规范直接执行即可（规范也可以调整）
如果公司没有要求，则产品经理经过和团队沟通，采用大家认可的、更方便表达和阅读的方式即可

2. PRD要写到什么颗粒度？

写过PRD的同学应该都有过这个疑问。尤其是对规则的描述，写粗了怕有遗漏，写细了怕没人看
除了描述上精简用词，还能从规则提炼和原型设计上进行把控。

规则提炼

对约定俗成的规则、可复用的规则的通过“全局说明”进行描述。如手势操作、输入框定义及限制等。

原型设计

输出的原型不要有高保真原型，耗时且影响UI发挥
不要有复杂交互，不利于快速识别，可在备注中说明；不要过度设计……

3. PRD由哪些部分组成？

对过往项目的PRD常用组成部分进行总结，从通用、概要、详细等部分来拆解，仅供参考
每份PRD的具体组成需要项目结合实际情况进行增删。

通用部分

• 名称
• 目录

• 更新记录

  概要部分

• 项目背景

• 预期收益
• 方案概述
• 项目范围

• 项目风险

  详细部分

• 产品框架

• 全局说明
• 原型页面
• 功能需求
• 非功能需求

  四、PRD组成

  终于到了编写环节！PRD制作是产品经理的基础工作之一，能够直观反映产品经理的底层专业能力是否扎实
  现在知道了PRD的组成，接下来以原型版为例具体说说各部分如何编写。

  1. 通用部分

  1）文档名称

  文档名称是为了能区分不同产品和版本
  常规命名方式是产品名称+版本号
  这里“版本号”的命名每个公司都不一样，可以用V1.0或日期作为版本号。能识别并快速区分即可。
  如：XX车辆租赁管理系统V1.0；XX车辆租赁管理系统-210504。

  2）文档目录

  一般word形式的PRD会配有文档目录，让阅读者更直观的了解全局
  使用原型版本也可以做到类似的效果，可以单独用页面定义为“目录”，将word版本的内容放进去，也可以通过对原型页面的规则命名达到此效果。如下图（部分页面做了隐藏）。

3）更新记录

每次PRD的更新一定要进行记录，帮助阅读者了解每次更新的内容
更新记录一般以表格形式呈现，主要字段包含

• 更新时间
• 变更属性（新增、删除、修改）
• 更新内容
• 更新人员

2. 概要部分

1）项目背景

背景描述是为了让阅读者了解项目或需求的来源和具体情景。
背景包含了

• 业务概况
• 业务流程
• 当前问题
• 整体解决思路

等相关内容
相应内容在用户调研和编写整体解决方案时都会涉及，可直接使用

2）预期收益

产品研发是公司商业行为的延伸，一定会有商业目标（预期收益）
定制化产品是为了实现客户对项目的目标期望（从乙方角度，客户验收通过即可）
自研产品的预期收益则不能简单粗暴的直接用业务收益来定
对于B端自研产品的预期收益制定需要符合**SMRAT原则**，可以考量功能使用率、客户满意度等

3）方案概述

方案概述是为了让阅读者从全局层面了解方案设计的思路，不至于直接陷入细节中
什么是方案概述呢？基于整体解决思路进行拓展，针对痛点问题描述产品的核心功能模块、技术实现方案、运营支持方案等内容

4）项目范围

系统不可能解决所有问题，所以会有边界
项目范围是指产品所涉及的业务范围、所关联的系统等

项目实施前需要及时和项目相关方（干系人）确定

• 项目的范围
• 实施时间
• 消耗资源（成本）

避免关键信息沟通不畅导致的项目风险

5）项目风险

风险是任何事项都不能忽视的问题。提前预设风险项及解决方案，从而降低失控概率
项目中存在哪些风险项呢？

流程

没有明确的规范流程
进度更新不及时
任务汇报占用资源过多（人员、时间）……

计划

重要事项遗漏
用时评估不合理
任务分配不合理
计划没有预留缓冲时间……

人员

人员不足
新人员的适应成本
任务和人员技能的不匹配

沟通

信息传递机制不到位导致沟通效率低（传递方式、触发传递条件、指定对接人）……

需求

需求变更
变更导致的工作调整（项目计划、设计、开发、测试）……

技术

开发环境不稳定
技术难点评估不足
开发和测试用时评估不准
三方系统对接进度延期……

其他

服务器没到位
市场及政策问题……

3. 详细部分

1）产品框架

产品框架是系列组成图表组成，为了阅读者更深刻的理解产品在组成和结构。包含以下：

系统架构图

通过不同层级展现系统的功能模块，表达功能层面的概况。

功能结构图

系统结构的拆解，是**一级菜单>二级菜单>具体页面>操作项**的细化
再细化到字段，就成了信息架构图

操作流程图

用户使用系统时如何通过系列操作完成对应任务的过程

状态机图

描述各关键节点的状态如何触发和流转。如订单状态的变化

以下是过往项目的示例，部分内容做了简化。如下图。

系统架构图

功能结构图

系统操作流程图

状态机图

2）全局说明

针对全局通用的术语、缩略语、交互、系统规则、异常情况等相关内容，可以在全局说明中统一说明。
避免在文档中反复出现，导致文档臃肿，造成阅读困难。
比如：输入框定义、类型、数字限制等，分页规则，各类型弹窗交互说明等。
异常情况则包含了断网、误操作、数据丢失等情况，需要描述对应情况下如何处理，也可以写在具体功能需求描述中。

3）原型页面

原型是对最终产品各页面上内容的呈现，阐述了用户与产品之间交互过程
通过产品架构可以得出需要设计的页面和页面元素
关于原型工具选择、配色选择、页面类型、交互注意事项等内容详见上一篇《B端产品设计：拆个“详细设计”给你看》。
原型页面通常和规则一起进行呈现，页面旁边是规则备注。

4）功能需求

针对每个页面、弹窗进行详细的功能描述，将功能逻辑、字段规则等信息描述清楚
同时尽量采用分段的陈述式描述，避免大段论述型描述
更详细的内容新开文章介绍

原型页面+规则备注

5）非功能需求

除了功能需求的描述，千万不要忘了非功能性需求
非功能性需求有很多种，也会涉及多个相关方，要结合具体项目具体需要进行设计
常规比如性能需求、运营需求、数据统计需求等

性能需求

性能需求需要考虑用户体验和资源投入成本，比如响应时间、最大并发量、兼容性需求……

运营计划

产品配套的运营推广计划，设计运营方，产品设计时需要确认并记录

数据统计

可根据产品需求进行数据埋点要求设计，进行埋点监控，如按钮、页面、事件等
可以自己埋点，可以使用市场成熟的数据采集软件