如何写出一份优秀的PRD-文档篇

没有看如何做写PRD准备的朋友，可以跳转：

如何写出一份优秀的PRD-准备篇

上回讲到PRD撰写前的准备工作，包括摸清PRD的目标用户的习惯，深入了解本次用户的需求，根据INVEST和MVP原则、按照业务流程做功能拆分。

本次继续讲撰写PRD的具体技巧，如何能够写出一份自己和团队都能够读懂的PRD。

1. 通用建议

写PRD有一些通用的tips，可以让你的PRD更易于阅读。

1.1 提供流程图

除了上传自己在准备阶段梳理的整体业务流程图，如果某些Story的功能仍然比较复杂，那么也应当梳理出流程图，帮助阅读者对story有个全面的理解。

1.2 使用专业、共识词汇

专业词汇可以分为IT行业通用词汇和行业词汇，需要你在工作和团队沟通中不断积累。比如：

• IT行业通用：

• 行业：流量、焦点小组、UGC、PGC、OGC、KOL等。

• 设计：banner、按钮、滑块、输入框、单/多选等。

• 前端开发：JS、CSS、HTML、WEB端、移动端、URL等。

• 后端开发：API、数据库、SQL、解耦合、并发、同步/异步等。

• 测试：冒烟测试、黑/白盒测试、bug、回归测试等。

• 数据分析：PV、UV、visits、点击、转化率、漏斗、用户画像等。

• 行业词汇：因不同行业而异。比如电商、社交、在线教育等都有各自的专业词汇。

共识词汇：指的是团队合作中大家常用的沟通用语。很多大厂的共识词汇甚至可能演变成行业通用词汇，即“互联网黑话”，比如赋能、拉通，组合拳、闭环、颗粒度等。个人不太喜欢这些词汇，有点过于滥用了。

1.3 提供概念词典

当你文档中出现一些不常见、复杂、有歧义的词汇时，建议列出你的概念并进行严谨的解释。放到“需求描述-业务规则”中最佳，方便阅读者在了解需求时对照查看。

1.4 使用在线文档

PRD最好写到在线文档中，与使用word等离线文档相比好处非常明显，更新之后开发、测试可以直接阅读最新的文档，不需要产品先发送文档，开发、测试再下载更新。

现在在线文档的种类非常多，并且功能越来越强大、体验也越来越好，并且很多提供了历史版本的功能，方便对比查看。

2. PRD的结构

日常迭代的PRD，内容我一般写的比较简单。包括：

• 版本说明

• 需求背景

• 业务流程

• 需求列表