一、PRD概述

1. 什么是PRD?

PRD在百度百科中的官方解释为：PRD为Product Requirement Document的简称，其中文翻译为：产品需求文档。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。

当然，这个定义针对的是一个全新的产品。广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。

我对PRD的正经理解为：在一个群体内一个相互达成共识并形成规范的描述需求的东西。它的形式可以是word文档，可以是Axure原型，也可以是一段视频等等，只要我们能把我们的需求清楚无歧义的向使用对象表达清楚即可。

我对PRD的歪解为：产品自我梳理的甲胄，与开发撕逼的武器。每一次产品经理写PRD都是对产品进行再次梳理，以前很多没想清楚的地方，写着写着就明了了；若不写文档让开发做，做出来的产品效果不理想谁来负责呢，若这时候有产品文档则有踪可寻，产品就不用当背锅侠啦。

2. PRD谁来写？

PRD正常是产品经理来写的，但有时候需求方（运营、市场等）也会直接出需求文档。

3. PRD给谁看

PRD的主要使用对象有：开发、测试、项目经理、UI设计师、交互设计师、运营及其他业务人员。

开发根据PRD获知整个产品的逻辑；测试根据PRD建用例；项目经理根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档。

二、如何写好PRD？

一份可读性高的文档遵循的基本原则为：文档结构有分类，事无巨细要详尽，语义精准无歧义，文图搭配更易读。

1. 文档结构有分类

一份PRD就是一个小产品，搭建一个有层次有分类的文档结构可以帮助阅读者快速了解文档的思路及容易阅读。

一般我写APP产品的文档时，根据模块-子模块-功能-子功能-页面的结构来搭建产品结构。描述页面需求时顺序：从左到右，从上到下；先讲正常状态流程，再讲异常状态流程。

例如常见的产品模块中有：流程图、产品功能需求描述、用户角色描述、产品逻辑说明等等。每一个模块下面又可进行很多的分类，例如：产品逻辑说明可分为功能逻辑、交互逻辑、视觉逻辑、技术逻辑、业务逻辑；流程图可分为业务流程图、页面流程图、任务流程图等等。

2. 事无巨细要详尽

详尽意味着我们在文档内要把产品里可能发生的一切情况描述出来，包含页面逻辑、交互逻辑、数据逻辑等等。

经常我们在写文档时，会出现这样一个情况，我们认为很常见很简单的逻辑，开发测试他们肯定都懂，那就不写了吧，然后这个地方开发的时候就出问题了，为什么常见简单的逻辑能出现疑义呢？

例如：之前在做一个年份选择功能时，我就简单的写了一个需求：年份从XX里集成出来，根据时间排序。我以为开发做出来要么升序，要么降序，我都能接受。结果……

一千个读者，就有一千个哈姆雷特。

我们写文档的时候是站在产品的角度来看这份文档的，那么站在技术或测试的角度来看呢？

由于产品的功能或方案都是我们产品设计的，我们很清楚功能逻辑的关联，而技术、测试没有参与到方案的产出中来，所以他们就不清楚方案中的一些定义。

例如：之前做一个广场发布图书的功能时，添加图书页与另外一个功能中借阅的书页极其相似，于是我就偷懒了，在写添加图书页面的需求时，就简单写到页面参照借阅的书页，而这两个页面的开发分别是不同程序小哥写的，于是写添加图书页面的程序小哥又把我抓过去重新撸了一遍图书排序、排序、及异常情况的需求，最终我还是把添加图书页的需求重新写了一遍。