PRD:如何写一份程序员爱看的需求文档？
2017-09-06 dreamer 开课吧产品100
PRD的作用就是，把需求白纸黑字外加图像的生动明确的表示出来，便于技术开发；便于需求的更改，便于需求的记录；便于需求沟通。对于用理性思考问题的开发来说，你用需求文档把问题都说清，可能比你追着他问进度更有效率~
产品经理的生涯中，肯定遇到过如下的痛点吧：
- 含辛茹苦地写完了需求文档（PRD），开发人员却将文档束之高阁（一万只草泥马在你的后脑勺奔腾而过……）；
- 开发人员反复来回地确认需求、细节逻辑等，问的你一脸懵逼，只能默默地去修改文档；
- 开发完成，进入测试阶段，想着一锅香喷喷的米饭就要上桌了，打开一看，居然是热腾腾的一锅粥～；
以上问题之所以会发生，主要的罪魁祸首当然是你的需求文档：
- 文档不简洁明了，读起来吃力，给到开发，犹如给他们吃了安眠药，开发当然不爱看。
- 文档的功能需求描述不清晰、逻辑不严谨，开发需要反复确认、浪费了大量时间，最后让开发对你越来越不信任（产品狗，你过来，我保证不打死你……）。
- 没有很好的把控进度，项目跟不紧，中途容易出问题，产品难以达到预期。
那么，如何写一份用户体验好、开发喜欢看、靠谱的需求文档呢？笔者将从以下几个方面展开阐述：
❶
产品简介
1.简要说明产品的使用价值
- 我是谁（一两句话写清楚产品的身份）？
- 我有什么用（我是做什么的，我能提供什么服务等）？
- 为什么选择我们（与竞争对手相比，我们产品的优势，核心竞争力是什么）？
2.目标用户、使用场景
- 产品的主要用户群是谁？
- 用户主要在什么场景下使用我们的产品。
❷
行业概要
- 简要阐述行业现状
- 未来的发展趋势
- 竞争对手情况分析
补充：如何快速了解一个行业？
1.通过艾瑞咨询、易观等网站查看行业的分析报告，深入了解整个产业的上下游结构；
2.通过商业模式画布工具，分析行业主要玩家的商业模式
❸
版本
按照版本来分类，点击版本链接可进入查看每个版本的文档。
文档的第一页如下图：
1、排期
每次的大版本开发，最好对应有一个排期表（与开发沟通确认时间的安排），开发过程中，根据进度情况，适当调整时间安排。
开发人员可以根据自己负责的模块，进入排期详情查看当天的任务，完成的模块可以进行标记，如图。
2、产品设计（重点）
实体关系图
当你做的产品是从0到1时，为了让数据库的开发人员更快速的了解你的产品，实体关系图（E-R图）将会发挥很大作用，数据库的开发人员可以参考此图来做数据表结构的设计（具体这里就不说了，大家可以网上详细了解E-R图）。
厂家、经销商、客户等这些都是属于实体，实体包含的的属性（字段）最好也要写出来，如下图举例：
用户角色权限表
涉及到角色和权限的，需要做一份全面的角色权限表格，方便开发人员参考。
业务流程图
通过业务流程图，可以在大方向上知道产品的整体逻辑，业务流程图拆解可以得到任务流程图，任务流程图拆解可以得到页面流程图。
全局说明
一些通用的控件、状态等，不需要每次都说明，比如空数据、网络异常、加载失败、刷新状态等等，只需说明一次即可。
需求、功能、交互说明
很多人在写功能说明、交互说明时，总是会遗漏一些细节，逻辑不严谨。从以下几个维度去说明，将会让你考虑的更加全面：
- 字段、字段说明、数据来源
- 前置条件、排序机制、刷新机制
- 状态流转（一个页面可能有多个状态，需要说明）
- 交互操作（正常操作、异常操作）
下面，笔者将以一个页面做举例说明：
产品设计模块里的结构如图：
（为了方面查看以及和视觉页面的对照，每个页面需要标注编号）
3、非功能需求
埋点需求
页面的打开率、按钮点击率等，如果需要记录，则需要做说明。
埋点是数据分析的基础，建议使用“GrowingIO” 这个工具进行可视化埋点，操作简单、方便，能减少很多的工作量。
性能需求
请求数据的响应时间要求、并发数要求等。
兼容性需求
系统版本的支持、多终端的支持、浏览器的支持等。
4、修改记录
文档的第二页如下图：
为了让开发人员更方便的浏览，增强阅读体验，使用markdown语言来辅助写需求文档是最好不过了，浏览体验会大大提升。
在公众号发送”文档”，即可查看笔者用 “markdown语言” 来做的需求文档结构模板。
好了，本次分享到这里，感谢您的阅读。
文/ dreamer
来源/微信公众号：拳头产品
「今日互动」
主题：说不清听不懂
其实产品和开发之间的羁绊就是这份需求文档，有的时候产品经理会觉得开发的效果有问题，所以要改改改；有的时候开发会觉得产品经理的需求根本没说明白，导致最后改改改。这时候写好一份PRD就尤为重要，把沟通得桥梁搭好，就会省下很多事。小伙伴们，你们在写需求文档的时候，为了表述清晰都会注意哪些问题呢？
欢迎在文章下方留言，大家踊跃发言，说说你们的想法吧~