不好意思的说,我没法接:你没有功能需求设计文档
这种撸起袖子就开干的方式,看似简单高效,便于直接沟通,能够快速迭代。却不知,发现没有一份正规且实时更新的功能需求设计文档,会付出三四倍的代价来弥补。
最终会引发一场产品狗和程序猿之间的“猿狗大战”…
WHY – 为什么需要功能需求设计说明书
在没有功能设计文档时,主要有如下几个问题:
前期研究团队沟通成本
如何要让团队里面的所有人员对软件产品的功能需求设计有一个共识?没有功能设计文档,反正我是想不出有什么办法。当该项目的团队人员越多,沟通成本就变得很高。
研发人员很容易有一个通病:以为自己了解了一小块需求就立即开始埋头狂撸……代码。最终很可能与项目经理和客户真正想要的功能相差甚远。
更可怕的,研发人员把数据库设计好了,代码也已经写得差不多了,这时产品狗突然跑到程序猿这,说我们的需求要做一点变化,大家都知道,“对产品狗来说那一点变化,可能会害得程序猿撸过几天几夜”。那很小的变更可能导致之前设计的数据库,码的代码都不能用了。对于程序猿没有什么比加班加点写了几个月的代码,最终被产品狗告知需求变了,代码要删除重新写更可怕的。估计只能用涨工资来安慰一下那受伤的心灵了。
还有一个比较隐藏的事情是,每个程序猿都认为自己写的代码很牛逼(其实对于大多数人这只是一个错觉,你写得代码并不优秀),不太愿意删除之前所写的东西,总是想在原有的代码基础上进行修改,让他们删除代码比杀了他还难。
作为公司的技术负责人,我每几天都会Code Review团队里面所有人的代码,一直要求他们把不用的代码去掉,但他们的应对方式总是加两个//。注释掉他们写的代码,而不是去做真正的删除动作。他们总有自己的理由,“这只是暂时注释掉,后面会用到”,但最终的结果是那些代码就像尸体一样,一直在那里,干扰着团队人员正常的思路。所以我只能强制性让他们那些“暂时没有用,以后会用到的代码”干掉 。
前期任务进度安排和分配
该文档也是任务进度安排和分配的重要依据。在没有功能需求设计文档之前的所有任务进度计划都是瞎扯淡,都不知道具体要做什么东西,哪能拿出合理的任务进度计划。如果你拿出来了,我也不相信那是经过认真分析做的进度计划,我知道那只是用来看领导看的。
中期产品经理需求变更
软件在开发过程中难免会遇到功能的需求变更,将程序猿们召集在一起把所有的变更讲一遍?当走出会议室的时候可能每个人都有自己的理解。下一场战争已悄然临近…
后期测试团队产品测试
测试团队应该在项目Kickoff之时就应该介入,而不是在产品开发完成之后。测试团队应该对功能需求设计文档充分了解,且以此来编写具体的测试用例文档。否则,只能是在界面上进行简单的表面测试,而真正的BUG并不在表面,这些BUG会藏得很深,等发现的时候可能已经造成很大的损失。测试团队想覆盖全部的测试用例此时已经相当困难,他们甚至都不知道产品有哪些功能。
测试用例应该尽可能详细,尽量保证测试用例走完能确保产品能上线发布。