一份好的产品需求文档，能够让产品人员全面的从整体到细节的，再次梳理和确认产品的重要步骤；也能够让研发人员非常清楚的了解，项目的背景、预期、以及产品的细节，尽可能全面的把产品各方面实现的，可能存在的问题都列举做出说明，提高开发效率，节省不必要的频繁沟通。
刚开始做项目时，我总是以为只要原型一画，和大家开个会一说，然后研发们就开始搞起吧。结果你会发现，这之后你每天都陷入各种答疑解惑的忙碌之中（临时召集研发开会做说明，指望他们能在两三个小时里把所有细节都记住？别做梦了）。
而有些开发也不好意思频繁的找你，就直接按照自己的思路做了，然后你就坐等验收的时候各种吐槽，提bug打回修改。结果导致项目需求延期，公司研发成本增加。
然后我发现，PRD文档真的省不了。
知道了PRD的作用，那么永远不要问如何做好一份PRD，而是——如何表述清楚你的需求？
01 文档具备可迭代性
铁打的文档流水的兵，一个好的需求文档就像一锅好卤，是越熬越香。
不论谁来接手正在进行中的项目，都能够一目了然的知道项目的前因后果：什么背景啊，每次调整都是为啥啊，哪个产品什么时间主导的啊……就像一份更新日志，记录着项目需求变更的每一次变化。
02 文档说明要尽可能的细致
产品模块以及细节介绍的部分，需要根据已有的原型稿有图有字的做出说明。文字部分主要针对某个模块或者界面详细的做出标注和说明。
如果描述性文字不足以理解，这里需要举几个例子给研发做出形象化的解释。
03 内容大于形式
在开始做文档前首先要明白项目的整个流程，保证你是对项目流程和功能最清楚的人。首先要先解决方方面面的问题，再着手文档书写。如：
- 流程上有没有明显的逻辑性错误？
- 每个界面的数据哪里来？什么接口获取？
- 接口有没有通？是否能够拿到产品所需的数据？
- 规则性限制是否已经考虑全面？
切莫本末倒置，一切以表达清晰需求，减少与开发，测试人员沟通为第一要务。
那么写出一篇高质量的PRD？换句话说，如何写能让看的人能读懂你的表述呢？
1、首先明确阅读者及使用者
PRD预期的读者包括：产品、开发、测试人员和业务方。
- 产品、开发、测试人员会从中了解到本次需求的背景和详细要求，以及每个需求点未来的优化方向或对用户的价值；
- 业务方则可以通过该文档了解PRD中所描述内容是否是自己期望中的需求，是否符合以及是否都覆盖到了自己的预期。
因此PRD也是产品经理同相关角色确认开发任务的重要依据，明确了读者编写时才张弛有度。
2、PRD应该包含的要素
（1）文档的命名和编号
文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。
文件命名的方法一般是通过版本号定义，比如简单的方法是：XX产品V1.0PRD_V2
- V1.0：产品迭代的编号；
- PRD_V2 ：版本号。
稍微详细点可以定义成，XX产品XXXX需求PRD_V2，注明需求，方便查找。
（2）文档的版本历史
文档的版本历史包括编号、文档版本、章节、修改原因、日期、修改人。
编号：记录修改的顺序；
- 文档版本：显示的当前修改的内容属于文档的第几个版本(或第几次修改，一次修改一般为一个版本)；
- 章节：具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容；
- 修改原因：为什么要修改该需求，让阅读者直观的了解原因；
- 日期：需求文档修改的时间；
- 修改人：需求内容的修改者。
（3）目录
目录是用来了解文档结构的。
（4）引言
引言包含产品概述、产品roadmap、预期读者、预期运行效果或目标、名词说明。
- 产品概述：解释说明该产品研发的背景以及核心功能；
- 产品roadmap：为产品规划的蓝图，每个关键阶段完成的核心任务。产品研发是个不断迭代的过程，需要经过若干个版本的迭代，对一个功能点做了N个迭代后最终又回归到了第一个迭代也是很常见；
- 预期读者：文档的使用对象；
- 预期运行效果或目标：旨在说明产品的目标和标准；
- 名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。
（5）需求概述
需求概述通常包括需求概览、目标用户及特征、运行环境、设计和实现上的限制、项目计划、产品风险等。
- 需求概览：分两部分。一方面业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释；另一方面是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级；
- 目标用户及特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和操作行为做出说明；
- 运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本，操作系统、数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户；
- 设计和实现上的限制：比如控件的开发环境、接口的调用方式等；
- 项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时间、开发的完成时间、上线时间等；
- 产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。
（6）功能需求
功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：
- 简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题，使用者说明；
- 场景描述：产品在哪种情况下会被用户使用，就是用户场景模拟。这也是产品经理讲“好”故事的必备条件；
- 业务规则：每上产品在开发时都有相应的业务规则，将这些规则清晰的描述出来，让开发、测试人员能够直观的明白该规则，且没有产生歧义。业务规则必需是完整的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改，建议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明，什么时候可见，不可见，灰掉或点亮的条件在文档中都给出说明。方便阅读者理解业务规则；
- 界面原型：产品经理可设计一个页面框架，将该页面要呈现的字段及其特征以及页面要使用的场景向视觉设计师解释清楚。之后完成产品的高保真原型设计；
前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件； - 后置条件：操作后引发的后续处理；
- 主流程：做出主流程说明，对每个功能流程走向分点说明。
（7）可选方案
列出所有可以选择的达到该产品目标的方案要点(主要思路)，给各方案适当的评价，并推荐最优方案(在功能需求中描述的)。
（8）效益成本分析
一个产品的成本衡量一般包括三个方面：效益预测、产品技术成本和其他成本支出。
- 效益预测是指所提供的功能在未来能产生的效益，可通过对比以往的产品或者竞争对手的产品来做预估，效益预测的指标，如每个功能点的潜在用户数、使用频率，吸引到的新的用户特征及数量；
- 产品技术成本是指研发设计以及上线后的运营需要的资源需求，包括人力，软硬件(带宽、服务器、机房)支出。当有项目经理时可以由项目经理来协调这部分需求，如果没有项目经理，产品经理得挑头了，召集开发经理去找运维等部门落实此事；
- 其他的成本还包括支持成本，比如上线后的运营资源投入、市场推广投入以及客服服务投入等。
（9）整合需求
产品业务合作通常是不可避免的，将隶属于两个不同来源的业务功能做整合也是常见需求。
（10）BETA测试需求
产品在正式上线前BETA版本或者内测版本，或者叫灰度版本，目的是在测试产品的一些核心功能或者性能。这部份内容不是必须的，但如果需要，需要给出在此阶段要实现的目标或测试、衡量标准。
（11）非功能性需求
一般情况下非功能性需求包括以下几个部分：产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等。这些信息构成了产品上线的完整内容，也很好的体现了产品经理的综合素质。
（12）运营计划
产品上线后如何运营，目标受众是什么，建议的推广策略、问题反馈途径、风险监控、亮点宣传等等，以及与运营人员的协作方式。
3、需求的变更
需求不是一成不变的，在产品研发过程中需求变更是正常的，在做需求分析时，尽可能把每个问题都考虑透彻，提前做好需求变更的预估及应对方案，必要的情况下和团队成员提前沟通存在变更的内容。
在与团队沟通变更时，需要以一种开放的心态，从团队成员的角度、产品未来的发展趋势、市场格局的变化正确的提出变更需求，始终保持产品方向的正确和团队成员目标的一致。
