项目初期的思考

前阵子新加入一家公司,由于公司业务扩张极快加上项目初期人员能力相对较弱,项目架构设计编码等各方面都留下了大大小小的坑,越往前走越感到举步维艰。

如何做?项目重构基本已经达成共识,但是重构需要考虑效率、成本、数据库拆分各种头疼问题,目前依然在讨论在思考,重构方案确定之后再专门整理出来。

今天想说说关于项目前期业务极速扩张,资源有限情况下,是尽快完成业务开发,还是考虑项目整体结构注重项目后期维护。

先说说这边初期的情况。

公司创业初期,技术薄弱,资源匮乏。幸运的是团队执行力强,抓到了不错的创意,赶上了互联网教育潮,幸运的拿到了融资。随着市场销售等方面的发展,对项目的功能要求越来越多,越来越强。本来一个前端的小网站,变成了包含销售、客服、市场推广、财务(简单)等多项功能的大集合体。薄弱的技术团队成了短板。

招聘困难,技术没有积累,资源有限,成堆的业务,不断添加的功能和改动。

——我要的XX功能啥时候能出?

——这10个功能明天必须要上。

——这么多BUG你们怎么搞的,行不行啊,今天再加几个工呢功能,赶紧的,今天必须全弄好。

——昨天提的那个功能改成这样的哈……..

苦逼的技术负责人:喵了个咪的,就这俩人,要这要那,要个杰宝啊。

面对公司各部门老大、青面獠牙的产品汪,技术团队加班加点,以一当十。什么维护性?安全?BUG?管他呢,没人说就先放那,哪有时间管这个。一晃两三年过去了,初期的无奈变成了技术团队开发的习惯……项目越来越惨不忍睹。

随着公司拿到C轮融资,技术部门的预算也增加了。招人,找人,要……

——我擦,这里怎么能这样设计呢,完全没法维护啊。

——这么大坑,根本就填补上啊。

——这样子不验证可以被人刷死的。

最后项目大量的问题,从架构、数据库设计、编码规范、系统漏洞方方面面都达到了瓶颈,重构(重做?)势在必行。其次原来团队人员养成了坏的习惯,制定正确的规则慢慢推行,困难重重,摊手。

思考:

1、如果开始就考虑各种维护性、安全性、架构合理、稍微慢点开发可以吗?

————不行!创业初期,就是拼时间拼执行力。早一天用上就可以帮公司提高效率,节省大量成本,促进公司发展。(这也是国内创业公司大量使用PHP的原因)

2、如果添加人手合理分配工作量,资深技术人员做好底层设计、审查核心代码,怎么样?

————比较合理,也是很多中小公司的方案。但是在这边存在的问题:1、技术方面没有积累,没有相对资深的技术人员,2。公司对技术团队预算有限,招人难。所以……

回头来看,当初的方案选择虽然是无奈之举,但是是正确的。

重要的是,技术负责人执行力很强,总是有各种办法在变态的设计下完成变态的要求或者逼迫产品汪让步换一种方法实现需求,加上项目的难点在于复杂度不在于访问量。项目到目前位置还是可以继续使用的。成功不仅仅是运气好。

关于创业公司技术方面个人的看法

1、需要有一个技术较强的负责人,有经验,有能力。可以在初期给团队指定好规则,团队健康的发展。做好底层的架构设计,防止后期出现大规模重构,底层数据重构。

2、既然创业初期,忙是跑不了的,都忙着把各种变态的需求实现了,拿就再加把劲趁着项目相对稳定的时候做做重构,不要给自己留坑。