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

去年入职新公司后，研发团队职员均不在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. 需求重点的标注

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

三、总结

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

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

本文由@没汤圆啦 原创发布于大家都是产品经理。
未经容许，禁止转载。

题图来自 Unsplash，基于 CC0 协议

该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。