如何正确编写Excel格式的需求文档?

之前参加枯叶讲师的公开课,提到了Excel需求文档的优势,刚好目前工作中也是通过Excel来编写需求文档,于是总结如下通过Excel来编写需求文档的经验和技巧。

一、需求文档的常见问题

产品经理的日常工作中,编写需求文档是一项必备的技能。

需求文档的重要性是不言而喻的,对团队的研发和测试人员,他们需要产品经理提供详情的需求文档,以便以此为依据,开展开发和系统测试的工作。

但是往往由于时间紧迫、产品经验不足等原因,提供的需求文档,常常出现需求描述不清楚、逻辑不通、需求遗漏等问题,这些问题很容易在研发和测试工作中发现,例如:

研发抱怨需求文档中没有描述清楚:比如:文档中写到:点击新增按钮,打开新增页面。前端就会跑过来疑问:这里新增页面是新开页面,还是当前页面打开。

研发在开发过程中,发现需求逻辑不通,找产品经理反馈,产品经理发现确实如此,赶紧补救。从而导致在研发过程中产生需求变更,引起众怒,还是引起研发人员质疑产品经理的能力。

需求有遗漏,不完整。产品在验收的时候,发现某个功能的排序规则不对,然后让研发修改。结果研发抱怨你的需求文档中,没有定义这个列表的排序规则,从而会产生团队矛盾。

那么,我们如何才能把需求说明清楚,尽量减少需求不清、需求遗漏、需求质量问题呢?

二、Excel需求文档

需求文档是以一种文档记录的方式,进行信息的沟通和传递。以便有迹可循,有理可依。

前面出现的:需求不清、需求遗漏、需求质量问题,我们可以通过编写Excel形式的需求文档,逐渐减少此类情况的发生,从而提升需求文档质量。

需求文档也是一个迭代的过程中,通过多次的迭代过程,一方面我们可以形成思考的方式,然后查漏补缺,进而逐渐可以完成出完整的需求文档。另一方面我们可以积累出需求文档库,便于后期的复用。

1. 历史迭代可追溯

首先Excel的需求文档,可以很清楚每个版本迭代的功能有哪些。产品不断的迭代更新,或是人员的交接,经常需要回溯之前的线上逻辑,需求文档的缺失或不完善,会导致线上逻辑不明确,甚至后续的产品需求设计的逻辑与线上矛盾或冲突,为项目的开发带来麻烦。

Excel需求文档中,可以通过sheet保留每一个迭代版本的需求内容。方便进行信息的查阅!

产品经理,产品经理网站

2. 需求颗粒度细

我们经常会很纠结,需求到底要写到多细,常常以为写的很详细了,结果研发还是有很多疑问。通过Excel的需求文档,对每一个元素进行描述,这样细化之后的需求,可以防止遗漏,思考就更加清楚,方便检查,查漏补缺,从而提升需求文档的质量。

例如:后台系统都有导出某个页面上的数据的功能,比如导出用户列表的数据。有些产品经理在写这个导出需求时只有一句话的描述:点击『导出』按钮后,将表格中的数据导出为excel文档。

但是我们经过一步一步拆解到不能再细的程度,这样再来审视这句话,会发现有很多不明确的点:

  • 导出的文件格式是什么?xlsx?xls?还是csv?(这三种格式都很常见)
  • 导出的表格是否区分sheet?sheet名称是什么?
  • 导出的表格包含哪些字段?
  • 如果还有图片(头像)等信息,怎么处理?
  • 导出列表数据的最大上限值是多少?
  • 导出的文件如何命名?

上述这些问题,如果在需求文档中不明确,在需求开发过程中通常会出现两种情况:要么是技术同学过来问产品经理如何定义(可能不止一次的沟通),要么是技术同学按自己的想法实现。前者增加了沟通成本,后续还是要花费时间完善文档或是再给测试同学讲需求,后者如果实现的方案在测试环节发现与产品或测试的想法不同,就需要返工再调整,两种情况无论怎样,都会浪费时间。

3. 迭代更新,沉淀需求库

需求传递到研发和测试人员之后,通过团队后续反馈,产品经理可以及时补充遗漏的地方,完善需求文档,并且总结遗漏的原因,避免后期再出现同样的问题,从而最终能够完成一个高质量的需求文档。

通过这样迭代,可以形成一个通用的需求库。其实在需求中,发现不同需求所用到的功能很多都是类似的,那么后面如果再碰到这样的需求,我们可以在这个基础上面进行复用,从积累的需求库中,提取出相应的功能即可。

三、Excel需求文档的模板介绍

下面来介绍Excel形式的需求文档的模板,定义好模板结构之后,可以快速编写。

1. 文档命名规范

文档的编号和命名很关键,每个产品都是经过若干个迭代才完成的,而每个迭代所完成的产品功能或者升级的需求都可能是不一样的,因此需要定义清楚该文件属于产品的哪个迭代,修改了几个版本。

文件命名的方法一般是通过版本号定义,比如简单的方法是:XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号,后面的V2 PRD的版本号。

2. 文档基本信息介绍

需求文档的封面基本信息,需要注明产品名称、需求文档的状态、当前版本、编写需求文档的人员和完成的时间。

3. 文档修改记录

产品是分多个版本迭代的,关于需求文档修改的记录页需要记录下面,包括:版本号、修订日期、模块、修订说明、修订人、备注。文档版本号显示的当前修改的内容属于文档的第几个版本(当前系统的版本XX产品V1.0+修改的版本V1),模板是具体到修改内容属于的功能模块,以便阅读人及时找到修改后的内容,修改原因说明为什么要修改该需求,让阅读者直观的了解原因。日期是指需求文档修改的时间,修改人是指需求内容的修改者。

产品经理,产品经理网站

4. 模板说明

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

产品经理,产品经理网站

  • 编号:编号就是功能的顺序号,主要是需求的唯一性标识。
  • 模块:把需求划分到系统的某个功能模块,一般只需要划分到系统的一级菜单。
  • 功能名称:系统化到系统的功能菜单,比如注册、个人中心、活动管理。
  • 功能点:这个功能菜单中具体的功能点,比如修改个人信息、查询订单。
  • 需求类型:需求类型一般包括:新增功能、功能改进、需求变更、界面优化、Bug修复、删除功能、接口需求等。
  • 功能详细描述:功能详情是描述这个功能点的页面展示、业务规则内容。是需求文档的核心内容。
  • 参数:对输入的参数信息描述。提示信息的描述。
  • 备注:其它任何信息,如:与哪个信息相关。

示例:如何以正确的姿势编写需求?

在编写需求文档的过程中,往往因进度紧而来不接写的完整,这就需要技巧性的简化文档,不妨先出一个系统框架,然后再补充每个栏目中的内容,最后再来扣细节,这样在检查的时候,能够及时发现需要是否有遗漏。没有任何文档是一次能写好的,所以在初期版本不要一上来就追求完美,有瑕疵是很正常的,在考虑到不影响开发设计工作的前提下,将后期迭代的思考加入其中就好了。

  • 搭建需求框架,细化了每个功能点上。
  • 针对每个功能点,结构化描述详情功能。
  • 最后整体检查,补充遗漏、抠细节,完善需求文档。

例如:一个活动管理页面如下,那我们要如何编写活动管理模板的功能说明。

产品经理,产品经理网站

1. 搭建框架

在写需求文档前,需要先搭建框架,首先会把这个模块尽可能细化到功能点,其实就是先写目录。结合产品功能的操作,涉及到多个页面或多个系统的状态变化;另一个是大框架下的内容是不是有遗漏,有没有遗漏描述某一项功能逻辑。

产品经理,产品经理网站

2. 结构化描述

通常完成了目录框架,自己对整个需求就很清晰明朗了,一种一切尽在掌控的感觉,接下来就是挨个补齐具体的需求的功能描述。功能是有逻辑的。而不是只讲功能点罗列出来。通过结构化的梳理,也是自己对系统的进一步深入思考。

所以,产品交付给研发的,是详细的系统功能说明。研发是实现功能,按照功能清单来,此时产品提供的就是简明扼要的功能说明。

产品经理,产品经理网站

3. 抠细节

工作中我经常建议产品同学写完需求文档后自己再读一遍,自己读一遍就能发现很多问题和漏洞。更重要的是,要能代入看需求文档的人的角色中,以他们的视角来审阅需求。最简单的,我习惯于将文档中我认为重要的,担心他人阅读时会忽视的段落文字加下划线或背景色标识,或是特别注明(此处设计师请注意有多个状态)等。代入测试的角色,试想自己看着这份需求文档在写测试用例,通常会发现很多漏洞。

总结

需求文档不仅仅是为了交付给研发测试而编写的,是为了降低需求遗漏的风险,降低团队的矛盾,确保研发理解的功能与产品想要的功能一致,从而有效避免了团队甩锅。

通过编写需求文档,产品经理也可以再次梳理一遍需求。或者在研发过程中,根据沟通发现问题,继续查漏补缺需求文档。最终反哺于自己,发现自己的遗漏,提升需求质量。这样长期积累下面的需求文档,就是一个功能库,一方面可以引导我们把需求思考的更加清晰,一方面当做功能库,便于后期的需求复用,帮助我们更快的完成需求文档,提升效率。

 

本文作者 @瓜子 。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部