PRD文档到底有什么用？

prd文档是指产品需求文档，而产品需求文档是将商业需求文档和市场需求文档用更加专业的语言进行描述；prd的主要使用对象包括开发、测试、项目经理、交互设计师、运营及其他业务人员。

该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然，这个定义针对的是一个全新的产品。

广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。

产品需求文档是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。

　首先，先了解清楚PRD的阅读对象，使用者。

PRD的模版中一般有如下信息：

PRD预期的读者包括：产品、开发、测试人员及相应的负责人和用户方代表。产品、开发、测试人员会从中了解到本次需求的背景和详细要求，以及每个需求点未来的优化方向或对用户的价值。而用户方代表则可以通过该文档了解PRD中所描述内容是否是自己期望中的需求，是否符合以及是否都覆盖到了自己的预期。因此PRD也是产品经理同相关角色确认开发任务的重要依据。当所有角色认可了PRD中的内容后，这份PRD将作为后续开发、测试、需求验证的依据。

其次，一个完整的PRD还应该具备的要素有

1、文档的命名和编号

文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。文件命名的方法一般是通过版本号定义，比如简单的方法是，XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号。稍微详细点可以定义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆。

2、文档的版本历史

包括，编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序，文档版本显示的当前修改的内容属于文档的第几个版本(或第几次修改，一次修改一般为一个版本)，章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求，让阅读者直观的了解原因。日期是指需求文档修改的时间，修改人是指需求内容的修改者。

3、目录

不需要自己新建，文档完成后直接更新模版中的目录即可。目录是用来了解文档结构的

4、引言

这部分的内容有：产品概述及目标、产品roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明

产品概述：解释说明该产品研发的背景以及核心功能。

预期读者：文档的使用对象

成功的定义和判断标准：旨在说明产品的目标

参考资料：PRD的参考资料

名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。

5、需求概述

需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等

需求概览：分两部分，一是业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释。二是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级。

用户类与特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和 *** 作行为做出说明。

运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本， *** 作系统、数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户。

设计和实现上的限制：比如控件的开发环境、接口的调用方式等等

项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时间、开发的完成时间、上线时间等等

产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。

6.功能需求

功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：

简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。

场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。这也是产品经理讲“好”故事的必备条件

使用者说明：对产品使用者做出说明，可融入简要说明中。

前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件。

后置条件： *** 作后引发的后续处理。

主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明(这是非常重要的)。

推荐一个方法：“用例”，在面向对象的软件设计模型中，用例是一个被阐述的内容，用例是对功能使用场景的解释。用例很条理的介绍了每个功能的前置、后置条件，主流程介绍，帮助开发、测试等角色快速的了解产品功能。

7、可选方案

列出所有可以选择的达到该产品目标的方案要点(主要思路)，给各方案适当的评价，并推荐最优方案(在功能需求中描述的)。你在做这个产品规划时一定有很多的备选方案，别放弃这些方案，永远没有过时的idea，只有最适合时机的idea。所以可以写出几个可选方案，或许是你下期产品改版一个方向。记住，多思考方案是永不为过的

8、效益成本分析

通过这一点上能看出产品经理必须是个全才，不仅要具备行业知识，还需要有财务知识。一个产品的成本衡量一般包括三个方面：效益预测、产品技术成本和其他成本支出。

9、整合需求

产品整合能力是产品经理很重要的一个能力，业务合作通常是不可避免的，将隶属于两个不同来源的业务功能做整合也是常见需求，比如系统登陆使用公司的域用户登陆，或者付款使用财付通、支付宝付款，解决好整合需求也是体现产品经理核心竞争力的一大重要表现。

10、BETA测试需求

很多产品在正式上线前都有BETA版本或者内测版本，或者叫灰度版本，目的是在测试产品的一些核心功能或者性能。这部份内容不是必须的，但如果需要，需要给出在此阶段要实现的目标或测试、衡量标准。

11、非功能性需求

一般情况下非功能性需求包括以下几个部分：产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等。这些信息构成了产品上线的完整内容，也很好的体现了产品经理的综合素质。

12、运营计划

产品上线后如何运营，目标受众是什么，建议的推广策略、问题反馈途径、风险监控、亮点宣传等等，以及与运营人员的协作方式。作为产品的设计人员不是开发完产品就能画句号的，让产品用起来、用得好，有口碑更为重要，所以非常建议运营计划的制定上有产品设计人员的参与。

首先，PRD是给我们产品部内部人看的。我们根据公司的阶段运营目标，提出合理的需求，那么实现这个需求的功能、逻辑，通过思维导图、流程图、用例图、状态图等做分析，再书写成PRD，慢慢梳理出逻辑。

其次，PRD是给团队的其他人看的。一个业务功能，即便能够在脑海里想清楚所有的功能、逻辑，但是还不能保证团队的其他人也能在头脑里想清楚一切逻辑。所以，就需要通过输出PRD，让团队其他人员理解需求的逻辑。

再就是，PRD也是给领导看的，这样，再跟领导申请资源的时候，给出一份清晰的PRD能够让领导看明白为什么我要要这些东西。

---