近日一则腾讯 TEG CDC 整个部门解散的消息在很多群里炸了锅，有的唱衰互联网行业，有的唉声叹气，还有的甩锅到 AGI 的发展。总体上来说，这个事情的确已经发生了，我想从组织架构和整体效能这两方面来分析下这次组织变化。

腾讯 TEG CDC 解散

6 月 28 日，网传腾讯 TEG CDC 整体解散，人员涉及设计师、开发人员等，数百人规模。CDC 是腾讯技术工程事业群 TEG 下属的一个中台化的设计支持部门，全称“腾讯用户研究与体验设计部”，2003 年开始组建，CDC 的初创成员唐沐、陈妍。CDC 负责了腾讯成立以来许多重要产品的体验设计：如 QQ、QQ 空间、QQ 游戏、RTX、QQ 电脑管家、QQ 浏览器、QQ 音乐、腾讯视频、腾讯地图、QQ 拼音、SOSO、拍拍等等。多年来，CDC 培养了上千名用户体验相关从业人员，现在，他们在多个行业、企业及岗位上担起重任。

聊聊中台部门的意义和价值

中台是一种体系/生态/方法论，解决顶层领域下各业务子域的高效协同和资源复用问题。中台源于何处未知，确实最早在阿里大中台小前台的策略下流行起来的，但是后来阿里又主动打破了中台，把技术下沉到了业务，这是后话。目前主流的中台定义和分类有如下四种:

• 数据中台:通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。

• 技术中台：提供技术重用组件能力，技术支撑能力，帮助解决基础设施，解决基础技术平台的复用。如微服务框架、DevOps 平台、容器、DB 等。

• 智能中台：提供共享算法能力，帮助提供更加个性化的服务

• 业务中台：或称为应用中台，提供重用服务，例如用户中心、订单中心、营销之类的开箱即用、可重用的能力。

中台建立初衷在于提效

其实，中台的想法在公司效率为王的时期是很好的。比如一款产品涉及 A 和 B 两个团队，A 团队发展迅速但资源有限只有 5 名设计师，B 团队需求稳定工作量小但有 10 名设计师。

存在的问题：

• 公司发展初期招聘不到足够多的特别有能力的资深员工

• 不同业务发展速度有别，资源不均衡

• 业务发展快，都急需支持

• 设计规范性差，两个部门两种风格，难以协同

解决方法：

• 把 15 名设计师独立成一个团队，由资深成员带领和指导

• 资深设计师制定产品规范和设计师支持计划

• 其它初级设计师按照规范工作，对多个产品进行支持，资深设计师进行把关

• 资源不足时，按照产品重要程度和时间节点等排优先级分配资源

这样做很大程度上解决了设计团队能力的问题，工作质量问题，也满足了业务发展的要求，公司整体效能得到了很大的提高。但是这种中台实际上是一种资源型中台，作为一个资源池，主要提供人力输出到业务线，和上面的各种中台还是有很大不同。

大而僵化的中台整体效能低

随着资源型中台部门变大，逐渐的固化和僵化，对业务的价值贡献度也在降低。

• 首先不深入跟进业务部门需求的初级设计师，会被业务认为不理解业务，阳春白雪，落不了地

• 其次资源池结构的设计部门，谁都去申请资源，申请更多的资源，甚至超出自己需要的资源。没有内部成本结算，设计师和业务双方也几乎都不考虑成本，整体效能低。

• 最后设计排期成为矛盾点。业务希望大干快上，踩着点一步步往前走，但是设计排期有自己的排期，双方节奏不一致，引起矛盾。

• 渐渐地业务方更愿意使用少量的 HC 去招聘一些有经验的资深设计师，按照公司 CDC 的规范专门支持自己的业务。既满足了自己的需求，也解决了排期的问题，但长此以往 CDC 的存在价值就更低。

资源型中台

整体上资源型中台的发展都会经历上面的过程，始于提效，终于效能差。除了设计师部门，下面的一些资源型中台也有这个问题：

• 专职和某业务对接的 SRE

• 专职和某业务对接的 QA

• 服务某个业务的运营

• 服务某个业务的客服

• 服务于一线的 PMO

• 
  

资源型中台建立的越多，沟通成本就越高，对业务的迟滞阻力就越大。每个团队都有自己的人力规划、资源排期和业务目标。当各个团队的业务目标和自己的业务方不一致的时候矛盾就会展现。业务 FTO/业务负责人就常会在这方面收到牵绊。

赋能型中台

上面说到的数据中台、技术中台、智能中台（算法中台）、业务中台，属于平台型、业务型，整体上来说通过屏蔽底层细节，建设平台和服务能力，支撑上游业务发展。虽然这些业务中台建立之初有大量的成本投入，整体上还是提效的，免去了很多人从前端到后端，从上层到下层所有东西自己都要动手写一遍，赋能属性是在的。至于能给业务点上几点天赋，这就要看建设方的功力和业务的诉求了。

本篇总结

整体上，我比较倾向于资源型中台打散下派业务线，赋能型中台保持短小精干长期聚焦。不要把资源型中台做大的同时，也不要把赋能型中台做没。这样做，对于公司来说整体效能是最高的，成本也是最节约的。