关于 PRD

什么是 PRD

产品发展的不同阶段会产生不同的需求文档，主要有 BRD、MRD、PRD，这些文档起到的作用各不相同，面向的读者也不同，详细比较如下表所列。

分类	商业需求文档 BRD(Business)	市场需求文档 MRD(Market)	产品需求文档 PRD(Product)
阶段	未开始	准备	实施
侧重	模式	市场	产品
特点	简短、有效	模型、数据	原型、流程
读者	老板	运营、市场、产品	产品、设计、开发、测试
内容	商业模式	运营模式	产品功能
作用	明确可行性	明确用户和市场	明确需求和原型
层次	要做什么？	要怎么做？	做成啥样？

为什么要写 PRD

PRD 在产品研发过程中起着如下作用：

1. 提高团队效率：上下游＆横向都在关心什么？如果能在PRD里解决，会大大提升理解成本＆评审效率，达到事半功倍的效果。
2. 信息备案共享：方便团队信息留存和共享，对新加入团队的 PD 友好，对外交流时也清楚清晰
3. 责任划分明确：各团队的责任在文档中划分明确，防止后期扯皮、甩锅等纠缠不清。

下表列出了一些上下游＆横向可能关心的问题，如果在 PRD 中可以解决这些问题，对整体效率提升和责任区分会很有好处。

老板	研发	运营	相关域的产品
目标是什么？ 计划怎么做？ ROI如何？ 什么时候上线？	功能要做什么事情？ 产品逻辑是什么样的？ 业务流程怎么走？ 改动点有哪些？ 涉及哪些域，分工如何？	能解决我的问题么？ 配置怎么配？ 操作会不会很复杂？	对我有什么价值？ 产品功能逻辑如何？ 对我的模块是否有影响？

怎么写好 RPD

PRD 的编写应当遵从以下几个原则：

1. 确定性：
   1. 明确改动点，明确组间分工
   2. 文字表达要清晰，不使用“可能”等不确定性字样
   3. 数据说明要准确，例如缓存更新周期一个月，要明确为“T+30”或“自然月”
   4. 每次改动内容应当是确定的，不轻易改变的，如有不得已的变更需求，必须联系项目成员确认
2. 有条理：
   1. 文档说明：修订历史、目录
   2. 产品概要：背景、目标、全景图、数据字典、相关文档等
   3. 产品描述：功能清单、产品流程、需求描述等
   4. 其它：运营计划、安全需求、性能需求、埋点需求等
3. 可读性：尽量使用简单语句，少使用长语句；在需要的地方适当加入图表和图片；
4. 字典化：PRD 应当既是索引，又是百科，通过 PRD 可以找到跟项目相关的文档，包含不限于：
   1. 上下游：MRD、交互视觉、技术方案、TC方案、UAT文档、复盘报告
   2. 关联域：涉及到域地PRD、API、二三方文档、摘录、调用部分高亮＆外链跳转
   3. 数据字典：所有可能存在歧义的用语，需要重新定义

此外，PRD 编写是一件很个人化的事情，每个人都有不同的写作习惯，一般来讲，我推荐在编写时注意以下几点：

1. 适合自己：不要拘泥于形式，应当基于要表达的侧重点而选择最佳工具，没有最好的PRD，只有最适合自己的
2. 信任他人：相信项目组成员的专业性，不要过多干涉别人的领域，做好自己应该做的
3. 前瞻展望：走一步看三步，方案设计时多考虑能否复用，能否延展

PRD 模板

这里提供一个我在编写 PRD 时使用的模板

版本说明

用于记录文档的修改过去现在

版本	日期	类型	说明	修改人
V1.0	2022/01/01	C	新增版本需求	Crispitol

注：改版说明中填写C-创建, A-追加,M-修改,D-删除,R-评审(如果是评审，请在说明栏注明，是否批准发布)

1. 项目背景及规划

1.1 需求背景

内容聚焦在：

• 业务/产品现状如何
• 做这个需求的原因

1.2 目标规划

内容聚焦在：

• 业务/产品价值：可量化、有理有据
• 业务目标：结合实际业务场景制定的落地目标，可追溯可复盘

2. 项目总览

2.1 相关文档

• 交互稿：
• 视觉稿：
• 技术方案：
• 测试方案：
• 相关域PRD：
• 相关 BRD/MRD 链接

2.2 数据字典

• 新增的模块 / 字段及其口径
• 难理解 / 可能产生歧义的模块 / 字段及其定义

2.3 需求清单

版本	相关域	模块	功能点	project ID	状态
V1.0					待评审

2.4 项目组成员

类型	角色	成员
业务	业务PM
主域产研	PDM
主域产研	PMO
主域产研	技术PM
主域产研	UED＆视觉
主域产研	服务端
主域产研	前端
主域产研	PTM
主域产研	数据侧
相关域	人群（举例）
支持	相关方

此处务必详尽，一是方便查找负责人，二是能提高团队凝聚力。

2.5 项目节奏

一般如果有一张像下面的图片能够展示是最好，如果没有，也可以写一个日期时间表，能把时间线理清楚就行。

3. 需求概述

• 从前端、后端、横向关联、策略等维度，帮助上下游新人更快的了解全局
• 无需过多赘述，尽可能简单清晰、能直接看懂

3.1 全局页面总览-前端视角

把所有涉及到的前端页面，通过按钮交互连接成一张大图，大图和链接放在此处。

3.2 全局页面总览-前后端关联视角

3.3 相关流程

业务主流程图和各个功能子流程图都放在这里。

3.4 审批流

3.5 系统链路

关于用户请求时

4. 需求描述

若需要交互或protal支持的部分，在标题中提及＆高亮展示

4.1 前端（需要交互支持）

模块	示例页面	功能说明	交互描述
模块名	原型图	1. 2.	N1 N2

4.2 后端（需要交互＆Protal支持）

提供后端原型页面，并提供页面说明。

对于展示数据类型的后端页面，提供如下数据字典：

名称	必填	位数	数据格式	数据区间	类型	选项	提示文字	备注
XX	Y	40	字符串	/	内容框	/	我是提示文字

5. 非功能型需求

5.1 安全需求

• 所有用户个人信息，比如用户名、性别、出生日期等内容，需要在接口层加密传输。
• 所有前端页面，需要使用HTTPS协议。

5.2 性能需求

• APP从启动到显示首页，时间不超过5秒；
• APP内操作的响应时间不超过3秒，3秒后无响应，需要给出提示：网络繁忙，请稍后再试，且页面可点击重新加载；
• 对页面元素做预加载处理。

5.3 可用性需求

• 操作系统支持：当下所有主流机型。
• 信息支持缓存机制，只要加载完成，网络中断后仍可显示信息。
• 定期补充语料和图片表情库。

6. 数据埋点

按照公司的统一的埋点要求描述需要埋点监控的按钮、页面、事件等。可以将数据埋点文档直接插入需求文档内。

• 指定页面spma
• 指定页面spmb

7. 角色和权限

提供角色权限表，可通过EXCEL的方式插入进来，也可以直接编写。

8、待决事项

所有待定事项