作者：Harvey's，出处：产品方案：我的PRD撰写规范
目录
第一部分：PRD的背景
本身，产品经理这个岗位并没有系统的科班专业（哦，不对，之前刷新闻的时候看到北京师范大学研究生院好像已经在今年开通了产品经理的硕士学位和相关的课程），所以我们在工作投入之前，其实并没有办法直接在相关硬技能上有比较系统的学习。大部分同学能进入互联网的产品岗位，要么是因为具备一定的软素养之后通过实习入行，要么是身边有得力的师兄师姐给予帮助分享，要么足够关注这个岗位平常有意识的学习和思考，要么就是其他相关岗位或行业之后的转岗或转行。
互联网的人经常说，「培养一个好的产品经理，至少需要3年」；「好的产品经理培养成本是100万起步」；「这个行业的产品经理很少见的」，都在说明入门产品岗位可能并不难，但是要实现一定的突破可能并不简单。
作为一个产品经理，我们的工作核心是围绕产品方案输出的，不断的通过一个新产品或者产品迭代来开展自己的持续性工作。不管是日常的沟通，还是参加各式的会议，以及输出相关的方案，我们的很多工作都需要通过一个核心中介来产出，这个核心中介产出就是：PRD。
我记得自己写的第一份比较大型和完整PRD是做一个理财网站的改版，一会是原型软件在绘图，一会是在文档上撰写，一会是在思维导图上梳理逻辑，而且相关工具用的还不够熟练，那叫一个手忙脚乱，毫无章循。而到了实际评审和需求开发的阶段，经常少了这个部分逻辑说明，或者少了这个流程说明。那个时候的问题原因在于，并不清晰每个阶段和每个模块的产出，和对应的最高效的方法和工具。
当互联网进入发展深水期，再加上各种不同的行业，不同方向的产品的取向，你会在身边看到各种形形色色的产品文档。作为一个在咨询和投行实习待过的产品人（因为这两个行业都有非常标准化的产出模板和方法论），一直对怎么标准化PRD这个命题努力不已。当然，产品最重要的应该是逻辑，形式化的文档和组件化的工具，都应该是以满足工作需求和提升工作效率而生的，过分注重流程和形式，从来都不适应这个讲求小步迭代和快马加鞭的快速发展的环境。
不过，磨刀不误砍柴工，还是想整理一下这几年关于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 | ||||
| 2 |
一、项目背景
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：文字描述或者表格形式整理皆可
第四部分：PRD的总结
PRD本质是我们项目方案的一个整体落地和记录，是一个完整的项目说明方案，也代表一个完整的项目思考过程，有了它我们才可以比较顺利的推进项目的进程。
通过对一个完整的PRD模板的介绍，总结了我自己日常整理一个需求的全过程。但是，视需求的大小、公司的节奏和团队的要求，这可能不是一个最好的模板，且有些部分可能不需要涉及。
我们当然可以通过口述和其他各种方法去呈现自己的项目需求，只不过这个过程一定要有章可循，有法可依，模板出发点不是为了固化思维，而是应该在所有元素的对照下，可以避免缺失、造成忽略和反复返工。
另外，也非常强烈建议大家的文档，都可以固定一两个类型，比如在线文档：飞书、Confluence、墨刀之类的，或者是原型文件：Axure、Sketch、MockPlus之类的，又或者直接是文档软件：Word、WPS甚至是Excel，同时做好命名、文档整理并形成清单，方便查阅、交接和复盘。这是产品经理的产出历程，是我们最宝贵的产出，值得珍藏并定时复查。
而除了这样的一个文档化的产出，大家也需要铭记在心的是，文档固然是文档，它应该是我们做这个需求的项目分析、思考过程和落地方案，我们更应该记住的甚至是脱口而出的是这三个点：
1、「它解决XX用户在XX场景下的XX问题？」
2、「它使用XX资源、提出了XX方案，并希望收获XX结果（数据）？」
3、「它带来XX核心价值（用户价值、商业价值、公司价值）」
这不仅是一个书写一个PRD文档最应该考虑的前提，也是撰写完一个PRD文档应该有的落地的复盘，在这两者之间，PRD是贯彻的业务逻辑的核心承载，希望大家在产品生涯中念念不忘，不弃不舍。
7075
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
