产品方案：PRD撰写规范

第一部分：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. 可能风险
2. 风险对应下的假设
3. 假设所带来的问题
4. 问题解决下所需要的依赖条件；

四、业务流程（流程图）

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：文字描述或者表格形式整理皆可

第三部分：PRD的总结

PRD本质是我们项目方案的一个整体落地和记录，是一个完整的项目说明方案，也代表一个完整的项目思考过程，有了它我们才可以比较顺利的推进项目的进程。
通过对一个完整的PRD模板的介绍，总结了我自己日常整理一个需求的全过程。但是，视需求的大小、公司的节奏和团队的要求，这可能不是一个最好的模板，且有些部分可能不需要涉及。
我们当然可以通过口述和其他各种方法去呈现自己的项目需求，只不过这个过程一定要有章可循，有法可依，模板出发点不是为了固化思维，而是应该在所有元素的对照下，可以避免缺失、造成忽略和反复返工。
另外，也非常强烈建议大家的文档，都可以固定一两个类型，比如在线文档：飞书、Confluence、墨刀之类的，或者是原型文件：Axure、Sketch、MockPlus之类的，又或者直接是文档软件：Word、WPS甚至是Excel，同时做好命名、文档整理并形成清单，方便查阅、交接和复盘。这是产品经理的产出历程，是我们最宝贵的产出，值得珍藏并定时复查。
而除了这样的一个文档化的产出，大家也需要铭记在心的是，文档固然是文档，它应该是我们做这个需求的项目分析、思考过程和落地方案，我们更应该记住的甚至是脱口而出的是这三个点：
1、「它解决XX用户在XX场景下的XX问题？」
2、「它使用XX资源、提出了XX方案，并希望收获XX结果（数据）？」
3、「它带来XX核心价值（用户价值、商业价值、公司价值）」
这不仅是一个书写一个PRD文档最应该考虑的前提，也是撰写完一个PRD文档应该有的落地的复盘，在这两者之间，PRD是贯彻的业务逻辑的核心承载，希望大家在产品生涯中念念不忘，不弃不舍。

产品/项目目标

非功能性需求