怎么写PRD

怎么写PRD

学习目标：

深刻理解三大文档的写作目的和应用场景

理解并掌握PRD文档的用途与作用

理解并掌握PRD文档的

1. 写作思路
2. 写作方法
3. 写作格式

 

产品需求文档（product  requirement  document  PRD）

PRD文档向上是对MRD内容的继承与发展，向下则是要把MRD文档里面的这种理论要求技术化，向研发部门与设计部门说明产品的功能和性能要求。

PRD文档是产品文档中最底层最细致的文档，所以写作的时候，需要细致耐心

 

PRD文档面对的对象：

研发人员：

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

设计人员：

设计人员本身更多的会关注与产品的调性与原型图，所以对PRD文档的需求是相对较弱的。

所以，PRD文档根据阅读对象的不同，用最平铺直叙最简单的话，把问题说的一清二楚，不要绕来绕去。

PRD文档的几种表现方式：

文字模式：word

原型图模式Axure

图片模式

影像模式

 

常见PRD文档包含的内容

1. 文档说明
2. 产品说明
3. 全局功能说明
4. 详细功能说明

 

1. 文档说明：

 

1. 产品版本号（1.26）

版本号（1.26）

重大调整升级

产品结构功能等有调整

子版本号（1.26）

在原有基础上面对局部功能进行了升级或调整

在原有基础上面对局部功能进行了升级或优化

修正版本号（1.26）

局部小范围优化与bug修复

一般是不动功能性的东西

 

版本号的命名原则

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

收费原则：子版本号和修正版本号的变化，一般看做版本内升级，付加收费用，版本号变化则加收费用

 

1. 历史修订

编号

版本号

修改章节

修改原因

修订日期

修订人

历史修订的作用：

1. 对修改前后进行比较
2. 有利于维护和管理PRD
3. 修订人
4. 修订日期
5. 方便查阅，可以只看修订部分

 

1. 名词术语表

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

 

1. 产品说明

包含：

1. 产品信息结构：

信息结构图是只按照产品经理思路中的产品表现信息来整理产品的一种示意图（mindmanager）

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

 

 

2.产品结构图：

产品结构图是按照产品的逻辑与表现方式，结构化的表现产品构造的一种示意图

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

 

 

 

3.用户使用流程图：

用户使用流程图用于表述用户在使用产品过程中的行为走向

通过用户行为串联信息结构与产品结构，阅读者通过阅读用户使用流程，能更好的理解产品经理设计的用户行为

 

4.全局功能说明

由于接下来我们要比较详细的表述每个类与每个子类的功能说明，所以这里我们就要把那些不能放到子类里面去的全局性的东西说清楚

尽管是全局功能，但也可以分类说明，例如：

UI

交互

等

例如：

用户交互统一说明

本客户端在用户触发操作后，应优先加载用户界面，同时在界面中加载数据的位置使用风火轮提示用户数据加载中

本客户端的时间显示，建议使用人性化提示，例如：20分钟前，一天前，三天前，超过七天的，则显示为具体时间，如：3月30日17点55分，超过一年的，则显示18年3月30日17点55分

 

5.详细功能说明

整体说明完成以后，我们就要开始对各个需求板块进行详细的需求说明

根据实际的需求，你可以按照你的习惯的表述顺序来表述，常见的表述顺序有：

1. 按照功能的逻辑来表述（更抽象，研发喜欢）
2. 按照产品的结构来表述（频道、页面、模块、元素的逻辑表述，相对于比较适合产品经理的逻辑，产品经理喜欢）

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

 

UML

常见的说明图类型

用例图-表述

状态图

时序图

结构图

 

什么是用例图？

用例：一种描述系统功能需求的方法

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

用例图的组成要素

参与者（可以是人，也可以是另一个系统，也可以是它的东西，是相对的）

用例

关联线

方框

 

用例图强调的是关系

 

详细需求说明的原则

 

MECE原则

Mutually Exclusive Collectively Exhaustive，中文意思是相互独立，完全穷尽，也就是对于一个重大的议题，能够做到不重叠，不遗漏的分类，而且能够借此有效把握问题的核心，并解决问题的方法

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

1. 撰写PRD文档前一定要保证思考到位了，产品结构本身短期内不会有重大改动
2. 需求分类与表述方式要参考MECC原则
3. 这样即便是在交付后，出现调整或者是需要优化的地方，也不会出现重构的情况

重构需求，重新调整产品结构等，对已经处在开发过程中的团队是灾难性的

1. 需求撰写，更多的是考验耐心、思路、经验，但产品架构的确定等更是考验一个产品经理对产品的规划与把握能力
2. 不要害怕，不要迷信

 

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

1. 正确  确保文档中的表述与产品经理的思路是对应且正确的
2. 无歧义  文档的表述方便阅读理解，不会产生歧义
3. 完备  MECE原则尽量保证对产品功能需求表述的系统完整
4. 一致  文档中用词用语一致，对于同一事物的表述应该一样，避免混用同义词
5. 具有优先级  产品的功能性需求是有先后主次的，对于一次性规划叫多功能的PRD，应该注明功能性需求的先后主次
6. 可验证  对于功能性的描述，是可以进行测试的，而不是无法测试，无法定性的东西，例如：效率高，交互完美等词语，都是无法验证的
7. 可修改  PRD文档利于后期的修改与升级
8. 可追踪  每个功能需求的来源应该是清楚明白的