为什么要写产品需求文档？产品需求文档包括什么？

高频面试题：为什么需要写产品需求文档？

当我们从用户那里收集到需求后经过初步的市场调研、需求筛选和可行性分析后会将需求转化为一条条用户需求，而在产品经理的规划和分析下会对这些需求进行去重、归类然后转化为产品需求，形成产品功能列表也就是我们常说的（功能列表）Feature List。这时候我们需要将大大小小的功能点汇总成为一个产品并最终实现它就需要将我们的意图系统的表达给设计狮、程序猿，然而此时任何的表达不清或错误都会造成后续工作的无法进行或返工，因此产品需求文档应运而生。

所以对这种文档的判断要求也就变得清晰明了，第一要规范化的格式，不能一个项目一套文档标准，采用统一的规范可以在最大的程度上避免产品设计上的内容疏缺。第二则是要以程序猿、设计狮能理解的语言来描述，专业的术语不仅能减少分歧更能使产品经理给相关各方留下一个专业认真的形象，有利于团队的凝聚力。

一份可读性强、文脉和思路清晰、流程和功能阐述明白、页面元素、输入和输出都定义明确的产品需求文档，通常都是需要经过几次持续的迭代和梳理，才能逐渐完善起来。

产品需求文档包括的内容

（1）概述

概述部分是概括地说明产品背景，简述产品功能，预期实现的目标，分阶段实现的阶段性目标。

l 背景介绍：是基于什么样的考虑要做这个需求。

l 产品目的：解释说明该产品是干什么的，为什么需要这样的产品。同时产品想要达到什么样的目标。产品概述及目标就是对产品核心功能讲解，同时希望可以达到的期望。

l 产品（路线图）roadmap：产品分期目标，阶段描述，以及时间点的确定，产品是个不断演进的过程，很多时间一期产品只完成了产品70%的功能，二期才会继续去完善剩下的30%，同时有可能会推翻了重新推出第二版。产品roadmap并不及着全部规划好所有的阶段目标，而是更多的通过维护来保持产品的更新和迭代。

l 名词解释：声明文档中出现的名词含义。

l 数据词典：介绍本产品中数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等。

l 文档阅读对象：声明本文档输出的阅读对象和注意事项。

l 产品风险：描述产品可能存在的风险，比如商务谈判的风险，外部合作的风险，不当使用的风险等等。风险级别为高中低。

（2）产品描述

产品描述介绍用户使用产品的逻辑流程，概括性的描述产品需求、产品版本规划、产品整体的框架结构以及功能列表。产品整体流程与产品框架都需要使用相应的图表展现。

l 产品整体流程：展示产品框架图和用户流程图。

l 产品需求描述：描述产品核心功能，解决哪些情景下的哪些需求。

l 产品版本规划：叙述产品版本迭代计划，版本号、主要模块、功能点、计划开发时间、计划结束时间、备注。

l 产品框架：展示页面层级，展现产品框架中各一级页面、二级页面、三级页面及备注信息。

l 功能列表：展示产品功能名称、对应模块、功能说明、备注等信息。

（3）功能描述

功能需求这部分需详细描述产品所涉及的各个功能点。将整体框架拆成数个独立的功能点，分别描述每个功能点的逻辑流程图、界面、字段说明以及业务说明。统一采用Use Case的方式进行描述。

l 流程图

l 界面原型

l 字段说明（包括数据字典）

l 业务说明（Use Case）

（4）效果预期

做任何一个需求，我们都有明确的目的，有了目的还不够，我们应当根据产品的现状，对此次需求上线后的效果有一个预期，效果预期主要通过数据层面来体现。

有了效果预期，PDR的读者就知道在需求上线后，会对产品带来多大的变化和影响，在需求实施的时候，也能更全面的考虑各种情况。

（5）数据埋点指标

这部分跟上述效果预期相关联，有效果预期以后，需要有相应的指标来评判效果，因此，需要在PRD中将详细的数据指标列出来，以便研发对数据指标的提取进行埋点，以及后续数据提取。这部分和效果预期常常容易被忽略，等到需求上线了，才发现需要的数据没有，导致需求效果难以评估，后续的迭代也没有数据支撑。

（6）非功能需求

非功能需求，也就是关于产品的其它方面的要求。一般情况下非功能性需求包括以下几个部分：产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需统计需求、性能需求、可用性需求等。与其说是全方位的掌握技能，还不如说是沟通，如何与不同的部门人员之间的沟通，让更多的人协助产品的正常使用与上线。

（7）运营计划

说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户，产品经理是核心需求的把握者，参与到产品整体运营计划显得特别的重要。

（8）PRD迭代记录

这部分也是容易被忽略的一部分，尤其是核心的产品需求，在初版需求文档出来以后，没有后续的迭代记录，会导致产品迭代多个版本以后，不知道早期某些功能是如何考虑，又是如何一步步演变成今天这个样子。

PRD从第一版诞生以后，经过多次需求评审，设计评审，详细设计评审、用例评审，其中有许多细节，甚至页面布局、功能点都会有变化，当时可能都是通过邮件、会议纪要来说明，如果不整理到需求文档中，时间长了，或者是人员变化，可能就没有人知道这部分需求最终的实现方案了。

因此，PRD迭代记录也是非常重要的一部分，记录下每一次讨论后需求的变化点，帮助各方使用者及时了解需求变化，以及对最终的实现方案做记录，方便后续查阅。