程序员喜欢什么样的需求文档（PRD）？

程序员喜欢什么样的需求文档？

那肯定就要从程序员的需求以及PRD这款产品的“定位”说起。

先来思考一个问题：也就是谁会查看我们的PRD。

大概分为4类：，这些人组成了PRD这款“产品”的。

UI关心什么内容？关心页面布局样式，对不对？所以在PRD中要把原型图罗列清楚；客户端开发关心什么呢？关心页面布局及跳转逻辑对不对？其实也就是PRD中的信息和交互这两部分所呈现的逻辑。服务端开发是提供数据的，所以来源，状态，边界等内容是写给服务端开发看的。测试呢？测试关心前后端的所有逻辑，因为要以PRD为准梳理测试用例。作为产品经理，我们的每一个产出物你都要把他当做自己的产品，去优化用户体验。

接下来给大家分享一个被很多公司借鉴的PRD写作方法以及“模板”。

为了更好的讲解产品说明文档的撰写方法，我们以京东的PRD撰写方法为例。但是必须需要说明一下，PRD的写作宗旨是：，所以只要能达成该宗旨的PRD模板都是OK的。

京东功能型产品经理一份完整的PRD，一般会包含以下几个部分：

第一个：项目概述

包含项目背景和项目目标，即为什么要做这个需求？做完之后希望达到的目标是什么？等等。这一部分有助于让项目参与方和其他对项目感兴趣的角色更好的理解需求的来龙去脉。

【为了帮助大家更好的求职产品经理，我梳理了一份求职大礼包，包含：1、社招&校招简历模板（可编辑版）；2、经典面试必备10题及解析；3、四款经典软件安装包及教程（Visio、Xmind、Axure、Sketch）;4、京东产品说明文档（PRD）模板；5、两大产品经理群面技巧；6、十本经典图书礼包。可以通过私信或者家威：xuelaoban667，免费领取】

第二个：修改记录

修改记录会包含下面几个信息：

版本是指PRD修改的版本，一般每修改一次PRD都要更新一下版本；

在此部分直接撰写PRD的修改或者更新内容即可。由于PRD整体内容偏多，直接将修改内容体现在这一部分，可以大大提高相关参与方检索信息的效率。

因为各种原因，比如多个产品经理负责同一个功能或者产品离职，都有可能存在一份PRD多人更新的情况。所以修改人这一栏有助于文档的阅读者产生问题时，直接定位相关责任人进行沟通。

即产品经理每次更新内容的时间，对于产品经理自己定位修改内容大有帮助。

第三个：需求列表

京东产品经理每次迭代输出PRD之前，先跟直属领导过一遍需求列表，确定这一个版本要做的需求有哪些。然后，才开始通过脑图、流程图、原型图梳理产品逻辑。原型图梳理完成之后再跟领导过一版方案，确认没问题开始写PRD，所以需求列表起到需求总览的作用。

需求列表一般会包含这几个信息。

其他几项信息非常好理解，重点说一下优先级。当项目着急上线而研发资源不足的时候，一般通过优先级的方法让研发先做优先级高的需求，从而保证项目能够按时上线。

大部分公司都是用T1/T2来标识优先级，而T1的优先级高于T2，至于哪个功能优先级更高，这就需要产品经理按照用户价值以及实现难度等维度去衡量了。

即4.6中梳理的流程图，放到PRD中可以让相关方从宏观上了解核心的业务的关键节点。

即4.7中梳理的产品结构图，放到放到PRD中可以让相关方从宏观上了解产品/功能的布局逻辑。

第六个：功能描述

当相关方从宏观上有个大概了解以后就开始进入了对于功能细节的了解了，即第六部分功能描述中我们需要把每一个功能的详细逻辑（包含前端交互逻辑、服务端逻辑、算法逻辑等）都要写清楚。这是PRD最核心的部分。

在撰写每一个详细功能的详细逻辑时，建议大家按照等6个维度进行梳理，这样可以保证产品方案更全面。

即每个页面上可视化的所有信息元素，包含可以点击的和不可点击的部分；

即点击或者滑动有反应的地方，需要在此部分将交互跳转逻辑是叙述清楚；

即元素的个数限制。比如以朋友圈为例最多可以上传9张图片，这就是图片数量的限制；还比如微信群语音通话最多支持9个人同时在线，这就是一个人数的限制。

每个实体元素的状态类型。比如电商中的订单状态会分为待支付、已支付、待发货、已收货、待评价、已评价等等；还比如约骑活动会存在可报名、已报名、已结束等状态。当然，有些实体元素是没有状态的，那这时就可以不写状态。

即元素的数据来源。比如轮播图一般是运营人员在运营后台配置的，所以轮播图的数据来源是运营后台；还比如电商网站中优惠券各项信息是从优惠券后台获取的，所以优惠券的各项信息元素来源是优惠券后台。在大公司中业务系统及其复杂，分别由不同的团队负责，作为产品经理将各项数据来源梳理清楚之后，可以极大的提升研发的开发效率。

当然针对中小型公司，系统相对简单，在撰写PRD可以考虑不写来源。

是指极少数情况下才会出现的场景。比如绝大多数用户在使用百度搜索内容的时候，都可以匹配到相关的内容，这是正常场景。但是约有0.4%的用户在搜索某些特殊内容时，如下图所示，百度无法匹配相关内容，即为异常情况。

在此类异常情况下，作为产品经理需要给出对应的产品方案。比如百度产品经理给出的方案是，先给出一句文案说明没有搜索到相关内容，再给出温馨提示和相关搜索，引导用户找到需要的内容。

下面以骑友APP首页的轮播图为例，讲解这6个维度是如何在PRD中体现的。

第一步，先把活动卡片上的信息元素罗列出来；第二步，然后再考虑该功能存在哪些交互行为；第三步，撰写元素来源；第四步，定义展示数量限制；最后一步，输出异常场景下的产品方案。由于活动图片不涉及到状态，所以在详细逻辑中没有状态一栏。

同时，做到图文对照，每撰写完一个页面的逻辑，把相应的原型图贴到下面，这样研发、测试、UI看PRD的时候如果对文字描述不理解，可以和图片对照一下，极大的降低他们的阅读成本。

以上就是京东产品说明文档的写作框架及撰写方法，不一定具有普适性，大家重点学习思路即可。