写好产品文档，是每个产品经理都要掌握的基本功。，但产品新人总会遇到各种问题，比如：

• 不清楚文档的内容，不知如何下笔；

• 文档内容不规范，逻辑混乱；

• -盲目套用模板，分不清使用场景，耗时且无用。

第1章 什么是PRD文档

1 PRD初识

PRD是产品需求文档（Product Requirement Document）的简称，该文档是产品项目由“概念化”阶段向“图纸化”阶段的最主要的一个文档。

• 战略：产品定位、目标市场、目标用户、竞争对手

• 战术：产品的结构、核心业务流程、具体用例描述、功能&内容描述等

2 PRD的用户及作用

2.1 PRD的由来

• 1、以文档的形式准确传达需求

• 2、约束产品经理、开发

• 3、验收产品质量

• 4、记录产品迭代

• 5、专业能力的体现

2.2 PRD阅读用户 （开发&测试、产品经理、UI设计师）

2.3 PRD的作用

• 产品经理：根据PRD进行方案的宣讲，并作为最终检验产品实现程度的依据

• 开发&测试：根据PRD的系统规则等内容作为研发依据；根据PRD的规则来编写用例及测试

• UI设计师：根据PRD的原型作为UI设计参考

最终目的都是为了团队成员能够理解业务，在产品研发过程中得到更好的执行

3 MRD、BRD、PRD的区别

BRD：商业需求文档 Business Requirement Document

MRD：市场需求文档 Market Requirement Document

PRD：产品需求文档 Product Requirement Document

三者区别.png

4 实现PRD文档的几种工具

• word 有目录让人更容易总览全局

• 原型软件 原型版在功能需求描述时表现更灵活 Axure（8 or 9），墨刀，摹客

第2章 30分钟内攥写一份敏捷的PRD文档

2.1 一份敏捷的PRD要素有哪些

PRD的要素：

• 命名、编号

• 版本历史、目录

• 引言

• 需求概述

• 功能性的需求说明

• 非功能描述

撰写原则：

• 贴合团队实际情况

• 清晰、有效

2.2 文档标识

• 文档命名和编号 XX产品V1.0PRD_V2

• 版本历史

  文档版本号：	V2.1	文档编号：	1.0
  文档密级：	项目组成员可见	归属部门/项目：
  产品名	慕课网	子系统名
  编写人：	xxx	编写日期	xxx

• 版修订记录

  版本号	修订人	修订日期	修订描述

• 目录

  目录.png

2.3 PRD文档引言

• 产品背景

  • 1、说明该产品研发的背景、市场趋势、发展前景

  • 2、说明该产品研发的目的、意义、里程碑式的建设

• 预期读者

  • 1、该文档的读者

  • 2、说明该产品每一阶段的迭代目标，开发及UI在初期要达到的效果

• 名词解释

  • 1、对文档中会出现的比较新的名称进行解释

  • 2、 该文档的参考资料

2.4 需求描述

• 业务流程

• 用户角色

用户角色.png

• 功能清单

功能清单.png

• 运行环境 该产品上线后的使用环境，比如支持的浏览器版本，操作系统、数据库的要求等等。测试人员看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运行环境告知用户，设计和实现上的限制，比如控件的开发环境，接口的调用方式等等。

• 产品规划

  • 对PRD中要求开发的内容，给出关键里程碑，比如需求评审通过的时间，开发完成的时间、上线的时间

  • 描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。

2.5 功能性需求说明

• 简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题

• 场景描述：产品在那种情况下会被用户使用，就是用户场景模拟，这也是产品经理讲好故事的必备调节

• 业务规则：每种产品开发时都有相应的业务规则，将这些规则清晰的描述出来，让开发、测试人员能够直观的明白该规则，且没有产生歧义。业务规则必须是完整的，准确的，易懂的

• 原型图（涉及到页面交互的部分）

原型图.png

原型图2.png

• 前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图片文献

• 后置条件：操作后引发的后续处理

5.png

2.6 非功能性描述

• 性能需求

  • 产品使用的并发性能，相应性能、安全性能、预期效果描述

  • 需求变更的机会

• 运营需求 产品上线后如何运营，目标受众是什么，建议的推广策略、问题反馈的途径、风险监控、亮点宣传等等，以及与运营人员的协作方式

• 风险分析 对产品上线后可能遇到的风险、问题进行可能性、严重性分析，并提出对应的策略，保持产品的持续运营。

2.7 总结

• 做好功能关联性，避免功能模块缺失

  • 在组织结构时，一开始不要陷入细节，从大到小进行组织

  • 从场景出发

  • 对照产品、按照页面顺序罗列功能点，然后往框架里面丢

• 汇总通用CASE大全，作为自查清单

  • 比如初识化时元素有哪些

  • 比如外界打扰（网络异常），如何反应

  • 表单提交或者操作时的各种状态等等

• 做好备选方案，考虑全面

  • 评审时技术提出B方案，这时需要给出A方案的优势

  • 如该方案无法实施，可以立马反应

第3章 用产品思维解析PRD文档

3.1 实战解析PRD 在线问诊APP

在线问诊APP.png

• 写前准备

在写PRD文档之前，我们需要先罗列出产品功能的信息内容

罗列信息的方式：文本，思维导图，架构图

3.2 文档与业务说明

在线问诊APP 文档说明.png

在线问诊APP 引言.png

• 全局说明

  • 名词、术语的说明 比如：预约挂号指用户在网上预约，在线下及进行就诊

  • 权限弹窗 例如游客身份登录，无法进行就诊操作

  权限弹窗.png

*   时间规范 比如格式为yyyy-mm-dd hh:mm:ss

*   异常情况 例如网络异常，未绑定手机号

在线问诊APP-异常情况弹窗.png

• 业务流程 举例：预约挂号流程

预约问诊流程.png

总结：

文档说明部分：一定要及时更新，让团队成员可以清晰进度

业务流程：最好分角色，分场景，分过程详细说明

3.3 角色与功能结构

• 用户角色

  用户角色	用户描述
  患者	主要使用预约挂号，在线问诊服务
  医生	主要使用发布信息，在线接诊服务
  药师	主要使用处方流转服务
  其他用户	所有使用在线问诊APP的外部用户

• 功能清单 功能清单时产品功能的列表集合，一般包括功能模块，子模块，功能点，优先级和功能描述

  功能模块	主要功能点	优先级
  首页	挂号	高
  	问诊	高
  	购药	中
  	特色服务	低
  	找医生	中
  	精选专区	低
  	健康商城	低

• 产品信息结构图

产品信息结构图.png

3.4 需求详细说明

• 原型图

在线问诊app 原型图.png

• 需求描述 需求说明：首页包含挂号，问诊，购药，医生列表

• 功能说明

  • 支持搜索，输入框形式

  • 支持消息通知，点击消息按钮可跳转到消息页面

  • 支持挂号，问诊，购药

  • 交互：点击挂号按钮，跳转到预约挂号页面

  • 交互：点击问诊按钮，跳转到预约问诊页面

  • 交互：点击医生模块，进入医生详情页面

    需求说明示例.png

• 非功能描述

  性能描述：展示订单数据的时候需要即时展示，不可以感受到明显的后台查询过程

  兼容需求：需要满足iphone 8以上，安卓系统

  风险分析：用户使用率不高，盈利不能支撑产品运营

  总结 ：需求描述一定要细，一定要全面

3.5 PRD文档的后续工作

• 需求评审

  • 召开需求评审会，向项目成员阐述需求

  • 成员：后端、前端、UI、测试

  • 需求更改：针对成员提出的建议完善PRD文档

  修订历史

  版本号	修订人	修订日期	修订描述
  1.0	北风大叔		新建
  1.1	北风大叔		修改首页挂号模块，新增线下预约功能

• 测试

  • 产品经理需要在开发完成后，走一遍流程，看是否闭环

  • 把自己想象成各种角色，带入各种场景

  • 剩下的测试，交给专业的测试人员就好

• 产品上线需要的文档

  • PRD文档

  • 用户操作手册（分角色）

  • 功能清单

总结： PRD只是产品工作开展的一步，后续的持续完善，跟进才是决定产品优劣的关键

第4章 课程盘点

4.1 写PRD文档时，产品经理如何做到不被开发怼

• PRD 输出效率

1. leve1： PRD输出速度慢+低质量

2. leve2： PRD输出速度快+低质量

3. leve3： PRD输出速度快+高质量

• PRD质量

什么样的PRD文档才算达标呢： 程序看的懂，测试不骂人 。产品架构、复用准则、逻辑思维、异常处理以及可读性体现

• 如何保证质量

  1. “先礼后兵”：用程序员的思维思考，决不妥协用户体验

  2. 有逻辑的讲故事

  3. 不放过细节，异常情况

4.2 产品PRD自查清单

需求的产出不难，需求产出后的设计细节容易有遗漏。针对产品经理写的PRD文档进行各项指标的检查。

• 产品PRD自查清单

  序号	类型	检查项	是否检查	备注
  1	介绍	背景以及功能说明
  2	介绍	需求涉及范围：如平台、app、公众号、小程序等
  3	介绍	需求涉及用户、岗位、描述、角色、权限等
  4	表单	文本框的输入长度、格式说明
  5	表单	文件、图片上传的大小、说明
  6	表单	时间控件精确年月日时分秒
  7	表单	明确表单输入项（启用，禁用）、输出项
  8	表单	需必填校验说明
  9	表单	数据重复校验说明
  10	表单	单选、复选、下拉选项默认值说明
  11	表单	单选、复选、下拉的数据来源说明
  12	表单	添加多组数据时最大值、最小值的限制
  13	表单	提示文案有无遗漏
  14	业务	需求在系统中的整体流程图以及流程闭环检查。如需求在系统从 开始到需求处理的整个过程到结束的每个步骤通过流程图的方式说明清楚
  15	业务	数据状态说明、变更说明、如开发中、测试中、已测试、 审核中、审核完成所有状态的说明及状态切换的测试条件
  16	场景	多场景的描述
  17	数据	针对功能新增，删除，编辑等操作按钮的控制说明
  18	数据	按钮功能的操作是否需要二次弹框确认，以及确认文案
  19	数据	列表数据的列宽大致说明，以及是否需要固定，如名称控制列宽能显示30个字符，如 超过用。。。表示，鼠标悬浮显示全称
  20	数据	数据的排序说明
  21	数据	数据权限说明
  22	数据	查询条件是否有默认值，有则需要说明
  23	数据	数据是否需要分页显示
  24	数据	数据的编辑，删除的控制说明，如数据被引用后点击删除、反选或者编辑的处理
  25	数据	是否关联其他数据或者功能说明
  26	交互	点击按钮的效果、如按钮点击前、点击后
  27	交互	弹出层、下拉框的高度、宽度说明
  28	交互	数据加载中，请求中，等待相应的说明
  29	交互	文案提示的位置
  30	交互	页面之间交互的说明
  31	初始化	功能模块是否初始化数据，有则需要说明
  32	初始化	历史数据是否需要进行特殊处理，有则需要说明
  33	测试	需求测试重点需要单独进行说明
  34	报表/图表	共用查询条件和每个报表的关系检查是否有冲突、如公共查询 条件有时间范围查询，但报表是阅读、年度查询
  35	报表/图表	每个报表或者图表的默认查询条件
  36	报表/图表	报表的数据来源，包含每个统计数据的来源
  37	报表/图表	报表或者图表的最大、最小限制说明、避免图表过于单一或者过于复杂
  38	报表/图表	数据精度说明，如数字保留2位小数
  39	报表/图表	报表或者图表的动效说明
  说明

  总结：需求的自查、有效有用的自查、是一个非常有效也有用的方法之一，能避免PRD文档出现低级错误或者明显的遗漏，导致后续时间成本、沟通成本、人力成本的增长

4.3 高效产出PRD的“三不”

PRD 的普遍交付形式 Axure原型+文本，即可视化

• 不写废话

  • 去掉大家都知道的规则，如 密码显示***

  • 详细说明特殊的规则，如切换按钮的条件

• 不做高保真

  • 缺点1：需求变更时，修改成本高，影响开发的进度

  • 缺点2：影响UI的判断，画蛇添足

  • 用线框图体现功能框架即可

  • 体现核心功能，需求说明详细即可

• 不重复

  • 全局规则很重要，这可以省去很多重复的说明，比如网络故障

  • 产品经理可以收藏或者积累一套组件，节省不必要的创新

  • 不是所有的设计都要创新，有时一致才是尊重用户

4.4 围绕用户体验的PRD文档

用户体验要素.jpeg

• 战略层

1. 用户画像（什么场景，那类用户）

2. 用户的痛点

3. 我们能得到什么

• 范围层

1. 输出功能+信息结构图

2. 输出整体的规划，具体到时间点

• 结构层 流程图的形式，从逻辑上梳理思路，并达成一致

• 框架层 制作产品demo，即原型图，这块的需求说明很重要！ 数据埋点，可以用截图+表格形式体现

• 表现层 输出产品UI图，表现如何看UI同学的实力