人人都是产品经理 : 如何写出一份优秀的 PRD ? 精于心简于形 !

人人都是产品经理 : 如何写出一份优秀的 PRD ? 精于心简于形 !

在一个真正的产品经理眼里，世间万物，皆是产品。

PRD（Product-Requirement-Document，产品需求文档）

一份目录结构清晰的PRD 长什么样?

一个好的prd框架结构应该至少包含以下内容：产品简介、产品概览、产品架构、产品原型、非功能性需求，如下图：

如何用Axure输出一份结构清晰的PRD？

1.1 产品简介

通过产品简介，让UI、开发、测试等相关人员迅速的熟悉产品的相关背景、产品描述、目标等，加深对产品本身的理解，有助于工作的开展。

有的小伙伴会好奇，公司通常情况下都会有产品启动会，会上已经说清楚了这些内容，产品还有必要多次一举再输出这些内容么？

答案是必然的，因为产品启动会并不能确定所有人员都到场了，也不能确保会上所有人员都认真听了（谁知道某个开发是不是在会上偷偷勾搭UI妹子呢…..），更不能确保产品开发中途没有新的成员加入，所以输出一份好的产品简介是十分必要且重要的！

下面说一下产品简介页面应该包含哪些内容：

• 产品简介：一句话说明产品核心的功能，两三句话说明产品大概的内容；
• 目标用户、使用场景：阐述一下什么人在什么情况下会使用该产品；
• 项目背景、痛点：简单说明一下为什么我们要做这个产品，目前存在哪些痛点；
• 产品目标：产品要解决的问题，最终实现的目标，能达到什么样的效果。

如何用Axure输出一份结构清晰的PRD？

详细内容各位读者可以根据自己实际情况做一定的调整，总之一句话：让所有参与人员通过查看页面内容能够迅速的理解该产品的基本情况！

1.2 修订历史

任何PM写prd，都不能保证考虑全面所有场景，更不能保证在开发阶段中prd不做任何变更。冒着被开发打的风险，给大家说一句：产品不改prd就好比开发写代码没有bug一样。

所以有改动是必然的，改动不可怕，但是在项目正式启动之后，每一次改动必须要有记录（无论改动多小），让项目成员知道你又在搞事情，搞了些什么事情~~~

修订历史必须包含：修订的日期、当前版本号、修订说明、修订作者。另外，建议提供链接，通过修订记录可以直接跳转到具体的修订页面。

如何用Axure输出一份结构清晰的PRD？

1.3 全局规则

一定要有全局规则！一定要有全局规则！一定要有全局规则！重要的事情说三遍。

为什么强调一定要有全局规则呢？

对于相同或者类似的规则，通常产品只会在一处标明。如在A页面列表标注：排序按照记录生成时间逆序排序，在B页面同样存在列表时，则未进行专门说明。按照产品理解，我前面已经写清楚了按照逆序排序，所以此处同理应该逆序排序。

然后事实是：开发分模块，每个开发人员只关心自己要开发的页面，他或许压根没关心你在另外的页面写了什么。所以，对于此类情况，我们应该写进全局规则里，因为全局规则是所有开发人员必须去查看的页面。

全局规则具体包含哪些内容呢？

答案：只要是需要所有开发人员查看，且适用于整个系统的都可以写进全局规则中，包括：交互说明、屏幕适配、全局字段说明等等。比如：字段‘邮箱’，在系统中多个地方出现，我们只需要在全局规则写明1次字段‘邮箱’的规则限制即可，而不需要在‘邮箱’出现的每个地方都进行重复编写规则。

同时一些特殊的说明也需要在全局规则页面备注好，让开发一目了然

为什么需要一个优秀的PRD

没有可读性的PRD都是耍流氓.

小案例：需求评审，预计1个小时的时间，PM自信的打开PRD，开始讲述自认为想的很周全的需求，可是研发们发现了PRD上没有的各种细节逻辑并开始质问，PM急得一头汗的回应着各种问题，评审会议也终于在2个小时结束；开始开发了，RD发现这份PRD中仍然缺少了相当多的逻辑细节，于是一边心里暗骂PM不靠谱，一边去找PM确认，于是PM在整个需求开发周期中一边被喷，一边心累着跟进需求；需求开发完毕，PM开始回归，发现很多细节不是自己想要的，于是去找RD修改，RD认为你这个不靠谱的PM还敢修改需求后果断拒绝了，并给出终极大招，看，PRD上没写，PM此时可以做的，只能是沉默…

其实我们从上面发现，一个优秀的PRD的用处。

1. 是PM基本功的体现
2. 节省开发中PM的精力
3. 增强在RD心中的靠谱程度（这很重要）
4. 需求验收的标准

如何写出优秀的PRD

那么，如何写出一个优秀的PRD–精于心，简于形。

每份PRD都应该是PM心血的体现，都应该让一个对需求完全不了解的人能够知悉需求中的全貌和细节，但是没人会一开始就写出一份优秀的PRD，没人会在一开始写的PRD中就想到了所有的细节，一份优秀的PRD必然是PM踩着坑，总结着坑点，一步一步的不断完善才完成的，那么一个优秀的PRD，必须包含的元素有哪些？干货见下：

1、需求纬度

一个PRD首先应该展示的内容是需求，需求的背景是什么，没人会想做一个完全不了解或者没有意义的需求，作为项目的一份子，研发们有必要知道需求本身最重要的内容–需求背景是什么？需求意义是什么？而且PM和研发也必须知道本需求有效的衡量方法，接下来有个固定的方法，即：

• 需求意义：XX需求为XX解决了XX问题，以提升XX指标/体验
• 衡量方法：XX数据发生XX变化

2、业务纬度

精于心：一个需求/项目（比较大的）里面包括了很多小的需求分支、业务逻辑、甚至是之前没有的名词和定义，这里需要用心考虑周全，业务上所有的角色的流程都要考虑到，以免照成影响。

简于形：相比大段的说明文档，可能大家需要的是一个逻辑图。

业务纬度的内容见下：

1）业务流程图

需求的具体业务是怎么样的，涉及到哪些部门，物料/数据/信息在各个部门中是如何流转的。

以淘宝退款流程为例

如何撰写赏心悦目的PRD？精于心简于形

2）操作流程图

用户角度对各个功能是如何使用的，页面跳转逻辑是怎么样的。

以登录流程为例

如何撰写赏心悦目的PRD？精于心简于形

3）功能分支图

整个需求都包括了哪些功能，功能的具体做是什么？

4）新定义说明

需求中涉及到的新定义是怎样的，跟业务的关系是怎么样的？

3、页面纬度

说明了需求，说明了业务，下一步就需要具体到页面，这部分是用户真正看到的内容，这里的细节也是研发真正实现的时候最容易遇到细节不清楚的地方，所以，精于心特别重要。那么页面纬度具体包括哪些内容呢？

共有5个方面的内容：

1）角色区别

进入页面时是否分角色展示不同内容。

2）展示方式

进入页面后，默认展示的样式、多信息排列的规则、UE图涉及到的逻辑变化、控件点击前后的细节、文字数目的限制等都需要做详细的描述。

3）交互方式

页面中各个控件切换的交互方式是怎么样的，是否有特殊的交互方式需要特别指出

4）退出方式

页面退出逻辑是否遵从从哪里进，退回哪里的逻辑（以场景判断，属于需求层面），若不遵从，需做明显标识。

5）数据规则

刷新、缓存、加载、loading具体细节如何，都需要做出详细的描述，但是由于此部分涉及技术层面内容较多，故一定要与RD做好预沟通后再将确定的内容填写至PRD。

如何撰写赏心悦目的PRD？精于心简于形

5、边界情况

非正常情况也需要在PRD中做详细的分类和描述，对于RD来说这部分不可缺失，且是PRD中最容易出漏洞的。边界情况大致包括以下6种。

1）登录相关

用户登录和不登录展示逻辑，是否可以进入功能等。

2）网络相关

无网/弱网如何处理，页面如何展示。

3）空页面相关

页面信息为空时如何展示

4）版本相关

历史版本如何包容新样式、新信息。

5）操作相关

用户在使用时杀掉APP，清理了缓存如何处理。

6）帐号相关

单个设备切换帐号后，如何处理数据。

7）数据相关

本需求中需要处理的数据在其他需求中有用到时，是否一并改动，如何兼容问题

如何撰写赏心悦目的PRD？精于心简于形

6、一定记得检查你的错别字和排版

一个错别字会让你之前的努力大部分付之东流，错别字的出现将使好不容易获得的靠谱度急剧下降，所以别小看它，它是一个PM专业态度的体现。

回头再看看排版吧，是否看着舒服，信息清晰易懂，这决定着这份PRD的第一印象，请像对待一件艺术品一样，对待PRD，排版也需要精于心，简于形。

总结：给个图吧，这就是上面所有的内容：

如何撰写赏心悦目的PRD？精于心简于形

一份PRD不仅仅是一份PRD，看一份PRD，就能看出这个PM的逻辑性、思考的缜密性、对需求的理解、对美的理解，也就代表了一个PM的水平。

精于心，简于形.

产品经理整体思维

一个PRD是衡量一个产品经理整体思维的标准，一个PRD可以看出一个产品经理在某个领域的专业性，同时也可以反应出一个产品经理的整体产品思维。

产品经理的整体思维体现在：

1、提炼核心需求

2、思考满足核心需求的方式

3、评估方式优劣选定方案

4、思考功能概要

5、思考支撑功能和关联功能

6、细化设计功能

7、子功能（功能间迭代）

PRD其实就是将以上的思维整体走向写出来，同时将产品的思想提炼出来，用文字表示给开发者，给UI、给视觉、给老板……PRD给的是一种思想，将产品的整体思想和核心需求灌输给产品的相关人员，都说PRD是个承上启下的功能，因为上接MRD，下对MRD进行技术性的描述。

1、文件命名（编号）

文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”，当出现产品第二版时，可以命名为“公司名-产品名-PRD-D2.0”。

2、修订控制页

一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序，文档版本显示的当前修改的内容是在哪个版本中出现，修订章节是具体到哪个章节哪个功能模块的修改，修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期，修改人显示修改内容模块的人，可能是当前用户也可能是其它产品人员。

3、目录

不建议自己去添加一个新的目录，你可以去其它的文档中拷一个过来，不考虑目录的内容，等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。

4、请与以下部门讨论PRD

PRD做为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上，需要与相关人员确定“沟通内容”，这对于产品整体流程将是很重要的。同时对于产品核心功能的提取也是一个重要环节。产品经理很重要的一个职能就是沟通。例与客服中心：客服服务部，讨论的内容：预测客服成本、工作量；讨论客服如何支持；协助评估诈欺/数据窜改风险：欺诈/数据窜改风险、不正使用风险。这就是要写在与其它部门讨论PRD中的。一个产品经理需要考虑如何与其它部门之间的沟通合作，文档很大一部分的功能是提醒你要做的工作，同时不断补充将要面临的工作。

5、概述

概念就是总结，它包括的点有：名词说明、产品概述及目标、产品roadmap、产品风险。

名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。

产品概述及目标：解释说明该产品是干什么的，为什么需要这样的产品。同时产品想要达到什么样的目标。产品概述及目标就是对产品核心功能讲解，同时希望可以达到的期望。

产品roadmap：产品分期目标，阶段描述，以及时间点的确定，产品是个不断演进的过程，很多时间一期产品只完成了产品70%的功能，二期才会继续去完善剩下的30%，同时有可能会推翻了重新推出第二版。产品roadmap并不及着全部规划好所有的阶段目标，而是更多的通过维护来保持产品的更新和迭代。

产品风险：描述产品可能存在的风险，比如商务谈判的风险，外部合作的风险，不当使用的风险等等。风险级别为高中低。

6、使用者需求

使用者需求一般只有个需求描述。需求描述有以下几项内容：目标客户、需求描述、场景描述、优先级。

目标客户即为产品的最终用户，确定产品的最终使用者。

需求描述是对目标客户的需求描述，表达用户最需要的是什么，找到用户的最根本需求。

场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。

优先级是指用户对于当前产品功能需求的优先级，哪些是用户最想要的功能优先级则排前。

7、可选方案

列出所有可以选择的达到该产品目标的方案要点（主要思路），给各方案适当的评价，并推荐最优方案。你在做这个产品规划时一定有很多的备选方案，别放弃这些方案，永远没有过时的idea，只有最适合时机的idea。所以可以写出几个可选方案，或许是你下期产品改版一个方向。

8、效益成本分析

产品经理是个全才，在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面：效益预测、产品技术中心成本、非产品技术中心支持成本。

效益预测是指提供在各种产品环境中的效益预测，并标明主要的变量及假设，最好能包含现在和过去的效益数据。如网站的PV值，软件的使用数都是效益预测数据。

产品技术中心成本是指设计及部署此产品的产品技术中心所需的资源需求，包括人力成本，软硬件支出等。很大时候这份成本需要由项目经理来协助，需要有什么样的人才加入产品中需与人力协助。

非产品技术中心支持成本，产品不是只有产品组完成的，同样需要其它部门的配合与协助。比如：需要客服部投入多少的资源用于该产品的服务，需要运营部投入多少的资源运营该产品。

9、功能需求

功能需求一般是由四部分组成，功能总览、功能详情、整合需求、BETA测试需求。

功能总览一般包括二个部分，一个是流程图，一个是功能表。流程图是对产品的整体走向的流程的规划，流程图是用来对产品整体功能的梳理。所以在做产品前建议所有的产品经理先梳理一下产品流程。功能表是将流程图文字化，同时将列出产品的功能点。

功能详情，这是所有的产品功能的描述和规划。包括以下内容：

简要说明：告诉此功能主要干什么的。

业务规则：每上产品在使用时都有自己的规则，而产品的业务规则则是将产品的流程细化。个人建议将这个功能的业务规则，包括一些细节，如排版形式、日期显示方式全定好，这样方便其它人员的沟通和理解。

界面原型：产品经理在这时做的原型界面只是显示的框架，别细化，这样会给交互和UI造成错觉。只需做一个简单的界面即可，更多的时候只是个框架图。

执行者：产品使用者。

前置条件：具体的操作。

后置条件：操作后的展示。在UC（user case）中后置条件又是另一种情况，所以对于建议在PRD中的前置条件和后置条件结果合起来。

主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明。将此功能的流程走向做个分点说明。

10、整合需求

产品经理很重要的一个能力就是体现在产品整合能力上，利用公司现有的资源或外部资源（合作公司等）实现产品功能需求的整合。实现功能贯穿的同时，更多的如何在新产品上实现功能的拓展来辅助核心功能。

11、BETA测试需求

很多产品都有BETA版本放出，为了就是收求意见和一些性能测试。这部份内容不是必须的，但现在很多产品已经开始先推出BETA版本再推出正式版，当然也可以通过升级来解决。所以BETA测试需求并不是一定需要的。如果有BETA测试需求，则需写出BETA版测试的要求和期望达到的目标要求。

12、非功能性需求

都说产品经理是全才，在这点上得到彻底的体现。很多产品经理在这点上忽视了，但很多方面是用到的，只是在产品过程中弱化了。

一般情况下非功能性需求包括以下几个部分：产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需求等。与其说是全方位的掌握技能，还不如说是沟通，如何与不同的部门人员之间的沟通，让更多的人协助产品的正常使用与上线。

13、上、下线需求

上线时限需求：此产品预定上线日期？上线日期有无任何特殊依据或规定？

下线需求（活动类需求必须明确下线时间）：此产品预定下线日期？下线日期有无任何特殊依据或规定？

14、运营计划

说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户，产品经理是核心需求的把握者，参与到产品整体运营计划显得特别的重要。

……

写PRD并不是产品经理的全部工作，但却是不可少的一部分，很大程度上反应了产品经理的思维和产品核心功能把握上，同时对产品经理沟通、协调、规划等都得到了一定的验证，但每个产品经理的第一职能是会写一份让其它人员看得懂的PRD。

PRD七坑：没有可读性的PRD都是耍流氓

第一坑——名词交流混乱

这是昨天文档中最大的问题，因为后台是管理订单的，所以会有大量的时间结点，但是目前只有两个时间结点有自己的专属名字。其他的时间结点的叫法都是今天一个样，明天一个样。

所以我在写文档的时候就按照自己的叫发来写文档，其中就有一系列相似名称的时间结点叫做“服务时间”、“次服务时间”、“官方服务时间”，技术同学在开发的时候，直接把“官方服务时间”的“官方”二字看掉了。

看错后就直接对“服务时间”的先关内容进行大刀阔斧的修改，所以就导致后台订单数据错乱。于是乎经过交流，终于重新定名“服务时间”、“订单时间”、“官方时间”。

关键词命名的注意点：

整个团队要将关键词进行统一，最好创建规范性名词解释列表； 关键词命名时，同一个模块、流程中的词语里边相同字的使用不要超过50%； 还有产品设计各个环节中，关键词的一致性，也是需要注意的。

第二坑——专业名称重复出现

昨天在写文档的时候，为了使每一个名词都能精确的定位到每个点上，所以每一个名词都使用专业名称来表示，全篇PRD专业名称横飞。由于昨天写的文档是属于纯逻辑性的文档，所以大量在专业名称充斥的情况下，整篇文章的可读性极差。

专业名称使用注意：

同一句话中，能使用代词来代指句子中的专业名称的时候，尽量使用代词表示，因为代词更口语化，也更容易让人理解。 如果使用代词会让整句话产生歧义，那就一定不要使用代词； 使用代词可以增加可读性，使用专业名称可以增加准确性，所以只有在恰到好处的地方进行敲到好处的表达，才能把文档的易读性和准确性最大化。

第三坑——行文逻辑不清晰

在写开发文档的时候，凭着直觉来写文档，在写之前并没有梳理清楚其中的逻辑，以至于最后写出来地文档逻辑混乱，各个板块互相穿插。

在撰写文档前，首先自己要清楚整个功能的流程，这个肯定是毋庸置疑的。但是，我们在写文档的时候，可能就没有这么在意行文的逻辑，全凭自觉来撰写。

所以在写文档的时候，不仅仅需要理清整个产品、功能的逻辑，还需要为整篇文章的结构和行为逻辑进行提前的思考，不然产出的文档可读性也很差。

第四坑——详细得臃肿

在写PRD时，为了想一次性把问题说清楚，让程序员能一次性把文档理解透。所以会把一个问题解释得很详细，从而使得文档变得很臃肿。

这不是认真，这其实是一种懒惰，因为想用文档砸给程序员，让他们自己去理解产品，不想和程序员进行过多的交流和文档解释。

其实在实际工作中，我发现有就算你写得再详细，如果不进行口头介绍，程序员想把如此臃肿的文档理解清楚也非常不容易。所以，如果能用流程图来表述，就不需要长篇累述；如果能先进行产品大致的介绍，让大家先理解整个思路，就不需要文字上过于累赘的表述。

产品文档应该做到“考虑全面，逻辑清晰，语言精练”

第五坑——文档排版不易读

原来才开始写文档的时候，完全不知道什么排版，在无数次打磨自己的格式后，开始对排版有了一点自己的理解。

如果说排版有什么技巧，我想可能是这几个：

以功能划分大板块，大板块标题醒目 把大板块简单拆分，并用小标题区分 用点号罗列观点 对于文档排版，统一文字格式后，做好以上几点就能确保文档基本整洁和可读性。但是排版是个长期打磨和锻炼的事情，必须要经常锻炼，才能有一套自己的合理的排版风格。

第六坑——重点内容不突出

重点加得非常随意，就会造成两个结果，重点不突出和重点不够重点。 所以，文档中应该标记重点，但也要注意：

重点最好为重要的动词、转折词、新名词和关键逻辑判定词等。 重点内容不在于多，更在于精，满篇重点则是没有重点。

第七坑——不用程序员喜欢的形式写文档

最后，特别重要的一点，也是不可不说的一点，那就是使用程序员容易理解的、喜欢的方式来写文档。

程序员更喜欢看到能用公式来展现各个数据或者信息之间的关系； 了解程序员编程的时候常用的逻辑，多以这种逻辑术语来写文档，这样程序员就更能理解； 多用分句，别用连句，一个分句表达一个意思就可以了。 能用配流程图的，千万别只写文字。

参考资料

https://www.toutiao.com/a6484380766481416717/

https://www.toutiao.com/a6394971740561506561/

https://www.toutiao.com/a6587653118945657348/

Kotlin 开发者社区

国内第一Kotlin 开发者社区公众号，主要分享、交流 Kotlin 编程语言、Spring Boot、Android、React.js/Node.js、函数式编程、编程思想等相关主题。

Kotlin 开发者社区