PRD写得好看还不如需求把握得准确，PRD写得好看还不如体验设计得顺畅。

工欲善其事必先利其器。

产品需求文档（以下都简称PRD）对于大多数产品新人来说都并不陌生，它是产品工作中非常重要的一部分。一份PRD可以直接的看出一个产品人对自己所负责的产品的整体把控能力，也能间接的看出产品人的产品思维，表现出产品人对某一垂直行业的专业知识广度和需求洞察能力。

而PRD从本质上是服务于产品执行的一种工具，它并没有一种严格上的定式，不同产品不同项目都有这样或那样的区别，而只有能够最大程度的服务好产品的PRD才是好的PRD。

一个好的工匠是擅长于利用和打造工具的，产品人亦然。产品人除了要擅于打造PRD这个工具之外，还要善于利用它去服务产品的执行工作。

那么，接下来我将以我的个人经验分享一下我打造PRD这一工具的方法论。希望各位可以求同存异，不断迭代优化。

一、头部。

1、文件撰写相关信息。

这里的相关信息都是非常常规的信息，包括文件名称、文件撰写人、撰写日期、文件版本号、文件审核人、文件审核日期等。

2、文件声明。

一般是文件使用权限声明、文件保密声明。

3、文件版本与修订记录

PRD跟产品一样也需要不断的迭代更新优化，那么每一次PRD版本的更新与修改都需要做详细的记录。

如图：

版本说明.png

这里的AMD分别代表：添加（added）、修改（modified）、删除（deleted），每次版本的相应操作都必须做出对应的标注。

二、前言

1、编写目的。

这部分主要阐述PRD的作用：

• 开发人员开发依据
• 设计人员输入源
• 产品经理跟进产品执行实现程度的依据
• 测试人员编写功能测试用例的输入源
• 外部人员产品理解或执行的依据
• 等等

2、产品（项目）周期。

这部分则是阐述清楚产品需求、设计、开发、测试、上线等的相关周期（可用甘特图表示）。一个项目开发周期确定后，没有特殊情况下就必须严格把控和执行项目进度。

附上简单甘特图：

3、相关参考文档资料。

附上相关参考文档的信息。以便相关人员获取更详细的信息。

如图：

三、产品（项目）概况

1、产品（项目）简述。

此部分主要是从整体的角度来去阐述一个项目或者产品，包括产品或项目解决的需求、包含哪些产品、包含哪些功能

1.1、产品或项目的整体描述。

整体上描述该产品或项目的全局，从解决的问题、如何解决问题、所创造的价值等方面进行阐述。

1.2、描述项目中包含的产品。

如果是一个相对较大的项目则需要分别阐述清楚项目下拥有的各个产品。比如，从客户端来说，有PC端、微信端、ios和安卓端；从用户端来说，有B端、有C端。简述各个产品在项目中发挥的作用。

1.3、描述产品中包含的功能。

接下则阐述各个产品所包含的主要功能。

如：对于某款K12实时一对一答疑辅导产品来说，他有老师端和学生端两款产品。老师端的主要功能有为学生解题。学生端的主要功能为上传问题。

2、专有名词解释。

此部分主要解释产品中涉及的相关专业名词的解释。

如下图，主要为教育机构中的业务专有名词：

3、产品（项目）用户角色描述。

当今互联网产品中，产品的用户都不止一个，PRD需在概况中描述清楚产品中涉及的每一种用户角色。
如下图：主要为教育机构中的各种业务角色：

4、产品（项目）总体架构。

此处画出产品的总体功能结构图：功能结构图根据产品的每个功能逐一深入画出结构图。
如下图：为K12教育产品学霸君的功能结构图；

5、产品（项目）业务流程图。

此处画出产品总体的功能业务流程图：（该流程图为现阶段搜提类K12在线学习APP的大致业务流程，流程中并没有对子流程进行细化。实际工作PRD中的细化子流程或文档可在功能性需求中详细附上并详细描述。）

流程图中的图示：

四、产品功能性需求

任何产品的需求都可以分为功能性需求和非功能性需求两类。

• 功能性需求一般是指产品中具体的、用户可使用和感知的功能需求，如登录注册功能、导航功能、文件下载功能、支付功能等等。
• 非功能性需求则一般偏向产品的性能需求，如产品响应速度需求、产品测试环境需求、产品的安全需求等等。

通俗的理解，就好比一部电脑功，能性需求是它能上网、能看电影、能听歌、能玩游戏等等；而非功能性需求则是它的CPU是双核还是四核，内存是4G还是8G，电脑构成材质是塑料还是金属等等。

某种程度上，一个产品的功能性需求决定了这个产品能不能用，一个产品的非功能性需求则决定了这个产品能用多久，而一个产品好不好用则是功能性需求及非功能性需求的双重体现。

以下将以“注册登录”功能为例，讲解在PRD中一个功能性需求的阐述。功能性需求的阐述也是一份PRD中最重要的部分，在实际工作中功能性需求的描述占了整个PRD的50%以上。

1、需求编号及名称。

可根据需求的类型、需求的名称以及需求的优先级对需求进行编号。

需求的类型。如： I=输入需求(Input)； O=输出需求(Output)； W=界面需求(Window)； R=角色及权限(Role)

需求的名称。如：登录=longin；支付=payment。当然，除了大部分通用的功能需求外，大部分的需求名字是配有专业名词的。如：课程消耗=CoursesConsumption。

优先级。则可直接按序号排列。

2、需求说明。

对某一项需求功能进行描述，描述清楚功能的使用者、使用场景、使用动作与步骤、使用结果。

如：登录需求：该需求满足了用户在未登录的情况下，触发相关条件，输入用户id及密码即可完成用户登录。

3、功能的用户用例。

这里将以用户主动登录的一个功能作为例子，展示功能需求中的用户用例。

相关概念的解释：

• 前置条件：即要完成当前动作，必须经过的上一动作。
• 基本事件流：用户在正常情况下无卡点完成某一动作的全部流程。
• 其他事件流：用户在某动作的操作中操作有误，由操作中的错误可能引发的相关流程情况。
• 异常事件流：异常事件流导致该用例无法完成。
• 后置条件：当前动作顺利完成后抵达的页面或触发的条件。

4、功能流程。

同样的将以登录业务流程作为例子展示登录业务中的流程图。该流程图详细地展示了登录过程中的所有流程可能，可详细查看。

5、产品界面原型。

此产品界面原型为上面所讲述的用户用例中的产品界面原型：

通常的情况下，在原型界面需要附上各个部件的文字解释以及页面的动作和跳转逻辑阐述。因为此登录功能为较常用功能，且用户用例中也已经描述较为清楚了，故此处不做文字解释及跳转逻辑阐述。

6、相关字段。

每个功能需求须要写清楚该功能需求下包含的相关字段。字段则是指一个对象中包含的相关变量。

如：对于一个学生用户来说，他的字段可能包含以下几种：id、username（用户名）、手机号码、qq、年级、所在学校等等

五、非功能性需求

1、产品性能需求。

• 用户承载量需求。如：支持2万用户同时在线。
• 产品响应速度需求。如：在网络状况良好的情况下，页面跳转速度不超过5秒。

2、测试环境需求。

• 产品测试环境与正式上线环境的需求。

3、产品数据统计需求。

• 自建的统计数据需求。如：相关事件埋点统计需求。
• 接入第三方数据统计接口需求。如：接入友盟统计。

4、安全性需求。

• 恶意注册防范需求。
• 恶意刷数据防范需求

5、产品兼容性需求。

• 客户端。如：各种主流手机设备均可正常使用，无显示异常，无闪退。
• WEB端。如：各种主流的尺寸及终端的WEB端显示的页面均无显示异常。

虽然我在文章开头写到“一份PRD可以直接的看出一个产品人对自己所负责的产品的整体把控能力，也能间接的看出产品人的产品思维，表现出产品人对某一垂直行业的专业知识广度和需求洞察能力”，但是，工具毕竟是工具，他只是服务于产品的执行，阐述一种产品执行思路。做产品的根本是需求和体验，再好的PRD也不能帮你找准用户体验，再清晰的PRD也不能帮你理顺用户体验。所以，话说回来，PRD写得好看还不如需求把握得准确，PRD写得好看还不如体验设计得顺畅。

而需求把握和体验设计的优化迭代，我将在以后的文章中写下个人看法。

作者： xavi，个人公众号：addoilbuddies 。

本文由 @ xavi 原创发布于人人都是产品经理。未经许可，禁止转载。