新媒易动态
NEWS CENTER
NEWS CENTER
2020-05-07
之前参加枯叶讲师的公开课,提到了Excel需求文档的优势,刚好目前工作中也是通过Excel来编写需求文档,于是总结如下通过Excel来编写需求文档的经验和技巧。
产品经理的日常工作中,编写需求文档是一项必备的技能。
需求文档的重要性是不言而喻的,对团队的研发和测试人员,他们需要产品经理提供详情的需求文档,以便以此为依据,开展开发和系统测试的工作。
但是往往由于时间紧迫、产品经验不足等原因,提供的需求文档,常常出现需求描述不清楚、逻辑不通、需求遗漏等问题,这些问题很容易在研发和测试工作中发现,例如:
研发抱怨需求文档中没有描述清楚:比如:文档中写到:点击新增按钮,打开新增页面。前端就会跑过来疑问:这里新增页面是新开页面,还是当前页面打开。
研发在开发过程中,发现需求逻辑不通,找产品经理反馈,产品经理发现确实如此,赶紧补救。从而导致在研发过程中产生需求变更,引起众怒,还是引起研发人员质疑产品经理的能力。
需求有遗漏,不完整。产品在验收的时候,发现某个功能的排序规则不对,然后让研发修改。结果研发抱怨你的需求文档中,没有定义这个列表的排序规则,从而会产生团队矛盾。
那么,我们如何才能把需求说明清楚,尽量减少需求不清、需求遗漏、需求质量问题呢?
需求文档是以一种文档记录的方式,进行信息的沟通和传递。以便有迹可循,有理可依。
前面出现的:需求不清、需求遗漏、需求质量问题,我们可以通过编写Excel形式的需求文档,逐渐减少此类情况的发生,从而提升需求文档质量。
需求文档也是一个迭代的过程中,通过多次的迭代过程,一方面我们可以形成思考的方式,然后查漏补缺,进而逐渐可以完成出完整的需求文档。另一方面我们可以积累出需求文档库,便于后期的复用。
首先Excel的需求文档,可以很清楚每个版本迭代的功能有哪些。产品不断的迭代更新,或是人员的交接,经常需要回溯之前的线上逻辑,需求文档的缺失或不完善,会导致线上逻辑不明确,甚至后续的产品需求设计的逻辑与线上矛盾或冲突,为项目的开发带来麻烦。
Excel需求文档中,可以通过sheet保留每一个迭代版本的需求内容。方便进行信息的查阅!
我们经常会很纠结,需求到底要写到多细,常常以为写的很详细了,结果研发还是有很多疑问。通过Excel的需求文档,对每一个元素进行描述,这样细化之后的需求,可以防止遗漏,思考就更加清楚,方便检查,查漏补缺,从而提升需求文档的质量。
例如:后台系统都有导出某个页面上的数据的功能,比如导出用户列表的数据。有些产品经理在写这个导出需求时只有一句话的描述:点击『导出』按钮后,将表格中的数据导出为excel文档。
但是我们经过一步一步拆解到不能再细的程度,这样再来审视这句话,会发现有很多不明确的点:
上述这些问题,如果在需求文档中不明确,在需求开发过程中通常会出现两种情况:要么是技术同学过来问产品经理如何定义(可能不止一次的沟通),要么是技术同学按自己的想法实现。前者增加了沟通成本,后续还是要花费时间完善文档或是再给测试同学讲需求,后者如果实现的方案在测试环节发现与产品或测试的想法不同,就需要返工再调整,两种情况无论怎样,都会浪费时间。
需求传递到研发和测试人员之后,通过团队后续反馈,产品经理可以及时补充遗漏的地方,完善需求文档,并且总结遗漏的原因,避免后期再出现同样的问题,从而最终能够完成一个高质量的需求文档。
通过这样迭代,可以形成一个通用的需求库。其实在需求中,发现不同需求所用到的功能很多都是类似的,那么后面如果再碰到这样的需求,我们可以在这个基础上面进行复用,从积累的需求库中,提取出相应的功能即可。
下面来介绍Excel形式的需求文档的模板,定义好模板结构之后,可以快速编写。
文档的编号和命名很关键,每个产品都是经过若干个迭代才完成的,而每个迭代所完成的产品功能或者升级的需求都可能是不一样的,因此需要定义清楚该文件属于产品的哪个迭代,修改了几个版本。
文件命名的方法一般是通过版本号定义,比如简单的方法是:XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号,后面的V2 PRD的版本号。
需求文档的封面基本信息,需要注明产品名称、需求文档的状态、当前版本、编写需求文档的人员和完成的时间。
产品是分多个版本迭代的,关于需求文档修改的记录页需要记录下面,包括:版本号、修订日期、模块、修订说明、修订人、备注。文档版本号显示的当前修改的内容属于文档的第几个版本(当前系统的版本XX产品V1.0+修改的版本V1),模板是具体到修改内容属于的功能模块,以便阅读人及时找到修改后的内容,修改原因说明为什么要修改该需求,让阅读者直观的了解原因。日期是指需求文档修改的时间,修改人是指需求内容的修改者。
需求文档的模板参考上图,需求文档的关键属性说明如下:
】
在编写需求文档的过程中,往往因进度紧而来不接写的完整,这就需要技巧性的简化文档,不妨先出一个系统框架,然后再补充每个栏目中的内容,最后再来扣细节,这样在检查的时候,能够及时发现需要是否有遗漏。没有任何文档是一次能写好的,所以在初期版本不要一上来就追求完美,有瑕疵是很正常的,在考虑到不影响开发设计工作的前提下,将后期迭代的思考加入其中就好了。
例如:一个活动管理页面如下,那我们要如何编写活动管理模板的功能说明。