作为产品经理，编写产品需求文档是基本技能之一，本文详细介绍了如何编写产品需求文档（PRD），希望对你编写有效的PRD有所帮助。

PRD是Product Requirement Document的简称，翻译为：产品需求文档。该文档是产品由“概念化”阶段进入到“图纸化”阶段的最重要的一个文档。编写PRD是一个产品经理最为基础的工作内容，也是一个产品经理最基础的能力。不夸张的说，通过一篇PRD文档就可以体现出一个产品经理的基本功是否扎实，这直接影响到整个研发团队的效率。

我常年从事To B系统产品的工作，因此本文的内容也仅针对To B系统的PRD文档，并不完全适用To C的系统产品。想写出一篇优秀的PRD文档，需要搞清楚如下4个问题：

1. PRD文档的编写目的是什么？
2. PRD文档在编写前需要做什么？
3. PRD文档在编写的过程中有哪些是需要注意的？
4. PRD文档编写完成后如何使用？

一、PRD文档的编写目的是什么

编写PRD文档最为重要的目的就是：协调各个相关角色，将产品高效正确的“生产”出来。PRD仅仅是为达到这个目标，产品经理经常使用的一种工具，只要是能够高效的完成最后的系统化产品，那么PRD具体的内容、形式也没有非常严格的标准。从这个目标出发，我们能够看到这样几个关键词：各个角色、高效&正确和生产

1.1 各个角色

这里的角色是涉及到整个产品研发过程中全部相关的角色，每个角色在这个过程中负责的工作和关注点有所不同，PRD中需要照顾到所有参与角色的关注点，To B系统产品在此过程中主要涉及到的角色如下：

• 领导（产品总监等）：这个角色的人一般不会太过关注PRD的细节，重点会看一下，做这项工作的原因、解决问题的影响范围、成本、以及最终给客户和公司内部提供的价值。当然，这些内容如果在PRD之前就使用其他的文档说清楚了，PRD文档中就不需要写了，我也建议在PRD编写之前，通过产品提案等方式，把这些内容全部确定好，达成一致。
• UI&UX设计师：这个角色的人一般会重点关注在一些页面的元素上，设计师会根据页面的元素进行视觉和交互设计，所以，PRD中已经要写清楚页面的元素以及这些元素的含义，并且说明最终用户在页面上大大致操作过程。
• 前后端研发工程师：前后端工程师关注的侧重点稍微有点不同，后端工程师侧重具体逻辑细节，前端工程师更关注在设计师给出的设计稿、交互说明和一部分少量的前端逻辑。所以，PRD中一定要把具体逻辑写清楚，最好把设计师的设计稿和设计说明一并汇入PRD中。
• 测试工程师：这个角色的人除了关注前后端逻辑、交互外，还关注系统最后希望达到的标准，以及最终的和兴使用场景。所以，尽可能的写一下最核心的几个使用方式，相当于最重要的几个测试用例。
• 产品运营：这个角色的人会关注最终产生的价值以及具体的使用方式，产品运营作为产品的客户之间的重要桥梁。所以，最好可以写一下系统使用说明。

1.2 高效&正确

写出来文档永远比无效的沟通更高效，工作的事件越长，对此越是认可，对于很多问题，特别是复杂问题，前午安不要觉得说一下大家就明白了，前因后果、如何做大家都清楚了，相信我一定不是这样的。

PRD就是提高效率的，把各个角色的共识全部写出来，大家都已PRD为最终的工作指导文档，在墙漆可以讨论修改，在后期可以追根溯源，多花点时间在PRD上一定会比不断地回答问题，不断地因为没有大臣一致的逻辑反复修改要高效的多。

1.3 生产

本质上，软件开发也是生产的过程，和生产实物是没有本质区别的。PRD作为指导生产过程的重要文档，类似实物生产的设计文档，必须要满足在生产过程中各种各样问题的回答。因此需要从生产流程的角度进一步的来说审视PRD的内容，包括：现状、准备工作、前提条件、开发逻辑、效果要求等。

二、PRD文档在编写前需要做什么？

在上一小节中建议在PRD编写之前，通过产品提案等方式把价值、成本等内容全部确定好，达成一致。实际上在PRD文档编写之前还远不止这些内容。

PRD开始编写，意味着整个业务调研、方案逻辑、可行性、价值判断基本上已经完成了，如果没有完成那么是不建议直接编写PRD文档的，因为就算写完了也很有可能改来改去或不做了，这不仅仅影响工作的效率，还会大大打击个人和团队的积极性。

• 业务调研：只有完全搞清楚业务的问题，才可以解决问题，在PRD编写前一定要进行业务调研，根据需求的复杂程度编写详细或简要的需求调研文档，明确需要解决的具体问题和要达到的具体目标。
• 方案逻辑：虽然PRD就是最后方案的详细说明文档，但是，在方案设计的初期，一定是有不同的方案来解决问题的，这些不同的方案需要进行一些维度的比对，最终选择合适的方案，因此，在PRD编写前，需要写一个设计思路文档。
• 可行性：围绕设计思路中的不同方案，要对技术可行性进行论证，这需要与具体的开发负责人进行沟通，明确方案是否可行，以及成本，最后决定最终的方案。
• 价值判断：如果说一个问题的解决成本大于价值了，那就没必要做了，也就没必要继续写PRD了，因此需要对方案的的直接和间接价值，以及直接和边际成本进行明确，确定推进是有意义的。

三、PRD文档在编写的过程中有哪些是需要注意的？

终于来到了最核心的部分了，PRD文档的具体结构，有哪些呢，这一部分在网上确实有非常多的模板可以参考，各个模板也是大同小异，但最为重要的是有一些细节上需要注意，这也和下一小节如何使用PRD文档有很大的关系。在我看来，一个TO B系统的PRD的结构大致分为：

3.1 文档管理

版本管理需要记录每次修改的概要说明，相关人员是为了明确具体的工作人员，开发当中的沟通以及后续问题排查需要，设计稿一般会有一个设计工具的地址，里面会有一些图片无法表达的内容，相关人员需要查看。

3.2 背景

背景和目标通常是比较简短的。

一方面是为了在内容层面表述大的背景和目标，比如公司整体的方向是让系统有更高的开放性，需要做一些API，所以本次的开发是在这个开放性的大背景下的，达到XXX部分对接，降低定开成本等等。

另外一方面是在写作技巧上，不能上来一杆子通到底了，需要与读者在某些信息上达成共识，引出问题后在再进行具体的说明。

3.3 需求说明和分析

需求并说明的部分主要分为2各部分，需求描述和需求分析，需求分析又分为现状分析和需求分析2部分：

• 需求描述：需求描述需要原滋原味的将最原始的需求进行表达，可以是客户的需求、竞品对比的需求、老版提出的需求、售前引申的需求等等，但无论来源是什么，在需求描述中一定要回归业务场景，没有业务场景说明出发点就要小心了，很有可能最后不会带来业务上的实际价值。
• 现状分析：针对需求，目前系统是如何解决的，还是没有任何方式解决，现有的解决办法为什么不是最优的。
• 需求分析：需求分析最考验一个产品经理的基本功（有人说是设计，我不这么认为），需求分是是在挖掘需求背后的真正目的，多问自己几个为什么需要。

3.4 产品方案概览

产品方案概览是为了让相关人员在查看详细的设计方案前对整体的情况有一个初步的认识，直接查看一个不熟悉的产品方案细节，很容易无法透测理解。方案概览一般从3各方面进行阐释，最后在将开发的任务和范围明确一下，为具体的功能说明做好铺垫。

• ER图：一般情况下，To B的系统都会有很多数据对象，数据对象之间存在复杂的关联关系，特别是整个方案中如果引入了新的对象或新的关联关系，那么一定要绘制ER图，说明不同抽象对象之间的关系。
• 整体方案：整体方案强烈建议使用一张图，一图胜前言，用一张图说明整条的方案，增加了什么页面、增加了什么字段、增加了什么逻辑处理、增加了什么对外接口等等，根据具体的需要一般会使用架构图、时序图等及西宁表达
• 使用方式：可以叫做使用方式，也可以叫做页面结构图，主要是为了阐释在真正客户面前这个产品是如何被使用的，当然如果没有页面的开发，这部分可以省略。

3.5 功能说明

功能说明就是对概览性方案的拆分说明，对每一个小的功能点进行详细的说明。一般分为原型和功能说明，没有页面的原型部分可以空着。功能部分一定要写清楚具体的逻辑。

非核心功能和非功能性需求，更加考验一个产品经理设计能力的细致，优秀的产品经理需要看到功能背后的需求，比如，性能、安全等等，这些细项像一个检查清单，产品经理在自己具体的领域里不断手机问题完善这个清单，然后在每个PRD里面一条一条的问自己需不需要。

3.6 验收说明

验收说明类似于P0的测试用例，切实描素用户最终的使用过程。

四、PRD文档编写完成后如何使用？

PRD文档编写完成就结束了吗，还没有，那就是使用PRD知道整个开发过程的工作了，从Planning会议讲解PRD开始，PRD文档正式投入使用，在这个过程中那面会对PRD文档进行一些修改，这时一定要记录好修改的内容，不然回头就忘了。

另外，在PRD使用的过程中，一定要不断的发现PRD模板的问题，不断优化PRD模板。