在很多软件公司,特别是一些创业型的团队中,对于这样的情景可能大家都很熟悉:项目经理或者产品经理(产品狗)口头或者简单记录一下软件产品的大致要做的功能,直接就让研发团队的兄弟(程序猿)去狂撸代码。然后他就去喝茶撩妹或者回家陪老婆了…
这种撸起袖子就开干的方式,看似简单高效,便于直接沟通,能够快速迭代。却不知,发现没有一份正规且实时更新的功能需求设计文档,会付出三四倍的代价来弥补。
最终会引发一场产品狗和程序猿之间的“猿狗大战”…
WHY - 为什么需要功能需求设计说明书
在没有功能设计文档时,主要有如下几个问题:
- 前期研究团队沟通成本
如何要让团队里面的所有人员对软件产品的功能需求设计有一个共识?没有功能设计文档,反正我是想不出有什么办法。当该项目的团队人员越多,沟通成本就变得很高。
研发人员很容易有一个通病:以为自己了解了一小块需求就立即开始埋头狂撸……代码。最终很可能与项目经理和客户真正想要的功能相差甚远。
更可怕的,研发人员把数据库设计好了,代码也已经写得差不多了,这时产品狗突然跑到程序猿这,说我们的需求要做一点变化,大家都知道,“对产品狗来说那一点变化,可能会害得程序猿撸过几天几夜”。那很小的变更可能导致之前设计的数据库,码的代码都不能用了。对于程序猿没有什么比加班加点写了几个月的代码,最终被产品狗告知需求变了,代码要删除重新写更可怕的。估计只能用涨工资来安慰一下那受伤的心灵了。
还有一个比较隐藏的事情是,每个程序猿都认为自己写的代码很牛逼(其实对于大多数人这只是一个错觉,你写得代码并不优秀),不太愿意删除之前所写的东西,总是想在原有的代码基础上进行修改,让他们删除代码比杀了他还难。
作为公司的技术负责人,我每几天都会Code Review团队里面所有人的代码,一直要求他们把不用的代码去掉,但他们的应对方式总是加两个//
。注释掉他们写的代码,而不是去做真正的删除动作。他们总有自己的理由,“这只是暂时注释掉,后面会用到”,但最终的结果是那些代码就像尸体一样,一直在那里&