1、理解并掌握PRD文档

-写作思路 -写作方法 -写作格式

2、什么是PRD文档

– PRD文档向上是对MRD内容的继承与发展，向下则是要把MRD文档里面的各种理论要求技术化，向研发部门与设计部门说明产品的的功能和性能要求。 – PRD文档是产品文档中最底层最细致的文档，所以写作的时候，需要细致耐心。

3、再谈BRD/MRD/PRD文档的区别与用途

3.1 BRD

-这么做有好处，并说明好处在哪里

– 唐僧出发前,参见唐皇（老板）,告诉唐皇西去取经的重要意义与大兴佛法的好处,唐皇答应,并发放免签护照（授权），于是唐僧带着任务出发了，那个时候唐朝真实V5啊。

3.2 MRD

-通过BRD明确了这个事情值得一做后，描述应该这么做，并说明这么做的原因

– 唐僧上路了，但是他需要选择走哪条路线，带几个人，为什么这么走，为什么带这些人，要说清楚：

A路线：妖怪多 B路线：神仙多 C路线：美女多经过分析，唐僧决定选择C路线，所以才有了三打白骨精，路过女儿国等经典故事（开个玩笑）

3.3 PRD

- 获得了授权，而且已经确定了要走的路线，剩下的就是打造装备（产品）了

– 要把装备的需求给工匠（研发人员），就需要把你（PM）对装备（产品）的要求讲清楚

金箍棒（需要能缩短到耳朵里面，直径1毫米，长度6毫米，需要金色，重量必须控制在1KG）九齿钉耙（必须要9个齿，废话啊，黑色，齿长8cm，把手长1.5米，直径2.5厘米）于是工匠（研发人员）根据需求，打造出了旷世的武器

BRD>MRD>PRD是一个逐步论证并得出结果的过程，是产品经理思维升华的过程，是这三个文档三位一体的过程。

4、PRD文档面向的对象

4.1 研发人员

-由于研发人员本生专注于功能的实现与性能，所以他们相对对其它诸如运营，市场，设计等表现相对不太关心，对于产品更多的了解来至于产品经理的产品宣讲。

4.2 设计人员

-设计人员本生更多的会关注与产品的调性与原型图，所以对PRD文档的需求是相对较弱的。所以，PRD文档，根据阅读对象，就不要去耍花架子了，用最平铺直叙最简单的话，把问题说的一清二楚就行，绕来绕去小心被程序猿们掏出板斧劈成两截啊。

5、PRD文档的几种表现方式

说到PRD文档，很多朋友之前看过模版，都会不假思索的打开Word开始写作，其实PRD文档的目的在于把问题讲清楚，而不是用什么工具！根据实际情况，能满足把问题讲清楚的方式大概有以下几种：

– 文字模式（Word…..最常见的） – 原型图模式（Axure….推荐使用的） – 图片模式（有的产品经理本来就是美术转交互转产品，所以他们擅长于此，有门槛的….） – 影像模式也可以，就是太烧油了

6、常见PRD文档包含内容

文档说明、产品说明、全局功能说明、详细功能说明

6.1 文档说明

6.1.1 产品版本号（1.26）

-版本号（ 1.26 ） –> 重大调整升级 –> 产品结构功能等有调整只有以上几点情况出现，才会修改版本号 -子版本号（ 1.26 ） –>在原有基础上面对局部功能进行了升级或调整 –> 在原有基础上面对局部功能进行了升级或调整只有以上几点情况出现，才会修改子版本号 -修正版本号（ 1.26 ） –> 局部小范围优化与Bug修复 –> 一般是不动功能性的东西只有以上几点情况出现，才会修改修正版本号 -版本号的命名原则 –> 归零原则：前一个数字增加一位，后面的数字都归零 –> 收费原则：子版本号和修正版本号的变化，一般看做版本内升级，不加收费用，版本号变化则加收费用

6.1.2 历史修订

– 编号 – 版本号 – 修订章节 – 修订原因 – 修订日期 – 修订人历史修订的作用： ->对修改前后进行比较 ->有利于维护和管理PRD ->修订人 ->修订日期 ->方便查阅，可以只看修订部分

6.1.3 名词术语表

将一些产品里面不易理解，容易混淆，或者缩写的词汇在开篇进行统一的列表说明，有利于阅读。例如产品100的： -积分：根据产品100用户的一系列操作行为系统根据后台设定产生的虚拟分数，积分决定了用户的等级与论坛权限，积分的计算方式为：总积分=发帖数X1 + 铜币X1 + 威望X1 + 会员历史在线时间X1 -威望：反应了用户在论坛里面的资历，是根据发帖数量，回帖数量，附件上传数量，在线时长等综合因素决定，是用户积分的重要参考依据 -铜板：产品100的货币，主要用于购买有价值的下载资料与信息，完成新手任务可以获得初期足够的铜板，发布下载资源也可以获得相当数量的铜板，铜板是用户积分的重要参考依据。

6.2 产品说明

包含：产品信息结构、产品结构图、用户使用流程图

6.2.1 产品信息结构

– 信息结构图是只按照产品经理思路中的产品表现信息来整理产品的一种示意图（后面会举例）

信息结构能帮助我们整理产品结构，同时是研发人员建立数据库的参考

6.2.2 产品结构图

– 产品结构图是按照产品的逻辑与表现方式,结构化的表现产品构造的一种示意图（后面会举例）

通过这个产品结构图，我们大致就能将之前抽象的逻辑形象化的表现出来，也便于文档阅读者理解我们的产品思路

6.2.3 用户使用流程图

– 用户使用流程图用于表述用户在使用产品过程中的行为走向通过用户行为串联信息结构与产品结构，阅读者通过阅读用户使用流程，能更好的理解产品经理设计的用户行为

使用流程图 -> 产品结构 -> 产品信息结构

6.3 全局功能说明

6.3.1 全局功能说明

由于接下来我们要比较详细的表述每个类与每个子类的功能说明，所以这里就要把那些不能放到子类里面去的全局性的东西说清楚尽管是全局功能。但也可以分类说明，例如：UI、交互等等….

全局功能说明案例：

用户交互统一说明： – 本客户端在用户触发操作后，应优先加载用户界面，同时在界面中加载数据的位置使用风火轮提示用户数据加载中。 – 本客户端的时间显示，建议使用人性化提示，例如：20分钟前，一天前，三天前，超过7天的，则显示为具体时间，如：3月30日 17点55分，超过一年，则显示12年3月30日17点55分。

6.3.2 详细需求说明

整体说明完成以后，我们就要开始对各个需求板块进行详细的需求说明 – 根据实际的需求，你可以按照你习惯的表述顺序来表述常见的表述顺序有：

按照功能的逻辑来表述（更抽象，研发喜欢）按照产品结构来表述(频道，页面，模块，元素的逻辑表述,相对比较适合产品经理的逻辑，产品经理喜欢），即按前面的产品结构图来表述。

– 具体哪一个，看团队要求和默契程度

6.3.3 UML > 用例文档 > 用例图与状态图

UML登场了(其实产品经理的PRD文档写作所涉及到的UML知识非常有限) – 中文名称：统一建模语言 – 英文名称：Unified Modeling Language – 定义：是一种面向对象的建模语言，它是运用统一的、标准化的标记和定义实现对软件系统进行面向对象的描述和建模。 UML常见的说明图类型 – 用例图-表述 – 状态图 – 时序图 – 结构图 – 等….

6.3.4 什么是用例图

用例：用例就是一种描述系统功能需求的方法用例图：用例图表述的是系统的外部参与者与系统之间的关系,是由参与者与用例组成的示意图用例图的组成要素：参与者(可以是人,也可以是另一个系统,也可以是其它的东西,是相对的)、用例、关联线、方框。**用例图不说明具体的流程，用例图强调的是系统与参与者的关系。 **

6.3.5 用例说明

你看到的这个表格,只是一个基本格式,关于用例在业内并没有一个成为和固定的专门供你套用的东西,一切都已你团队的默认习惯和达到那你的目的依据来写作用例。根据你自己的需求去做。

6.4 详细功能说明

6.4.1 详细功能需求描述的基本结构

产品的整体用例图 -功能板块1需求 – 功能板块1的子功能1 • 功能板块1的子功能1的元素1说明(用例描述) • 功能板块1的子功能1的元素2说明(用例描述) – 功能板块1的子功能2 • 功能板块1的子功能2的元素1说明(用例描述) • 功能板块1的子功能2的元素2说明(用例描述) • 功能板块2需求(用例文档) – 功能板块2的子功能1 • 功能板块2的子功能1的元素1说明(用例描述) • 功能板块2的子功能1的元素1说明(用例描述) – 功能板块2的子功能2 • 功能板块2的子功能1的元素1说明(用例描述) • 功能板块2的子功能1的元素1说明(用例描述)

6.4.2 详细需求说明的原则

①MECE原则

MECE，是Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”。也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，

而且能够藉此有效把握问题的核心，并解决问题的方法。

②MECE只是一种思考方式，当PRD文档撰写交付研发以后，其实多少还是会存在没有考虑到位或者需求调整的情况

所以:

– 撰写PRD文档前一定要保证思考到位了,产品结构本身短期内不会有重大改动 – 需求分类与表述方式要参考MECE原则 – 这样即便是在交付后，出现调整或需要优化的地方，也不会出现重构的情况重构需求,重新调整产品结构等,对已经处在开发过程中的团队来说是灾难性的 – 需求撰写，更多的是考验耐心，思路，经验，但产品架构的确定等更是考验一个产品经理对产品的规划与把握能力 – 不要害怕，不要迷信

7、优秀的PRD文档应该具备的特点

7.1 正确

确保文档中的表述与产品经理的思路是对应且正确的

7.2 无歧义

文档的表述方便阅读理解，不会产生歧义

7.3 完备

MECE原则尽量保证对产品功能需求表述的系统完整

7.4 一致

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

7.5 具有优先级

产品的功能性需求是有先后主次的，对于一次性规划叫多功能的PRD，应该注明功能性需求的先后主次

7.6 可验证

对于功能性的描述，是可以进行测试的，而不是不发测试，无法定性的东西，例如：效率高，交互完美等词语，都是无法验证的

7.7 可修改

PRD文档利于后期的修改与升级

7.8 可追踪

每个功能性需求的来源应该是清楚明白的

8、关于数据

“一份国外数据分析，样本数据30万份，其中71.3%的人左手持手机左手拇指进行操作，82.6%的人在iPad上右手操作，平放在腿上时用食指，双手握时用右拇指”。

是不是和我们的想象很不一样？
做产品，有时候需要感觉，有时候需要数据。