一份逻辑完整、设计合理的PRD文档是产品经理的基本功。
一方面因为PRD是产品方案的产出物，另一方面，PRD会被交付给业务、设计、研发等各个部门，以它作为依据，产品才能顺利的推进需求落地。
一份顶级的需求文档至少要讲清楚三个层次的问题：
- 是否设计正确：设计的需求是否正确（重要性：60%）；
- 是否设计全面：产品模块与业务规则描述是否全面（重要性：30%）；
- 设计是否高效：设计的是否有可优化点（重要性：10%）。
文档目录
1. 文档历史
2. 需求背景
3. 需求list
4.需求文档：
功能一：
-功能逻辑图
-页面流程图
-页面描述
功能二：
-功能逻辑图
-页面流程图
-页面描述
5.全局规则
6.数据埋点
1.文档历史
文档历史用来说明每次变更的内容、修改人，方便团队成员追溯功能历史，查看最新的变更内容。我们以评论发布功能为例：
| 序号 | 版本号 | 更改时间 | 修改人 | 模块 | 更改内容 |
| 1 | v1.0 | 2022-04-20 | 张三 | 评论模块 | 发布成功 |
| 2 | v1.0 | 2022-04-26 | 张三 | 评论模块 | 等待审核 |
2.需求概述
需求概述可分为3个部分写：
1）需求背景：
需求背景目的是让团队成员快速的熟悉本次需求是解决什么问题，根据需求不同，有不一样的表达方式。比如体验优化类的需求，可以放上数据分析、流程分析；新功能可以写一些前期调研内容，竞品的示例页面；CMS后台等功能，可以详细说明运营市场的需求、使用场景等。
2）需求内容：
需求内容是基于需求背景，给出的解决方案，简单描述本次需求的核心功能即可。
3）项目排期：
根据需求优先级和紧急程度，说明需求的期望上线时间。
3.需求List
表格一般包括4个部分：
1）端口：说明该功能在哪个端口实现，比如APP、PC等。
2）所在模块：说明功能属于哪个业务模块。
3）需求名称：说明该版本新功能的名字。
4）需求描述：更详细的描述每个功能点。
5）优先级：表示该需求的优先级。
| 端口 | 模块 | 功能名称 | 功能描述 | 优先级 |
| APP | 评论模块 | 评论功能 | 展示用户评论 | P0 |
| APP | 评论模块 | 举报功能 | 针对单条评论进行举报 | P0 |
4.功能逻辑图/业务流程图：
清晰的梳理出复杂的业务流转逻辑，根据需求内容不同，用不同的方式去呈现（UML或流程图）。
5.页面流程图
页面流程图是用来说明前端页面之间的跳转，可以用原型图+跳转箭头去呈现。
6.页面描述
说明每个页面，功能逻辑、以及页面上每条数据（表单、文本、图片、链接等）的取值逻辑、展示&刷新规则、交互规则、异常的数据处理。
7.全局规则
如果需求里有使用全局的功能，可以单独列出来，比如按钮的状态、列表展示数量等。
8.数据埋点
埋点目的：为了尽可能完整的收集可以体现用户使用场景和真实需求的行为数据
主要步骤：定义数据指标-->数据收集-->数据分析-->反哺业务
分析方法：4W1H（who/when/where/what/how）
who：用户ID
Where：IP分析
When：时间戳
How：设备型号、操作系统、产品版本、上级页面
What：用户目的
主要关注：用户使用频次和使用完成度
常用指标：使用量、使用频次、流程达成率（目标产品的用户流程较为简单，查看用户是否完整整个流程）
核心业务：平台靠用户浏览广告进行盈利，核心业务卖广告，体现核心业务健康情况的关键指标为平台流量
上传机制：事件发生时上报：用户产生某个行为，触发买点后，将以上数据传输至后台
埋点需求：用户是否愿意使用社交账号登录？
埋点规划（7天）：账号登录用户占下载用户数量的比率
埋点文档：
| 模块 | 模块ID | 事件名称 | 事件ID | 参数 | 参数key | 参数值 | 事件描述 | 上报位置 | 更新时间 | 类型 |
| 登录 | 10000 | 微信登录- 进入首页 |
1 | 登录结果 | result | 0、成功 1、app没给数据 |
点击微信登录上报，记录结果 | 客户端 | 2022-04-26 | 新建 |
注意：市面上的PRD模板有很多，每个公司团队的合作方式、对PRD的要求也不同，产品的核心竞争力不是PRD，写PRD之前，你对业务的研究和思考才是最重要的。