1.  文档能力是产品经理最基本的能力之一，学生时代我们写的日记、作文、报告，以及论文等，都是在以不同的形式输出文档。实际的产品工作中输出产品文档的过程，本质上是把自己的产品逻辑进行文本化的描述的过程，最终目的是让阅读对象能清晰的阅读并理解，产品相关文档撰写并不需要产品经理拥有很强的文字驾驭能力（当然有这种能力是更好），只要掌握基本的文档撰写方法、思路和规范就能写出合格的文档。<br />(PS:个人愚见：年幼时为了追求所谓的高分以及老师的赏识，一味地在文章中使用各种华丽的辞藻。但一篇整整有价值的文章取决于是否有缜密的逻辑和清晰的框架。<br />小时候的文章追求各种华丽辞藻的思维就是为了得高分，为了得表扬去的，真正一篇好的文章的判断与否取决于文章是否有强大的生命线以及缜密的逻辑）

啥才算PRD

PRD，即需求记录文档。
PRD应该写什么内容？该怎么写？有没有通用的标准，什么工具去写比较好？这是很多产品同学面临的一个问题，我的格式是否正确，为啥上次和这次所需要的结构还不一样。一发现需要和别人进行协同，就会或多或少发现缺陷遗漏，然会回头还得一个劲补充修改。

但是，产品经理有一项优秀的能力，即借鉴思维（产品经理的事儿，怎么能算抄呢），凡事遇到麻烦先询问百度呀，可是不管是百度还是各大博主，给出的PRD模板五花八门，有些许相同但又不完全一样。不管了，先套一下，完成任务再说。然后下一次，咱们又迈上百度查资料或者努力翻出之前的文档内容，诸如此类重复低效的工作中。这样的方法谈不上错误，但是绝对是不利于个人发展的。

怎么才能写好PRD

每次看到“怎么才能”字样的问题，我都喜欢下意识地将这句话换一句话来思考：为什么要？比如题目中，“为什么要写一份好的PRD”，换一句话，其实就是希望抓住这件事背后的目的/本质是什么？

为什么要写一份好的PRD，那得思考一下产品的工作职责是什么样的，产品经理的主要工作从本质来说无非是两点，一个是判断需求，另外一个就是粘合团队。落实到实际工作中则为：1.收集，分析，筛选需求 2.将需求以某种方式传递给团队的其他人，包括研发，测试，UI等等。

所以，为什么要写一份好的PRD的答案可以这样回答：PRD是将产品经理思考的内容用文本和图形的方式呈现出来，核心作用是准确地传递需求。

一份PRD里应该都包含什么

清晰地认识到产品的工作职责以及明白PRD的作用就是为了传递需求之后，我们来理一下一份PRD模板的内容：
xiaopiu :这是原型工具xiaopiu给出的一份产品PRD模板：

image.png
版本修订记录：告知查阅人每一次改版的责任人是谁，是谁修改的需求/原型，是什么时候改的，记录改的地方时间状态，方便回档，避免了和开发吵架时候只是口说无凭的状态。

版本记录/版本说明：清晰反映出每个版本的具体内容，是否上线？责任人是谁？时间节点是否会延期？同时每个版本遇到什么问题以及解决问题的概况性记录，都可以记录在这里，这样做的原因在于，针对每个版本的问题在复盘的时候能够有一个很清晰直观的认识。

image.png
使用说明：名词解释可以算是使用说明的一部分。使用说明中得包含一些文档涉及的范围以及一些边界的内容阐述（比如，哪些是我的活，哪些是项目经理干的，又比如文中哪部分是高度不可泄密的），以及对需求中特有的名词进行解释，避免产生歧义。
image.png
全局介绍：给团队里所有人一个清晰的认识，阐述项目的目标，需要遵守的规则，产品的需求，亦或者客户的需求，让团队的意识处于同一战壕中，避免发生：客户想建小别墅，产品设计出来一个摩天大楼，测试理解为客家土楼，最后开发开发出来一个碉堡。
image.png
image.png
需求清单，需求变更记录：需求清单以及需求变更是产品经理经过收集，分析，筛选之后得到的清单，结合需求用户或者客户，列出各项需求的优先级，项目经理这时可以根据优先级，进行归类分析以及进一步风险评估。同时，也避免了产品遗漏某个功能或者需求的风险发生。
image.png
功能列表：功能列表中会包含 ：告诉开发，我们会有多少个应用端，有哪些模块和功能，每一个功能要去怎么样实现，有什么限制以及特殊需要在里面，每一个模块的优先级等等

角色列表，权限列表：这两项通常可以放在一块，角色列表告知开发和测试，系统中包含多少种角色，每个角色的权限范围在哪，是否有交叉，角色之间的层级关系是怎么样的等等，而权限表则告知，系统中会有多少种权限，每一项权限能干什么，不能干什么。

image.png
框架图：框架图可包含信息框架结构图，功能架构图等等，目的就是让大伙对产品有一个整体框架上的认识。

流程图：流程图中可能包含数据流程图，业务流程图等等，制作流程的过程中，产品也相当于替客户，开发梳理了一份逻辑性很强的结构图，避免了很多不必要的返工以及撕逼。

image.png
原型图：将抽象的需求以及功能具象化，变成可视化的页面，让团队成员对产品会长啥样有一个提前的认识。

image.png

image.png
其他要求：清晰表述特别的要求，如性能要求（负载均衡、响应时间）、安全要求（防火墙、非对称加密）、复用要求（模块化低耦合高内聚）等。

扒一扒PRD的背后

上面简单地介绍了一下各大模板都会有的内容，有些同学还是有疑问，问题也五花八门。有的说他们公司流行用Excel写PRD，有的同学说他们是初创公司，备注什么的都直接写在原型文档上了，开发遇到不明白了再直接询问，PRD文档技术都是闲暇时间才去看看的，面临写完没人看的苦难情境。还有的是玩敏捷的同学，甚至没有文档的概念，一张白纸，一只笔，就可以阐述需求。

其实回顾上面PRD中包含的内容，发现PRD不仅仅只是一个记录需求的文档，有时更像一个明确每个人的工作职责的文档（谁的锅自己背好），我可以把PRD背后的逻辑本质理解为：消除信息差，记录有歧义的内容。

比如你的团队就俩人，是不是只要产出一个原型就够了呢，比如开发对边界以及权限的边界，那是不是权限部分就可以少写一点呢，把时间花在大家有认知歧义的地方呢？比如密码的设计，运营觉得四位够了，减少客户的流失几率；研发出于严谨，希望是八位，并且需要大小写混合；最后产品同学出于经验，决定折中，六位且包含数字和英文。

当我们想明白了，为什么写PRD，以及PRD写的到底是什么，是不是发现选择模板的时候，思路瞬间清晰不少呢？