第四章：产品设计(2.6)PRD写作 - 需求文档

内容导航：

第四章：产品设计(2.6)PRD写作 - 需求文档

产品经理PRD写作

产品经理文档之PRD

产品经理的PRD到底该怎么写

一、第四章：产品设计(2.6)PRD写作 - 需求文档

2.6、需求文档（PRD文档）

前面的几个步骤是为了帮助我们梳理需求、验证可行性和明确细节，到了这一步的时候我们已经非常清晰的了解产品需求，此时撰写产品需求文档可以大大减少和避免了撰写文档时容易忽略的细节黑洞。

产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式，主要用于产品界面设计和研发使用。因为每个人的习惯和团队要求都是不一样的，所以产品需求文档没有统一的行业规范标准，无论以什么样的格式撰写产品需求文档，最终的目的都是让执行人员能够理解产品需求，根据需求完成产品。

产品需求文档的表现形式有很多种，常见的有Word、图片和交互原型这三种形式，文档内容通常包含信息结构图、界面线框图、功能流程图、功能说明文档。虽然产品需求文档没有标准的规范，但是有两项是必不可少的，那就是文件标识和修改记录。文档在撰写过程中，我们可以自行不断的修改完善，但是如果正式发布或交给团队其他成员后，一旦有了修改，为了文档的同步，我们就需要标注出文档的修改内容，备注修改记录，这样可以方便大家查看和了解改动的内容。关于文件标识和修改记录，格式都大同小异。

① Word

这是传统意义上的产品需求文档，主要有四个部分组成(具体根据产品要求进行划分)，分别是：结构图、全局说明、频道功能、效果图。

因为产品需求文档的阅读者主要是偏向于技术人员，因此文档的目的性非常明确，就是要描述产品的功能需求，所有产品需求文档没有关于市场方面的描述。为了保证需求的执行效率，建议大家尽量减少不必要的文字，在能够让阅读者看懂并且了解产品意图的情况下，文字越少越好。这主要是因为绝大多数人是没有足够耐心认真看完产品需求文档的，因此我们要尽量减化文档内容。

①-1、结构图：

①-1.1、信息结构图：主要是辅助服务端技术人员创建或调整数据结构的参考文件

①-1.2、产品结构图：主要是辅助设计和技术开发人员了解产品的全局结构。

①-2、全局说明：

主要讲解产品的全局性功能的说明，例如网站产品的页面编码、用户角色，移动产品的缓存机制、下载机制，这类全局性功能的说明。这里我举一个移动产品的“状态维持与恢复”的例子。示例如下：

状态的维持与恢复

当用户退出产品时（误操作、Home键、锁屏、自动关机），产品需要维持用户操作前的状态，当用户返回产品时仍可以恢复到之前状态，并继续使用。

维持状态包括流程操作、信息浏览、文本输入、文件下载。

锁屏状态时，如果用户在产品中有下载任务时，仍然保持下载。

①-3、频道功能：

以频道为单位，页面为子项，分别描述产品的频道、页面及页面模块元素的功能需求。示例如下：

1、频道名：频道介绍及需求说明

2、页面1：页面介绍及需求说明

2.1、页面模块1：模块功能需求说明

2.1.1、页面模块1-元素1：功能说明

2.1.2、页面模块1-元素2：功能说明

2.2、页面模块2：模块功能需求说明

在撰写功能需求时，我们需要考虑用户的流程，例如一个“完成”按钮，我们需要描述他完成后，系统要不要给出反馈提示(反馈提示是什么样的形式反馈，内容显示成什么，有没有内容需要调取数据库)，或者要不要跳转页面(跳转到哪个页面，这个页面是其他频道页面，还是这个功能的子页面，如果是子页面就需要再描述这个子页面的模块及元素内容)。

①-4、效果图：

效果图是由设计师完成的产品图，和实际开发完成的产品保真度一致。

这个示例是一个移动产品(iPad)需求文档，其中部分隐私内容已过滤隐藏，并且只保留了首页和地图找房频道的需求说明。由于工作环境没有交互设计师，所以Word文档中包含了部分交互说明。

② 图片

图片形式的产品需求文档是基于效果图的说明文件，将传统Word形式的功能需求说明标注在效果图上，这种方式经常使用在移动互联网领域，实际上是图文形式的交互需求文件，只是在此基础上更深入的描述出功能需求。

对于图片形式的产品需求文档，我们只需要另外再描述一下全局说明，其他频道页面的需求直接以图片形式展示，这种方式相对于Word文档的纯文字更加生动易读并且直观，因此有一些产品经理非常喜欢用这种方式代替Word形式的产品需求文档。

③ 交互原型

这里指的交互原型就是前面篇章讲到的原型设计，使用Axure PR之类的交互原型设计软件制作出来的产品原型非常真实和直观，并且原型软件还支持元素标注和导出Word文档，因此很多产品经理都喜欢使用Axure PR来代替Word完成产品需求文档。

当我们通过Axure PR制作出产品原型后，实际上他已经是很完善的产品Demo了，因此我们只需要加上元素的标注，在标注中说明功能需求，这样导出的HTML文件相比Word文档更直观易懂，是非常高效的产品需求说明方式。

无论你采用哪种方式撰写需求文档，最终的目的都是为了方便团队成员理解产品的意图，因此哪种方法能够避免细节黑洞，高效完成产品的设计和研发，那么这种方法就是最有效的方法。

产品需求文档(PRD文档)系列导读

一、产品经理PRD写作

PRD是什么？

可以说，产品经理最重要的工作就是跟团队说清楚需求，只有说明白了需求是什么，才能让开发、设计、测试等去进行后续的工作。PRD是产品经理说明需求的不二选择。

什么是PRD？

PRD，产品需求文档(Product Requirement Document，PRD)的英文简称，这是一个产品经理为了跟其他项目成员说明需求的重要文档，也是PM参加需求评审会时，你的成果作品。

你可能还不知道需求评审会是什么，那我就简单讲一讲。需求评审会就是产品经理提出需求跟大家PK，让大家评估产品经理提出的需求，然后决定后续工作的会议。几乎所有的开发、设计、测试都会有忙不完的活，你凭什么让他们把你的需求优先开发，这将严重考验你和你的PRD。如果搞不好，你会被开发、设计、测试从头到脚批一遍，那个场面，就像在直播吃翔。

至于为什么会搞不好，很大程度就是产品经理没有把需求的各方面思考清楚，哪怕有一个逻辑没有思考清楚，或者漏掉了某个步骤，团队的其他人就会向你投来怀疑的眼光。如果一次评审会议中你被多次怀疑，那么不用想了，你就是在直播吃翔。

PRD是给谁看的？

首先，PRD是给产品经理自己看的。产品经理提出一个需求，那么实现这个需求的功能、逻辑，通过书写PRD的过程，能够慢慢梳理出逻辑。有人说：”我做高数微积分题全用心算完成，你那些功能、逻辑，我都能想得清清楚楚”。

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

再次，PRD也是给老板看的。产品经理需要做某一个产品，在跟老板申请资源的时候，给出一份清晰的PRD能够让老板看明白你到底要做什么。

你知道PRD有多重要吗？

PRD的重要性，怎么夸大都不过分。

首先，PRD有证明需求的作用。你口头跟开发、设计、测试说一个需求，他们可能也口头上答应帮你做。然后，可能就真的没有然后了。。。接近项目上线，你突然发现他们没有做你的需求，这时你再去找他们，他们完全可以说你没有提出过需求，那场面，直接就是在吃翔。所以，产品经理需要认真写一份PRD，通过需求评审后，邮件群发给开发、设计、测试等大爷，有文件留底，到时候他们就赖不掉了。

其次，PRD有证明PM的作用。很多公司将PRD的修改次数作为作为评判PM水平的标准，还可能作为PM升级评定的参考因素。如果一个产品经理写的PRD平均修改次数过多，那将严重影响升级评定。

PRD闭环

做产品无时无刻都需要思考产品闭环的问题。PRD作为需求的说明书，更是需要体现产品闭环。完成下面的步骤，你就能够写出一份优质的PRD了。

你的目的是什么？

这个是一份PRD最重要的地方，其实做一个产品，或者实现一个功能/逻辑，都不是困难的事，但是你得想好为什么要做这件事，或者说，你要确定做这件事所获得的东西是不是你自己想要的。这个问题想不清楚，后面的都是白搭。比如，你准备做一个游戏活动页，本来目的是为了拉新，但是目的没有把握好，后面做成了留存，那么你的KPI很可能就“呵呵”了。

实现目的所需要的功能？

在目的已经清晰、明确的前提下，PM得好好思考实现该目的所需要的功能，这些功能是实现目的的必经之路。最好给出功能列表，一个功能点都可以单列一条，并且和测试用例一一对应。

还可给出功能的应用场景，方便团队其他人理解该功能的作用。比如，一个简单的用户在某活动页兑奖的情景：

用户在购买某服务后，得到兑奖网址

用户输入该网址后，弹出活动页

用户点击“领取奖励”按钮，页面弹出注册/登录框，用户输入账号密码，登录成功，领取奖励

列出了功能点后，还需要对功能列表里的功能进行排序，得出 优先级 。暂时不做的需求，也要事先提出，放入需求池。

完成功能需要的逻辑？

这部分其实就是将功能分成很多小的功能点，比如一个兑奖的功能，可以分拆成注册、登录、第三方登录等小功能点。实现了每个功能点的逻辑，就组成了整个兑奖功能。

这部分，我感觉是 实现产品体验的最重要阶段 。实现一个功能的逻辑，如何做到让用户使用起来不复杂，同时能够让开发工作量不要太大，同时还能让大部分情景能够正常触达正确的结果，这不是一件简单的事。

异常逻辑、危机处理？

大部分用户能够正常使用功能后，就需要思考一些异常逻辑和危机情况了。这一部分非常考验产品经理的逻辑思维，从深度、广度两个方面全面考验。这一部分也最容易被团队其他人发现逻辑漏洞，分分钟让你感觉在直播吃翔。所以，这一块大家要加把劲，争取想出每一种异常逻辑，做好危机处理。

还是以兑奖活动为例子说明，一个兑奖活动页，目的是为了让某客户端装机量上升，那么必须设定该活动页必须在该客户端中输入，才能跳出兑奖网址（该客户端带浏览器功能）。那么异常逻辑可能就有：

用户不在客户端里输入网址

用户在断网情况下在客户端/其他浏览器输入网址

用户超过活动时间后才输入活动网址

…………

争取需要的资源

完成上面的步骤后，就需要跟项目组要资源了。

项目成员 ：完成产品开发工作所需的程序员（前端、后台、运维等），设计师（交互、视觉），测试，运营，商务等。

硬件资源 ：服务器，宣传物品等

数据反馈

这部分也是非常重要的，你做出了一个产品，肯定是需要知道它的市场反馈如何，得到反馈后，才能决定下一步该怎么走。这里就需要设计数据反馈系统，订立考核指标。

访问量

转化率

留存率

用户活跃天

产品收入

任务、活动完成量、质量

完成以上步骤，一个完整的PRD闭环就做好了，这下子，可以去找其他人PK了，做得足够认真的话，应该就不用直播吃翔了，可以挺直腰板当大爷了。这个世界就是一个“ 要么你是大爷，要么我是大爷 ”的世界，各位还是争取自己当大爷吧。

注意事项：坑，还是很多的

这部分说明一下具体写PRD时，需要注意的事项。

换位思考

写PRD一定要时刻想着换位思考，你得想着你的文档是给开发、设计、测试等看的，语言上尽量好理解，尽量不要用形容词，描述功能时，可以尝试用开发的逻辑去思考书写方式。

不要求大求全

这部分是我踩的一个深坑，我之前总想着把所有的逻辑都整理在一个流程图上，然而这在很多情况下是不可能的，除非你做的这个产品比较简单。即便你真能够将所有逻辑整理在一个流程图上，那么这个流程图也会很复杂，不容易让团队其他人看懂。 功能最好分点说明，正常逻辑和异常逻辑分开说明 。

所见即所得

这是一个读图的时代，图片展现是最清晰明白的。有的功能点，逻辑比较复杂，这时可以考虑用原型图展现，原型图可以做到所见即所得。

实现进度如何？

在PRD之外，最好再做一个项目进度表，这份表格要做到及时更新，让整个团队知道项目的进度。

关于语病和错别字

一份优质的PRD，最好达到新闻稿的校验程度，基本不要有语病和错别字。语病和错别字太多的话，容易让大家觉得你很不严谨。

排版标准

排版一定要有一套标准，保证你的每一份PRD都按照同一份标准。排版力求美观大方，字体、颜色、字号、行间距等方面都需要有一定的选择。

好了，以上基本将PRD的理论知识介绍了一下， 我所说的，可能都是错的 。说了那么多，其实PRD的作用就是让其他人帮你干活。一个极致的情况，模仿全栈工程师，我提出一个“全栈产品经理”的概念。当一个产品经理强悍到精通策划、前端开发、后台开发、设计、测试、运营、商务等，那么这种人我称Ta为“全栈产品经理”。

如果你是全栈产品经理，那么上面我说的关于PRD的东西可能对你来说都是垃圾，你自己就能做完所有的事情，请你务必要加我微信，让我膜拜你一圈。但即便你是全栈产品经理，能一个人完成所有工作，但是完成时间肯定会很长，效率肯定会下降。所以，广大PM兄弟姐妹们，咱们还是老老实实写PRD吧！

二、产品经理文档之PRD

PRD：产品需求文档，全称是Product Requirement Document，是产品文档中最底层最细致的文档。文档侧重对产品功能和性能的说明，主要是把产品规划与设计中的产品流程，界面，功能等定义向研发、设计、测试等团队做清晰的描述说明。

1、帮助团队存档产品信息

产品实现过程中，有很多的逻辑、算法需求，没有文档的记录，容易在团队变更、交接班的时候出现较大风险。通过产品需求文档记录产品的各种需求与实现方式，能有效降低团队的风险，同时也能提高交接效率。

2、提升内部信息沟通的效率

虽然需求可以口述，但是不代表说一次全员就都能记得，会遇到开发、设计或测试记不清楚的地方，可以直接查看文档。结构明确、表达清晰的文档仍然有不可取代的作用。

3、产品工作有据可查

各方需求理解不一致，或延期产品工作的时候，通过产品需求文档都可以有效的找到问题根源。

研发人员：由于研发人员本身专注于功能的实现与性能，所以他们相对于其他岗位比如运营，时长，设计等，表现相对不太关系，对于产品更多地了解来自于产品经理的产品宣讲。

设计人员：设计人员本身更多的会关注产品的表现形式与原型，所以对PRD的需求是相对较弱的。

还有老板、项目经理、运营、市场、客户、财务……

所以，PRD文档，根据阅读对象，可以用最平铺直叙的话，把产品描述清楚就行。

文字模式 ：Word。时间较为充裕的或岗位责任制分明，有文档要求规范的团队，建议选择Word撰写文档。

原型图模式 ：Axure。追求时间效率灵活性的团队，建议选择Axure撰写文档，原型搭配产品说明，无需切换，只用一个文件就可，方便快捷。

无论哪种方式，都是大同小异，本质上并不影响PRD文档的使用效果。

1、修订记录：版本号、修订日期、修订章节、修订内容、修订人等。

版本号说明，以1.25举例：

版本号（ 1 .25）：重大调整升级，一般是产品结构功能等有调度。

子版本号（1. 2 5）：在原有基础上对局部功能进行了升级或调整。

修正版本号（1.2 5 ）：局部小范围优化与Bug修复，一般是不动功能性的东西。

版本号的命名规则：

归零原则：前一个数字增加一位，后面的数字都归零。

修订记录的作用：

对修改前后进行比较

有利于维护和管理PRD

记录修订人和修订日期

方便查询，可以只看修订部分，快速查找变更之处

2、名词术语：将一些产品里面不易理解，容易混淆，或者缩写的词汇在开篇进行统一的列表说明，有利于阅读。

全局说明包括：权限说明、授权说明、异常情况、键盘说明等。

权限说明：对角色权限进行划分，例如登录和未登录状态下可访问的功能权限。

授权说明：手机号授权、地理位置授权、相册授权等。

异常情况：加载失败、网络异常等。

键盘说明：数字键盘、字母键盘。

......

1、产品结构：包括产品功能结构图、信息结构图。

2、业务流程图：通过用户行为串联信息结构和产品结构，可以更好的理解产品经理设计的用户行为。

3、功能清单：清单包括功能模块、功能点、功能描述等。

4、功能详情：原型设计、功能说明和用例。

功能详情的表述顺序可以按照功能的逻辑来表述，或按照产品结构来表述，具体可以看个人习惯和团队要求。

用例：用例图和用例说明。用例图表述的是系统的外部参与者与系统之间的关系，是由参与者与用例组成的示意图。

注意：

撰写前要保证思考到位，产品结构本身短期内不会有重大改动。这样即便是在交付后，出现调整或需要优化的地方，也不会出现重构的情况。

文档中用词用语一致，对于同一事物的表述应该一样，避免混用。

非功能性需求是对产品非功能性需求的说明，包括性能需求、技术组件需求、安全性需求、可用性需求、质量需求等。

性能需求：系统满足多用户同时工作，保障同时在线用户五千人，并发操作一千人的使用需求。

技术组件需求：数据存储及计算使用星环大数据平台等。

安全性需求：涉及外网环境的需保证数据网络架构上保证数据的传输安全、具备良好的跨平台部署能力等。

可用性需求：系统支持IE11并向下兼容，支持Chrome等主流浏览器。

质量需求 ......

上面的文档结构只是PRD的基本结构，并没有成为固定的可以供套用的东西，文章只是一种思路的分享，具体还是要根据自己公司及团队的习惯和达到你的目的为依据来进行调整，切勿生搬硬套。

阅读原文

对产品经理感兴趣的朋友，可以移步“ 行业与市场分析 ”，期待共同交流。

三、产品经理的PRD到底该怎么写

PRD（Product-Requirement-Document，产品需求文档），写作目录如下：
1、文件命名（编号）
文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代。
2、修订控制页
一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。
3、目录
4、请与以下部门讨论PRD
PRD作为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上，需要与相关人员确定“沟通内容”，这对于产品整体流程将是很重要的。
5、概述
概念就是总结，它包括的点有：名词说明、产品概述及目标、产品roadmap、产品风险。
6、使用者需求
使用者需求一般只有个需求描述。需求描述有以下几项内容：目标客户、需求描述、场景描述、优先级。
7、可选方案
列出所有可以选择的达到该产品目标的方案要点（主要思路），给各方案适当的评价，并推荐最优方案。
8、效益成本分析
产品经理是个全才，在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面：效益预测、产品技术中心成本、非产品技术中心支持成本。
9、功能需求
功能需求一般是由四部分组成，功能总览、功能详情、整合需求、BETA测试需求。
10、整合需求
产品经理很重要的一个能力就是体现在产品整合能力上，利用公司现有的资源或外部资源（合作公司等）实现产品功能需求的整合。
11、BETA测试需求
很多产品都有BETA版本放出，为了就是收求意见和一些性能测试。
12、非功能性需求
都说产品经理是全才，在这点上得到彻底的体现。很多产品经理在这点上忽视了，但很多方面使用到的，只是在产品过程中弱化了。
13、上、下线需求
上线时限需求：此产品预定上线日期？上线日期有无任何特殊依据或规定？
下线需求（活动类需求必须明确下线时间）：此产品预定下线日期？下线日期有无任何特殊依据或规定？
14、运营计划
说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户，产品经理是核心需求的把握者，参与到产品整体运营计划显得特别的重要。
……
写PRD并不是产品经理的全部工作，但却是不可少的一部分，很大程度上反应了产品经理的思维和产品核心功能把握上，同时对产品经理沟通、协调、规划等
想学习更多PRD文档写作方式，可以来官网学习