需求文档是以一种文档记录的方式,Excel需求文档的优势在于能够帮助更好地查阅信息。如何编写Excel格式的需求文档?作者根据自身经验,并结合案例分享了相关经验,希望对你有用。
之前参加枯叶讲师的公开课,提到了Excel需求文档的优势,刚好目前工作中也是通过Excel来编写需求文档,于是总结如下通过Excel来编写需求文档的经验和技巧。

我们经常会很纠结,需求到底要写到多细,常常以为写的很详细了,结果研发还是有很多疑问。通过Excel的需求文档,对每一个元素进行描述,这样细化之后的需求,可以防止遗漏,思考就更加清楚,方便检查,查漏补缺,从而提升需求文档的质量。
例如:后台系统都有导出某个页面上的数据的功能,比如导出用户列表的数据。有些产品经理在写这个导出需求时只有一句话的描述:点击『导出』按钮后,将表格中的数据导出为excel文档。
但是我们经过一步一步拆解到不能再细的程度,这样再来审视这句话,会发现有很多不明确的点:
导出的文件格式是什么?xlsx?xls?还是csv?(这三种格式都很常见)导出的表格是否区分sheet?sheet名称是什么?导出的表格包含哪些字段?如果还有图片(头像)等信息,怎么处理?导出列表数据的最大上限值是多少?导出的文件如何命名?上述这些问题,如果在需求文档中不明确,在需求开发过程中通常会出现两种情况:要么是技术同学过来问产品经理如何定义(可能不止一次的沟通),要么是技术同学按自己的想法实现。前者增加了沟通成本,后续还是要花费时间完善文档或是再给测试同学讲需求,后者如果实现的方案在测试环节发现与产品或测试的想法不同,就需要返工再调整,两种情况无论怎样,都会浪费时间。
3. 迭代更新,沉淀需求库需求传递到研发和测试人员之后,通过团队后续反馈,产品经理可以及时补充遗漏的地方,完善需求文档,并且总结遗漏的原因,避免后期再出现同样的问题,从而最终能够完成一个高质量的需求文档。
通过这样迭代,可以形成一个通用的需求库。其实在需求中,发现不同需求所用到的功能很多都是类似的,那么后面如果再碰到这样的需求,我们可以在这个基础上面进行复用,从积累的需求库中,提取出相应的功能即可。

需求文档的模板参考上图,需求文档的关键属性说明如下:

在写需求文档前,需要先搭建框架,首先会把这个模块尽可能细化到功能点,其实就是先写目录。结合产品功能的操作,涉及到多个页面或多个系统的状态变化;另一个是大框架下的内容是不是有遗漏,有没有遗漏描述某一项功能逻辑。
通常完成了目录框架,自己对整个需求就很清晰明朗了,一种一切尽在掌控的感觉,接下来就是挨个补齐具体的需求的功能描述。功能是有逻辑的。而不是只讲功能点罗列出来。通过结构化的梳理,也是自己对系统的进一步深入思考。
所以,产品交付给研发的,是详细的系统功能说明。研发是实现功能,按照功能清单来,此时产品提供的就是简明扼要的功能说明。
工作中我经常建议产品同学写完需求文档后自己再读一遍,自己读一遍就能发现很多问题和漏洞。更重要的是,要能代入看需求文档的人的角色中,以他们的视角来审阅需求。最简单的,我习惯于将文档中我认为重要的,担心他人阅读时会忽视的段落文字加下划线或背景色标识,或是特别注明(此处设计师请注意有多个状态)等。代入测试的角色,试想自己看着这份需求文档在写测试用例,通常会发现很多漏洞。
总结
需求文档不仅仅是为了交付给研发测试而编写的,是为了降低需求遗漏的风险,降低团队的矛盾,确保研发理解的功能与产品想要的功能一致,从而有效避免了团队甩锅。
通过编写需求文档,产品经理也可以再次梳理一遍需求。或者在研发过程中,根据沟通发现问题,继续查漏补缺需求文档。最终反哺于自己,发现自己的遗漏,提升需求质量。这样长期积累下面的需求文档,就是一个功能库,一方面可以引导我们把需求思考的更加清晰,一方面当做功能库,便于后期的需求复用,帮助我们更快的完成需求文档,提升效率。
本文由 @瓜子 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
上一篇:互联网人好脾气修炼指南