需求文档,对于每一个产品经理都不陌生,这是大家日常工作最基本的产出。它集合了我们对需求的分析、对需求的理解、以及对需求的规划。但是到底什么样的需求文档才是一份好的需求文档呢?相信很多产品经理都有自己的见解,在这里,我只想表达我自己的一些想法,如果这篇文章能对一些或者一个产品经理有帮助或者有一丝的启发,那我觉得就很知足了。

首先,我们需要确定需求文档是用来干嘛的,即类似于产品定位。需求文档主要作为产品经理开展工作的一种介质,它用于我们工作中需求的记录、传播,基于文档来保证我们的信息同步,是我们下游的工作人员开展工作的基本依据。

其次,要确定需求的目标用户,我觉得主要目标用户有三类:
1、开发人员:他们是需求的实现者,他们是否能读懂你的需求,直接影响到你的需求能否按照要求实现。因为他们要将你的需求文档转化为对应的代码,进而表现到具体的产品上。
2、测试人员:他们是需求的验证者,他们是否清晰的理解需求,直接影响需求的实现质量,因为他们要将需求文档转化为千变万化的使用场景,模拟真实用户使用产品的各种场景。
3、其他产品:他们可能是需求的交接者(尤其是互联网公司,人员流动很大,产品经理离职一定要做工作交接,这时候文档起到很关键的作用),他们是否能清楚地把握需求,直接影响后续需求的迭代,因为他们要基于你的需求不断优化产品,让产品不断达到预期的目标。

接着,我们要确定我们这个文档要实现的目标:让阅读的人,通过文档知其然知其所以然,即既要知道这个需求是什么,还要知道为什么要做这个需求,深入理解需求。
然后,我们要开始梳理需求文档的大体框架,类似于产品需求的梳理阶段。基于我们对用户需求的分析,大体可以梳理出来需求文档需要有以下几项内容:
1、需求背景:描述我们现在面临的问题,我们的需求就是致力于去解决这些问题的
2、需求目标:方便上线后对于需求效果的考核
3、需求对接人:便于梳理需求涉及到的系统及对接人,前期把涉及到的系统都梳理到且有对接人,后期要省事很多,不然真到了后期实施时才发现,就很可能会造成需求的延期
4、需求描述(包含概述和具体流程):这是需求文档的主体,可以通过流程图、原型图等附件来辅助说明你的需求,方便其他人来理解需求
5、其他说明:可以包含数据埋点、系统响应、后续的验收标准等信息

再然后,开始填充内容,也就是项目的实施阶段。我们要基于需求的架构来具体的书写我们的需求文档。撰写需求文档时,一定要注意条理清晰,尤其是需求描述部分,切记长篇大论,尽量使用简洁的语言,合理划分段落层次,增加文档的可读性。
最后,增加目录,检查文档,这个算是验收阶段,查漏补缺。
最后的最后啰嗦一点,就是希望大家可以养成良好的文档习惯,做好版本记录。需求文档并不是一成不变的,评审之后可能有改动,而且到后续项目的开发测试阶段也很有可能会有变动,这些变动有的来自于产品经理,有的来自于开发测试同学,不要害怕变化,要拥抱改动,同时做好需求文档的维护,添加好版本记录,将每次的改动都更新到需求文档中,这样才能保证你的需求文档是相对完善的。

网友评论