近日一則騰訊TEG CDC整個(gè)部門解散的消息在很多群里炸了鍋，有的唱衰互聯(lián)網(wǎng)行業(yè)，有的唉聲嘆氣，還有的甩鍋到 AGI 的發(fā)展。總體上來說，這個(gè)事情的確已經(jīng)發(fā)生了，我想從組織架構(gòu)和整體效能這兩方面來分析下這次組織變化。

騰訊TEG CDC解散

6月28日，網(wǎng)傳騰訊TEG CDC整體解散，人員涉及設(shè)計(jì)師、開發(fā)人員等，數(shù)百人規(guī)模。CDC是騰訊技術(shù)工程事業(yè)群TEG下屬的一個(gè)中臺(tái)化的設(shè)計(jì)支持部門，全稱“騰訊用戶研究與體驗(yàn)設(shè)計(jì)部”，2003年開始組建，CDC的初創(chuàng)成員唐沐、陳妍。CDC 負(fù)責(zé)了騰訊成立以來許多重要產(chǎn)品的體驗(yàn)設(shè)計(jì)：如QQ、QQ空間、QQ游戲、RTX、QQ電腦管家、QQ瀏覽器、QQ音樂、騰訊視頻、騰訊地圖、QQ拼音、SOSO、拍拍等等。多年來，CDC培養(yǎng)了上千名用戶體驗(yàn)相關(guān)從業(yè)人員，現(xiàn)在，他們?cè)诙鄠€(gè)行業(yè)、企業(yè)及崗位上擔(dān)起重任。

聊聊中臺(tái)部門的意義和價(jià)值

中臺(tái)是一種體系/生態(tài)/方法論，解決頂層領(lǐng)域下各業(yè)務(wù)子域的高效協(xié)同和資源復(fù)用問題。中臺(tái)源于何處未知，確實(shí)最早在阿里大中臺(tái)小前臺(tái)的策略下流行起來的，但是后來阿里又主動(dòng)打破了中臺(tái)，把技術(shù)下沉到了業(yè)務(wù)，這是后話。目前主流的中臺(tái)定義和分類有如下四種:

• 數(shù)據(jù)中臺(tái):通過數(shù)據(jù)技術(shù)，對(duì)海量數(shù)據(jù)進(jìn)行采集、計(jì)算、存儲(chǔ)、加工，同時(shí)統(tǒng)一標(biāo)準(zhǔn)和口徑。
• 技術(shù)中臺(tái)：提供技術(shù)重用組件能力，技術(shù)支撐能力，幫助解決基礎(chǔ)設(shè)施，解決基礎(chǔ)技術(shù)平臺(tái)的復(fù)用。如微服務(wù)框架、DevOps平臺(tái)、容器、DB等。
• 智能中臺(tái)：提供共享算法能力，幫助提供更加個(gè)性化的服務(wù)
• 業(yè)務(wù)中臺(tái)：或稱為應(yīng)用中臺(tái)，提供重用服務(wù)，例如用戶中心、訂單中心、營(yíng)銷之類的開箱即用、可重用的能力。

中臺(tái)建立初衷在于提效

其實(shí)，中臺(tái)的想法在公司效率為王的時(shí)期是很好的。比如一款產(chǎn)品涉及A和B兩個(gè)團(tuán)隊(duì)，A團(tuán)隊(duì)發(fā)展迅速但資源有限只有5名設(shè)計(jì)師，B團(tuán)隊(duì)需求穩(wěn)定工作量小但有10名設(shè)計(jì)師。

存在的問題：

• 公司發(fā)展初期招聘不到足夠多的特別有能力的資深員工
• 不同業(yè)務(wù)發(fā)展速度有別，資源不均衡
• 業(yè)務(wù)發(fā)展快，都急需支持
• 設(shè)計(jì)規(guī)范性差，兩個(gè)部門兩種風(fēng)格，難以協(xié)同

解決方法：

• 把15名設(shè)計(jì)師獨(dú)立成一個(gè)團(tuán)隊(duì)，由資深成員帶領(lǐng)和指導(dǎo)
• 資深設(shè)計(jì)師制定產(chǎn)品規(guī)范和設(shè)計(jì)師支持計(jì)劃
• 其它初級(jí)設(shè)計(jì)師按照規(guī)范工作，對(duì)多個(gè)產(chǎn)品進(jìn)行支持，資深設(shè)計(jì)師進(jìn)行把關(guān)
• 資源不足時(shí)，按照產(chǎn)品重要程度和時(shí)間節(jié)點(diǎn)等排優(yōu)先級(jí)分配資源

這樣做很大程度上解決了設(shè)計(jì)團(tuán)隊(duì)能力的問題，工作質(zhì)量問題，也滿足了業(yè)務(wù)發(fā)展的要求，公司整體效能得到了很大的提高。但是這種中臺(tái)實(shí)際上是一種資源型中臺(tái)，作為一個(gè)資源池，主要提供人力輸出到業(yè)務(wù)線，和上面的各種中臺(tái)還是有很大不同。

大而僵化的中臺(tái)整體效能低

隨著資源型中臺(tái)部門變大，逐漸的固化和僵化，對(duì)業(yè)務(wù)的價(jià)值貢獻(xiàn)度也在降低。

• 首先不深入跟進(jìn)業(yè)務(wù)部門需求的初級(jí)設(shè)計(jì)師，會(huì)被業(yè)務(wù)認(rèn)為不理解業(yè)務(wù)，陽春白雪，落不了地
• 其次資源池結(jié)構(gòu)的設(shè)計(jì)部門，誰都去申請(qǐng)資源，申請(qǐng)更多的資源，甚至超出自己需要的資源。沒有內(nèi)部成本結(jié)算，設(shè)計(jì)師和業(yè)務(wù)雙方也幾乎都不考慮成本，整體效能低。
• 最后設(shè)計(jì)排期成為矛盾點(diǎn)。業(yè)務(wù)希望大干快上，踩著點(diǎn)一步步往前走，但是設(shè)計(jì)排期有自己的排期，雙方節(jié)奏不一致，引起矛盾。
• 漸漸地業(yè)務(wù)方更愿意使用少量的 HC 去招聘一些有經(jīng)驗(yàn)的資深設(shè)計(jì)師，按照公司 CDC 的規(guī)范專門支持自己的業(yè)務(wù)。既滿足了自己的需求，也解決了排期的問題，但長(zhǎng)此以往 CDC的存在價(jià)值就更低。

資源型中臺(tái)

整體上資源型中臺(tái)的發(fā)展都會(huì)經(jīng)歷上面的過程，始于提效，終于效能差。除了設(shè)計(jì)師部門，下面的一些資源型中臺(tái)也有這個(gè)問題：

• 專職和某業(yè)務(wù)對(duì)接的SRE
• 專職和某業(yè)務(wù)對(duì)接的QA
• 服務(wù)某個(gè)業(yè)務(wù)的運(yùn)營(yíng)
• 服務(wù)某個(gè)業(yè)務(wù)的客服
• 服務(wù)于一線的PMO

資源型中臺(tái)建立的越多，溝通成本就越高，對(duì)業(yè)務(wù)的遲滯阻力就越大。每個(gè)團(tuán)隊(duì)都有自己的人力規(guī)劃、資源排期和業(yè)務(wù)目標(biāo)。當(dāng)各個(gè)團(tuán)隊(duì)的業(yè)務(wù)目標(biāo)和自己的業(yè)務(wù)方不一致的時(shí)候矛盾就會(huì)展現(xiàn)。業(yè)務(wù)FTO/業(yè)務(wù)負(fù)責(zé)人就常會(huì)在這方面收到牽絆。

賦能型中臺(tái)

上面說到的數(shù)據(jù)中臺(tái)、技術(shù)中臺(tái)、智能中臺(tái)（算法中臺(tái)）、業(yè)務(wù)中臺(tái)，屬于平臺(tái)型、業(yè)務(wù)型，整體上來說通過屏蔽底層細(xì)節(jié)，建設(shè)平臺(tái)和服務(wù)能力，支撐上游業(yè)務(wù)發(fā)展。雖然這些業(yè)務(wù)中臺(tái)建立之初有大量的成本投入，整體上還是提效的，免去了很多人從前端到后端，從上層到下層所有東西自己都要?jiǎng)邮謱懸槐椋x能屬性是在的。至于能給業(yè)務(wù)點(diǎn)上幾點(diǎn)天賦，這就要看建設(shè)方的功力和業(yè)務(wù)的訴求了。

本篇總結(jié)

整體上，我比較傾向于資源型中臺(tái)打散下放業(yè)務(wù)線，賦能型中臺(tái)保持短小精干長(zhǎng)期聚焦。不要把資源型中臺(tái)做大的同時(shí)，也不要把賦能型中臺(tái)做沒。這樣做，對(duì)于公司來說整體效能是最高的，成本也是最節(jié)約的。

DevOps｜中式土味OKR與績(jī)效考核落地與實(shí)踐
DevOps｜研發(fā)效能+項(xiàng)目經(jīng)理PMO
AI DevOps | ChatGPT 與研發(fā)效能、效率提升(中)
DevOps｜AGI : 智能時(shí)代研發(fā)效能平臺(tái)新引擎（上）
devops｜中小公司效率為王，沒必要度量