项目开发中,文档撰写究竟有多重要?
昨天接到领导通知,支援隔壁兄弟项目组。同样是报表开发,他们人还比我们多。为啥还需要我们项目组支援呢?不问不知道,一问吓一跳。原来是需求分析这一关出了问题,用户测试时发现数据对不上,而今甚至连可复盘的需求文档都不完整。好家伙,难怪他们大过年的也在加班。
问题背景
在需求分析阶段,由于项目周期紧,BA(Business Analyst)在和用户沟通后,没有给出足够清晰的业务分析文档,甚至很多逻辑直接口述给开发人员。而项目到了后期,用户进行验收测试(UAT,Uaer Acceptance Test)时发现数据对不平。那咋办?检查项目代码,再次确认业务逻辑咯。而在此过程中一个很重要的依据就是需求分析文档,这记录了项目一半以上的工作。可惜需求文档并不完整,无法给项目复盘提供有力的支持。同时因为缺少文档,某些业务逻辑连BA自己都无法自圆其说。如此一来,BA要和用户重新确认需求并落实文档撰写,开发人员基于新的文档,好几处逻辑需要修改甚至重新开发。Deadline近在眼前,项目却面临推倒重来的风险?尽人事,听天命;项目组整个春节都在家加班。
BA、用户、开发铁三角
可能有小伙伴会问了。开发不是可以直接和用户沟通吗?当然可以。在和用户谈需求的时候,开发往往也要在场,技术和业务结合自然最好。但时间紧张的时候,就几乎只有BA和用户谈需求了。而且用户往往是国外友人,需求分析的第一关就面领着语言和业务的双重考验。同时由于金融领域的业务复杂性,为避免理解上的偏差,BA往往有着金融专业背景。作为一枚小开发,不得不说在此面临的窘境:我知道我的数据从哪里来,中间经过了怎么样的处理,最终存储到哪里去。但有时候我不知道为什么要这样处理,业务背后的意义又是什么。故而在和用户的沟通上,BA充当了一个重要的桥梁,让开发能够专注于业务的实现。专人专事,在这样一个年轻的团队,取得了不错的效果。
如何应对口述业务的场景?
不要嫌麻烦,把口述的内容形成文档,反复邮件确认,可以避免后续潜在的很多问题。这里突然想起去年的时候,也是因为项目周期紧,BA没有时间进行系统化的文档梳理。没办法,每次口述完业务,我都通过邮件进行二次确认,一个报表开发完后,形成了一串长长的邮件列表。虽然麻烦,但也为后面的复盘带来了很大的便利,有争议的地方也可以直接拉出邮件:“看吧,我是严格按需求文档来开发的!”
开发人员暂时不理解业务怎么办?
虽然了解了业务处理逻辑,但感觉还是没理解透怎么办?除了反复的请教、确认外,还有一个方法——数据流分析。作为一个软件工程专业的孩子,数据流分析法是我用的最顺手的策略之一了。项目周期紧没时间慢慢理解业务了?没关系!对于程序开发来讲,先理清楚以下三个问题就可以支撑起初期的业务实现了。
- 数据从哪里来?呈现出什么样的格式?
- 数据要经过什么样的处理?
- 数据处理结果要到哪里去?
总结
工作场景中,远不止是需求分析,许多情况下都需要有书面的文档记录,此中的意义远不局限于复盘。