产品经理PM如何撰写一份“对标大厂”的PRD

PRD是产品由立项阶段进入到需求阶段的最重要的一个文档。

简而言之，PRD就是将宏观抽象化的业务，拆分成具体化的功能需求，并通过文字或图像等方式呈现出来。

PRD文档主要使用对象有：产品、设计、项目、开发、测试。产品经理可以根据PRD进行功能自查，从而更加完整的梳理产品；设计师可以通过PRD来设计交互细节，并改善用户体验；项目经理可以根据PRD拆分工作任务，并分配开发人员；开发人员可以根据PRD获知整个产品的逻辑；测试人员可以根据PRD建用例，并进行可用性测试。

传统的PRD文档冗长而复杂，一方面不方便产品经理清楚且全面的表达产品设计的相关细节，另一方面不方便产品经理将需求简单且清晰地传达给PRD阅读者。

二、PRD文档的目的

PRD文档是产品新人入门的一门必修课，是进入职场的敲门砖，也是产品经理基本功的体现，更是衡量产品经理整体思维的一个标准。

PRD文档是每个产品经理打交道最多的文档。也是项目启动之前，必须要通过项目组评审，并确定最终需求范围的重要文档。

PRD文档在项目立项阶段，可评估产品机会。在需求阶段，可定义产品功能范围。

PRD文档可以梳理产品业务逻辑，记录需求变更内容，管理产品迭代过程，便于部门需求沟通。PRD文档的好坏直接影响到开发进度、测试质量以及最终的实现效果。

PRD文档是产品经理和开发人员沟通需求的重要工具，产品经理一般用它做需求管理和版本管理。PRD文档首先应该展示的内容是需求，如果一份PRD文档能够充分的表达用户需求，那么它就可以作为需求验收的标准。

三、如何写PRD文档

之前有些想转行和刚入门不久的产品朋友，在产品经理朱学敏公众号留言问我怎么写PRD文档。借着这个机会，给大家分享一下我自己的一点产品经验。

撰写PRD文档的方式有多种，常见的有Word、PPT、Wiki或Axure等，但我个人更倾向于直接在Axure中撰写PRD。此外，描述需求或业务规则，我侧重于用视化的结构图、流程图和原型表示，文字只是作为补充说明。

PRD文档内容结构包括：文档概述、产品说明、全局说明、功能需求、非功能需求、改进建议等。基于以上几个方面，从理论角度阐述，结合案例做分析。

1、文档概述

1.1 修订记录

主要包括版本、时间、内容、备注等，方便沟通和记录产品成长路径，为规划未来产品迭代提供参考。以下是PMLink产品迭代的一个简化修订记录。

1.2 项目背景

简单描述项目的背景、目标、定位和用户等，让成员对项目有整体的认知以及明确方向。

1.3 阅读对象

文档的主要阅读对象和使用者，一般包括产品、设计、项目、开发、测试和甲方负责人。

1.4 专业术语

对文档中会出现一些专业名词做解释，方便项目成员理解业务并统一名称。

2、产品说明

从产品生命周期了解各个阶段的运营活动，比如产品路线图、功能清单、产品结构设计、用例图、业务流程图、需求列表、产品进度、开发进度等。

2.1 产品路线图

2.2 功能清单

2.3 产品结构设计

2.4 用例图

2.5 业务流程图

2.6 需求列表

2.7 产品进度

2.8 开发进度

3、全局说明

对产品设定的一些行为准则，按照既定标准、规范的要求进行操作。比如页面设计规范、产品状态规范、操作提示规范、数据加载规范、消息通知规范等。

3.1 页面设计规范

3.2 产品状态规范

3.3 操作提示规范

3.4 数据加载规范

3.5 消息通知规范

4、功能需求

功能需求一般是由四部分组成，功能总览、页面原型、用例描述、业务规则。主要是对所有的产品功能的描述和规划。其实就是通过场景模拟，告诉用户此功能主要干什么的，并了解产品在哪种情况下会被用户使用。

4.1 原型页面

常见的原型设计方式有手绘原型、灰模原型、交互原型。产品经理一般是画低保真的手绘原型或灰模原型，而高保真的交互原型更多是让UI去实现，但我们要在软件需求中，说明所有页面的展示及每个功能的状态。

4.2 用例描述

用例描述文档是用文本方式来表述的，为了更加清晰地描述用例，也可以选择用例图或流程图来辅助说明。

用例名称：该用例的名称；

用例编号：该用例的编号，一般定义到功能Uc级；

操作角色：参与或执行该用例的用户。

优先级：功能优先级排序；功能目标：功能要实现的预期效果；

前置条件：参与或执行该用例的前提条件，或者所处的状态；后置条件：执行完毕后的结果或者状态。

4.3 业务规则

业务规则是指对业务定义和约束的描述，用于维持业务结构或控制和影响业务的行为。即告诉我们此功能在操作时有哪些约束条件。

以PMLink快捷登录为例，会对操作、输入框、内容格式、长度、点亮、控件、数据之间的关联性做出说明。产品在使用时要有相应的业务规则，且业务规则必需是完整的、准确的、易懂的。

业务规则将系统处理的业务逻辑从程序代码中抽取出来，将其转变为简单的业务规则，以结构化的业务规则数据来表示业务行为。这样用户无需找程序员帮忙，就可以更改业务规则。

最典型的就是CRM客户关系管理系统，其复杂且多变的的业务规则，就需要一套业务规则引擎的架构设计。

5、非功能需求

非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。一般会涉及到的有：性能需求、安全需求、可靠性需求、数据监控需求、系统需求、运行环境需求、外部接口需求等。

以性能需求为例，我们会关注每秒处理的事务,功能操作的响应时间,页面刷新时间。以系统需求为例，我们会关注服务器连接失败后的重启次数.时间引起失败的比例 失败时数据崩溃的可能性。

6、改进建议

改进建议实际就是基于用户体验区优化产品路径。

网上有太多的PRD文档，可以作为参考，但不是标准规范。最忌讳的就是把BAT大公司的文档规范标准，按部就班的套用过来。要结合公司的实际需求，去撰写适合自己产品团队的PRD文档。

写好PRD不是一蹴而就的，除了基本的专业能力和逻辑思维，还得此外，要常收集、常反馈、常总结。

写PRD文档不能为了面子工程或个人绩效，写一堆无关痛痒的废话。这样只会导致需求评审时，产品经理说的天花乱坠，开发人员看得眼花缭乱。需求最后最后要回归到时效性，在业务逻辑清晰的前提下，尽量用精简的语言，把需求快速传递给开发。

一份接地气的PRD文档，一定是遵循整体逻辑清晰，语言简洁易懂，信息实时共享，明确功能范围，并快速需求落地的原则。总而言之，PRD文档最重要的就是把需求表述清楚。