關于中臺,我的幾點思考

3 評論 4646 瀏覽 25 收藏 10 分鐘

各行業興起的中臺熱潮趨于平淡,但還有公司在不停上線相關項目。本文從中臺目的和潛在應用、筆者了解的國內中臺情況、主導中臺搭建的部門和大概率失敗的情況和大家一起討論,期望能為中臺和搭建中臺的小伙伴提供一定的思路。

一、中臺目的和潛在應用

首先明確的是不管公司大小,大家都有構建中臺的權利。有人會說小公司沒有足夠的資本支撐中臺的運作,這個說法陷入中臺要大到包含全部業務而忽視中臺核心目的的處境中。

在談中臺目的和潛在應用之前,我們來重復下其起源:Supercell,一家400人的芬蘭游戲公司,5-6人就能完成一款游戲開發。阿里巴巴15年參觀并宣傳后,中臺正式登入國內互聯網人的眼球而得以迅速發展。Supercell快速開發的原因在于其將美術、數值等具備模塊開發內容集成在一個單元,使其具有超強的復用性,而中臺則是互聯網人賦予具有復用性工作模塊的方法論名稱。

因此,中臺目的是將業務模塊化以便快速應用,而具有模塊化業務的部門\公司都可以開發自己的中臺。但是上馬中臺業務前,需考量下是否有業務可以模塊化,如:互聯網公司H5頁面開發、游戲公司建模、銷售公司用戶操作平臺。。。

在這留個疑問:是不是中臺一定要集成在一個操作系統(平臺)中呢?

二、國內中臺情況

在寫這篇文章前筆者認為阿里和頭條的中臺應該是國內做的最好的公司(理由等下列舉)。但是近日《阿里中臺搞了3年,搞砸了?》曝出后留下個懸疑,畢竟互聯網公司換帥多半是管理層對于業務不滿的最直接原因。言歸正傳,根據國內互聯網公司近幾年產出,談談個人對當下國內中臺的幾種情況:

1. 阿里巴巴中臺

阿里巴巴訪問Supercell后,2015年在國內首先提出中臺概念,當然這不是認為阿里巴巴中臺做得好的原因。

不知正在瀏覽這篇文章的你是否記得2018年的雙11,阿里系APP彼此聯動導流,筆者當時在預售期下載了十幾個阿里系APP拿到100多紅包,相當于不到10塊/活躍用戶(非常劃算?。?!)。

引流形式簡單粗暴,每個APP上均有一個H5,H5的任務分為完成本APP活躍任務和下載阿里系APP兩種類型,完成相關任務后即可領取紅包。數據效果可以看當時APPSTORE的排行榜,阿里系十幾個APP均位列蘋果商店免費榜TOP30。試想如果沒有中臺業務支撐,十幾個APP的開發協調、數據打通需要多久才能完成呢?

這種以活動驅動搭建的中臺我們可以稱之為活動型中臺。

至于阿里換帥,或許是中臺在驚艷的18年雙11后未能有超越性的應用?抑或是學釘釘重新創業?或許只有當事人才能知曉了!

2. 頭條系中臺

字節跳動以數據驅動發家,而數據無疑是互聯網公司的核心(不接受反駁),字節跳動在數據的基礎上所做出的業績在此不表。筆者表一表自己認為頭條系中臺做得好兩個原因:

1、與阿里雙11紅包相媲美或更上一層樓的頭條系春節紅包,和阿里系APP聯動相同的套路,不同的是每年春節都讓大家玩得很嗨~

2、近年來經常性聽到頭條又發布了某個領域的APP,多閃、飛聊、aikid、goodkid …… 這么頻繁的發布產品, 不管是HR、亦或是程序、營銷等等,哪個環節不需要強大的控制和數據能力呢?據此是不是可以推斷頭條系內部有個產品中臺呢?(阿里換帥有沒有這個原因呢?)

而以產品驅動搭建的中臺我們可以稱之為產品型中臺。

3. 騰訊中臺

目前對于騰訊的中臺介紹大部分是開放能力賦予騰訊生態的第三方,騰訊內部也成立了技術委員會來籌備中臺。但通過和騰訊內部人溝通,目前中臺僅局限在六個事業群里,功能也沒有想象中的豐富多彩,比如微信用Excel處理數據(19年的時候),當然舉例不是為說騰訊的Excel。

不知各位看官是否對前幾年被熱炒的微信“敏捷開發”有印象,張小龍說的是有點子就要快速去嘗試,再根據結果決定停止還是繼續擴大規模嘗試。試想一款日活10億的APP,哪一個快速嘗試的想法不需要交互、用研、開發、策劃、運營等崗位的參與呢?那我們就假設微信內部在阿里提出中臺概念前已經有了一套類似中臺的機制吧。

以模塊化迭代驅動搭建的中臺我們可以稱之為模塊型中臺

三、到底哪個部門主導中臺

說到哪個部門來主導搭建公司級的中臺,有跟進過的小伙伴估計會有各種討論出來,如產品經理、程序、數據管理、運營……反正各個崗位都想獲得主導權,畢竟國情和權力都會讓其投放在放大鏡下。接下來我們舉例來討論下各個部門主導搭建的情形:

假設場景:只有運營面向用戶,其他崗位均支持運營。產品經理服務于運營的工具搭建、數據管理服務于運營的提單數據處理,程序完成運營或產品相關需求。(為最大化展示利弊,場景完全虛構)

  • 產品經理:由于我們是負責工具功能的搭建必然由我們主導搭建,為此產品開始設計、數據管理輸出數據、程序開發……轟轟烈烈搞了半年中臺后運營的同學沒法用。
  • 數據管理:我們擁有最全的數據理所應當主導,同時由于具有一定代碼能力自己開發了一套中臺……但無應用場景,然后開始重新找運營獲取場景,并對中臺用上了手術刀。
  • 運營:我有場景,有數據應用,任何自己在SQL里操作數據這不就是中臺了嘛…….新入職的員工看的一臉懵逼。

從上面場景哪個崗位最適合來做主導呢?筆者覺得主導還是由產品經理來主導,但是其中應該首先結合運營的業務場景來做決定,開發設計過程中讓運營全程跟進參與。

這里留個假設:中臺的搭建必然需要復合型的人才。如前文所述,整個搭建過程中必然出現產品經理不清楚運營訴求或者要求運營給出價值體現的情況,網絡上流傳了千年的運營、產品經理和程序互撕的傳說,在涉及0到1的中臺搭建不見得會和平!

四、大概率失敗的中臺

簡要列幾個個人看法吧:

  1. 單純為了做中臺的中臺,整個中臺沒有業務目的、沒有目標導向。
  2. 將原有該做的系統包裝成中臺強行和中臺結合,同時不斷想往上增加不實用的功能。
  3. 為做中臺將原有不相干的系統、權限等強行整合為一個系統,這個失敗概率不一定大。但其中的風險控制不僅要重新投入大量資源(有人必然有風險),還要承擔權限設計導致未來出現的風險呢。到時誰來承擔呢?

小結

做中臺一定有業務驅動,可模塊化的業務均能設計為中臺。同時大而全的中臺也不要強求哦!最后祝各位中臺人一切順利吧。

 

本文由 @逗逗一世 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 請問作者大大,中臺是否應該過多參與業務側目標設定?我們現在有很明顯的問題暴露出來,就是業務側提過來的一些強勢的創新需求,因為沒有參考的數據以及上線之后的效果保證,中臺這邊領導都不建議產品去做,但是業務側明確必須要做,小產品夾在中間很為難

    來自北京 回復
    1. 1、這個要看對業務側KPI是否能夠起到影響,比如功能只是單純提升人效而對業務價值無影響則不用參與指標
      2、業務側的新需求其實可以用讓業務側的demo來進行驗證或者業務側提需的場景通用性怎樣來判斷

      來自廣東 回復
    2. 好嘞~謝謝~

      來自北京 回復