一份让研发同学爽的「PRD文档」，都有哪些内容？

“乖乖，一看你这个文档，我心里就有底了。”

我们都知道一份完整的PRD，面向阅读人群有：设计师、市场、运营、测试、研发、领导…那在实际工作中，真的会有这么多角色来看你的PRD吗？

其实，因为互联网快速迭代的原因（我曾经负责的产品每周发版），一方面阅读落到做这件事的研发头上，一方面PM也没有充裕的时间去思考和完善PRD中那些为了某些非核心阅读人员看的内容。

所以，我这里说的主要是：如何写一份看上去清晰，研发容易理解的PRD。

那么研发在看一份PRD的时候到底关注什么？经过这几年我与不同岗位、不同层级的研发同学深入沟通和交流，总结为以下几点：

1、为什么做这个？

团队中少数研发会很关心这个问题，他们不愿意盲目去写代码。

2、业务关系是什么样的？

这个功能涉及到的整体业务流程和系统架构是什么。

3、页面长什么样子？

页面很大部分决定前端的工作量，大部分后台同学也习惯于通过前端页面去评估。

4、数据从哪里来？

从后台来？从其它事业部来？还是从合作的第三方API拿？亦或是人工上传？

当然，研发同学肯定关注的问题不只以上4点，但一开始这4点说清楚了，基本上这个文档就很容易读下去了。

曾经一位研发总监给我一个建议：PRD先画一个整体流程图，不要一上来就说具体功能，不然很容易就产生“这个功能好复杂好难”的潜在心理暗示。我深表赞同！

那么接下来，就实际说一下，满足以上条件的PRD到底怎么落地去写。

先放一个文档结构图：

一、需求背景

解释一下为什么做这个需求？我们遇到的问题或现状是什么样的，我们做这个需求是为了解决什么具体问题的。尽量用大白话描述，不用太书面化。

这么几年工作下来，大概感觉是研发团队中其实不到50%的人在意这个需求背景，一大部分研发还是习惯于直接看功能描述，看怎么做，偏向于单纯的写代码。

二、产品目标

1、功能目标

描述一下这个需求具体要实现什么功能，这里的描述类似于一句话给别人介绍你这个产品。

2、数据目标

现在这个时代下，不关注数据的产品迭代行为都是耍流氓。你可以不完全依靠数据去做决策，但是必须知道你做的产品，核心衡量数据指标是什么吧？即所谓的OMTM（one metric that matters）。

建议这个指标不要超过3个，聚焦在核心路径上，甚至最好是只有1个。

三、系统架构&流程

这部分我认为主要是用来向研发同学传递以下2点内容：

1、功能的逻辑流程

基本等同于从用户使用角度的用例流程。

2、各个端之间的交互

前端、后台、算法等是怎么交互的。像机器人产品就更复杂了，大范围划分要涉及到客户端、机器人前端、机器人后端、服务器、语义平台、云平台等等。而某些机器人端功能更是要讲核心板和算法板也划分开。

建议是用泳道图的形式来表现这部分内容。

四、页面 & 功能结构

说白了就是功能的概览图，但是很多时候我们会面临：这个概览图是按照页面纬度还是功能纬度去划分。

我的建议是，根据这个需求的实际表现情况，如果涉及到超过5个以上大大小小的页面了，那么建议从页面纬度来划分功能概览；如果是主页面就涉及到2、3个，那么从功能以及功能分支维度划分可能更好一点。

当然，时间宽裕前提下，还是建议从2个维度画一下。建议用脑图工具来呈现，Mac端我最喜欢用的脑图工具非MindNode莫属（链接: https://pan.baidu.com/s/1pKASFHp，密码: chgi）。

五、最小化功能描述

这部分你就要开始详细的描述一个功能点了。我一般会从以下几方面来描述一个功能点。

1、功能简介：一句话说明这个功能要完成什么操作；

2、原型图：如果有设计稿就直接放设计稿截图部分；

3、入口：主要入口在哪里？同时要多想一下用户还可能从哪些地方进来，比如APP可能有PUSH消息直达；

4、前继条件：进入此功能需要满足什么条件吗？有什么必须带入的参数吗？等等此类说明；

5、页面或功能包含元素：事无巨细的列出这个页面或功能由哪些元素构成；

6、每个元素的属性和作用：纯文本元素还是文字链？是否可被点击；

7、整个页面和功能的交互规则：点击某个元素会触发什么操作等描述；

8、数据内容从哪里来：从后台调取还是前端写死？前端写死的话此处要附上文案。

对一个功能如果以上8点描述清楚了，我相信基本就可交付开发了。

当然，在这几年实际迭代中，我发现在PRD交付后，项目后期或者测试期间，最容易被问到的问题就是：没数据了怎么办？数据太多了怎么显示？

此类问题，每次写都嫌弃麻烦，但是不写的话测试同学可是会给你提BUG的，况且还会影响产品功能和项目进度。建议勤快点，此类问题提取出来作为公共规则，在公司内部建立公用文档，每次需要的时候直接超链在PRD中即可。

以上希望对一些同学有帮助，如有其它写作PRD的实战经验，欢迎交流。