如何撰写产品需求文档（PRD文档）

在撰写产品需求文档之前，首先要做好以下几点准备工作：

1、  了解你的用户、竞争对手、产品团队的实力和需要的技术。你需要从用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。

2、  确定产品的目的，任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求，你的产品如何达到这个需求。产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。

3、  确定用户原型、用户目标（用户意愿）和用户任务（用户为达到目标使用产品而需要做的任务）。

4、  定义产品原则，需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡，为你的产品标准作出最佳的决定是非常重要的。它将在项目中，在面对众多问题而作出决定的时候提供指南。

5、  产品原型和检验

6、  验证和质疑，当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设。

做好以上准备工作，就可以开始撰写产品需求文档（PRD）了，以下列出产品需求文档包含的要点：

一、文件命名（编号）

很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变动可以直接命名为“公   司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”，当出现产品第二版时，可以命名为“公司名-产品名-PRD-D2.0”。

二、修订控制页

一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序，文档版本显示的当前修改的内容是在哪个版本中出现，修订章节是具体到哪个章节哪个功能模块的修改，修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期，修改人显示修改内容模块的人，可能是当前用户也可能是其它产品人员。

三、目录

不建议自己去添加一个新的目录，可以去其它的文档中拷一个过来，不考虑目录的内容，等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。

四、与相关部门讨论PRD

产品需求文档做为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上，需要与相关人员确定“沟通内容”， 写在与其它部门讨论PRD中。

五、概念

即总结，主要包括：名词说明、产品概述及目标、产品roadmap、产品风险。

名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。

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

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

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

六、使用者需求

一般只有需求描述，主要包括以下几项：目标客户、需求描述、场景描述、优先级。

目标客户：即为产品的最终用户，确定产品的最终使用者。

需求描述：是对目标客户的需求描述，表达用户最需要的是什么，找到用户的最根本需求。

场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。

优先级：是指用户对于当前产品功能需求的优先级，哪些是用户最想要的功能优先级则排前。

七、可选方案

列出所有可以选择的达到该产品目标的方案要点（主要思路），给各方案适当的评价，并推荐最优方案。你在做这个产品规划时一定有很多的备选方案，别放弃这些方案，永远没有过时的idea，只有最适合时机的idea。所以可以写出几个可选方案，或许是你下期产品改版一个方向。

八、效益成本分析

一般的效益成本分析包括三个方面：效益预测、产品技术中心成本、非产品技术中心支持成本。

效益预测：是指提供在各种产品环境中的效益预测，并标明主要的变量及假设，最好能包含现在和过去的效益数据。如网站的PV值，软件的使用数都是效益预测数据。

产品技术中心成本：是指设计及部署此产品的产品技术中心所需的资源需求，包括人力成本，软硬件支出等。很大时候这份成本需要由项目经理来协助，需要有什么样的人才加入产品中需与人力协助。

非产品技术中心支持成本：产品不是只有产品组完成的，同样需要其它部门的配合与协助。比如：需要客服部投入多少的资源用于该产品的服务，需要运营部投入多少的资源运营该产品。

九、功能需求

需求一般是由四部分组成，功能总览、功能详情、整合需求、BETA测试需求。

功能总览：一般包括二个部分，一个是流程图，一个是功能表。流程图是对产品的整体走向的流程的规划，流程图是用来对产品整体功能的梳理。所以在做产品前建议所有的产品经理先梳理一下产品流程。功能表是将流程图文字化，同时将列出产品的功能点。

功能详情：这是所有的产品功能的描述和规划。包括以下内容：

简要说明：告诉此功能主要干什么的。

业务规则：每上产品在使用时都有自己的规则，而产品的业务规则则是将产品的流程细化。个人建议将这个功能的业务规则，包括一些细节，如排版形式、日期显示方式全定好，这样方便其它人员的沟通和理解。

界面原型：产品经理在这时做的原型界面只是显示的框架，别细化，这样会给交互和UI造成错觉。只需做一个简单的界面即可，更多的时候只是个框架图。

执行者：产品使用者。前置条件：具体的操作。

后置条件：操作后的展示。在UC（user case）中后置条件又是另一种情况，所以对于建议在PRD中的前置条件和后置条件结果合起来。

主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明。将此功能的流程走向做个分点说明。

整合需求：利用公司现有的资源或外部资源（合作公司等）实现产品功能需求的整合。实现功能贯穿的同时，更多的如何在新产品上实现功能的拓展来辅助核心功能。

BETA测试需求：很多产品都有BETA版本放出，为了就是收求意见和一些性能测试。这部份内容不是必须的，但现在很多产品已经开始先推出BETA版本再推出正式版，当然也可以通过升级来解决。所以BETA测试需求并不是一定需要的。如果有BETA测试需求，则需写出BETA版测试的要求和期望达到的目标要求。

十、非功能性需求

一般包括以下几个部分：产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需求等。

十一、上、下线需求

上线时限需求：此产品预定上线日期？上线日期有无任何特殊依据或规定？

下线需求（活动类需求必须明确下线时间）：此产品预定下线日期？下线日期有无任何特殊依据或规定？

十二、运营计划说明

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

以上仅为PM提供一些参考，产品需求文档描绘出公司将要创造的产品，影响着公司产品团队的成果，公司的销售额、市场、客户满意程度，它需要清楚简明的表达出产品的目的、效果，功能，表现。产品开发团队将使用这份文档开发出产品并检验，所以PRD需要提供足够的信息。一份优秀的产品需求文档不一定会作出优秀的产品，但是无疑的没有一份的好的产品需求文档就更难作出好的产品！