听我的，必须干掉中台！

墨笑书:
最共情的一个视频，我以前在杭州的一个某电商代运营上市公司就是学的阿里搞中台，给我最大的感受就是，没关系寸步难行。除了已经做通的SOP以外，创新的需求基本执行端是推不动的，发给中台的需求优先级完全取决于发起人而不是需求本身，这里有一个矛盾，即领导基本不做具体执行，而在中台模式下，能推进创新需求的却只有领导，所以大量的执行需求停留在请求批示状态，即拖累了执行端效率又增加了管理的复杂性，更不用说中台端本身就是反创新的，你提出的任何新需求=我新增的工作量，而你创新的收益中台端却不能直接分享，权利和责任的分配才是中台的根本矛盾。

【回复】我也经历过，中台搭建后，第一要务慢慢会变成保证稳定，然后基本就不接受任何业务需求了[藏狐]
【回复】我们小组就是，为了保新业务增长，老系统维护只放1个人力，而且还必须得做出增量（比如解决了原有的xx bug、提升了xx运行效率），否则只是处理oncall或者临时故障的话也不计工作量的（而且有些老系统对接很多下游中台的，往往就是下游SLA降低影响我们的服务，但是排查完下来发现只能叫下游帮看，没有增量可做所以依然不算工作量）
【回复】回复 @woo502 : 每天的工作就是写需求文档[脱单doge]，然后被打回，然后@领导，然后当面口头解释为什么一定要做，然后领导再口头去交涉，然后重发需求，WOW效率太高了[doge]
大标头:
游戏公司的中台都是纯支持的部门，比如美术，数据，不涉及核心构架，比如就没有游戏策划中台。还有就是底层框架的，比如一个游戏类型的核心框架，在这个之上做修改，这个部门只给其他工作室做这个框架部分的支持，其他的修改和调整由各工作室自己去做。虽然也有效率和沟通问题，但不会出现因为中台不支持或者排不开导致业务无法开展最后绕开中台自己做这种情况

【回复】游戏公司的中台一塌糊涂的也多，最典型的中台为了证明他们牛逼造所谓黑科技逼着项目组用，然后项目组用着要么跑不动要么一大堆细节问题，然后把项目组搞废，最后还要说这个项目组水平不行[微笑]
【回复】游戏开发太标准了，底层框架很通用，就看低代码平台和蓝图对比，蓝图都不知道强了多少倍。 游戏本身作为一种艺术，商业模式很固定，更多依赖内容，所以只要是辅助高效生成游戏资产的，再怎么提效都不过分。 而业务产品里业务逻辑和模式占大头，做通用了全是问题，立项成本、沟通成本、运营成本，一切成本都会上升，而实际能复用多遍的轮子，一个基础平台部门就搭完了，中台大多数时间是在拖业务后腿，然后小部门没优先级死的更快了，最后整个组织都停止创新，只能围绕核心业务收缩，属于大公司头铁硬撞墙，小公司一去不复返。 不过中台最大的好处在于改革，改革就会造就新贵，就会发生权力转移，虽然整体很沙币但部分人可以腾飞，哪怕知道这东西坑多大，从业者还是会向各大传统行业渗透游说，大厂刷段经历学一套管理模式忽悠忽悠就能过去当个总经理，落地的时候拉上咨询公司跑几轮，从无到有基本折腾几年就升走了，留下一地鸡毛相信后人智慧[捂眼]
【回复】我那游戏中台分美术和技术，技术中台负责用户系统和对接其他平台api，不用管游戏具体业务
曦哥的真情:
我从来没看老曾在视频里这么激动，真的要爆了，看来当年打击不小。

【回复】老曾的想法是，有钱要赶紧赚，不用管那些和赚钱无关的鸟蛋中台！我今年的kpi才是最该考虑的…… 而上面的想法是……舍不得孩子套不着狼……先做做看！我这么大公司，总不能啥也不想，只管赚块钱吧？
【回复】切身感受，当年还不能吐槽，今日终于可以一吐为快[喜极而泣]
凌逸lingy:
我理解的中台就是一种变相的行政，掌握核心资源和决策权力但不是业务导向，行政的目的是帮老板最好管理，中台也就是老板管理业务的新手段，防止业务过多自己被架空

【回复】但有一条是up吐槽的点，需要频繁换模具的零件中台不想干，他们觉得自己做通用模块的，你这频繁换模具不符合我中台的设计理念，业务部门觉得我就是做整合的，你是做零件的，应该由你做，矛盾通常会折磨产品经理，因为产品经理经常会被夹到中间
【回复】回复 @小鹿deerj :中台的初衷是为了更快的前台业务创新，结果做成了最不希望频繁变更的部门
【回复】应该理解为中台做各种零件，各个业务线按照自己的需要把模块做不同的整合，就比如做车，中台把发动机，车轮，车门等等都做好，其他业务线按照自己的需求做两轮的三轮的四轮的车，需要什么零件拿什么自己组装
二十岁的春夏:
个人觉得还是好大喜功。 不是这个事儿不对，而是时间不对，现在的技术完成不了一个合格的中台。代价比想象中高很多

【回复】回复 @这样真的是太好了 : 可以大概理解为，你有个东西需要做成ABC，而隔壁部门有个类型的东西但需要做成ABD，那么AB它们就是重复的。这个时候就可以把重复的部分交给中台处理，你和隔壁部门只处理各自不同的C和D即可[doge]
【回复】中台是个伪需求。从根子上就不可能实现。除非你功能的颗粒度足够细，能支撑我所有的差异化需求。但话说回来到那地步和我自己写代码有什么区别。
Agent276:
我觉得中台本意是好的，很多共性的东西中台做了业务单元就不用重复造轮子了。比如我中台搞了一个购物车系统，后面出个X宝我集成中台现成的，再往后要搞一个X猫这个时候我也直接集成就行了。一开始想想是好的，后面真的X宝在做的时候就变成这东西本来做做也不复杂，我们自己能做，我知道中台有通用件能拿来用，但这样绩效还要分过去，还要跟他们沟通联调，想想自己重复造个轮子算了。

【回复】通常需要重复使用的产品是竞品[doge]
【回复】强耦合集中到一个地方，一阻塞就丢失上下文。一碗水端平的难题。
【回复】回复 @hanin123 :[doge]这一集主要是曾老板从阿里出来后阴阳马云屁技术不懂的。俗称马云只是运气好找到能人帮他在风口上当猪飞。听话听音，他哪里是来讲中台的
飞奔的鱼丸:
把可复用的模块抽象出来做成模块或组件，放到组件库里共享，有需要的就copy或者调用，满足不了的自己做就好了，这样确实可以减少一定程度上的重复造轮子，但如果非要做成中台，就得做标准化，因此其复杂度随着业务扩张带来的维度增加呈笛卡尔集式的增长，并且还要做一套与之匹配的配置管理，对于负责该模块的产品和技术确实可以锻炼和拔高，但是一旦人员流失就瓦了

【回复】其实就是用有限的人脑逻辑去描述无限的世界变迁，这是典型的程序员式的职业自信。再加上官僚不能随时跟踪，设计从开始就落伍了。组件化在这种模式下是不可行的，业务人员和程序员都无法区分组件的粒度。程序员的思维趋向收敛，一招破万法。业务人员的思维趋向发散，一法有万招。
【回复】回复 @loslow : 我倒是倾向于把这些组件视作现成的工具，如果其他业务适合复用就拿去用，不适合就自己做，并不是非用不可，当这种共享的工具积累到一定的量级，开展新业务就跟搭积木一样，拼拼凑凑模型就出来了，岂不美哉，当然这些工具也要带上对应的说明书，用法灵活点呗，程序员都知道copy现成代码自己改改节省时间，产品做新业务也一样会参考或者抄竞品做设计
【回复】回复 @极致奢华的小板凳 : 而我现在的公司，做中台的是一个有股份的老员工，是单独的部门，天天和老板吵架，老板都说再搞不出来就要让他走人了，而一些新业务的前端小组他们根本不用中台，猴年马月才成熟，用的是另一套他们的系统，而我们物联网研发部则搞的是另一套，幸好和他们业务关系不大。是支持部门[吃瓜]
凤凰是不死鸟:
最为曾经的阿里人，最大的问题的没有沉淀出真正的既懂业务又精通软件架构的架构师团队，一年年的KPI考核不会等你沉淀，人才都被3.25然后被优化了[脱单doge][笑哭]

【回复】[滑稽] 都是小年轻哪里来的懂业务的，刚搞懂就拜拜了，就像一个工厂，成天把30～35的熟练工开了，工厂里面没几个懂产线的，全是就会大螺丝的小年轻，结果产线有问题全抓瞎，问谁都不知道。最后把大量时间放在处理问题上。
【回复】我就是一个既懂业务又懂架构的架构师，我们这种人最头疼的就是下面的小产品工作几年对业务的理解没我们深，然后我们能发现产品需求文档和实际需求差距太大，然后天天跟产品吵架。产品那边口头禅就是你是产品还是我是产品，我搞了十几年产品开发你这种想法的产品看的太多了。
【回复】回复 @克尔苏加德OvO :然后考核制度对架构师成长不利，所以也很难养和筛选好的架构师
irreallich:
这就是业务优先模式的思路 一切以业务为主 说白了就是没什么科技含量，什么赚钱去做什么 比如互联网赚钱公司 还有另外一个技术优先的模式 一切以引领潮流引领技术为主 比如英伟达，Google，微软等 英伟达认准了cuda，从十几年前市值很低的时候，宁愿显卡业务上少赚钱，也要坚持cuda，才有了今天的技术垄断 google做安卓也是一个道理

【回复】大部分公司本来就是应该业务为主，从科研到专利到相关工具的形成到商业模式的成熟这个过程的风险根本就不是一般公司能承担的，就应该是大公司研发出有用的工具，其它公司购买相关服务才合理
【回复】阿里很矛盾，听口径特别是马云嘴里说的，都像是阿里是创新驱动。实际上蚂蚁，tb都是业务驱动。而且阿里的业务线还贼强。
FrankEDM:
大厂的话，做一些通用的开发运维工具合并是可以的，不用重复造轮子，比如CICD，代码编辑器，微服务治理，监控，paas平台，可以把各种开发上线流程提效，就行了。中台这种东西很多时候真没必要，你说他通用吧，他通用在哪里呢？本质上也没什么核心技术，数据处理还得按不同业务逻辑，你还得跟他讲一遍业务，还不如各个业务部门各自加点人算了。几个人忙里忙外，搞不懂业务，有一些东西兼并不了的还要定制化，太没必要了。

【回复】又有业务经验又有架构抽象能力的人很贵，请不到。没这样的人不如不弄
记录碳头的日常:
我现在在的公司就是这样，系统越弄越多，数据也需要更多人去输入，但是并没有什么真的卵用...

【回复】表，数据化，集合，分析。如果本身就是表够清晰，不出错，上级部门想要数据的时候，能在1小时内给予，的确卵用。我们单位年底要问各个业务部门要销售数据，订单的分布数据，往往到等3天。ERP几分钟就搞定了，也不需要去催业务要数据。领导部门想看的时候就能看。工厂越级找领导，领导看数据也大概知道什么情况，省的某些人脑容量不够回忆不好。
【回复】回复 @xiao46121 :是的，这些乱七八糟的系统都是为领导服务的，而且很多时候张罗做系统那个领导还有不低的返点，所以外包做的系统越来越多，需要递交的数据也越来越杂，苦的是一线员工。
【回复】回复 @superwave :头痛是肯定的，财务要数据，市场要方便，你还要和软件开发做对接。最好的办法就是带上开发一起去财务和市场，大家的供需关系明了，软件能最快进度的开发下去。码农拿那么高工资，总要体现一下能力吧。只要市场的人不是文盲，现在的软件基本就是点点点+数量，最后自动生成需要的表。有了数据，财务不就是建模、数据分析、做账。怕就怕市场搞黑钱，弄的太明白财务去老板哪里打小报告。
机械亲王:
中台这件事我持保留意见。如果独立业务搞闭环，业务一听能快速上线满口答应，但是一旦到了大促业务也要来蹭一波红包，那不好意思，不在一个流程体系里玩不了，业务在那里干跳脚，结果还是得做融合，业务才不会管你是中台还是自闭环，业务只看结果；你也说了很多业务流程不一样，如果没有中台这么一个统一的执行标准，结果就是你产品经理有这个精力就把所有的跨业务叠加场景评估进来，然后技术再从一层层屎山代码里搞清楚每一个ifelse做方案保障，方案复杂度几何倍数的膨胀，各种并行项目还都得有这个自觉，否则各种叠加各种出问题；倒头来还是技术跟着倒霉；中台为什么是核心业务的外包，因为核心业务给预算了，创业新业务是不给钱的，说到底不还是业务自己的预算策略问题，给钱的业务配专有资源，不给钱的走公共排期，我也不觉得有问题；说到底，是不是有资源支持创新业务，并不是只中台的问题。

【回复】你要搞明白，游戏领域里面的中台都是一些什么东西，而且游戏开发周期远比现在互联网应用的周期长的多，开发模式都不是一套，你用别人的逻辑，我上面说了，你说的这些根本不需要一个什么中台，一套标准化接口全都搞定，需要你去搞中台么这个单独东西出来么。
【回复】回复 @Hey挡 : 说到底，互联网还是一群臭做生意的，计算机技术只是辅助工具而已。这就是我最大的感受
【回复】还是你觉得，操作系统和其他应用互联也是中台技术呢，还是硬件通用接口也是所谓的中台？你中台就不会屎山代码了么，不会为啥要重构呢。
爱吃锅巴菜:
整合什么？说白大部分时间都是在夺权夺资源吧？ 干得好是中台调度得当，领导指挥有方，屁颠屁颠跟大老板汇报去， 干不好就是底层执行不力，各种复盘 扣钱， 中台没人问责，只要能讲明白故事和ppt，然后就是脱离实际天天闭门造车的馊主意让下面无条件执行， 如果此时再加上一个无能甩锅的直管领导，那就更热闹了

90后已老去:
中台分业务中台，技术中台，数据中台，技术中台防止重复造轮子，数据中台对于大数据有必要存在，业务中台是商业模式的抽象，是想快速复商业模式，比如滴滴的打车，顺风车，快车，租车等类似的业务，有很多核心业务类似，就可以使用业务中台，这对架构师有很高的要求。

【回复】昨天跑步的时候在想这个问题，其实业务中台可以由业务来做，通过业务考验后再集成到业务中台，没必要开始就非走业务中台变成阻碍
【回复】回复 @猫剑0_0 :数据很多，但是又脱离于产品日常的运营，确实是需要一个中台负责数据生产定义使用展示归因的全流程的，这个让产品运营来搞，头都是大的，搞数据很繁琐也很专业。
【回复】对，我也想说数据中台非常重要。不然你就看着一堆互相打架的数据和莫名其妙的数据源反复刺激你的大脑…到时候指标都不知道怎么整理。
帕先森呀:
必须三连，我们公司跟你说的几乎一模一样。第一，说是复用，其实可复用的微乎其微，复用的成本高过重新开发的成本；第二，组织架构的变迁让沟通成本急剧上升，本来只要沟通前后端，现在加一个中台；第三，确实无法刹车，能提出这个概念并推动的人往往位高权重，位高权重者是不可能当所有人（尤其是他的领导）承认自己浪费了公司机会和资源的；第四，中台往往会变成一个大后台，后端同学会全部去到中台，来做后端的架构，问题来了，那中台还是不是中台

【回复】说到底，大包大揽，边界不清晰，中台相当于一个服务提供方，而不是构建方，这是我的认知，如果大包大揽什么都要搞，差异化你很难做的，对于特殊需求你要么让别人单独做，要么你的服务能支持他们做，说到底，就是啥都想做，上层差异化那些东西就不要管。按着UP的描述，我感觉阿里这些人更想构建的其实是一套工具，类似游戏开发逐渐出现的所谓引擎，其就是一套构建工具，但是游戏这东西方向性和边界是比较明显的，而且大型游戏开发周期很长，不是适应现代网络服务这类敏捷开发，游戏那些人，搞一个新类型游戏突破原有边界，发现工具不能满足自己新游戏的技术要求了，要么自己写一套工具，要么对原有工具做更新扩展，这都是要时间的。
jiangzhan1009:
不能一概而论，有点标题党。本人经验，银券机构，贷 存 理财的核心业务系统肯定是中台化的，本质不在于多么解耦 多么可复用，而在深度理解业务，比如复杂金融产品代销系统，不可能每个获客端单独一套上下架 交易 清算系统。但跟业务绑定不是说你只管你业务内这一亩三分地，而是系统职责之内必须要提供支撑。但每个企业环境不同，如果自上而下的决策和资源强力支持，又有自下而上的业务场景依赖，这事儿才顺理成章一些。没必要神话也没必要妖魔化中台。

【回复】那是因为你们这类产品一般很少做新需求，你可以了解一下市面上其他大厂的产品，基本都是瀑布式流程，市面上哪个功能火就马上抄，先抄好的产品就能占的先机。与其浪费那么多时间跟非本业务团队去沟通需求，还不如业务团队自己做好拉倒呢。因为非本业务团队的人根本不了解这个需求可能涉及到的其他功能耦合部分，产品如果一开始没想到没同步到位的话，后期才发现的话就肯定得延期，这部分风险实在太大了。相反本业务团队虽然开发要点时间，但是风险可控
【回复】说白了特别是银保证监管主体下的业务模式，流程复杂而固化，跟零售还是差别很多的，所以感觉UP武断了，要么限定词加好，在自己熟悉的领域声音可以大点没关系[脱单doge]
【回复】回复 @jiangzhan1009 :每个银行的业务都是固化的，但是每个银行的业务都有细微差别，就那一点点细微的差别就得找一堆人才能处理掉
优花里:
哈哈哈，和我们的erp系统一样，但集团公司还是强制用

【回复】有句话咋说来着，上erp找死，不上erp等死[doge]
【回复】回复 @优花里 :嗯，所以其实erp上之前要做oa的流程梳理或者再造。需要业务部门充分参与跟支持，也是很忌讳生搬硬套
【回复】erp其实用的好很省事[吃瓜]