PRD全称Product Requirement Document，中文名为“产品需求文档”。其核心目的是帮助开发、测试、运营、产品人员理解该需求的背景和具体要求，减少产品实现过程中诸多不必要的重复解答，从而提升整体项目推进效率。那么，一份合格的PRD应该包含哪些内容才能避免被怼呢？
一、更新记录
由于项目在实际推进过程中会出现多方并行，以及需求的变更和完善等情况，一份最终版的PRD可能经过了多次编辑和更新。所以需要在文档中添加更新记录，方便团队成员了解完整的需求信息。更新记录中一般包含版本号、更新时间、核心变更内容（尽可能添加文档索引）和操作人。需要注意的是，由于大型项目的版本更新需求涉及的业务相对较多，所以产品不同版本的PRD一般分成不同的文档进行汇总，而此处的版本号指文档变更的版本，并非产品对应的版本号（如合并到同一文档可在前面再添加一列记录）。
二、目录
此处的目录指带索引功能的目录（方便团队成员快速锚点到文档对应位置），可通过文档自动生成。
三、概述
1. 需求说明
主要说明项目的背景和原始需求，帮助团队成员理解需求的出发点。
2. 产品结构
用于描述该产品或需求的主体结构（该结构应和后文的功能性需求或非功能性需求说明目录保持统一），可使用MindManager/Xmind等脑图工具绘制，如结构图过大可考虑通过添加附件的方式提供。
3. 主业务流程
通过流程图、泳道图（可用visio工具绘制）对核心业务流程进行表达。需要注意的是，此处并非详细的逻辑/交互流程，而是对主业务流程的示意，如示意图过大可考虑通过添加附件的方式提供。
四、名词释义
如文档内包含特定的专有名词，包括全新定义的、已有的非常见的名词，以及常见名词的衍生定义，则需要对相应的名词进行解释。
五、功能性需求
1. 全局性交互和数据规则
1）交互
全局性交互更多见于一些加载、网络、提醒情况下，某些特定的交互和场景下也可能存在特殊的全局性需求（如微信的悬浮窗功能）。
2）数据规则
全局性数据规则常见于最高优先级（相对）的数据，用于限制下级数据的下发，如黑名单管理、用户状态等。
2. 各个模块的详细说明
对于各个模块的层级划分需和前文的产品结构保持一致，需详细描述业务模块的展示、交互和数据逻辑，一般包括以下几个方面：
1）原型
具体该模块的原型，若与实际设计图有变化（包括信息元素的变动或布局的较大变动），应替换为设计图截图或修改后的原型。
2）信息/显示规则
基于原型所见内容或规则需要，模块中会用到哪些信息，以及展示时候有哪些类型或限制，具体说明为：
A.信息展现形式：文字、图片、图标；
B.信息展示内容：具体文案、图标的需求；
C.同一信息如果存在不同类型或状态的说明，比如性别男、女；
D.信息展示的规则限制，常见有：字数限制、行数限制、高度限制、宽度限制、缩放限制、颜色限制、格式限制、隐藏限制等。
3）交互规则
交互的范围很广，常见的交互需求应包括以下内容，但可能很多交互情况的处理方式可以标准化，但在需求中仍需说明，具体应根据实际产品/需求而定。
A.交互操作：点击、加载（加载中、加载失败、加载超时）、滑动/拖动（左滑、右滑、上拉、下拉）、长按、双击、多点操作等；
B.交互响应：变色/变暗/变量、区域响应、文字响应、动画响应、效果响应、文字显示；
C.响应结果：指的是交互操作后的各种结果，某些情况下如果需求特殊的交互响应过程/动画，应特别说明；
D.技术实现：专指特殊的交互动作/动画需求，应提前找到案例或与开发人员沟通，避免不具备可实现性。
4）数据规则
与“信息”的差异在于，信息更偏于直接显示的、以及落地到每一个文字/图标细节的元素，而数据规则是更整体化的规则说明。数据规则制定时，应首先确定好方向定位，再拟定初版规则并进行完善，同时数据规则的设定一般对技术依赖严重，因此需提前和技术沟通。（一般而言，数据规则至少包括数据如何获取、数据如何缓存两部分）。
5）异常状态
异常状态常见包括加载失败、无数据、超时等，同时，部分特定场景下的产品/功能还有特别的异常状态，比如未获得相关权限、无相关设备、空间存储不够、文件丢失、文件格式不支持等。
六、非功能需求
非功能性需求基于不同类型的产品/项目，差异性可能较大，常见的类型包括：
1）性能需求。如大致响应时间需求、最大并发数要求等；
2）兼容性需求。通常情况下，PC端网页要求对主流浏览器如IE、Chrome、360、QQ的兼容，H5网页要求对UC、QQ、微信、Safari等浏览器或客户端兼容，iOS APP要求兼容iOS891011系统以及iphone5、5s、6s等以上设备，安卓APP要求兼容4.2/5.x/6.x/7.x/8.x/9.x等主流系统以及华为、小米、三星、oppo、vivo等设备；同时移动网络都要求兼容电信、移动、联通三大运营商基本网络类型等；
3）网页的URL和TKD；
4）大页面/模块的缓存规则（但如果部分模块的缓存规则是独立的，则应在具体模块的数据规则说明中直接说明）；
5）纯文字/图片设计内容（比如设计礼物、表情等）；
6）风险控制需求。部分业务有可能存在一定的风险，比如被刷注册、刷评论等，这类风险可提前在技术实现时做一定的兼容可控性。
七、数据统计需求
数据统计有的可直接在服务器统计，有的则需要前端/客户端上报统计，有的还可以直接使用第三方统计工具，需根据实际情况区分。但一般包含以下四部分：
1）基本数据统计：如用户新增、活跃、留存等统计；
2）业务数据统计：如业务收入、支出、付费率、退款率等统计；
3）事件行为统计：以操作类统计为主，可组合成相应的路径统计；
4）统计展示后台：主要用于展示数据报表，方面产品、运营和管理人员直观查看数据。
八、交付与上线
1.交付说明
交付的核心是保证项目/产品在推进过程中有对应的人员进行对接，所以需要针对涉及到的不同部门，明确相应的交接人员，如：开发、测试、运营、财务等。
2.上线方案
为确保产品的最终效果，一个优秀的上线方案至少应从以下方面准备充分：
1)历史数据或交叉业务处理；
2)技术支持；
3)运营方案；
4)推广策略；
5)数据和用户反馈跟踪。
结语
PRD的意义在于围绕业务把需求表达出来，把要做的东西说清楚说明白，提前把一些需要准备的事项安排好，其核心的目的是提升项目的沟通和推进效率。不可否认，PRD的编写能力，可以体现一个产品经理对于需求的理解和表达能力，但这并非适用于所有公司和产品。对于一些小型项目或者小版本改动，可能大部分的交互和逻辑描述只需要在高保真原型上示意就够了，编写完整的PRD再推进还可能影响整体的项目推进效率，所以，最重要的还是围绕业务和项目实际情况，选择合适的方式把需求准确的表达出来。
