欲练此功，必先自宫。
本系列文章的宗旨是让大家从源头上理解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能力
常见的运营需求也算是一种对运营的假设行为，此部分一方面有助于理解产品所需的资源，便于推进相关任务的进行，另一方面便于研发人员思考相关约束，减少后期返工和修改。
相关阅读
