每天5分钟，你也可以成为优秀的产品经理 。你好，我是郭杉。欢迎来到 《郭杉 产品经理50讲 》第37讲

先给你说个故事，前几天有个小伙伴向我诉苦说：他几乎每天他都要被技术、测试狂怼。一会是开发问“过来一下，这个需求是什么意思”，一会又是测试说“这个页面怎么变成这样了，之前文档里怎么没写，开发都知道吗？”，整的他每天都很郁闷。问我，难道产品新人的成长路上就一定要经历这些锥心之痛吗？

其实，他经历这些是必然的，但不是必须的。问题出在他压根就没有掌握好产品经理的一门必修课——写好产品需求文档（PRD）！

为了避免你也经历他这些锥心之痛，今天这一讲我就来好好给你讲讲如何写出让大家都认可的高颜值PRD来。

1. 高质量产品PRD的写法

较为完整的产品需求文档（PRD）主要由文档修订记录、文档目录、需求背景及目标、需求列表（版本Feature list）、逻辑展示（需求的流程图、结构图和原型图）、详细逻辑描述（文字化描述功能细节）、性能需求、数据需求及其他非功能需求组成。

接下来，我们就一起了解产品需求文档各组成部分的写法。

1、文档修订记录

修订记录对于产品需求文档来说是比较重要的，修订记录的核心是记录产品需求文档每次更改所涉及到的“要点”。包括修改时间、修订版本号，修改内容，撰写人，以及有无特殊备注。

对于每一次文档的修改，我们都可以用一种不同的颜色给它标注出来，比如V1.1版本修正了产品逻辑，PRD正文中对应的部分可以用红色的文字标注出来。再比如V1.2版本新增了通讯模块，我们就可以用蓝色的字，在PRD相应部分标注出来。

在某个版本的PRD里如果有删除的内容，我们也不要直接将其从PRD中删除，而是用划横线的方式，将它划掉并加以备注，这样读者就能清楚地的知道原来的这个部分为什么删除了。

2、文档大纲目录

大纲目录也是我们撰写PRD的一个必要组成部分，大纲一般由编辑软件自动生成。优秀的大纲目录要做到逻辑结构清晰，读者看起来一眼可以对应清楚PRD中各个逻辑之间的关系。

3、需求背景及目标

这是产品需求文档中不可缺少的部分。这一部分主要是写明需求背景及项目目标。

l  项目背景：简单说来就是用一段话概括为什么要做这个版本的需求。这一部分需要我们根据要做的产品需求去提炼需求背景描述，方便大家理解为什么要做这些需求，让大家在工作中做到有的放矢。

l  项目目标：定义项目的目标，也就是项目上线后验证数据完成情况依据。需要注意的是，目标一定比较具体的，可被量化的。例如，主页曝光量达到10万PV

在撰写项目目标时，有些产品经理总喜欢把目标写的很大、很虚。动不动就会写DAU提升10%或者留存率提升20%。我们要知道，这两个指标跟很多因素有关，不是一两个产品功能或一次版本迭代就能实现的。

因此，在撰写项目目标时，一定要注意“务实”，不要一到产品目标不知道怎么写，就拿这两个数据“开刀”。

4、产品需求列表

需求列表可以让读者快速了解需求文档中都包含哪些点，对涉及的模块有个初步的认知，方便参与者去了解需求，评估需求开发大体需要多长时间，做到心里有数。

我们在需求列表中需要列出这个版本要实现的所有需求（不在此版本实现的需求 ，不需要放入需求列表中）。如果需求较大，我们也可以把它进行拆分，如按模块拆分，或者拆分成更细致的功能点。

对于数据需求，我们需要在需求列表中单列出来，提醒开发同事不要忘记在实现产品功能的时候还有“数据埋点”数据埋点需要做。

5、产品结构与流程设计

这一部分比较简单，要做的就是把之前画好的产品“功能结构图”、“信息结构图”和“产品结构图”以截图的方式列在需求文档中结构图部分中，并对应好相应的名称及编号，以备功能详述部分调用。

同理，我们还需要把之前画好的，产品核心“业务流程图”、“功能流程图”与“页面流程图”照着上面的方法贴上来,以备调用。

6、产品功能需求详述

产品需求文档的功能详述部分在撰写时并没有统一的格式要求，我们只要能把功能的表层逻辑（包含：核心页面、入口、交互流程、文字内容、状态弹窗）和底层逻辑（包含：业务/数据底层、异常逻辑、边界情况和后台）说清楚，并在PRD上体现出来就可以了。

我推荐大家使用如下所示的结构表（用例表）的方式来撰写功能的详细需求。

功能详述结构表

表中各项内容写法如下：

1. 功能名称/用例名称：给功能/用例起个简单易懂的名称。如：修改个人头像，方便大家理解功能的含义。

2. 功能编号/用例编号：给每个功能/用例编个号，方便后续检索。编号的价值在于我们每次跟他人核对功能时，只要直接说出功能的编号，大家就知道你说的是哪个功能，省去不断复述功能名称的麻烦。

3. 参与角色：功能的使用者、参与者或执行者。指的是与该系统发生交互的人或其他系统。如：注册用户。

4. 功能描述：介绍该功能的作用和目的。如：注册用户修改个人头像。方便读者了解功能的用途。

5. 前置条件：功能执行功能之前系统/用户所处的状态。如：用户已登录个人中心页面。

6.  基本流程：最主要的一个场景下的流程。需要按照先后顺序用简短的文字来对每个步骤描述，说明使用者与系统之间是如何交互的，既使用者对系统操作了什么以及系统做出了什么反应。

如： 1.用户点击“修改头像”按钮，打开修改头像编辑页面，页面显示用户现有头像2.用户在编辑页面点击“选择本地图片”，系统弹出操作系统文件选择对话框（限制文件类型为JPG、PNG\GIF）。3.用户选择本地图片后，点击”打开”按钮，系统上传该图片病并显示在头像编辑页面。4.用户点击“确认”按钮，系统保存该图片为用户新头像（原头像图片不保存），原页面打开用户个人资料首页。

7. 备选流程：除主要场景外，其他场景下的流程称为备选流程。一个基本流程往往随之会有多个备选流程，备选流程的描述篇幅常常会比基本流程多得多。备选流程除了基本流程描述要求外，还要说明备选流程是从哪个步骤开始的，在什么条件下触发，以及功能在备选流程结束后如何继续。

如：在点击“确认”按钮之前，用户点击“返回”按钮，对头像任何编辑均无效。

8. 异常流程：在一些特殊情况下，流程/用例里的流程可能会出现一些意外情况，这些场景下的流程成为异常流程。在异常流程这一项，我们需要尽量列举出可能出现的异常流程以及相应的处理方法。

如:异常一：选择本地图片大于5MB时，用户点击“打开”按钮,对头像的任何编辑均无效。

异常二：用户点击“确定”按钮，系统关闭提示对话框，重新弹出系统的文件选择对话框让用户选择本地图片，用户点击“取消”按钮，系统关闭提示对话框。

9. 后置条件：功能执行完毕后系统可能处于的一组状态。如：用户个人资料首页头像更新。

10. 备注新：对功能的一些补充说明

“结构表”可以作为产品经理功能详述的“写作框架”，规范我们的文档写作，控制文档质量与内容风格，避免一篇文档里内容风格与文档质量不一致的情况发生。同时，还能避免我们在撰写需求时漏掉某些重要元素。

同时，还能方便开发和测试人员深入理解产品需求。

这也是为什么很多互联网公司内部，推荐产品经理使用“结构表”的方式去描述“功能详情”的根本原因。

对于功能需求，我们除了要在PRD里说清楚背后的功能逻辑是如何运行的，还要讲清楚前台界面与交互是如何设计的。这时，我们就可以在结构表的下面贴上相应的产品UI设计图及产品交互设计稿，并对其进行说明。

好了，以上就是本讲的全部内容了。

关于“高质量产品PRD的撰写”，你有什么想说的呢？欢迎你在评论区留言给我。

如果觉得这一讲的内容不错，记得给我点个赞。

下一讲，我们继续一起继续聊聊“撰写高质量产品PRD”这个话题。

记得准时观看哦！

好的，本讲的内容到这里就全部结束了。我是产品专家郭杉，我们下一讲见。