编写PRD文档：产品需求文档(Product Requirement Document，PRD)

每一个产品经理都写过无数的PRD，大到整个系统，小到某一个功能。今天我们来聊聊PRD文档如何编写，以及如何写好一份PRD文档。

首先，我们用产品的思路来分析一下，PRD文档的用户是谁，以及使用场景是什么。

1、需求方：当需求方提出需求并与产品经理讨论后，产品经理开始编写PRD文档，编写完成后，与需求方开会确认PRD文档中的内容细节。修改确认无误后，再去跟研发人员进行讲解。

2、研发人员（交互设计师、UI设计师、前端工程师、研发、测试）：在与需求方确认并锁定需求后，将PRD文档中的需求向研发人员进行讲解。让研发人员明白需求，可以开始进行研发。同时在日后的研发过程中，如果研发人员对细节遗忘或者需要确认，只需打开PRD文档找到对应内容即可。

从以上两个最常用的使用场景来看，PRD要具备非常强的可读性，同时对功能的描述要非常详细，不能有遗漏（是的，绝对不能漏功能，不然少做一项内容就是产品经理的锅），最后还要保证专业度。

看起来好像很难，我们来拆解一下，一份完整的PRD都包含哪些内容，请看下图：

我们一项一项来说：

1、修订历史：

在与运营确认需求的时候，总是无法避免修改功能。甚至有时候在给研发讲解的时候，由于技术原因有些需求也需要修改。这个时候就产品经理就必须要记录每一次更新的历史，同时记录原因。你可以这么写：

2、项目背景：

通常来说这个不是必须写的，为了完整性和专业度，建议产品经理还是写一下，也算是一个记录。比如“双11大促，冲刺100亿销售额”之类的。

3、业务描述：

与项目背景一样，不是必须写，但依然是建议写，可以不用写太多。或者你可以补一张业务流程图，以抽奖为例：

4、产品模块：

依然不是必须要写，但还是建议写的内容。主要包含本次项目中的所有模块，可以不用细到功能点，但建议有功能点的描述。如果是一个跨多个系统的项目，还需要增加属于哪一个系统这一列，比如一个退换货流程：

5、功能描述：

这部分是整个PRD的重中之重，必须要写的很详细。每一项都要包括一张线框图和文字解说。如果一张页面有不同的状态，要分开解说，以及说明这些状态是在什么条件下进行切换。我以登录框为例：

这么一个看上去很简单的登录框，要如何写说明呢？我的原则是，先进行交互元素的描述，然后是规则。你可以这么写：

- 手机号输入框为文本输入，能够输入最大的长度为20个字符，如果超过20个字符则不显示在文本框中；

- 密码框为密文密码输入，用户不可见输入内容。能够输入的最大长度为20个字符，如果超过20个字符则不显示在密码框中；

- 出错信息位只在验证出错的时候用于文本提示，平时不用显示；

- 登录按钮，用户点击后进入登录验证流程：

1、验证手机号文本框是否为空，出错提示为：请输入手机号！

2、验证手机号文本框中输入内容是否为合法手机号。验证规则为：11个数字。出错提示为：输入的手机号有误，请从新输入！

3、验证密码框是否为空，出错提示位：请输入密码！

4、验证手机号和密码是否匹配。出错提示：手机号密码不正确，请从新输入！

- 注册按钮，用户点击后，新打开一页跳转到注册页。

如果你想写得更好一点，验证流程可以补一张流程图。

至于有一些登录框是在输入内容后失去焦点验证，或者在输入错误3次以上的时候增加验证码输入，大家可以自行脑补如何编写。

6、数据需求

通常来说，数据需求我们会新启动一个项目单独做。但是像活动这样的PRD，我建议还是补充上数据需求，因为除了常规的数据监控以外，活动总会有一些特殊的数据需要记录。这里的也要写的很详细，在什么页面记录哪些事件。

7、人员评估

这里是一份排期表，一般来说我们会使用单独的工具（比如project），生成一份排期PDF后，可以附这里。

8、测试需求

除了功能性的测试，如果有一些特别需要注意的测试内容可以写在这里。比如：需要在iOS10、iOS10.1、iOS10.2下进行测试。

9、风险评估

主要写一些跟项目相关的风险问题，如果没有就可以不用写。比如：UI设计师小明身兼三个项目，可能会对项目造成影响；又或者研发小李在10.1之后请了7天年假，可能需要从研发二部临时抽调人员。

希望对大家编写PRD有所帮助。