最近换了新工作，又重新开始用模版写PRD，上一份工作中PRD是没有模版的，流程图和原型画出来，业务规则写上去，就交给设计研发和测试同学实施了，以便快速迭代，团队小，不清楚马上沟通就好，文档工程师从来不看。新工作团队大，一个模块做出来可能要跨很多个部门，模版式的PRD成了必不可少的沟通基础。看着新公司的PRD模版，回想上一份工作的简易PRD文档，我开始思考，到底一份优秀的PRD文档应该是怎样的呢？

做产品不到4年，这是呆过的第三个产品团队，见过的PRD文档不多，只能根据经验和平时跟其他朋友的沟通，来说说我认为的一份优秀的PRD文档应该包含哪些内容？

在我看来，一份优秀的PRD，应该像你的产品一样，有清晰的目标用户（设计师、开发、测试），有具体的使用场景（设计在进行交互、页面、视觉设计，研发在进行详细设计、需求开发，测试在进行需求测试时使用），有明确的需求痛点（熟悉需求要做什么），产品的PRD文档就是针对上述用户在相应场景下的需求痛点给出的解决方案，因此，一份优秀的PRD文档就是针对多角色的优质解决方案。

因此，一份好的PRD文档应至少包含以下模块：

需求背景、需求描述、角色说明、流程图、页面及功能、与其他系统交互接口、效果预期、数据指标、prd迭代记录

1.需求背景

在早年开始做产品的时候，花在需求背景上的思考时间总是最少的，因为认为这部分对需求实施方来说并无太大作用，简单的几句话，看的人又能获得什么呢？需求实施看到更多的是流程、功能、页面这些具体的内容，因此大部分精力都花在流程功能上了。

直到这一年来，对产品对需求的理解更往前了一些，接触到的优秀设计师和研发人员也多了，每次需求评审前，都会有人问需求目的是啥，我才慢慢理解需求背景的作用。

需求背景，在我理解就是需要解释清楚这么几个事情，需求是如何被抽象出来要在产品中落地实现的，是基于什么样的考虑要做这个需求，做完以后又希望能有什么效果，达到什么目的。

举例来说，得到app中专栏订阅的请朋友读功能，如果让我来描述这个需求的需求背景，我可能会这么写：

由于目前专栏订阅的内容呈现以及消费内容的基础功能已经相对完善，下一阶段重点之一是内容推广，让更多的用户消费订阅内容并愿意为专栏付费，除了平台推广外，我们希望能通过用户对优质内容在社交媒体的自传播拉动用户增长，因此，希望在此版本中增加“请朋友读”功能。

2.需求描述

在讲清楚需求背景以后，紧接着我们需要用总结性的几句话，说明具体的需求描述。

PRD文档的目标用户在了解完需求背景后，大概率希望能看看这个需求到底要做什么，有哪些大的规则方向，会有哪些大的功能模块。总之，就是用三五句话让大家能对要做的需求有一个整体的认知。

还是上面那个例子，如果让我来写需求描述，我可能会这么写：

此次需求主要是在专栏每期内容详情页增加请朋友读分享功能，用户可通过此功能将专栏内容通过社交网络分享给朋友，被分享者可在站外直接打开当期内容详情页消费内容，阅读及收听均可，同时用户可在站外直接购买专栏内容。

3.角色说明

需求的整体概述说清楚以后，在进入详细的需求分析阶段之前，我们要定义清楚，此次需求涉及到的角色都有哪些，这可以帮助PRD文档的阅读者更好的理解需求。

在进行角色说明时，我通常会分为两类，一类是真实的人群角色，一类是涉及的系统。

真实的人群角色好理解，这次需求会有哪些人群参与，比如得到这个例子，主要的参与角色当然是分享者和被分享者，也就是已购买专栏的用户和未购买专栏的用户。

涉及到的系统，通常情况下，一个需求实现可能会涉及多个系统，尤其是大公司的产品被切割得很细，并且用户端的产品，通常还会跟公司外的其他产品交互，比如微信、微博这种社交网络，这些系统都应该在角色说明里体现。

4.流程图

在介绍完上面三部分以后，要开始进入详细的需求分析了，从流程图开始。流程图是需求文档中必不可少的一部分，PRD的读者，从流程图开始对产品有了具体的认知。

通过流程图，读者可以知道此次需求的核心流程是什么，会有哪些角色参与，角色与角色之间是如何交互的，信息是如何在不同角色间流转的，核心的环节又要哪些。

在绘制流程图时，我通常会分两种情况来考虑，如果流程相对简单，涉及的角色不超过2个，我可能会用单线的步骤流程图来呈现，比如下图：

单线步骤流程图

如果流程相对负责，涉及的角色多，各环节之间的交互复杂，多重判断，这个时候我会用泳道图来绘制流程图，习惯用visio来绘制，比如下图：

多角色多判断流程图

5.页面及功能

这一部分不用多说，是PRD的主体部分，详细的描述此次需求包含哪些页面，每个页面的布局，具备哪些功能，每个功能的规则是怎样的。

PRD的读者通过这部分的阅读，可以说基本清楚此次需求到底是做什么的，详细的规则是怎样的。

在这部分的编写中，我会按照大的页面来划分，每个页面当作独立的模块来说明，在进行每个页面的需求分析时，又会分为3部分：功能说明、页面显示、业务规则。

功能说明：整体的概述这个页面承担的功能，包含哪些衍生的子页面，以及与哪些大页面有交互；

页面显示：很好理解，说明大页面以及子页面是如何布局的，包含哪些元素，精确到子页面来说明。比如有一个大页面是信息录入页面，但是这个大页面根据不同的录入状态又会衍生出来许多子页面，这时候要精确到子页面来进行页面显示的说明。

业务规则：跟页面显示对应，说明每个子页面包含功能的业务规则。

页面及功能

6.与其他系统交互接口

根据前面所说，相对复杂一些的需求，可能都会涉及到与其他系统的交互，有的是公司内部的其他产品，有的是外部的产品，这时候，就需要在需求文档中说明，会与之交互的系统，并且附上定义清楚的接口文档。

研发人员和测试人员，通过这部分，能清晰的知道会涉及到哪些系统的交互，哪些信息需要在多个系统间流转，是以什么方式流转的，需不需要加密处理等等。

7.效果预期

做任何一个需求，我们都有明确的目的，有了目的还不够，我们应当根据产品的现状，对此次需求上线后的效果有一个预期，效果预期主要通过数据层面来体现。

有了效果预期，PDR的读者就知道在需求上线后，会对产品带来多大的变化和影响，在需求实施的时候，也能更全面的考虑各种情况。

8.数据指标

这部分跟上述效果预期相关联，有效果预期以后，需要有相应的指标来评判效果，因此，需要在PRD中将详细的数据指标列出来，以便研发对数据指标的提取进行埋点，以及后续数据提取。

这部分和效果预期常常容易被忽略，等到需求上线了，才发现需要的数据没有，导致需求效果难以评估，后续的迭代也没有数据支撑。

9.PRD迭代记录

这部分也是容易被忽略的一部分，尤其是核心的产品需求，在初版需求文档出来以后，没有后续的迭代记录，会导致产品迭代多个版本以后，不知道早期某些功能是如何考虑，又是如何一步步演变成今天这个样子。

PRD从第一版诞生以后，经过多次需求评审，设计评审，详细设计评审、用例评审，其中有许多细节，甚至页面布局、功能点都会有变化，当时可能都是通过邮件、会议纪要来说明，如果不整理到需求文档中，时间长了，或者是人员变化，可能就没有人知道这部分需求最终的实现方案了。

因此，PRD迭代记录也是非常重要的一部分，记录下每一次讨论后需求的变化点，帮助各方使用者及时了解需求变化，以及对最终的实现方案做记录，方便后续查阅。

最后说一下，我理解的PRD的形式，不一定是要写在word文档里，可以在原型图里来呈现；也不一定要是上述部分全部都有，不同的产品阶段，不同体量的产品包含的内容项可能都会有差异，只要能说清楚需求要做什么，怎么做，做完怎么评估效果，就是一份好的PRD。

最后，希望大家都能写出优秀的PRD，不让我们的设计师、研发、测试，从理解需求阶段就折了！

2017.9.29 帝都

-END-

Miss陈

互联网产品经理，喜欢读书，旅行；

理财，成长管理学习中；

有趣的人终将相遇！