公司经过4年的发展的，从最初的10个人到300人、从最初的单一产品线到四条战线齐驾并驱，从最初的一城一池到全国行业第一，在这个算作快速的发展中，作为研发四年里的感觉是一年比一年痛，或者说快乐且痛着。市场业务的快速扩展，无时无刻不在拉扯着产品技术，不敢有任何松懈。

但随着团队人数、业务线扩大和越来越复杂，在当前的这个时间点一种无力感尤为突出。质量与效率的平衡，满足市场需求的速度都不再是能通过增加人手可以搞定了。

公司内部在修炼制度的同时，产品技术域应该做怎样的调整突破？

既然是要改变，那就先说说要改变什么，只有理清了问题才摸得到下手的脉路。

技术痛点第一次

和所有的故事开始一样，人少枪少的年代，一切都从简单的开始。最初的工程就是一个单war的工程。

市场走的很快，大家常聊的单体诟病自然少不了：代码臃肿撑大工程，编译发布效率低，难以维护，模块之间连肉带筋等等。

但彼时彼刻上面的问题团队认知的还不是那么深刻，因为团队人数也还只是10人左右，有事吆喝一嗓子，比啥都好使，而另一个问题则是团队的初痛。

那时，我们使用一个单体工程以SaaS的方式项目化服务了两类用户对象A和B。A与B在平台上是供需的关系，就类似淘宝的卖家与买家。但问题发生在，作为需求方的B中也有一部分客户群体同样需要A相同的功能，我们且称之为功能Z。

本着不重复造轮子的原则，我们高举复用大旗，很轻易就满足了B。从这一刻，事情变化了。做为服务方A是功能Z的重度用户，基本每个迭代版本对这块都有更新。B就不理解了，用的好好的东西为什么会变。这冲突积攒着，也便触发了我们第一次工程拆分。

技术痛点第二次

我们抡起一把大斧头，对着工程一劈两半。

随着这一斧头下去，我们逆向执行了康威定律，在团队内也分出了团队A和团队B。当我们沉浸在终于可以撸起袖子再大干一场的情绪中，还没有过半年第二个痛点如约而至。

客户这个上帝始终是让你琢磨不透，又或者我们并没有在这个行业滚打10000小时。因团队与工程的拆分，这个项目的技术走向发生了差异。同时，因为有业务上的往来，工程之间相互依赖。原本单体工程中的依赖耦合，现在演变为两个团队的交织不清。并不会像鸣人与佐助的羁绊，更糟糕的是团队心境发生了变化。那些我的问题还是你的问题的问题，开始不断的消耗团队的精神。那时候，我们大概有50人了。

还记得那个A和B都需要的功能Z吗？现在变成了，如果一个被判定为相通的需求，A团队和B团队需要同时做一遍！！！天！！！

一直在心里骂自己是个蠢货，怎么干出这么折腾的事情，直到两年后看到《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》这本书的这幅插图才有所释怀。

不过蠢还是蠢，别忘记了工程A和工程B还是那样的单体存在着的。