产品经理的学习笔记（四）撰写产品需求文档（PRD）

PRD（Product Requirement Document），即产品需求文档，是产品由“概念化”阶段进入到“图纸化”阶段的最重要的一个文档。是产品经理对某一产品或功能的详细描述和说明，也是产品从想法到落地过程中极其关键的环节。

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

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

1.1 各个角色

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

• 领导（产品总监等）：重点会看一下，做这项工作的原因、解决问题的影响范围、成本、以及最终给客户和公司内部提供的价值
• UI&UX设计师：一般会重点关注在一些页面的元素上，设计师会根据页面的元素进行视觉和交互设计
• 前后端研发工程师：后端工程师侧重具体逻辑细节，前端工程师更关注在设计师给出的设计稿、交互说明和一部分少量的前端逻辑
• 测试工程师：除了关注前后端逻辑、交互外，还关注系统最后希望达到的标准，以及最终的和兴使用场景
• 产品运营：会关注最终产生的价值以及具体的使用方式，产品运营作为产品的客户之间的重要桥梁

1.2 高效&正确

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

1.3 生产

本质上，软件开发也是生产的过程，和生产实物是没有本质区别的。PRD作为指导生产过程的重要文档，类似实物生产的设计文档，必须要满足在生产过程中各种各样问题的回答。

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

PRD开始编写，意味着整个业务调研、方案逻辑、可行性、价值判断基本上已经完成了，如果没有完成那么是不建议直接编写PRD文档的。

• 业务调研：只有完全搞清楚业务的问题，才可以解决问题，在PRD编写前一定要进行业务调研
• 方案逻辑：在方案设计的初期，一定是有不同的方案来解决问题的，这些不同的方案需要进行一些维度的比对，最终选择合适的方案
• 可行性：围绕设计思路中的不同方案，要对技术可行性进行论证，这需要与具体的开发负责人进行沟通
• 价值判断：如果说一个问题的解决成本大于价值了，那就没必要做了，也就没必要继续写PRD了

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

一个TO B系统的PRD的结构大致分为：

3.1 文档管理

版本管理需要记录每次修改的概要说明，相关人员是为了明确具体的工作人员，开发当中的沟通以及后续问题排查需要。

3.2 背景

背景和目标通常是比较简短的，一方面是为了在内容层面表述大的背景和目标，另一方面是在写作技巧上，不能上来一杆子通到底了，需要与读者在某些信息上达成共识，引出问题后在再进行具体的说明。

3.3 需求说明和分析

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

• 需求描述：需求描述需要原滋原味的将最原始的需求进行表达
• 现状分析：针对需求，目前系统是如何解决的，还是没有任何方式解决，现有的解决办法为什么不是最优的
• 需求分析：需求分析最考验一个产品经理的基本功，需求分析是在挖掘需求背后的真正目的，多问自己几个为什么需要

3.4 产品方案概览

产品方案概览是为了让相关人员在查看详细的设计方案前对整体的情况有一个初步的认识：

• ER图：一般情况下，To B的系统都会有很多数据对象，数据对象之间存在复杂的关联关系
• 整体方案：整体方案强烈建议使用一张图，一图胜前言，用一张图说明整条的方案
• 使用方式：可以叫做使用方式，也可以叫做页面结构图，主要是为了阐释在真正客户面前这个产品是如何被使用的

3.5 功能说明

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

3.6 验收说明

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

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

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

请点击以下链接阅读完整文章：阅读文章