关于如何写一份优秀完美的PRD，文章多的数不胜数。我今天结合自己这几年的迭代经验浅谈一下自己对PRD写作的理解和思路。

为什么强调“落地”这个词呢？很简单，我们都知道一份完整的PRD，面向阅读人群有：设计师、市场、运营、测试、研发、领导......，那在实际工作中真的会有这么多的角色来看你的PRD吗？（可能有一些迭代周期长的大项目大家都会看），实际中因为互联网快速迭代的原因（我曾经负责的产品每周发版），一方面阅读者很具体的落到做这件事的研发头上，一方面PM也没有充裕的时间去思考和完善PRD中那些为了某些非核心阅读人员看的内容。

所以，我这里说的“落地”也可以解释为：如何写一份看上去清晰，研发容易理解的PRD。

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

为什么做这个？团队中少数研发会很关心这个问题，他们不愿意盲目去写代码；

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

页面长什么样子？页面很大部分决定前端的工作量，大部分后台同学也习惯于通过前端页面去评估；

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

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

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

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

先放一个文档结构图：

依次会谈一下我对写作这样一份PRD的浅见。

（以下为PRD正文内容了）

---

1 需求背景

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

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

2 产品目标

2.1 功能目标

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

2.2数据目标

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

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

3 系统架构&流程

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

(1)功能的逻辑流程，基本等同于从用户使用角度的用例流程；

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

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

4 页面&功能结构

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

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

当然，时间宽裕前提下，还是建议从2个维度画一下。

建议用脑图工具来呈现，Mac端我最喜欢用的脑图工具非MindNode莫属

没有用过的同学可以下载体验一下：链接: https://pan.baidu.com/s/1pKASFHp 密码: chgi

5 最小化功能描述

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

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

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

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

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

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

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

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

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

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

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

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

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