产品⽂档和原型咋弄（一）

  前言

回顾一下之前的两篇关联文章：

1、究竟谁是Stakeholder(利益相关者) ？

2、场景思维：解决那个属于用户的场景问题

今天来讲讲梳理完利益相关者的场景问题后，需要输出怎么样的PRD（产品需求文档）。

  PRD给谁看？

不同的人关注的PRD内容就会不一样，而PRD对自己也有很大的好处，便于自己回顾当时是怎么思考这个问题的

而对于开发、测试很大程度关注的这个需求的实现逻辑，避免开发沦为工具人的情况，在评审的时候也需要说明为什么会产生这样的需求，这个需求能解决什么问题，这里面就会关联到利益相关者场景问题了。

最后如果你的需求要别的系统配合改造，那么就会有其他产品经理来看你的PRD了，他们除了会关心前面开发、测试的问题外，还需要关心要怎么配合改造。

  常见的文档类型和含义

BRD：商业需求描述，全称为：Business Requirement Document。是基于商业目标或价值所描述的产品需求内容文档（报告）。产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。

FRD：功能需求文档，全称为：Function Requirement document。一般FRD都是在PRD内容的一部分，很少见单独弄一份FRD。

MRD：市场需求文档，全称为：Market Requirement Document。是市场部门的产品经理或者市场经理编写的一个产品的说明需求的文档。该文档在产品项目过程中属于“过程性”文档。该文档是产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。

FSD：功能详述文档，全称为：Functional Specifications Document。有一点像“概要设计”，在BRD、MRD和PRD的基础上，这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。相应的，有很多内容，比如表结构设计，要由项目经理来编写了。PS：可以理解为原型图

PRD：产品需求文档，全称为：Product Requirement Document。将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述

User Story：用户故事，从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

• 角色：谁要使用这个功能。

• 活动：需要完成什么样的功能或目标。

• 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

DRD：交互设计文档，全称为：Design Requirement Drawing。一般用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。PS：如果没有交互设计师，那么这一块的工作就是产品经理在原型上说明一下。类似我会在Axure的说明字段定义一个“交互说明”。

（点击放大查看）

UC：用户用例，全称为User Case。需求人员写给开发人员看的一种最基本的文档。列有用例场景描述、参与者、事件流、前置条件/后置条件等。

以上的文档含义描述源于百度百科，看到这么多文档不要慌，其中BRD、MRD、PRD被称为产品经理三大文档，先关注这三个。

  PRD要有什么内容？

现在我的PRD和原型图都整合在一起了，方便开发、测试在同一个原型HTML文件里查看，可对照图文一起理解。

  结语

其实没有标准的文档格式，只有合适自己团队的文档。在每一次评审时，你可以根据现场的问题，看看大家对你说的理解程度，调整下一次的文档内容。

-------- END ---------

你的认可，是对我最大的鼓励。

觉得好请关注

点个“在看”，来个“赞”，求“分享”