欲练此功，必先自宫。

本系列文章的宗旨是让大家从源头上理解PRD每个章节的内容，对内容的表达可以创新，但万变不离其宗。 enjoy~

写PRD时，你是否曾经做过以下的事：

• 从公司研发规范文档中下载模版，进行内容填写；
• 当不了解章节的内容时，直接写略或者删掉；
• 在网上找到相似产品的PRD，对文章内容进行替换。

前几年我所在公司刚转型的时候，PRD管理比较混乱，很多产品经理常常使用上一个迭代，或者其它产品团队的PRD模版。把其中的内容进行替换，自作主张的删减，严重者只剩下“产品功能”这一部分。导致了很多需求要么没有可读性，要么又臭又长，甚至需求遗失，团队沟通成本极高，项目延期率居高不下。

这与其说是产品的偷懒行为，不如说是对PRD的理解不够，不得其法。

PRD的定位

我们知道，PRD是MRD的技术量化版，可以指导产品实现，是承上启下的重要文档。因此在产品实现过程中，PRD的重要性不言而喻。因此好的PRD文档，无论格式和内容如何演变，一体式也好，word也好，以下两个问题必定是明确的：

• 在产品实现过程中，谁会看这个PRD；
• PRD是否具备所有读者需要的内容。

所以，PRD的内容需要根据产品形态，项目组织形式等情况，做相应的调整。通常情况下，读者包含但不仅限于以下角色：产品总监、研发、UI、测试、相关产品团队（含硬件团队）、运营、客服。

PRD的结构

互联网敏捷团队，轻文档，重过程，对PRD形式没有特殊要求，最重要的是要合适你的团队，大公司的模版不一定适用小公司，小公司模版也不一定适合大公司。有得的队研发强，有的团队测试强，有的团队运维强，PRD要有所侧重；有得团队经过长期磨合，一个眼神，就知道你的隐性需求，PRD当然可以不写，但是你给别的团队用，可能要解释半天甚至返工。在团队磨合过程中，要形成恰当的PRD，需要对PRD的理解上有了一定的功底，才能写出最合适的PRD。

因此，本系列文章的宗旨是让大家从源头上理解PRD每个章节的内容，对内容的表达可以创新，但万变不离其宗。

整体概览如下，后面会对每个章节分解说明：

基本结构

先从简单的说起，很多只重视“产品功能”的描述，对其它信息不重视，这是一种误区，特别是文档本身的基本信息。当文档涉及到跨项目，跨部门，跨公司，跨集团时，这些内容是很重要的。

封面

这部分是需求的门面，一定程度上可以展示公司和团队形象。

• 公司信息：包含但不仅限于logo，名称，传真等，一方面提升公司形象，一方面便于联系
• 保密级别：公开，普通，机密，绝密等，在一些游戏产品或涉及公司重大战略的产品，保密很重要。这同时也是一种免责声明。
• 文档名称：xx项目/产品 PRD，我见到不止一次，A项目的文档写着B项目的文档名称。
• 文档编号：如果公司有要求则按公司要求，无要求则根据产品体系自行填写，文件名最好带上文档编号。
• 文档编写人：编写人信息，包含部门， 姓名等，代表的是一种责任。
• 编写时间：一般为重要文档版本对外发布时间。

版本信息

又叫修改控制纪录，这部分就像软件的更新说明一样，表明文档与上个版本有什么区别。

• 日期：版本的修改时间；
• 版本：文档版本号，结构与产品版本号类似；
• 版本描述：修订xx章节，新增xx章节，删除xx内容，让读者对文档变更内容有个大致了解；
• 版本作者：该版本的编写人，便于沟通；
• 审核人、批准人：根据实际项目变更委员会的组成情况，确定是否需要。

编制说明

一般情况下PRD文档都省略或合并了这个部分。我曾经参与过一个国家级的项目，当时由多个公司，n多专家共同编写，历时几个月，产品文档共有10个分册，十本纸质的加起来将近有30公分厚。编制说明用于说明文档编制的情况，互联网提倡小而美，快速落地mvp，不会有那么大的需求，所以大家会在背景或概要描述时顺便提一句。

• 编制来源：描述因何进行编写文档。如：因什么政策，有xx公司牵头，xx公司参与，以什么为目标，展开本次工作。
• 编制过程：描述文档编制的过程。如：x日成立工作组，x日组织了研讨，x日组织专家分析，x日正式启动编写。
• 文档体系结构：用于描述本项目或产品涉及所有文档，如：xx综述分册，xx业务模型分册，xx需求规格分册，xx数据模型分册等。
• 编制说明：用于描述当前文档的定位和边界，如：本文档负责是承接并叙述xx相关成果内容，起草单位：xxx。

目录和正文

目录：在修订文档后，更新域即可。一般情况下用不到目录，定位段落的时候用文档结构图比较方便。但是如果需要打印成纸质的项目，目录就必不可少了。

正文：PRD的主体。一般包含引言，概述，功能需求，非功能需求，环境。PRD的功力深浅，就在这体现了。

引言

引言即文档开头，是PRD正文部分的开始部分。

其作用是提供辅助读者深入理解整个文档所需的其它相关信息

背景

描述所说明的软件的应用，尽可能精确地描述所有相关的利益干系人。

• 软件／产品名称：待开发软件/产品名称；
• 提出者、开发者、用户：明确产品干系人；
• 例子：xx产品，是由xxx与xxx合作项目，由xxx提出，由xxx承担开发人物，目前用户为xx项目的车主。

参考资料

列出有关资料的名称、文件编号、发表日期、出版单位、作者等，并说明参考文件的来源。

包含但不仅限于：

• 经过核准的任务计划书
• 上级机关批文
• 项目相关的合同
• 本项目其它已发表的文件，如：MRD、原型
• 文中引用的其它文件、研发规范等

术语

列出本文件中用到的专业术语的定义和缩略语对照，便于理解，适用于接触新业务领域的团队。

概述

如果说引言是帮助读者理解文档，那么概述则是帮助读者理解项目和产品本身。

项目／产品描述

叙述该项软件／产品应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。

• 应用目标：可以理解为产品要解决什么问题，如：针对xx状态下，无法进行xxx的情况，使xx产品可以通过xxx完成对xxx的工作开展。
• 范围：明确产品边界，说明产品将干什么，不干什么。
• 开发背景：为何要开发这个产品，一般情况下根据团队理解程度，节选BRD、MRD相关调研背景资料。

建议平时多与团队沟通探讨，不要把评审当做一种宣贯。

系统模型

用于帮助读者理解系统整体结构，常用于向上汇报，帮助理解系统整体运作。

（1）系统总体结构图

产品涉及的系统整体所处环境分解关系、各层次作用以及数据传递关系，便于理解各系统之间如何配合工作，各自边界是什么。

（2）网络拓扑结构图

系统所处的网络环境，用于理解各系统部署情况。帮助读者理解集群，负载，网络安全等相关信息，便于产品设计和相关决策。

这部分要求产品需要具备一定的技术能力。

假设和约束

指的是产品在实现过程中，必须满足的假设条件和所受的限制。这部分是被大家删减最多的部分。

（1）约束

这个比较好理解，就是影响产品的一些限制，比如：

• 必须兼容的相关系统或硬件
• 必须使用的语言，技术，或者通信协议，如java，dubbo，nginx，灰度，xmpp
• 必须控制的成本，安全要求，保密要求。
• 必须满足的完成时间，比如xx节日之前。

（2）假设

总有一些因素，不是产品的约束，但它们的改变可能影响到需求，比如：

• 最终获取的经费预算满足xx条件
• 某某技术的成熟度满足xx条件
• 公司xx资源满足xx条件
• 市场部或运营部具有xx能力

常见的运营需求也算是一种对运营的假设行为，此部分一方面有助于理解产品所需的资源，便于推进相关任务的进行，另一方面便于研发人员思考相关约束，减少后期返工和修改。

相关阅读

PRD修炼真经•卷一：一份标准化产品需求文档的逻辑思路

PRD修炼真经•卷二：一份标准化产品需求文档的逻辑思路

PRD修炼真经•卷三：一份标准化产品需求文档的逻辑思路

作者：小星星，8年互联网工作经验，5年技术，3年产品。

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

题图来自 Unsplash，基于 CC0 协议