产品的臃肿过程

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

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

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

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