prd相关规范

https://www.growthhk.cn/cgo/product/36084.html

PRD规范

一、表达：

• 1、文字，最常见的信息表达介质，中文、英文、数字、符号组成的文字是最基础的表达
• 2、表格，对于情况比较多而又有逻辑共性的一些表达，可以用表格结构化的整理
• 3、图形，对于相对比较具象化或者逻辑性的表达，可以用原型图、流程图甚至设计图来表述

二、表现：

• 1、框架，一般在业务的整体框架或者产品的框架，需要绘制这样的图，来把每个业务的系统模块去做整体的逻辑关联，把握相关的业务关系。
• 2、流程，一般在描述业务链路和有流转分支的逻辑关系时候使用，特别是在复杂条件判断和业务链路环节比较长的场景下使用
• 3、用例，一般以产品使用者的角色代入进行业务分析使用，能够清晰的反应用户使用的过程和环节

三、逻辑：

• 1、演绎-前提、规则、结论，通过一定的假设，并通过规则性的分析，从而获得结论
• 2、归纳-个别、特殊、一般，通过个体，推理到对应的聚类，在推理到一般的群体，实现推演
• 3、类比-比较、类推、预测，通过对比找到同类属性，进行同类性推理，从而做出一定的预测

四、原则：

• 1、简洁-废话不要，对于业务逻辑和想要实现的需求，应该简洁的表达出来，不需要啰嗦
• 2、清晰-表述清晰，对于重要的流程、环节和步骤，应该清晰的表达，避免造成混淆
• 3、严谨-概念严谨，对某个重要的概念和术语，应该严谨的定义，避免造成歧义

五：阶段：

• 1、需求分析阶段：主要做需求的调研、分析和推演的过程
• 2、需求确认阶段：主要做需求的梳理、方案和确认的阶段
• 3、需求实现阶段：主要做需求的落地、开发和验收的阶段

PRD的模板

标题：[PRD][XX项目]_[XX版本]_[XX日期]

零、更新记录

• —WHAT：更新记录是在项目方案经过评审之后，所有的需求逻辑和业务方案变动点，都应该做及时的记录和通知
• —WHY：保证资源方可以及时获取到需求的更改和变动点
• —HOW：按照下图表格形式结构化整理

零、项目排期

• —WHAT：项目排期是在项目做了需求评审和技术评审之后，整体的项目对应负责人、对应排期和上线计划的时间清单
• —WHY：保证资源方统筹和项目管理控制，避免不必要的责任认知缺失和延期风险感知缺失
• —HOW：按照下图表格形式结构化整理

零、评审记录

• —WHAT：项目在多次评审过程中的评审会议记录，尤其关注的是确定的点、待定的点和删除的点
• —WHY：评审记录过程会对需求方案做大量的讨论，有效的记录可以让大家会后清晰的梳理出变动信息
• —HOW：按照下图表格形式结构化整理

一、项目背景

1、业务背景

• —WHAT：项目所在业务的需求背景，包括行业背景、竞品动态、数据观察等关背景信息
• —WHY：业务背景是需求的出发，也是帮助其他人快速了解进行该项业务的核心出发点是什么
• —HOW：文字描述即可，附图更好，有数据更佳

2、目标人群

• —WHAT：通过用户研究，深入分析人群，找到目标用户或者抽象出来的虚拟角色
• —WHY：业务的用户是一个整体，而项目和需求针对的肯定是一类人群，人群的定位可以保证业务的专注性
• —HOW：文字描述即可，附图更好，有数据更佳

3、用户场景

• —WHAT：用户实现目标而经历的过程，也是一种抽象的描述，可能是正面的叙述，也可能是反面的吐槽
• —WHY：用户可以很清楚明白的知道我们在什么情况下会用到这个产品设计，这个产品设计增强了产品的可用性和用户体验
• —HOW：文字描述即可，附图更好，有数据更佳

4、用户需求

• —WHAT：针对业务分析过程中，获得的用户需求挖掘
• —WHY：需求决定本次项目的具体解决目标，一般是用户的痛点
• —HOW：文字描述即可，附图更好，有数据更佳

二、项目方案

1、产品规划

• —WHAT：针对本次需求提出来的整体项目大致规划，包含每一期的迭代方向、目标和主动动作
• —WHY：规划可以让别人知悉你的项目优先级和整个计划
• —HOW：文字或表格描述即可，列出版本、周期和规划

2、方案说明

• —WHAT：本次项目的方案的概况，包含主要流程、主要功能和主要页面
• —WHY：项目方案的整体性描述
• —HOW：文字或表格描述即可，体现核心逻辑

3、运营策略

• —WHAT：本次项目应有的运营策略和计划
• —WHY：项目方案的运营支持
• —HOW：文字或表格描述即可，体现核心逻辑

4、资源准备

• —WHAT：本次项目的资源准备，包括合作方的资源、采购的资源和支持方的资源
• —WHY：整体资源的罗列
• —HOW：文字或表格描述即可，体现核心逻辑

三、收益风险

1、收益分析

• —WHAT：大概的方案所希望达成的收益和数据目标，包含定性和定量的情况，定性主要是针对产品的用户价值的描述
• —WHY：关注目标，不管是自己、老板还是业务方都需要相应的目标来确定工作的重要性和优先级
• —HOW：定性文字描述即可，定量需要体现数字1.1 定性1.2 定量

2、可能风险

• —WHAT：对项目方案可能会带来的负面影响的描述
• —WHY：帮助评估实现业务可能带来的风险
• —HOW：文字描述即可

四、业务流程（流程图）

1、业务流程

• —WHAT：对项目业务的流转链路进行描述，是针对业务逻辑的体现
• —WHY：可以清晰的梳理出来整个业务的逻辑
• —HOW：流程图展示，流程用UML图

2、页面流程

• —WHAT：对项目的的页面关系表达，是针对业务流程的前端体现
• —WHY：可以清晰的定位项目的页面和功能
• —HOW：文字描述即可，页面使用截图或者形状图替代

五、功能清单（脑图或表格）

1、功能清单

• —WHAT：需求的功能清单，也称Feature List，一般是需求的重点描述
• —WHY：关注目标，不管是自己、老板还是业务方都需要相应的目标来确定工作的重要性和优先级
• —HOW：按照下图表格形式结构化整理

2、接口清单

• —WHAT：需求的接口清单，一般是对应功能页面所需的大概功能接口，也可以忽略，由技术自行设计
• —WHY：方便自己、也服务端同学清晰所需接口设计
• —HOW：按照下图表格形式结构化整理序号接口接口详述

六、原型设计

1、原型设计：

• —WHAT：完整的页面原型设计，原型应该依靠上述的功能清单和接口清单作为基础依据
• —WHY：需求评审、设计依据和开发查看需求的主要部分
• —HOW：绘制原型图，重要逻辑需要附注

七、需求详述（图文逻辑）

1、状态定义

• —WHAT：部分专业数据、文档概念的描绘
• —WHY：统一概念，避免产生混淆和概念理解偏差
• —HOW：按照下图表格形式结构化整理序号名词释义

2、需求说明

2.1 需求详述

• —WHAT：原型+逻辑基本就是需求详述的内容，也是需求投入开发的主要依据
• —WHY：需求文档PRD的核心部分
• —HOW：按照下图表格形式结构化整理

2.1.1 前端部分

2.1.2 后台部分

2.2 中英文对照

• —WHAT：如果APP涉及多语言，还需要对部分文案做英文版翻译
• —WHY：海外用户或英文偏好用户的需求
• —HOW：按照下图表格形式结构化整理序号页面模块中文英文

八、数据需求

1、数据埋点

• —WHAT：对项目功能进行的数据埋点方案设计，主要是采集想要的用户数据点和生成相应的报表
• —WHY：针对上线后的产品进行相应的行为数据挖掘和数据分析，并生成相应的数据报表
• —HOW：按照表格形式结构化整理或直接在原型图上标注更贴切

2、数据报表

• —WHAT：是整个产品核心数据的落地，按照指定周期定时产出
• —WHY：对应项目的核心目标，及时跟踪用户行为和产品数据
• —HOW：按照表格形式结构化整

九、设计产出

1.设计文件：

• —WHAT：整个项目的整体设计方案，包含体验设计、视觉设计和品牌设计
• —WHY：设计产出，直接的页面设计成果
• —HOW：设计稿原件或者导出的图片文件

十、灰度方案

1.灰度方案：

• —WHAT：项目上线的灰测方案，分人群逐步开放新功能或者针对不同分组的人群做对照试验分析
• —WHY：可以及时验证产品功能，发现产品问题和及时调整产品策略
• —HOW：文字描述或者表格形式整理皆可

04 PRD的总结

PRD本质是我们项目方案的一个整体落地和记录，是一个完整的项目说明方案，也代表一个完整的项目思考过程，有了它我们才可以比较顺利的推进项目的进程。

通过对一个完整的PRD模板的介绍，总结了我自己日常整理一个需求的全过程。但是，视需求的大小、公司的节奏和团队的要求，这可能不是一个最好的模板，且有些部分可能不需要涉及。

我们当然可以通过口述和其他各种方法去呈现自己的项目需求，只不过这个过程一定要有章可循，有法可依，模板出发点不是为了固化思维，而是应该在所有元素的对照下，可以避免缺失、造成忽略和反复返工。

另外，也非常强烈建议大家的文档，都可以固定一两个类型，比如在线文档：飞书、Confluence、墨刀之类的，或者是原型文件：Axure、Sketch、MockPlus之类的，又或者直接是文档软件：Word、WPS甚至是Excel，同时做好命名、文档整理并形成清单，方便查阅、交接和复盘。这是产品经理的产出历程，是我们最宝贵的产出，值得珍藏并定时复查。

而除了这样的一个文档化的产出，大家也需要铭记在心的是，文档固然是文档，它应该是我们做这个需求的项目分析、思考过程和落地方案，我们更应该记住的甚至是脱口而出的是这三个点：

• 1、「它解决XX用户在XX场景下的XX问题？」
• 2、「它使用XX资源、提出了XX方案，并希望收获XX结果（数据）？」
• 3、「它带来XX核心价值（用户价值、商业价值、公司价值）」

这不仅是一个书写一个PRD文档最应该考虑的前提，也是撰写完一个PRD文档应该有的落地的复盘，在这两者之间，PRD是贯彻的业务逻辑的核心承载，希望大家在产品生涯中念念不忘，不弃不舍。