今天和大家聊一聊工作中最常见的产品需求文档，虽然各平台上讲PRD的文章很多，但我还是想分享一下我写PRD的心得。
方便阅读，大家先了解一下文章结构：
一、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里集成出来，根据时间排序。我以为开发做出来要么升序，要么降序，我都能接受。结果……
一千个读者，就有一千个哈姆雷特。
我们写文档的时候是站在产品的角度来看这份文档的，那么站在技术或测试的角度来看呢？
由于产品的功能或方案都是我们产品设计的，我们很清楚功能逻辑的关联，而技术、测试没有参与到方案的产出中来，所以他们就不清楚方案中的一些定义。
例如：之前做一个广场发布图书的功能时，添加图书页与另外一个功能中借阅的书页极其相似，于是我就偷懒了，在写添加图书页面的需求时，就简单写到页面参照借阅的书页，而这两个页面的开发分别是不同程序小哥写的，于是写添加图书页面的程序小哥又把我抓过去重新撸了一遍图书排序、排序、及异常情况的需求，最终我还是把添加图书页的需求重新写了一遍。
如何详尽各种情况？
刚开始做产品写文档时，我经常也会漏写很多的特殊情况，那时候被开发和测试拉到墙角怼得呀，提需求都只能蹲着提。后面研读测试用例后，了解了测试用例中描述的各种情况，后面在写的时候就采取测试思维，来检查文档中是否将产品中会遇到的问题都描述出来了。
3. 语义精准无歧义
语义精准包含两个层面的内容。
一是产品文档中避免出现概念模糊的词汇，如：似乎、好像、大概、可能、应该等等词汇，应该说一为一，不要给阅读者留下遐想的空间。
二是避免多个词汇定义同个东西。例如：常见的搜索栏，如果一开始就定义叫做搜索栏，那么在后文中，不可再给它取其他的名字，如搜索框、搜索条等等。
4. 文图搭配更易读
一份PRD文档内，肯定包含了大量文字描述，但是我们能用图表的地方，尽量用图表。一个图或者一个表通过少量的元素能传递大量信息，图表可将复杂的关联性可视化呈现，帮助读者快速理解内在逻辑。
例如注册流程的介绍，画一个简易的流程图比写个200字的需求易懂。
文末再说两句，写PRD的目的在于 降低团队沟通成本，统一将团队认知，推动产品顺利上线 ，不要因为偷懒而不写PRD文档。
