編輯導語：過往的營銷其實都是在經營産品，将其宣傳出來，讓更多用戶來消費産品。當将産品銷售出去後，産品的經營與用戶的經營成為了二者利益平衡的杠杆，如何尋找二者平衡最優解，本文通過中台概念對産品經營進行分析，以此尋找二者平衡解決點。

前言——産品的價值

在談論遊戲中台之前，我想先和大家聊聊産品的思考，由此去引申中台的思考。

無論自然界、人類社會，抑或浩瀚宇宙，一切事物從整體上都在向着無序化邁進，這就是熵增的過程。

随着信息化的快速發展以及疫情沖擊下的“後遺症”，我們越來越能明顯感覺到，當下社會似乎很難按照既定的規則運轉下去，熵增現象越來越明顯，而當下的業務重心也慢慢的從經營産品偏移到經營用戶。

過往很多行業甚至當下一部分傳統行業的營銷都是在經營産品，簡單來說就是怎樣将産品宣傳出去，賣給若幹個消費者。而經營用戶将這款産品賣給這個客戶後，可以讓他重複購買若幹次，與此同時還可以帶動若幹個客戶，讓這若幹客戶重複購買……以此類推。

期望值的公式=概率x結果/收益

所以，期望值的大小是由概率的大小和收益的大小二者共同決定的，所謂尋找最大期望值也就是在概率和收益之間找到最佳的組合和平衡，并以最大期望值來指導我們的行動。顯而易見經營産品的期望是遠小于經營用戶的期望值。

那麼在現有經營産品的前提下，如果更好的去經營用戶呢？之前有提到說，産品是依照于一套既定的規則下的産物，那在這套熟悉的工作流之下，是否能夠通過經驗的積澱，開發流程與接入流程的規範下去提升工作效率，以便更好地去經營用戶呢？

本篇内容主要内容在于通過中台的概念去提升經營産品的角度，而非大篇幅的經營用戶，或許會在未來的文章中去展開講講，敬請期待。再回到遊戲中台來說，或許它的存在就是我們尋找最佳平衡的解決方案。

一、遊戲中台的思考

互聯網中台的起源的故事與發展的曆程想必大家早已經熟知，我也不再去引用于贅述。然而遊戲行業的中台卻很少提及，我想借着這個機會和大家一起探讨探讨，當然畢竟隻是我的一家之言，肯定會有片面的地方還請諒解。

回到中台的核心内容：簡而言之就是系統組件化，避免重複造輪子，提升開發的工作效率，降低或減少人工與時間的成本。這麼看或許說辭有些模糊，其實中台的設計往往無法脫離業務，所以在概要定義下中台的邊界是無法明确的。

俗話說風險與機遇并存，在中台概念火熱的背後也存在着盲目跟風，許多本該不屬于中台領域的東西被莫名的堆積到中台範疇，從而導緻中台失去了原有的核心價值。并不是所有的公司或者部門都需要“中台化”，中台化其實是由為“中心化”、“平台化”演變而來的。

随着企業規模的膨脹、業務複雜度的提升等過程中不斷暴露出來問題，以及對于各部門或者各項目組之間協作的要求就會越來越高，對于已經具有一定的中心化趨勢且存在多條業務線并行的情況下，工具、内容、協作等模塊不斷抽象出中心内容，但各模塊又相互獨立存在于各個平台，亟待一個中央模塊去連接和組合，那麼此時建設中台就很有必要性。

二、遊戲中台的組成

一個中台部門的搭建不是想當然，除了需要自己強勁的“内功”底蘊之外，還要有八面玲珑的“外功”去搭建。因為中台的所有需求發起點都來源于項目組，以滿足項目組需求去搭建組件與功能而非去虛空想象需求。

再加上中台項目往往不像項目那樣會直接創造利益價值，所以在前期立項就會面臨從裡到外的重重阻力。當然這部分内容與各企業的戰略規劃相關，在項目管理中劃分在啟動過程組的階段需要着重去分析考慮的事情，而本次内容更多針對于規劃、執行過程階段。

遊戲中台體系是由技術中台 業務中台 數據中台等構成。其中業務中台又可以拆分為運營中台、内容中台和營銷中台，當然每個企業對于中台的範疇或命名不盡相同，但萬變不離其宗。

其中技術中台可以拆分為：引擎平台、工程平台、技術美術平台、AI平台等。

運營中台可以引申為：内容平台、營銷平台、用戶平台、工具資源平台（GM向）。

拿運營中台來說，采用多租戶模式，通過運營中台為不同的遊戲項目作為單獨的實例提供組織服務。實現多個租戶之間共享中台組件，以達到提高複用效率減少開發時間與人力的目的。

三、如何建設遊戲中台

1. 權限管理模型選用

常見的有ACL 訪問控制列表、DAC 自主訪問控制（ACL拓展）、MAC 強制訪問控制、RBAC 基于角色的訪問控制，每種的優點、局限性等常規内容可自尋搜索此處不再多贅述。我個人是采用RBAC的模型進行運營中台的設計的：

定義：

• 規定角色可以對哪些資源進行哪些操作
• 規定主體擁有哪些角色 當一個操作

同時滿足a與b時，允許操作。

說明：RBAC的思想，來源于現實世界的企業結構。比如銷售角色，擁有查看客戶信息的權限。當一個銷售人員小王入職了，可以把銷售角色賦予小王，那麼小王就擁有了查看客戶的權限。這種方式，避免了ACL模型下，每次新人入職，需要逐個配置資源表的情況。同樣，權限變動也變得很方便，隻要修改角色，即可實現多用戶的權限修改。

局限性：RABC并不總能滿足所有權限的場景。比如，我們無法對遊戲運營角色，進行個體定制。比如，遊戲運營角色擁有創建、删除的權限。如果我們要對運營人員小李，去掉删除的權限。那麼，我們就必須創建另一個角色，來滿足需求。如果這種情況很頻繁，就會喪失角色的統一性，降低系統的可維護性。

2. 運營中台

對于遊戲運營中台來說一定是多租戶模式，不同的遊戲項目組共用相同的系統或程序組件，并且仍可确保各用戶間數據的隔離性。

針對不同遊戲的業務方提出的遊戲運營管理需求，通過建立将功能層面高内聚、低耦合的通用遊戲運營管理系統，以提供業務多重用性、系統易維護性、功能高擴展性的解決方案。

同時為滿足各個遊戲項目組的應用管理需求，設計開發通用的遊戲運營系統。基于通用的服務端接口級的功能響應，打通與其他服務之間的數據交互，提供支持多租戶、自助接入、并具有自由拓展性的系統及服務。

3. 營銷中台

随着玩家數量的增長，用戶、遊戲内容等數據源急劇膨脹、維護玩家的生命周期變的困難、運營方案疊代緩慢等問題的顯現，營銷管理平台應運而生。基于對數據驅動業務增長以及精細化運營的迫切需求，需要延長玩家在遊戲内、遊戲外的生命周期：

• 幫助運營快速獲取數據，實現靈活高效的洞察，促進業務快速疊代
• 幫助運營分析行為和業務數據，快速提高業務轉化與玩家留存
• 幫助運營管理用戶生命周期，精細化運營及智能增長
• 打通分析-決策-行動完整閉環

營銷平台定位為建立行為分析産品體系，整合多種運營策略和工具，打通增長、精細化運營閉環，目标降低産品分析、運營的時間人力成本，提升整體效率，豐富擴展産品增長和内容運營能力。

4. 專題活動中台

專題活動中台算是非必選的一項架構，是否構建取決于業務對于此類需求的依賴程度，在遊戲行業中較為多見。

要首先判斷在以往的消費類/活躍類的遊戲活動中是否可以抽象出通用的組件，或者是高頻重複出現的活動場景。例如宮格抽獎、轉盤等基礎規則元素，周期性的特殊節日等素材積累就具有很強的通用性和高複用性。

可以理解為簡單的換皮活動，這些都可以由業務屬性來做靈活的配置組合。而對于日常的廣告圖、盒子圖、背景圖或banner等可以積累為素材，雖然這些内容或許帶有自身很強的定制屬性，但作為素材的積澱還是可以考慮保留的。比如同一個聖誕主題的活動背景，如果時間緊的話，換一些關鍵元素是不是也可以在另一些項目中使用呢。

（1）提高活動複用率和複用效率

• 讓每一個上線過的活動都變成可複用的模版
• 通過配置即可上線，無需額外開發

（2）減少（避免）重複性邏輯、接口開發

（3）規範用戶信息校驗、發獎等通用邏輯，減少測試開發量

（4）做好與外部系統對接的準備

（5）專注頁面效果與用戶體驗提升

四、對于中台産品的挑戰

1. 溝通協作挑戰

其實我剛開始也是在業務部門，我所面對的業務需求都是較為明确直接和相對輕松的。雖然也是面對多方項目組，但沒有中台概念以及不用考慮複用的思維，業務需求也是做的順風順水。直到經曆業務量不斷地膨脹之後，愈來愈多的問題暴露出來。

以對接需求為例，對于不同體量不同成熟度項目組的需求配合的意願也是參差不齊的。體量大或者收益較高的團隊由于他們的業務以及流程脈絡較為清晰，一方面需要我們能夠支持快速響應，在較短的時間快速疊代日常活動的上線，另一方面他們又不會主動考慮實現的複雜度，不想由于我們的開發進度來幹擾他們的排期進度，處于較難調和的溝通。

但也有類似不是很成熟的項目組找我們對需求時，對于需求的描述不是很準确，對于最終功能的表現也不是特别關心，甚至某些時候完全是我們替他們在想需求。所以其實在這過程中大量的精力會分散于不同部門之間的溝通協調，反複對同一個需求進行确認，整個結果确定的周期被無效拉長。

說話這門藝術，還是需要一直學習的。

2. 邏輯抽象能力挑戰

如果說溝通協作算作一個中台産品很重要軟實力的體現，那麼邏輯抽象能力就是一個考驗硬性能力的體現了。

因為對于一個中台所要面對的一系列解決方案，都是能夠服務于多業務多項目組的，那這這套解決方案的設計不僅需要強大的邏輯思考能力，更要有抽象延展能力，在滿足所有的需求同時也能夠敏銳的察覺到不同需求之間的公共特性，從而輸出一個面向多租戶的産品解決方案。

好比說項目組需要運營平台能夠支持一個白名單功能，需要滿足針對特定的人群執行特殊邏輯。

這看起來是個很簡單的需求功能點，但是對于中台産品來說需要挖掘一切可以複用的場景，在滿足業務需求的功能前提下，抽象出公共邏輯。很明顯這個需求在後期運營中需要複用的場景還會有很多，比如延展到黑名單、活躍用戶、大R等用戶群體，那麼我們就沒必要重複造輪子，每次都去開發相同或類似的邏輯。

在實際的業務場景也會有更多更複雜的事情需要解決，這個例子也是起抛磚引玉的作用。

在産品方法論文章中也有提到，有些需求其實是僞需求，還可以繼續深挖。白名單功能去抽象拆解，實際就是篩選出一個用戶群體，并對這個用戶群體實現某種特定的功能。

這樣來說的話這個需求就可以這樣做：将原本一次性的白名單功能開發，實際轉化為用戶标簽系統的開發。在基于運營平台原有的用戶體系，加入用戶标簽功能，既能滿足原有的白名單功能，又可以拓展一系列潛在的用戶需求。

3. 其他挑戰

從整個産品層面來說，對于中台産品的綜合能力要求還是很高的。

一方面，需要有強大的業務拆解能力與功能抽象的邏輯思維能力以及全局統籌的能力，清晰地梳理出業務中的關鍵路徑與業務流，并且能夠把控整體的系統疊代能力，在業務實現中也可以把控系統功能完善的節奏。

另一方面，又需要面面俱到的溝通和協作能力，能夠在遊走在多個業務線之間，不斷稀釋平台建設的成本分攤精力，與此同時也要滿足好業務方的需求，同整個系統的相關幹系人一同推動完成整個中台的功能實現。

五、後記

自然規律是由無序變有序，而産品的誕生其實也是這種說法的表現形式之一。我之前也說過，産品就是一套标準規律的運行。而中台更像是整個系統的一個規律體，當随着整個系統的愈發膨脹，才會更加體會到中台系統的作用。

作者：WāngWénhào；阿司匹汪（aspWwang)

本文由@ WāngWénhào 原創發布于人人都是産品經理，未經許可，禁止轉載。

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部