产品经理在日常工作中，不可避免地要接触产品需求文档这类产出物。那么，产品需求文档要怎么写，才是一份合格的需求文档呢？这篇文章里，作者梳理了核心思路，并从五个方面进行了讲解，一起来看。

产品需求文档（Product requirements document 简称PRD）是产品经理在工作中最重要的产出物，是承上启下的核心文档。

图：

• 承上：业务需求。
• 启下：研发、测试、UXD的工作依据。

因此，PRD文档是产品经理职业生涯中必须要掌握的技能。

我会从以下几个方面讲解，到底怎么才能写好PRD文档。

1. 目的
2. 形式
3. 技巧
4. 态度
5. 环境

一、目的

写PRD最重要的目的是：把需求讲清楚，但一份优质的需求文档一定是合适的方案+表达清晰。

合适的方案是指：我能分析清楚业务的现状是什么，期望是什么，要解决什么问题，用什么方案解决。

表达清晰是指：我能把我希望用的解决方案表达清楚，传递清晰。

如何分析需求并找到合适的方案，我会在另外的文章中来讲解，本文的重点会着重放在表达清晰上，但在我多年的实际文档经验中，往往合适的方案和表达清晰是一个交替生成的，当你尽可能想表达清晰时也能促使你获得更加合适的方案，所以表达清晰不仅仅是应该，而是必要。

如果把需求讲清楚是总纲，它还能分为三个小目标：

文档受众能精准理解文档并转化为他们的产出物：

• 研发人员 ====> 代码
• 测试人员 ====> 测试用例
• 交互设计人员 (User experience design，简称UXD) ====> 交互图

多个角色间的无歧义标准：涉及研发、测试、UXD以及跨域的产品等角色时，需求文档应作为在发生分歧时的唯一标准，帮助多个人之间消除歧义而不是引发新的歧义。

可追溯性文件：

• 上线一段时间后的线上BUG，用来判断是产品设计缺陷 OR 是代码问题。
• 后续迭代需求的基石：能够让新人快速理解现状并输出需求，同时能够帮助新人查漏补缺（往往新人会漏考虑一些细节，当文档足够完善时能起到提醒的作用）。

二、形式

一般来讲，需求文档总是图表和文字的形式出现，几乎没有人会使用视频和音频，需求文档一般会伴随着需求评审，以便能够进一步解释说明和对文档查漏补缺。

三、技巧-结构

技巧分为结构和表达，本篇文章会着重介绍结构部分，表达不分：图表的介绍和使用以及其他文字性技巧、习惯会在后续的文章中体现。

从宏观到微观的描述顺序，能够让文档受众在获取到背景信息的前提下理解文档的内容。比如当你看到Chair is blue时会认为它是什么含义？

• 椅子是蓝色的？
• 主席是忧郁的？

想要正确的理解这个句子，需要是加一些背景，比如在一个办公室里，他得知公司将要破产，这样我们才能顺利成章的理解他作为主席，听到这个消息非常沮丧。

因此，我会推荐将整个需求文档都变为总分的结构，这会更加的便于文档受众的理解，也恰好符合金字塔原理。

金字塔原理是一种重点突出、逻辑清晰、层次分明,简单易懂的思考方式、沟通方式、规范动作。

金字塔原理的基本结构是:结论先行,以上统下,归类分组,逻辑递进。

先重要后次要,先总结后具体,先框架后细节,先结论后原因,先结果后过程,先论点论据。

针对整个文档，我会将他们分为两大部分：为什么要做 和 要做什么。

1. 为什么要做？

此部分着重交待清楚背景、问题、价值、目的。

背景：用来描述此需求发生的业务背景，比如业务将要开拓一个新的市场，这个市场上大家普遍都会以货到付款作为交易的方式。一番描述之后会让对这个需求不熟悉的人更快的进入到这个需求的情境中。

问题：用来描述业务的预期与现在现状的落差，这个落差是问题也是需求。如果能正确的描述归纳和描述问题，就能更快找到问题所对应的“答案”。

价值：做这个需求有什么价值？我发现大多数产品经理，尤其是新手，往往会忽略价值的思考和表达。认为这可能是上一级或者业务应该思考的事情。我在产品经理的任何阶段都建议大家去思考价值，价值背后所隐藏的信息有：

• 这个需求该不该做？（同时综合方案的成本）
• 这个需求什么时候做？（也就是优先级的问题）

描述价值的同时，一方面是对自己工作的肯定，我在做有意义的事情，另一方面也是在说服文档受众，告诉他们：为什么你的需求非做不可。

深入思考价值也你后续在跟业务沟通时判断是否为伪需求打好基础，没有价值的事情坚决不浪费时间做。

在盈利性组织中，价值只来源于两个方面：盈利和成本。

1. 营收：做了这个功能可以带来多少营收，能增长多少客户等
2. 成本：做了这个功能可以提高多少效率（提高效率往往意味着精简人力），可以节省多少成本等。

目的：此处的目的更多的是从系统建设的角度给出一些比较精简的目标，比如需要在XX模块兼容货到付款的业务。

2. 要做什么

此部分着重讲方案的主体。

整体设计：也称为概要设计，主要的目的有2个：

1. 让文档阅读者有整体的概念，能够让他站在更加宏观的视角理解方案。
2. 为后续理解具体的功能用例提供铺垫。

需求详情：在这个大模块里需要对需求要实现的功能/特性做详细的逻辑说明，一般写需求时先要对功能（也叫用例）进行拆分，拆分完在针对不同的功能点做详细补充。

功能拆分：拆分完需求一般可以输出一份功能地图（Roadmap），需求拆分核心需要遵守MECE原则，即不重不漏。

• 不重：功能点之间不重复，同样的功能写一遍即可。写一遍能省时间，以及方便后期维护（若写多遍改的时候要改多个地方，所以要尽量抽象到一个里面。）
• 不漏：一个完成的需求需要不同模块间的协作，漏了以后可能会导致卡流程。

功能描述：需要对逻辑做最详尽的说明，根据团队协作的习惯尽量细化，需细化到是或否应该走哪个分支流程，甚至细化到要用什么表的什么字段。

四、环境

良好的环境能够帮助产品经理在文档能力上快速成长，此处罗列一些我认为较重要的因素：

文档规范：良好的规范有助于产品快速融入团队整体的表述方式，同时也能够帮助一些产品些人快速成长，我曾经待过一个团队，全部都是在需求卡片中写一句话的需求，既没有沉淀也没有规范，导致需求上线后没有人知道会有这样一条逻辑。

需求模板：产品团队一般都会有需求模板，但是模板也只能约束整体格式，具体的写作风格还是会因人而异。

管理方式：文档的管理方式大致有三种。

1. 增量式文档：每次需求都是一个全新的文档，优势是前期迭代快，对文档管理的要求较低，后期维护麻烦，很难溯源。
2. 白皮书式文档：按模块划分，优势是后期维护较简单，容易溯源，所见即所得，可以有效缩短产品对现有逻辑的调研时间，但对于跨模块的需求，阅读者读起来较麻烦，文档分散（需要一些书写技巧规整以方便阅读）。
3. 综合性文档：增量的内容定期维护到白皮书中，这种管理方式看似能实现前两者的优势但需要消耗大量的产品时间去做维护的事情，在实际的工作中很难实现。

研发测试的严格要求：同事的高标准、严要求，评审会上的“挑战”都会促使你精进文档能力，将需求描述的更加简练清晰，无歧义。

能有机会做大项目：只有较大的项目才会涉及到多个模块、多个系统，这会有效提升整体设计的能力，全局设计的能力。

有人带：团队中有人带可遇不可求，一方面能手把手让你快速上手现有业务，一方面可以阶梯式的给你分配项目，并不是项目越大越好，循序渐进的增加项目难度会更适合新手。

五、态度

没有人可以叫醒一个装睡的人，不管在什么样的环境中，我们都不要成为那个“装睡的人”。

精益求精：

• 主动寻找更好的写文档的技巧。
• 不因项目/需求大小而放低文档的质量，没有小需求，再小的功能也能体现你的价值。

为他人着想：你写的明白，别人看的清楚，需求文档就是建立信任最基本的产出物。

保持高标准：认认真真写一个文档简单，认认真真写每个文档就很难，但某天当你回首以望时，你早已从小草长成参天大树。