产品经理产品需求文档撰写指南

在产品经理的日常工作中，经常需要借助各类文档来和技术、设计等团队成员打交道。

从需求收集到功能落地，一份合格的产品文档能够减少很多沟通成本，避免返工，帮助产品经理更好地推动项目进程。

因此，写好产品文档是决定工作效率与质量的关键因素之一。

毋庸置疑，产品文档的撰写是产品经理的必备基础技能；虽说是基本功，但是能写出一份清晰简洁的文档，却非易事。

想要写好产品文档，首先要进行反复的深入的思考，写文档不是目的，目的是将产品的思维和逻辑通过文档的形式表达出来。

因此我们可以说，要想写好一份产品文档，就要进行一次有序而全面的思考。

一般我们说的产品文档更多指的是PRD，其他常用的产品文档有BRD和MRD。

那么这几个名字相似的文档究竟有何差别，又分别会用在什么场景下呢？为了进行初步的了解，以下为常见文档的差异对比：
PRD是产品文档中出现频率最高的一种。

一般在需求收集完成，产品经理完成需求相关的业务逻辑、流程梳理后，开始撰写PRD；通过PRD将需求相关的业务流程、数据流向、页面交互等信息清晰地展现出来，作为技术开发评审需求和进行功能开发的依据。

根据不同的产品类型，PRD包含内容和侧重点各不相同。

但是核心在于，完整表达产品经理对于该产品的功能的逻辑、页面以及所有需求的有效表述，有效表述的标准是，技术人员能理解并借助PRD完成开发。

PRD对于产品经理而言最大的作用是沉淀信息，同时也是在产品迭代过程中的需求记录；对于技术而言是开发的依据，是一份“书面化”的任务工单。

一般PRD都是word文档形式居多，但是也可以用AXURE等工具来展现。

既然PRD是产品经理与技术之间沟通的桥梁，那么这座桥梁就应该是双方共同搭建。

技术将自己的理解与开发习惯同步至产品经理，产品经理根据技术的理解、习惯形成针对性的PRD，减少沟通成本，增强PRD 的可读性与价值。

对于入门的产品新手而言，“模仿是最好的学习方式之一”。

需求文档虽说没有标准化的模板，但是在表述清晰简洁的基础上，一般可将需求文档的结构分解下：
文档信息一般包含文档与撰写人的相关信息，包含但不仅限于文档名称、文档版本、撰写人信息（手机、邮箱、部门等）、文档修改记录等信息。

文档名称与版本可帮助产品经理更好地管理和使用文档，撰写人信息可供文档阅读者有问题时及时反馈至撰写人，文档修改记录尤其重要，一方面可帮助技术人员快速分辨出最新版本文档的修改点，减少无效阅读时间；另一方面可帮助产品经理在版本迭代过程中进行文档管理。

需求总览一般可用需求表格形式展现，内容包含但不限于需求分类、需求简单说明、优先级、技术对于需求的分解、排期等。

需求列表不但可以对整个文档的需求做一个完整的统计与整理，在需求范围未确认前，还可作为需求初评的依据。

若是单个需求如活动需求，可将活动流程作为需求总览进行展现。

具体的需求说明需要根据需求的类型进行定制化的说明，一般可能包含页面说明、交互说明、数据来源说明等方面。

页面说明主要阐述页面包含的元素和模块，以及各模块分别满足的需求。

交互一方面要说清页面的业务流程与逻
辑，另一方面要结合设计图与交互稿对页面的反馈、焦点等交互逻辑进行说明。

数据来源主要说明该功能的接口逻辑，数据流程以及后台相对应的编辑功能等。

每个产品经理都应该有自己的PRD管理库。

一方面是针对同一个产品在不断的迭代过程中的各项功能、页面的优化、升级情况有一个全面的统计和沉淀；另一方面，当一个产品经理同时负责多个产品或者多个模块时，PRD管理库能够帮助产品经理更好更快地形成自己的文档撰写风格，发展处一套属于自己的PRD撰写方法论。

经过以上对PRD 的介绍说明，我们已经能对PRD有一个初步的了解和认知。

那么在何种场景下我们会用到PRD？PRD在现实的产品工作中应该如何撰写？让我们以某抽奖活动的需求为例，来讨论下实战中的PRD。

那么，产品经理在何时进入PRD撰写阶段是比较合适的呢？以某活动需求为例，一般产品经理会接到来自营销部门的活动需求，根据需求产品经理提出大致的产品方案，产品方案可以是简单的文字描述、草图说明等，可以让营销、技术理解大致的活动流程和功能即可。

产品经理带着产品初步方案召集需求方和技术团队进行需求初审，确认需求的可行性后，就可以进入需求文档的撰写阶段了。

文档的撰写过程让我们根据上文提到的PRD结构，一一展开详细的说明。

1、首先是关于文档的信息。

我们将文档名称、文档版本、撰写人的信息、文档的修改记录以表格的形式，做简单的说明，如下所示：
2、接下来是关于需求总览，即需求列表。

需求列表一般包含需求编号、需求分类、需求简单说明、需求优先级、任务分解、评估工期、备注等信息中的几项；一般版本中会涉及到多个需求时候，需要以需求列表的形式进行整理，以便技术能一目了然地看到版本的需求信息；当只涉及到一个核心需求如活动需求时候，只需做简单的分类、需求分解、评估工期即可，可简单整理如下：
需求列表需要产品经理针对性地进行调整，会因版本的内容、功能的复杂程度、涉及的模块等有所不同。

3、然后就是针对具体的需求进行说明。

在进行具体某个需求的描述之前，对整体的需求进行概括性地总结，可以结合产品结构图、业务流程图、操作流程图等进行描述。

4、对需求进行整体说明后，我们将对具体功能进行详细说明。

这部分是技术、设计、测试等使用最多的一个部分。

该部分展示的是功能页面的详细信息，主要有页面的描述、交互流程说明以及数据来源（后台接口需求）。

首先是页面描述，根据页面的功能、展现的元素进行说明，举例说明，我们可对做以下页面说明：
页面包含的元素：页面主要包含转盘区、中奖名单、活动规则和我的奖品入口等；转盘中奖品档最多为6种，既支持实物奖品也支持虚拟奖品（电影套票和话费）显示奖品图片名称，后台可添加；
功能基本逻辑：开始状态指针朝12点方向；用户选中“抽奖”并确认，先后进行登录判断、是否有权参与活动、次数判断和中奖结果判断；若用户未登录，则弹出登录页面，用户完成登录之后回到抽奖页面；若用户已登录，则转盘开始转动；如果抽中某个奖品，则在“我的奖品”中显示相应奖品名称；转盘停止后，根据指针所指的奖品出现中奖或者未中奖提示窗口。

其次是交互说明，对页面的焦点，页面交互逻辑进行说明：
交互说明：页面的默认焦点在转盘的『抽奖』。

点击『抽奖』按钮结果共有5种状态：1）进入登录流程2）无权参与活动提示3）次数用完提示4)中奖结果弹窗5)未中奖弹窗；提示框中的提示文本后台可编辑，与4种抽奖状态一一对应，每种状态对应不同的提示语；默认中奖提示：“恭喜你，人品爆发，抽中“xxx”（xxx为奖品名称）……！“，显示“知道了”按钮和“立即领取”（与“我的奖品”中的领取逻辑相同）；默认未中奖提示：“很遗憾您本次没有中奖”，显示『知道了』按钮。

最后是数据来源（后台接口）逻辑说明：。