产品管理流程及规范（四）——PRD文档撰写

对产品经理来说，必备的一项技能就是写出逻辑清晰可以实施的prd。本文作者就从why，what，how三个层面对PRD文档撰写展开了分析，供大家参考学习。

上一篇文章已经详细讲解了产品原型的保真度区别，原型设计的注意要点，规范标准，本篇文章将针对PRD文档撰写的why，what，how三个层面进行分析。

01 写PRD的目的

产品需求文档，即Product Requirement Documen，PRD的主要使用对象有：开发、测试、项目经理、设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；设计师可以通过PRD来设计交互细节。

PRD文档是将产品项目由“概念化”阶段推进到“图纸化”，将需求落实到可开发的。PRD文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。

02 PRD撰写的前提条件

进行了需求收集与分析，构建了系统架构，绘制了功能结构图、信息结构图、产品结构图，2大流程图（业务、页面流程图）以及所有页面的原型稿、交互稿。完成这些部分之后，对以上部分进行有机的整合，撰写PRD文档。

03 PRD内容

3.1 文档编写记录

记录文档创建，修改的情况，文档的编写状态，编写人

示例：

3.2 文档修订记录

记录每次修改的修改内容，更详细的进行记录每次修改的情况，对修改情况做概要性的描述，使查看人能够清晰的感知修订情况

示例：

3.3 目录

根据PRD文档的章节自动生成生成，如果有变化进行更新整个目录的更新即可

示例：

3.4 概述

3.4.1 背景介绍

简要说明产品/项目需求产生的背景，要达到的目的和需要实现的功能

示例：

通过建立招商加盟平台的商户管理系统，商户（招商公司）能够在商户后台直接发布项目、文章，进行自有项目的推广。商户（招商公司）能够在商户后台支付会员、广告宣传、站外文章发布等增值服务费用。可以接待来咨询访问的用户，并进行交谈，记录用户线索，形成用户档案。

商户管理系统同时能为商户提供数据分析功能，对在该商家的访问、咨询、成交用户进行分析，对商户发布文章的宣传效果，广告投放效果进行综合分析，为商家的进一步业务开拓提供决策依据。

3.4.2 涉及范围

描述本次需求，主要涉及到公司内部的哪些平台，并简要描述各平台应该做哪些事情

示例：

3.4.3 阅读对象

描述本文档的的阅读对象有哪些，一般包含：公司业务总负责人、各平级部门经理、产品经理、UI设计师、研发工程师、测试工程师等与本项目相关的所有人员。

3.4.4 名词解释

对项目或者行业的专业词汇的解释，对于较为独特的行业，或者专有名词的，复杂的系统，一定要进行名词解释。名词解释的目的：所有成员中达成认知的一致，防止一个事物多种命名的情况产生，提高信息的传递效率，消除歧义。

3.5 结构图

产品相关结构图一般包含3种：功能结构图、信息结构图、产品结构图

3.5.1 功能结构图

定义： 功能结构图就是以功能模块为类别，介绍模块下其各功能组成的图。

作用： 产品设计时，辅助思路梳理，避免功能概念模糊、缺失。

绘制功能结构时，尽量避免信息结构要素出现的可能性，形容一个功能点时建议多采用“动词+名词”的语言描述形式 。

示例：

3.5.2 信息结构图

定义：指脱离产品的实际页面，将产品的数据抽象出来，组合分类的图表。

作用：帮助PM梳理复杂内容的信息组成，避免信息内容在展示过程中出现遗漏、混乱、重复；

作为开发工程师建立数据库的参考依据；信息结构图的绘制通常晚于功能结构图，往往是在产品设计阶段的概念化过程中，在产品功能框架已确定、功能结构已完善好的情况下才对产品信息结构进行分析设计。

示例：

3.5.3 产品结构图

定义： 产品结构图是综合展示产品信息和功能逻辑的图表 。可以理解为产品结构图是对产品原型的简化表达，产品结构图就是通过信息架构设计，将功能和信息以一种合理自然的逻辑，把功能结构图和信息结构图中的内容放入产品中的每一个页面的结果。

示例：

一般而言，直接采用产品结构图，对于概要描述，根据情况使用功能结构图，使用xmind制作产品功能结构图，并对产品功能进行简要描述。

3.5.4 产品功能概要

功能等级基本为三级+描述备注（模块、功能、子功能或者其它叫法），根据功能结构图而来，控制好级别，并进一步描述功能的内容和作用，对功能排列优先级，功能是否要进行分期开发，如果需要分期开发，则对应的开发周期需要注明，是否有另外的说明和备注，如果有则可以添加备注，尽量不要使用Excel中批注，很容易遗漏。

示例：

3.6 核心业务流程

对于本次需求中最核心的业务，采用泳道+文字描述的方式，对核心业务的阶段、步骤以及异常情况及判断进行描述。

在画业务流程之前，要深入了解核心业务，与相关业务人员进行深入的沟通，确认。确定泳道（即任务），确定产品有哪几个阶段，思考业务在各个阶段的形态，如果业务流程涉及多个部门的，需要共同进行沟通探讨，并可对部分流程进行优化。思考清楚后开始画业务流程图，在画的过程中也在头脑中进行梳理，尽可能的不遗漏任何的分支或异常情况。

可以采用的思考方法：

1. MECE——是Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”。也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够藉此有效把握问题的核心，并解决问题的方法，也是找出异常流程的重要方法之一；
2. 5W1H分析——是对选定的事项、流程或操作，都要从原因（何因Why）、对象（何事What）、地点（何地Where）、时间（何时When）、人员（何人Who）、方法（何法How）等六个方面提出问题进行思考。可以寻找流程的改善方向，构思新的工作方法，以取代现行的工作流程方法；
3. 运用ECRS四原则——即取消、合并、重组和简化的原则，可以帮助人们找到更好的效能和更佳的工序方法。）。

业务流程图并不是一成不变的，在多次讨论会后中可能会有调整和变动。但每次调整或变动都需要进行明确，保证流程的清晰，不要存在核心流程的模糊死角。如果核心流程不清晰，则子流程以及后续很多工作都会导致极大的变动性，也会影响整体项目的进度，特别是在研发已经介入的情况，如果流程还存在不清晰的地方，开发工作也会反复。

3.6.1 核心业务流程

跨职能的泳道图——泳道图中需将业务数据流所涉及的所有业务平台加入到泳道中，同时需区分正常流程和异常流程。

示例：

业务流程描述：

用文字描述上述流程图中的所有流程，用以作为流程的补充说明，注意，流程中的每一步需以单独的数字序号进行描述。

示例：

优惠券发放、使用、核销流程

（1）优惠活动创建

1. 优惠活动由平台设置。
2. 平台创建优惠活动，费用由平台、设备提供方、或其它方承担，具体承担方由运营进行设置之前与各方沟通确认，并在设置的之时进行确定。
3. 此处活动的设置，主要设置基本信息，如活动的优惠类型（满减、立减、折扣类型可适当减少，比如第一期只用满减），针对什么商品类别或是单个商品，针对区域店铺或者单个店铺。

（2）优惠券发放

1. 从优惠活动中选择活动，设置优惠投放方案，如发放时间，有效期，针对门店，针对用户（新用户or老用户），自动发放还是用户手动领取
2. 设置投放方案后是否立即启用，如果启用，则在设置的投放时间向用户投放
3. 不支持正在投放的优惠券临时修改，只能停止作废，后台作废之后，用户端不管是否还在有效期内，均不能领取及使用
4. 正在使用的优惠券，优惠活动原始模板不能更改，如要改变，需单独创建。

（3）领取使用

1. 如果是系统自动发放的优惠券，用户不需要单独进行领取，优惠券自动领取，在用户端优惠券中心可以看到
2. 如果需要用户领取的，用户可在领券中心进行领取
3. 用户在领取优惠券之后，升降柜的优惠券使用可让用户自己选择，双开门柜为拿货之后自动结算，则自动选择优惠券使用，以优惠最大的券为准。

（4）核销结算

1. 用户使用优惠券购买商品之后，如果用户发生退款，则优惠券不退会，且不可再使用（即优惠券只能使用一次）
2. 如果订单中包含多个商品，均有使用优惠券，如果退款退货只退其中一部分，则优惠券也只退其中一部分，按比例进行摊薄
3. 进入清分结算的订单，有使用优惠券时，则在清分中按实际支付进行清分，并标注使用优惠券
4. 优惠券不进入清分，优惠券只进行费用承担，但使用该优惠券的订单结算完成后，该笔优惠券的费用承担状态为完成。

备注：

1. 优惠券采用创建与发放分开的形式，创建为创建优惠活动，不配置具体的发送方案
2. 用户领取优惠券后，在购买商品时，进行金额的抵扣（用户级别不一，则抵扣金额和券的类别有差异）

系统异常处理流程：

主要描述跨系统、角色间的业务流转方面的异常处理逻辑。还有其它的一些通用异常处理：

1. 获取地理位置权限失败
2. 发送通知权限获取失败
3. 网络情况

优惠券流程示例：

1. 优惠券发放错误，停止活动，则已发放的优惠券用户不能再使用，优惠券失效
2. 优惠券过期失效，不能再使用，并标记已过期失效，并给予提示
3. 退款订单中已使用的优惠券，不再恢复到可使用状态（即便未过期），直接作废
4. 其它

3.7 产品界面级功能及交互需求说明

根据产品原型上的页面结构，构建功能需求说明树。

示例：

3.7.1 功能一（界面）

粘贴产品功能界面，并对产品功能界面的功能、交互进行描述

示例：

使用流程：

以任务流方式，描述用户在完成该功能时的步骤、业务逻辑。

示例（登录）：

页面交互：

各页面间的交互，互动链接关系，以一个功能所涉及的相关页面为

示例

异常处理：

描述业务发起过程中的异常处理流程。

1. 手机号做位数及类型限制，位数只能11位，只能是数字。
2. 密码由字母+数字构成，字母区分大小写，密码的组合方式为“大写字母or小写字母+数字”，如果用户输入字符与此规则不匹配，则进行提醒用户按规范输入
3. 如果用户未输入账号密码点击登录，手机账号：提示“手机账号未填写”；密码：提示“密码未填写”；账号与密码不匹配时，
4. 输入的账号未进行注册，提交检测在后台无记录，提示：用户账号不存在
5. 用户输入的账号与密码不匹配，则提示：用户名或密码输入错误

3.8 安全需求

描述项目需要遵循的安全标准及需要进行安全验证等。验证包括手机短信、身份信息、银行信息，信用信息（芝麻信用）所有这些均有第三方接口进行验证，支付费用即可进行验证。

3.9 数据监测分析

数据监测

采用数据埋点、数据采集等方法统计用户行为数据。

第一种方式：自己开发——优点是保密性高，所有数据都在自己的平台中，但是很费时间，要想做的好，对技术也有一定要求

第二种方式：使用第三方接口——比如友盟、神策、growio、百度等均提供接口，能快速的解决问题，另外growio，百度都有无埋点方式，就是不需要一个个数据点进行单独的埋点，而是监测所有有数据传输，操作行为的点，接入sdk之后，可以自主选择数据点进行分析。这种方式，不会存在遗漏，灵活度也非常高。

数据分析

第一种方式也是完全自主开发，在早期的时候，数据量不大的时候，可以直接将数据导出进行Excel表的分析，

第二种方式是接入第三方接口，比如finebi、powerbi、DataFocus、tableau等，在选择第三方的时候要注意，是否满足企业要求（当下及后期），是否可以进行私有化部署，后期扩展的灵活性，是否简单易用，费用。

3.10 系统日志需求

对系统处理业务的操作记录或者逻辑记录在日志中，便于后期查找、追溯。

3.11 验收标准

说明需求验收上线的评价指标及参与验收的人员，可以制作验收单，产品是最终负责人。

3.12 其它产品需求

3.12.1 性能需求

明确产品的性能，知道产品性能上限，随着业务的发展，清楚改善节点。在早期考虑综合成本的情况并满足业务需求的情况下，可以对性能做一定的妥协。

• 并发量：简单的可以说，同一秒的登录量，同时在线，订单并发量最高可以允许多少。比如客服系统，允许同时对话200，也就是允许同时存在200对话通道。
• 图片加载：图片加载的时间，页面跳转切换的时间，在不同网速下，允许的时长（不同网络情况下，信号有强弱，可能根本4G、5G信号，或者用户的卡是3G）

3.12.2 兼容性、适配需求

PC——兼容目前主流的浏览器，比如IE8、及Firefox3.5、safari、chrome等主流浏览器的主流版本，将相关版本进行罗列，同时考虑H5的跨设备适用性问题（比如官网在pc和手机的查看，看到过有些系统将功能复杂的后台没有做适配要在手机查看使用一团糟的情况，功能复杂的后台基本是不太适合在手机上操作的）。

机型——通过各种渠道（talkingdata，友盟）查目前的主流机型，市场占比，根据公司情况，选择占比靠前的测试机型，或者采用第三方测试平台（testin，testbird）

3.13 相关文档

A、原型地址

XX平台商户后台墨刀地址（密码XXX）：

XX平台系统后台墨刀地址（密码XXX）：

B、消息通知模板

C、其它

商标，软著，域名、服务器、支付平台、消息接口、其它需要准备各类平台账号及及截止时间节点，部分事项可以并行，部分事项有严格的先后顺序，在进行计划安排时，需要作出区分，尽可能缩短时间，不要出现绝大部分人等一个人的情况出现。

04 产品向各方需求文档内容

4.1 给设计师文档

思维导图、流程图、功能清单、原型图（含交互）。

4.2 给研发文档

思维导图、功能清单、流程图、原型图、UI设计图、PRD文档、数据埋点文档

4.3 给运营文档

思维导图、流程图、功能清单、PRD文档、产品使用说明书，上线资料准备清单（上线前需要准备的比如需要录入的商家信息）。

以上是PRD文档相关内容，下一篇文章将是——版本命名、验收规范、发版管理；