产品⽂档和原型咋弄（一）-技术圈

前言

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

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：用户故事，从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：