国内中台概念大概率来源于阿里的 大中台小前台的概念吧
但是对此有一个深深的疑惑，前中台的人力如何平衡？
中台目也在直接承载来自前线事业部的需求（中间环节，产品很多时候是透传前台需求），这时候所谓中台又会背负所谓中台建设的职责，即考虑通用性、避免重复建设、考虑作为中台后期的扩展性等等
但是有个非常大的困惑，中台人力也比较紧张，而且在人力资源不变的情况下，中台对接的是多个前台事业部，而这多个前台事业部各自的需求即使有多有少，有大有小，后面按照一定频率汇总到中台的时候，在人力相对固定情况下，需求会越来越多、大型项目也会越来越多、中台功能越来越丰富、中台面向不同事业部想快速验证的时候，交付质量、整体架构一定会变得越来越糟糕（因为人力不足，大多时候都是赶工赶点的做出来的）
而且有时候中台产品各自对接前线事业部，团队内部信息差较大，直接沟通少。加上产品更关注来自前线事业部的评价、满意度评分，就会经常出现一些话语：“我不关注其他事业部是啥、以后再说、其他事业部和我没啥关系、先支持我这个” 等等研发听到极度反感的话，毕竟再好的技术架构，也顶不上需求的瞎胡乱造
到最后，可能看起来表面祥和的所谓中台，背后里其实可能都是所谓的拼积木一样拼起来的应用，碰一下就乱晃，岌岌可危
在里面的维护的同学开发体验痛苦，没有好的架构支撑，很多是特殊逻辑和定制化开发，小心翼翼增加一个小东西，影响面评估不了
影响面评估不全面落地到测试手里就比较痛苦：影响面评估不全，也就意味着存在潜在风险，而且这个风险有可能会在线上某一处暴雷。而这种暴雷说不定在上线之后一个月才暴露出来，完全不知道是当时某个改动引起的
如何破局？
- 控制需求质量
- 加人
如何加人呢？ 排期紧张，给出的工作量评估多次超过团队负载。 但是这个要多次才可以，但这几次的负债其实也就慢慢积攒下来了
