【PM】产品需求文档（PRD）

¶写在前面 / 链接存档

• 如何编写产品需求文档（PRD） | 人人都是产品经理

  备注：仅针对To B系统的PRD文档，并不完全适用To C的系统产品

  1. PRD文档的编写目的是什么？
  2. PRD文档在编写前需要做什么？
  3. PRD文档在编写的过程中有哪些是需要注意的？
  4. PRD文档编写完成后如何使用？

• 一篇完整PRD实例 | 人人都是产品经理

  主要介绍日常繁琐工作中的“文档型”PRD编写，中小需求均适用

  看到这篇文章的产品可以直接实战，适合新入职场的产品童鞋

如何编写 PRD

¶什么是 PRD

• PRD（Product Requirement Document），翻译为：产品需求文档。

• PRD 是产品由**“概念化”阶段进入到“图纸化”**阶段的最重要的一个文档。

¶<1> PRD 的编写目的

• 最重要的目的：协调各个相关角色，将产品高效正确的“生产”出来

• PRD仅仅是为达到这个目标，产品经理经常使用的一种工具，只要是能够高效的完成最后的系统化产品，那么PRD具体的【内容、形式也没有非常严格的标准】。

• 几个关键词：各个角色、高效&正确、生产

¶一、各个角色

• 指的是：整个产品研发过程中全部相关的角色

• 每个角色在研发过程中负责的工作和关注点不同， PRD 中需要照顾到所有参与角色的关注点

• To B 系统产品在此过程中主要涉及的角色：

1. 领导（产品总监等）：

   1. 这个角色的人一般不会太过关注PRD的细节，重点会看一下，做这项工作的原因、解决问题的影响范围、成本、以及最终给客户和公司内部提供的价值。
   2. 以上内容如果在PRD之前就使用其他的文档说清楚了，PRD文档中就不需要写了
   3. 建议在 PRD 编写之前，通过产品提案等方式，把这些内容全部确定好，达成一致。

2. UI&UX设计师：

   1. 这个角色的人一般会重点关注在一些页面的元素上
   2. 设计师会根据页面的元素进行视觉和交互设计，所以PRD中已经要写清楚页面的元素以及这些元素的含义，并且说明最终用户在页面上的大致操作过程。

3. 前后端研发工程师：

   1. 前后端工程师关注的侧重点稍微有点不同
   2. 后端工程师侧重具体逻辑细节
   3. 前端工程师更关注在设计师给出的设计稿、交互说明和一部分少量的前端逻辑
   4. 所以PRD中一定要把具体逻辑写清楚，最好把设计师的设计稿和设计说明一并汇入PRD中

4. 测试工程师：

   1. 这个角色的人除了关注前后端逻辑、交互外，还关注系统最后希望达到的标准，以及最终的核心使用场景
   2. 所以，尽可能的写一下最核心的几个使用方式，相当于最重要的几个测试用例

5. 产品运营：

   1. 这个角色的人会关注最终产生的价值以及具体的使用方式
   2. 产品运营作为产品的客户之间的重要桥梁。所以，最好可以写一下系统使用说明。

¶二、高效 & 正确

• 写出来的文档永远比无效的沟通更高效

• PRD就是提高效率的，把各个角色的共识全部写出来

• 大家都以 PRD为最终的工作指导文档，在前期可以讨论修改，在后期可以追根溯源

• 多花点时间在 PRD 上，一定会比不断地回答问题，不断地因为没有达成一致的逻辑反复修改要高效的多。

¶三、生产

• 本质上，软件开发也是生产的过程，和生产实物是没有本质区别的。
• PRD 作为指导生产过程的重要文档，类似实物生产的设计文档，必须要满足在生产过程中各种各样问题的回答。
• 因此需要从生产流程的角度进一步的来说审视 PRD 的内容，包括：现状、准备工作、前提条件、开发逻辑、效果要求等。

¶<2> PRD 文档在编写前需要做什么？

1. 建议在PRD编写之前，通过产品提案等方式把价值、成本等内容全部确定好，达成一致
2. PRD开始编写，意味着整个业务调研、方案逻辑、可行性、价值判断基本上已经完成了，如果没有完成那么是不建议直接编写PRD文档的

(1) 业务调研
只有完全搞清楚业务的问题，才可以解决问题
根据需求的复杂程度编写详细/简要的需求调研文档，明确需要解决的具体问题和要达到的具体目标

(2) 方案逻辑
在方案设计的初期，一般都有不同的方案来解决问题
不同的方案需要进行一些维度的比对，最终选择合适的方案
在PRD编写前，需要写一个设计思路文档

（3）可行性
围绕设计思路中的不同方案，要对技术可行性进行论证，
需要与具体的开发负责人进行沟通，明确方案是否可行，以及成本，最后决定最终的方案

（4）价值判断
对方案的的直接和间接价值，以及直接和边际成本进行明确，确定推进是有意义的
如果问题的解决成本大于价值，PRD就没有必要继续写了

¶<3> PRD 文档在编写过程中需要注意的点

PRD 文档的具体结构

¶1. 文档管理

包括内容：【版本管理】【相关人员】【设计稿位置】

1. 【版本管理】需要记录每次修改的概要说明
2. 【相关人员】是为了明确具体的工作人员，开发当中的沟通以及后续问题排查需要
3. 【设计稿】一般会有一个设计工具的地址，里面会有一些图片无法表达的内容，相关人员需要查看

¶2. 背景

包括：【背景】【目标】

1. 背景和目标通常都比较简短

2. 一方面是为了在内容层面表述大的背景和目标

   比如公司整体的方向是让系统有更高的开放性，需要做一些API，所以本次的开发是在这个开放性的大背景下的，达到XXX部分对接，降低定开成本等等。

3. 在写作技巧上，不能上来一杆子通到底了，需要与读者在某些信息上达成共识，引出问题后在再进行具体的说明。

¶3. 需求说明和分析

需求说明包括：【需求描述】、需求分析

其中需求分析包括：【现状分析】、【需求分析】

1. 需求描述：

   1. 需要将最原始的需求进行表达

      可以是客户的需求、竞品对比的需求、老版提出的需求、售前引申的需求等等

   2. 无论需求来源是什么，在需求描述中一定要回归业务场景

      没有业务场景说明出发点就要小心了，很有可能最后不会带来业务上的实际价值

2. 现状分析：

   1. 针对需求，目前系统是如何解决的 / 没有任何方式解决
   2. 现有的解决办法为什么不是最优的。

3. 需求分析：

   1. 挖掘需求背后的真正目的
   2. 多问自己几个为什么需要

¶4. 产品方案概览

是为了让相关人员在查看详细的设计方案前对整体情况有一个初步认识

直接看一个不熟悉的产品方案细节，容易无法透彻理解

方案概览一般从三个方面进行阐释：

1. ER 图：

2. 一般情况下，To B的系统都会有很多数据对象，数据对象之间存在复杂的关联关系

3. 特别是方案中如果引入了新的对象或新的关联关系，那么一定要绘制ER图，说明不同抽象对象之间的关系。

4. 整体方案：

   1. 强烈建议使用一张图，一图胜千言
   2. 用一图说明整套方案：增加什么界面、增加什么字段、增加什么逻辑处理、增加什么对外接口
   3. 根据具体需要，一般会使用**架构图、时序图**等表达方式

5. 使用方式：

   1. 可以叫做使用方式 / 页面结构图
   2. 主要是为了阐释在客户面前这个产品是如何被使用的
   3. 如果没有页面的开发，这部分可以省略

¶5. 功能说明

• 对概览性方案的拆分说明

• 对每一个小的功能点进行详细的说明

  • 分为【原型】与【功能说明】
  • 没有页面的原型部分可以空着
  • 功能部分一定要写清楚具体逻辑

• 【非核心功能】和【非功能性需求】→更考研产品经理设计能力的细致

  • 优秀的产品经理需要看到功能背后的需求，比如性能、安全等
  • 【非功能需求】下的这些细项像一个检查清单
  • 产品经理在自己具体的领域里不断收集问题完善这个清单，然后在每个 PRD 里面一条一条的问自己需不需要

¶6. 验收说明

类似于 P0 的测试用例，切实描述用户的最终使用过程

¶<4> PRD 文档编写完成之后的使用方式

• 使用PRD，知道了整个开发过程的工作

• 从 Planning 会议讲解PRD开始，PRD文档正式投入使用

• 另外：在PRD使用的过程中，一定要不断的发现PRD模板的问题，不断优化PRD模板

PRD实例

需求实例：“M公司分销系统设计”

¶一、文档综述

¶1.1 版本控制

¶1.2 需求干系人管控

¶二、项目背景及价值

¶2.1 项目背景

M公司是M集团下属电商公司（M集团是一家经营了十几年的成功企业，旗下拥有零售超市、生鲜电商、金融理财等多条业务线，业务发展良好，系统建设成熟）主营生鲜商品，以C端客户为主，业务稳定。三个月前尝试开展分销业务（也叫大客户，ToB业务）。

分销业务的目标客户是大型连锁餐饮集团，以及大型生鲜分销商等企业级客户（注：M公司并不会参与客户对商品的二次转卖，即下一级生鲜品后的分销过程）。

业务试点在北京、上海开展，三个月以来业务发展迅速。目前分销业务月流水50w，以每月20%增幅快速发展。但是在高速发展中，若干流程、管理风险问题突出，现急需配套的软件系统来提升业务效率，控制经营风险。

目标：在两到三个月时间内搭建一套分销业务平台，至少支持分销业务在未来两年内的高速发展，有效提升效率，控制经营风险。未来内部系统成熟后，将这套分销业务平台Saas化对外售卖。

我暂时搞不了酱紫的描述吧？？？公司角度我了解不多，但是可以根据业务本身来阐述项目的需求背景和前景什么的

¶2.2 项目价值

战略目标：扩充并尝试新销售渠道，发展高端零售的分销通路，战略目标是3年内打入主要的一二线城市的高端零售分销市场。

¶2.3 市场分析

M公司即将研发的分销平台，目前客户是农产品渠道商，渠道商业业务规则在万亿级别，而这些渠道商在信息化、数字化方面投入只占营业额的0.01%，测算得出针对农产品领域的分销类软件产品，年市场规模大概1亿元人民币。在农产品分销软件平台领域，市场占有率最高的3家软件供应商，总共占据了40%的市场份额（即行业集中度CR3=40%），是一个竞争充分的市场。

¶三、需求总览

¶3.1 需求场景

可以以excel方式展示有哪些业务场景，需要做什么

拍照（美颜、姿势指导、滤镜）、AI换脸、妆造图生成（有/无背景、图片大小、动/静图）

¶3.2 功能框架图及分期实现步骤

将业务场景拆分到功能模块，并进行优先级排期，由于本次需求涉及到新系统搭建，故分期进行。

PS：如果是小的需求，就在大的功能框架图中标注变更/调整点。

¶四、需求详细描述

B端产品的细节方案设计，通过对整体方案中总结出的【业务场景】，逐个进行深入分析，包含【业务数据建模】、【页面流转设计】、【界面设计】、【权限设计】等。

B端产品进行细节设计的常见流程：

• 首先梳理业务流程
• 接下来提炼背后的数据模型
• 然后基于流程和数据模型确定业务流转图
• 再着手进行每个页面的具体设计，同时提前规划好系统用户角色
• 最后完成权限设计。

【需求详细描述模块】是研发同学实现的依据，涉及到方方面面细节，故也会存在多个版本的修订补充，需要在【版本控制】模块做好管理。

¶4.1 业务数据建模

业务数据建模是数据库设计中最重要部分，会影响数据库表结构设计，很多产品经理常常忽略业务数据建模，只关注功能界面设计，最终陷入混乱的逻辑中。

数据建模工作面临两种情况，
第一种是已有业务流程，第二种是还没有业务流程。

前者的建模工作相对简单一些，需要做好已有数据表单，实体的识别和抽象（目前互联网企业一般是前者，产品经理在日常繁琐PRD中，往往会忽略对现有表单的影响，导致以为实现很简单，研发评估后发现改造较大，而产生分歧等问题）；

后者设计人员没有线下的流程和表单可供参考，需要自己从零梳理设计。

关于本次分销平台的“业务数据建模”

¶a. 用户、订单、商品模型

分销系统中，1个用户（or大客户）下1笔订单，N个商品，一个商品也可能存在多个订单中，每个订单中包含多个商品；一个订单对应0个或多个运单，因为订单可能没有配配送，或者被拆分成多个运单配送；同时一个运单必须有一个对应的订单。

¶b. 客户模型

分销平台客户诉求：
目前分销客户中，有比较大型的集团客户，下设若干机构、库房和门店。

调研时客户诉求如下：
上海、广州采用[中央仓库]模式，客户从M公司采购商品后，商品首先配送到中央仓库，再由客户自己从中央仓库向地区门店发货。故需要开通[采购员]账号，以实现中央仓库系统中下单。
其他地区是[门店自采]模式，即门店采购员自行下单菜单，商品直接从M公司配送到门店，因此需要[针对每个门店创建采购员账号]。
还需要一个[高级采购员]账号，能帮助同一地区各仓库和门店代下单。

故整理出以下客户业务数据模型：

¶

¶c. 分销平台数据 ER 图

综合a、b模型，提炼出分销平台数据ER图，如下：

¶4.2 流程与角色

[流程合理、角色清晰]是系统设计正确的前提和保障，
流程确定后，再绘制页面流转图，最终完成页面细节设计。

系统中角色一般与公司中岗位对应，分销业务客户包含如下几个角色：卖方-销售人员、卖方-分公司运营人员、卖方-总部运营人员、客户-管理员、客户-采购员。

结合上一节数据建模提炼出的数据对象，以及对角色模型分析，绘制出以下[业务流转图]，根据业务流转图，可以设置相应的[角色岗位以及系统权限]。

¶4.3 界面流转

页面流转图描述的：用户完成某项工作[需要访问的页面]及[页面跳转顺序]。

绘制页面流转图可以帮助设计人员审视、思考系统页面设计方案，包括[系统总共需要哪些页面]，[哪些页面可以重复使用]，[哪些页面需要定制化开发]。

根据用户角色，设计出以下分销系统界面流转概况：

¶4.4 界面详细设计

界面详细设计，即我们熟悉的[原型图]，B端系统的[线框原型图]，一般采用[表单形式]。

→ 产品经理绘制出原型图，并表达清楚每个界面，每个字段及按钮的[设计需求]。
→ UE/UI协助产品完善交互体验，并制作交互原型。
→ 前端工程师拿到UI切图文件，进行前端开发，包括实现交互、动效等。

以上为分销系统下单界面、报价管理、门店管理界面示例，除了图之外，产品经理还需仔细描述清楚图中每个字段及按钮的需求，这是一项庞大而繁琐的工作，但也是从细节中见真知，对细节的描述也不容忽视，这样才能保证后续系统开发工作的顺畅进行，减少双边的返工成本。

（行业内主流产品经理画图软件为：墨刀、Axure，我之前也写过一篇关于：墨刀功能的简介，有兴趣的朋友的也可以去看看）

¶五、灰度测试

灰度节奏一般与[业务侧]对齐，根据业务实体，如分销系统实体中的门店，选取中型门店，
上线后，灰度期间，先完成[业务流程的跑通]，再逐步[推向城市及全国]。

¶六、上线后业务复盘

PS：一般上线后半个月，或一个月，对产品进行上线后数据分析，看是否达到项目目标，此模块需要业务同学协助进行。