产品汪07：产品经理如何写好PRD文档

PRD是什么？有什么用？

PRD是Product Requirement Document的简称，其中文翻译为：产品需求文档。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。

PRD的主要使用对象有：开发、测试、项目经理、设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑，测试可以根据PRD文档编写测试用例，项目经理可以根据PRD分解任务并分配工作，交互设计师/UI设计师可以通过PRD来完成相关设计，培训人员可以根据PRD文档来制作培训文档，市场人员可以根据此文档来撰写新闻稿/微信公众号宣传文章，PRD文档的重要性不言而喻。

图.根据PRD制定的开发计划（有部分删减）

PRD用什么工具写？

常见的PRD写作工具有：Word、Axure，不常见的有Excel、PPT、Visio等。

我2007年刚入行的时候公司（北京金山软件）基本都不写，直接拿Visio画原型然后给开发和设计师各讲一次。后来逐渐开始用Word来写，近些年来行业里比较流行Axure来写，左边是页面原型，右边是需求/交互/业务逻辑说明。

因页面缩放原因，右侧需求说明文字有重叠

但这么多年下来，我个人还是比较习惯或者推崇Word方式来撰写。PRD用什么来写，没有最好的，只有最合适的，每个人所在的公司背景都不一样，大公司要求文档规范细节到位，小公司可能只需要记录关键信息，剩余的靠口头沟通，甚至都不需要文档。

但我要重点强调的是：PRD拿什么写无所谓，一定具备良好的可读性。我见过有产品经理用Axure写的，整个文件横向纵向各种拖动，看的人崩溃。我也见过订单结算页面使用平台红包、卖家红包、卖家优惠券的业务规则/逻辑说明用了整整3页纸将近1500余字的，这个开始写在了Axure里面，后来可读性太差，最后改成了Word文档的。

PRD怎么写？

一份PRD应该包括但不限于以下部分内容：需求背景、需求描述、流程图、WBS、页面及功能、交互接口、迭代记录、其它部分等。

1.需求背景

简单了说就是：现状是什么样，为了解决什么问题，期望达到什么目的。

展开了说就是：要阐述为什么要做这个需求，是新增的功能还是已有功能的优化和完善？是为了解决用户的哪些问题，满足用户的哪些需求？亦或者是公司高层的拍脑袋决策？这个需求才做到什么程度，达到什么阶段性的目标？这样才便于PRD阅读者快速了解整个项目的梗概。

• XX电商网上线至今已1年多，还没有形成一套客观的、可量化的评价系统来对卖家进行约束、促进和规范。而评价系统对于XX电商网、终端店（买家）和经销商（卖家）三方具有重要的意义。

• XX电商网：评价系统是电商网站的标配，XX电商网需要这样一套评价系统来了解经销商的真实经营情况和买家反馈情况，约束卖家诚信经营、督促其用心服务，提高服务水平和质量；同时也可以为后期搜索和推荐/排序等功能奠定基础（电商网站的搜索结果排序有很大一部分来自于评价/评分）；

• 终端店：买家可以根据评分和评价来选择卖家（二期功能），进而督促卖家提高服务质量和配送效率（有多个卖家可选的情况）；可以获得积分或虚拟货币奖励（拓展功能）；

• 经销商：可以帮助省级/市级总经销商了解下级经销商（二级或三级经销商）真实的服务/配送情况，便于对下级经销商做评估和考核；同时也可以帮助经销商了解业务员、配送员真实的工作情况，便于发现工作环节中的缺陷和不足，进而对各职能部门进行约束、规范和促进；

2.需求描述

简单了说就是：到底做什么，有哪些大的功能模块或者通过哪些方式来实现前文业务背景里面描述的问题。此处的篇幅不宜过长，但需要通俗易懂，避免使用过多专业术语。还是以XX电商网的评价系统为例。

完成评价系统的基本业务模型搭建，即买家（基于订单）评价，卖家查看/管理评价，运营平台可以查看经销商的所有评价信息和评价数据统计；

交易平台：

1. 买家可以针对已完成订单进行评价（含评分、评论）；

2. 买家可以查看评价、可以追加评价；

3. 评价管理：卖家可以查看评价数据统计，可以查看所有买家给的评价信息；

运营平台：

1. 评价数据统计：可以查看全部经销商的评价数据统计，可以按名称，经销商区域和满意度区间进行筛选；

2. 评价内容管理：可以查看所有买家对卖家进行的评价和评论信息，可以按照名称／订单号、评价时间和满意度等信息进行筛选/搜索，可以对有图片的评论进行审核；

中长期目标：评价系统在具体业务中的运用，比如评分和评价内容在商品或者商家详情页显示，在搜索结果中影响排序结果等（本期先不做，但系统设计时需要考虑到后期的扩展）；

3.流程图

俗话说一图胜千言。有些功能无论你通过怎样的文字来进行阐述或者说明，都不如几张图来的简洁明了。产品经理在平时描述业务流程时常用的图有流程图、时序图，学有余力的话还可以了解一些泳道图、类图等。

下面是在XX电商网终端店用户在注册审批时用到的泳道图，仅供参考。

下面是货到付款订单增加买家取消功能用到的流程图，进攻参考。

4.WBS

WBS是工作分解结构Work Breakdown Structure的英文首字母缩写，其是项目管理重要的专业术语之一，WBS将交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。

别人家的WBS是长这样的。

我司现有的WBS是长这样的，将所有的功能点罗列并形成表格形式，使阅读者对于此需求的功能点总体上有个基本的了解。以下是订单结算页优化的WBS；

5.页面及功能

这一部分是PRD的主体部分，详细的描述此需求包含哪些页面，每个页面的布局，具备哪些功能，每个功能的规则是怎样的。PRD的读者通过这部分的阅读，可以说基本清楚此次需求到底是做什么的，详细的规则是怎样的。

这个时候我们一般以页面为维度来进行详细的需求说明撰写，撰写的时候一般是先贴图，贴图来自于Axure原型，贴图要能体现该页面包含哪些元素，文字/按钮/图片的位置和比例等。然后就是页面元素的说明，我们会从上到下从左往右逐个元素进行规则交互的说明，见下图所示。

虽然上图写的是交互规则，其实里面还有业务规则。

每个产品/功能点在开发时都有相应的业务规则，PRD需要将这些规则清晰完整的描述出来，让开发、测试人员能够看的清楚读的明白，且没有产生歧义。

业务规则如果比较复杂，则建议配上截图或者流程图。另外页面的输入框、下拉框等等，则需要对于其内容格式、长度、默认值等等做出说明，什么时候可见，不可见，灰掉或点亮的条件在文档中都给出说明。

异常情况：之前听过一个观点觉得很有道理。PRD把正常业务规则写完整不难，但把所有异常情况考虑全却不简单。后文有专门的讲述，此处不赘述。

6.交互接口

《西游记》里唐僧每次介绍自己都会说：“贫僧唐三藏,从东土大唐而来,去往西天拜佛取经”。这几句话包涵了每人都要问自己的三个问题：我是谁？我从哪里来？我要到哪里去？这句话用在产品（开发人员）身上也同样适用：我是谁（在哪个页面）、我从哪里来、我要到哪里去。

换做开发人员的视角，他们比较关注的是：

• 我是谁：用户需要输入什么，在哪里输入，输入方式是什么？输入的内容是否有限？应当被如何检查？页面显示什么？数据怎么加载、怎么缓存、怎么刷新？

• 我从哪里来：用户从哪里进入到这个页面？怎么来的？是否可以相互转移（单向还是双向）来的时候有哪些数据一起跟着来的？数据从哪儿传送的？

• 我要到哪去：用户从这个页面会去向何处，哪些数据会跟着一起去？数据怎么传送（提交/上传）？相应操作之后会有什么交互事件？页面会发生什么样的变化？会影响到哪些页面或功能？

当然大部分产品大部分情况无需过多的关注交互接口相关的东西，但如果是程序猿转产品经理的，可能会关注数据交互相关的内容。

7.迭代记录

PRD从第一版诞生以后，经过多次需求评审、内部评审、设计评审、用例评审、开发（接口）评审等环节，对于页面布局、功能点多多少少都会有修改或变化，当时可能通过邮件、会议纪要、微信群聊天等来说明，但如果不整理到需求文档中，时间长了，或者是项目人员变动，可能就没有人知道这部分需求最终的实现方案了。

因此，PRD迭代记录也是非常重要的一部分，记录下每一次讨论后需求的变化点，帮助各方使用者及时了解需求变化，以及对最终的实现方案做记录，方便阅读人员及时找到修改后的内容，直观的了解修改原因。

8.其它部分

以上只是PRD比较核心或主要的部分，其实PRD还有一些其它内容，例如：

1)相关影响点

2)非功能性需求

3)角色权限需求

相关影响点

没有任何功能是独立存在的，其或多或少都会与其它系统发生关联。这就要求PRD文档在撰写的时候需要指出这些影响点，并给予解决方案。

非功能性需求

我司对于非功能性需求的要求包括页面性能、监控和兼容性3方面。然后根据功能模块和平台的不同，又可以细分为以下部分：

角色权限需求

部分产品或者功能点可能会涉及到角色权限部分，比如哪些人可以使用这些功能，有什么条件限制等等。

本文章收录于我的电子书《从零开始做产品：产品汪》