产品的臃肿过程

时间:2023-01-02 22:31:58

当面对一个需求时,产品人员会在完成时间与资源投入上与研发人员进行“谈判”,有时要么威胁,要么悬赏。产品人员关注的是系统可以做这事,可以做那事(以后可以做);而研发人员则为了自身利益着想则是想先把这事做了再说,于是两者便很快达成协议。至少在这一刻,研发人员只能聚焦到一个点上,因为单纯做一件事简单,所以重实现轻设计的恶习被养成!我已经遇到好多已经快编完码才迫于形势(质量要求)来参加设计评审的事情了。

随着时间的推移,我们的产品便由这些大都是“临时”或“应急”的项目拼凑而成,于是我们的应用系统便越来越庞大而臃肿。庞大可以理解,但臃肿是我们无法接受的。臃肿发展到一定程度,会严重影响效率,制约着业务进一步发展。我们在不停的增加机器,不停的更换性能更高的服务器。然而这不是通用的解决方案,有时候我们对现有系统已经不能在做什么了,于是“架构升级”便被提到日程上来了。这是个自然规律,我们的业务系统也需要“进化”。然而就像生物界的“进化”一样,有些物种被替代了,而有些则变得更加强大。“替代”的代价是巨大的!这意味着先前的投入被历史所埋葬,遗留价值渺小甚至没有。

我不得不承认目前国内的一流的B2C公司就是以这样的方式支撑着如此巨大的业务,并且有的以每年200~300%的速度在发展。他们的业绩非常的漂亮,但有多少人知道多少研发人员度过了多少个不眠之夜?这些公司技术大都落后于业务半拍或一怕甚至是瓶颈问题!小一点的公司因为业务量的问题,可能没有那么严重,但其技术实力我是不那么乐观的。

这是不是说明我们的技术很被动的呢?技术服从于业务我很认可,但技术永远跟在业务后面跑我不认同!