需求文档的重要性，相信大多数产品经理都有所感知了，一份好的需求文档，更是能提高效率，减少重复沟通所花费的时间。那么，好的需求文档，到底长啥样？

去年入职新公司后，研发团队人员均不在base地，且都是通过外协的形式进行项目开发（问就是初创团队的难），这对导致了产研团队沟通成本很高。另一方面，对于产品工作的最后一公里、产品经理的重要交付物——需求文档的要求也极其的高，因为异地协作沟通成本高的问题，一份好的需求文档可以有效降低重复沟通的时间，以便有更多的时间去摸鱼（bushi）。

那么，就让我来聊一聊需求文档（prd/产品需求规格书）的结构和一些需要注意的点。

一、好的需求文档，到底长啥样？

在说我的结论之前，我们先来看看市面上的文档管理工具所提供的需求文档的模板格式，下图分为飞书、语雀和云效：

以这三家为例，我们来看看对应的需求文档的结构：

• 飞书：版本信息、变更日志、文档说明（名词解释）、需求背景（产品/数据现状、用户调研、竞品分析）、需求范围、功能详细说明（产品流程图、交互原型图、功能说明）、非功能需求、埋点、项目规划、附录。
• 语雀：变更记录、背景介绍（业务背景、业务场景）、产品概述（产品定位、服务对象、产品逻辑、信息架构、角色术语）、需求说明（需求列表、需求明细、非功能需求）、人员&排期。
• 云效：基本信息（项目成员）、需求背景、产品目标、衡量指标、产品需求、功能及界面设计、问题、暂不支持、附录。

是不是很相似？

互联网随着这些年的发展，需求文档也慢慢的标准化，只需在对应的模板稍许改造就能得出符合自己团队的模板。在前司中，因在线文档管理工具使用的是语雀，其中不乏有同事直接使用语雀的需求文档模板。

而我的需求文档，随着工作这几年的迭代和与不同团队的适配，自认为还是比较好的模板（叉腰），让我们来看下文档结构，如下图：

其中我认为版本记录、需求说明、名词解释、需求列表、详细需求说明和问题为需求文档的必要性内容，而暂不支持、性能需求、数据需求及其他均为选择性内容。

1. 版本记录

版本记录是需求文档非常重要的一部分，因为很多需求都是会产生变更的，特别是在一些比较大的需求上…这就导致了版本记录的必要性，这样在用户（研发/测试/自己…）阅读文档时就能大体上知道这个需求的迭代情况。

版本记录包含日期、版本号、修订人和修订描述，其中需格外注意的是修订描述。在修订描述中需求描述修订原因和具体内容，当然修订原因也可单独拆分出一个字段进行管理，原因需说明该版本的‘增删改’情况。具体内容则需说明修改的‘场景+结果’，例如后台管理端新增用户时剔除手机号的必填校验，则可将具体内容描述为用户在管理端「用户管理」中新增/修改用户时，提交时去除手机号的必填校验。

言简意赅的内容描述，可以降低理解成本。

2. 需求说明

需求说明包含需求来源、需求背景和需求目标。

需求来源主要记录需求的所属项目、需求提出人和主要的负责人（需求负责人/研发负责人/测试负责人…）。在一个公司中有多个项目在开发属于正常现象，因此需记录需求的所属项目；需求提出人则可以是老板、对应的业务同事或者是自己，若后续需求提出人出现离岗交接时，也可跟进对应的提出人；主要负责人则按照公司规模进行实际填写，我前司人员较多，还会涉及到系统支持、排版等相关人员。

需求背景主要描述需求产生的背景，即为什么要做这个需求。需求背景的书写切不可流于形式，深入的理解需求背景可以更好的理解当前公司的战略方向，因为每一个需求都是公司战略执行层的具体表现。

需求目标则是描述需求实现的目标，即要做什么。需求目标可大可小，小至功能目标，大至业务目标，需把握好需求目标的尺度。

3. 名词解释

名词解释主要解释该需求的专业名词，让用户更好的理解需求。例如在票据行业中的背书、贴现、前手等专有名词，是有必要在对应的需求中进行阐述说明的。

4. 需求列表

需求列表（feature list）记录了需求的具体需求，即怎么做。对于历史项目/需求的更新，需求列表则尤为重要，在需求列表中描述本次需求的变更点，可以让研发/测试更好理解本次的需求内容，起到了‘总’的概览作用。

5. 详细需求说明

详细需求说明需包含UML图、原型图和详细逻辑说明。UML图在正常的需求中起码要包含活动图/时序图+状态机图（UML这么画请看这篇文章），一个逻辑清晰的图可以胜过千言万语；原型图和详细逻辑说明相辅相成，构成了需求文档篇幅最大的部分，是对「怎么做」的更加详细的描述，详细到页面如何跳转、按钮的交互逻辑、字段的展示逻辑等。

6. 问题

问题主要记录需求评审过程中参会人员提出了相关问题，其中若未能当场给出解答的部分，则需对问题和结论进行记录。

7. 暂不支持

暂不支持记录当前需求无法实现的部分。正常情况下，需求评审之前应对需求的可实现方案进行初步沟通，即和研发通通气，这样可以避免评审过程针对不可实现的打断问题。

8. 性能需求

性能需求包含并发量、响应速度等一系列系统性能相关的需求。性能需求相关的内容偏向于技术层面，我在当前基本不写（写了也没啥用）。

9. 数据需求

数据需求包含数据量、存储时间等，这与单独的报表需求不同，因此我也不写。

二、一些tips

说完我当前的需求文档构成之后，我再来补充几点我认为比较重要的tips。

1. 善用目录导航

对于动辄几千字的需求文档，要善用目录导航，这样在阅读时可快速定位需求内容，结构性会更强。

关于管理端来说，我一般目录导航中会根据页面的从上到下的逻辑进行描述，例如按照查询条件、列表和操作进行说明。

2. 文档拆分

如果是一个大需求，涉及到系统的多个模块的变更改造，最好对文档进行拆分，再利用文件夹对其规整，这样在团队人员阅读起来会降低一定门槛，对于后续的任务分配的工作也有一定帮助。

3. 需求颗粒度

需求的颗粒度是一个很难把控的事情。

比如，是否要涉及到表的相关字段。这个非常考验产品经理对于表的理解和系统的熟悉程度，因为很多情况下用户端的字段和数据库的字段并不是一一对应的。于我而言，若是比较陌生的系统，则是按照‘取值路径+截图’的形式进行描述，这样能有效避免二义性。

另外，B端产品很多情况下会涉及到与外部对接，那么对方系统和本司系统避免不了要交互，那么在这种情况下，尽量保证详细到对接文档中的每个字段，这样能最大程度降低沟通成本。

4. 举个例子

很多时候，研发和测试对于需求的描述会感到非常晦涩难懂，这样「举个例子」就不可避免。我一般是会在比较难懂的部分后面增加一个实际例子，就比如：

1 + 1 = 2

通过一个具体的例子来对需求点进行阐释，可以有效增强需求的可读性。

5. 需求重点的标注

需求文档作为产品经理的输出物，产品经理对于需求可谓是了然于胸，那么在文档中就可以着重标注出需求的重点（例如用红色字体进行突出），以此突出某个重要需求点，要求研发和测试着重关注。

三、总结

需求文档对于我来说主要作用还是传达和记录，让团队成员对于需求达成相同的认知，以及让后人对某个需求有迹可循，不至于系统‘口口相传’。因此，需求文档并不是所谓产品经理一言堂的一个文档，而是团队对需求的共同认知，所以适合团队的就是一份好的需求文档。

如果需要我对好的文档下一份定义，那就是——问题的答案都在文档中。