軟體工程師羅小東，多年平台架構設計和落地經驗，這裡主要是針對于中台化項目傳遞與傳統項目傳遞的一些心得體會。
理念
Supercell遊戲開發公司内部有一套技術平台，旨在提供支援Supercell開發的多款遊戲的共享工具、技術和基礎設施。這個中台包括了各種元件和服務，如玩家賬戶系統、社交網絡功能、統計分析工具、虛拟貨币交易系統等等，這些工具和服務都可以在Supercell開發的不同遊戲之間進行共享和複用。
讓Supercell遊戲開發團隊更加專注于開發遊戲本身，而無需重新開發已經存在的功能或迎合特定遊戲的需求。同時，這也能夠促進Supercell内的知識共享和協作，并且降低整體開發成本和風險，這也是中台架構的由來。
概述
在過去幾年中，一直專注于中台架構和項目的開發。尤其是在進行中小型項目方面，積累了一些的經驗。以下是一個典型案例的分析，将從實踐中總結出的心得和經驗。在23年的第一季度，團隊完成了一個約為百萬級的大資料項目。我們采用中台産品和ISV（業務組）合作夥伴的方式進行傳遞。
SuperCell模式在傳遞和團隊優化方面有明顯的不同，隻是說感覺相對于網上各種理論來說，各種概念的解釋來說，原來初衷的理念更加符合，而我想要的也是這個模式，而不是網絡上被各種名詞和概念所淹沒的中台模式，有時候會把一些簡單的事情說得太過于玄乎，而沒有展現初衷，這也是為什麼标題使用SuperCell的原因。
起初聽到芬蘭SuperCell模式時，原本覺得有這個可能，但是過程當中的體會沒那麼深，對外交流的時候，各種底氣還是來自于一些材料，但是當真正自己在用SuperCell模式(也就是中台)的時候，你會發現，這個結構在一定的程度上确實将團隊的結構還有能力進行了優化處理，而且整個流程過程會更加順利，這裡主要從幾個角度進行闡述：
- 項目中的中台組織結構是怎麼樣的；
- 過程怎麼分工處理同時做好前端的支撐；
- 過程的一些常見問題和規避操作；
不同于大廠的中台傳遞模式，但團隊和經驗不同，是以我們隻針對中小型項目進行說明，我有我思。
過程
在過程中，做了很多的職責分離，這裡針對于原來的數字中台營運方式來進行，角度闡述也是從這個營運思路。
項目中的中台組織結構是怎麼樣的
傳統項目的組織結構會一個項目從各個層級跟到尾，可能管理團隊多個方面，而這裡略有不同。
在這個大資料項目裡面，我們的組織結構基本上對項目經理的職責還有中台人員的職責進行了調整（這裡不提商務）。
在傳統或者一般的項目裡面，項目經理對接的職責和範圍可能會比較大，在項目組裡面人員權限也比較大，調動的人員可能從下層的開發和底層的技術人員可能都會涉及，而在中台的組織結構裡面，我們把項目結構進行了兩層拆分，分成了中台層和項目層，而項目經驗對接的隻是每層的負責人。另一個是項目的實施過程也進行了拆分，分多個階段，一個是中台的産品傳遞和業務需求的實施傳遞，還有另一個是中台後期的支撐。
感覺這個過程好像跟一般的項目過程，比如甲方乙方等實施傳遞差別不大，我第一感覺也是如此，但是實際并不是。
這個階段之間的分隔，在傳統項目傳遞裡面并沒有那麼明确，而且人員意識還有團隊意識，過程的溝通，傳遞産物等，各個角色支援力度等需要更加的明确，怎麼說的呢，就是在前期一些教育訓練階段的時候，問題最多不是技術，反而是這個階段之間的實施問題。常常會出現，要麼就是業務進到中台層裡面，要麼就是中台層進入到業務裡面，類似的情況，往往是缺少階段處理的意識，這個就會形成一定的傳遞隐患。
中台層要做的是架構方面和一定範圍能力的技術的支援，但是不要介入到業務裡面，業務場景最合适的業務層的解決辦法，中台需要提供的是平台級的能力，因為中台層要支撐的不僅僅是一個項目，而是多個項目，這個需要在支撐階段提出明确的支撐能力，哪些有，哪些沒有。
業務隻需要根據中台的能力來進行場景的規劃，如果需要的或者确實沒有的而一定需要用到的，或者送出需求到中台即可，而不是等着中台解決業務問題，形成兩邊的死循環。
在前期的組織結構初期，就做了明确的溝通要求了邊界，明确劃分哪個階段參與和明确提出計劃和時間。
過程怎麼分工處理同時做好前端的支撐
傳統項目可能前期有需求還有原型等之類的，或者需求調研之後才會考慮到實施，這裡也略有不同。
在數字中台上會帶有一部分基礎的業務能力，還有一些通用的服務元件，在項目确定開始之後，基本上實施計劃和工作就已經開始，另外加上是一些資料類項目，通用的元件更多，而我們要做的是資料輸入層，也就是資料調研和采集，這個前期都有一定的模闆和樣例，在項目開始的前一周，實施的準備條件就已開始部署，傳遞出第一版本給客戶示範的時候，差不多是項目開始後的兩三個星期左右，後面就是教育訓練使用。
而這個過程業務端在進行業務的處理的開發，中間加上客戶的時間情況等等，這個業務型開發的時間在一個月左右，因為在中台上也包含技術devops，在這個過程都會自動同步到使用者測試環境，這個過程時間相對來說，也比較從容，業務團隊過程中需要的文檔和手冊等處理，中台團隊會有一些教育訓練，這個教育訓練時間大概是前面的三天左右時間。其它的就是等資料調研這部分的結果，完成之後資料采集到資料中台裡面，進一步的分層、計算、接口等擷取到名額，輸出給業務方，這部分主要是中台的過程中的操作，同步帶好業務端的人員怎麼使用，帶好流程。
這個過程中一個比較大的體會是角色定位和分工上，還有時間點的把控上等都會比較明确，會有一些卡點，但是相對于以前傳統項目方式來說，這個會更加明确。
過程有碰到的一個時間是過年時間，在這個時間後，基本上業務示範的第一版本也就出來了，在給上司層做示範，得到一定的認可後，基本上就走驗收流程。前後大概是兩個月的時間，其它的時間點會有一些運維和管理的操作，這部分在業務上，也在移交到運維層面上，在項目上投入的資源也進一步的減少。
這個過程中的一個比較明确的體會就是時間，時間點上會比較明确和準時，如果說業務組在缺少資料中台産品的支撐和中台團隊的支撐，是基本上不可能在這麼短的時間出的結果，而中台團隊沒有前期的積累也基本上不太可能會跟業務組和項目實施等配合得好。甚至在實施過程中，因為業務組一直做的是業務元件（我們把業務元件分開和微服務化），在傳遞實施過程才發現這個項目是一個比較大的項目，涉及到子產品那麼多，這也是原來考慮的，業務組要做的是做好業務場景需求就可以，其它的中台層給好支撐點。
另外一個因素是中台和業務組的磨合，初期的項目會有一些磨合，如果這個過程沒有做過，可能會消耗一至兩周的時間點，這個需要考慮的。
過程的一些常見問題和規避操作
過程一直強調角色和職責，業務組和中台組就做好自己的事情就可以。
在這個過程中，也會有很多的坑點，一些不注意可能也會形成項目後期的問題，類似于技術債，大緻列了幾個問題：
-
避免讓業務組接觸太多的技術概念而忽視業務
在中台會有很我技術概念和學習層面，這個過程容易使業務組的技術人員深入到技術層面，比如微服務、容器化、主資料、Hive等，它需要的是一個模闆和使用說明，而不是研究說明，根據業務場景來進行模闆輸出就可以，後面根據個人興趣去學習即可，重點是給出使用案例。比如資料采集，跟業務組人員說“發送到資料總線”可能他們會迷糊一下，但是跟他說“發送到這個API接口”他就立馬明白。
-
實施過程中台文檔的産出
文檔材料的産出是過程中特别需要注意和加深的，也是中台組的要求，這裡對業務組的要求由項目經理，但是中台組的要求是一定要有文檔的産出，這個文檔的産出并不是隻是一個項目，而是多個項目都有在使用的時候，這些文檔和沉澱對中台組來說意義就比較大，實作的輸出的意義也比較大，同時對文檔有比較嚴格的要求，格式還有内容等，形成高品質的文檔，這部分不論在哪個項目都做了強制性的要求，同時友善後期更新疊代等。
-
避免兩個組之間互相切換和沉入
中台切入業務，業務切入中台，這個是前期特别容易出現的問題，隻需要一個簡單的場景，在讨論過程中，如果沒有這個意識，就會變成中台組在做業務元件開發的情況出來，或者業務組提要求了，然後中台組根據特定（注意是特定）修改中台元件的情況，後面一種是我們特别容易出現的，而且也特别頭大，有些情況下确确實實是中台組加個字段或者加個功能會比較簡單，但是這個屬性是某業務特有的，實際上這個過程從業務組做維護會更好。比如我們會用電信廠家的接口發送短信，而不會給個單獨給某個業務設定接口，除非說這個接口有多行業公共的屬性，那再統一內建。
當然，還有周期、工時、支撐、商務等挺多方面，這些主要依賴于過程的團隊的情況和管理方式進行處理，這裡就不做過多的闡述。
總結
在前期多個中小型項目中，我們建設中台體系的過程雖然有聽說中台模式的好處和優勢，但是身邊比較少成功的案例（除了一些大廠），或者說在使用了并沒有發揮出它本身應該有的作用，結合起來發現并沒有達到降本增效的層面，反而發現過程更加複雜和麻煩，最後發現可能還沒有原來單體應用的簡單。
這些以前見到其它陷入的比較多，從自己的心得來說，這些是一個過程點，但是要達到終點，這個需要比較大的，而且長期的團隊實戰和不斷疊代更新過程，上面是在這方面的心得體會，希望可能給一些參考。