本文將根據筆者所做項目為例分析，業務中臺需要產品經理具備何種能力。

中臺，最近因2019騰訊全球數字生態大會再次被大家討論的火熱。

眾所周知，阿里是國內最先實施中臺的企業，也是目前國內將中臺運用的最好的企業。隨著今年產業互聯網成為很多大公司追捧的方向，中臺在其中所將起到的作用更是不可忽視的。

那么作為中臺產品的靈魂，一個優秀的中臺產品經理更是不可或缺的存在，市場上現在可以看到中臺產品經理的薪資也隨著產業互聯網水漲船高。

筆者了解到，北京某行業頭部公司，對有1-3年工作經驗的中臺產品經理的開的工資是20-30w/年。

那么，一個優秀的產品經理都需要有哪些能力呢？

接下來本篇文章將詳細講一下業務中臺產品經理都需要哪些能力？

一、業務抽象

在業務抽象階段，通過業務調研和業務分析，設計業務藍圖和抽象業務元素，為下一階段的中心建模階段準備頂層思想和業務素材。

這一階段，根據企業不同的實際情況，可輕可重。比如企業已經做過咨詢調研和流程梳理工作了，那就可以在以往工作成果基礎上進行短期的業務理解和業務設計工作了。如果企業對以往的咨詢工作并不滿意或者上一次咨詢時間久遠，競爭環境發生了巨大的變化，這就需要做仔細完整的業務咨詢了。

二、高階設計

1. 中心規劃

經過業務的調研和分析，技術架構師理解并熟悉了業務?；谏想A段輸出的主題域，技術架構師按照中心的多個劃分標準，進行中心的規劃。

2. 0 級架構設計

業務中臺的0級架構本質上是應用架構，它以中心為最小單位進行設計，因此也稱為整體架構設計。

0級架構包括了功能層級的架構和技術層級的架構。

功能層級的架構需要描述業務中臺在整個數字平臺中所處的位置，業務中臺由哪些中心組成，以及中心與應用、中心與后臺的交互關系。功能層級的0級架構承接了企業的應用藍圖規劃，指導企業各IT系統的職責劃分和定位。

下圖所示為一個企業功能層級的0級架構示意圖。

功能層級的0級架構示意圖

從上圖中我們可以看到，企業整體功能架構從下往上分為IaaS層、PaaS層、基礎組件層、數字中臺層（包括業務中臺和數據中臺）和業務應用層。

每一層的具體功能如下：

• IaaS層：完成硬件資源的虛擬化管理，為用戶提供對資源的使用服務。
• PaaS層：為應用軟件提供部署平臺和運行環境。
• 基礎組件層：介于業務服務和技術中間件之間，提供通用的業務功能和技術功能，并解耦業務應用和技術中間件。
• 數字中臺層：分為業務中臺和數據中臺，實現企業業務活動的核心機制，并通過數據中臺對業務運營提供指導。
• 業務應用層：通過調用和組合中臺能力，實現應用邏輯。

技術層級的0級架構需要說明各系統、各中心分別使用什么技術來實現，以及整個體系的技術分層，如下圖所示。

技術層級的0級架構示意圖

技術架構總體上分為展現層、服務層、接口系統、運營管理和運維支撐。

展現層與服務層相分離，展現層采用當下主流的前端框架，分別對移動端、PC端進行支撐。通過合理的技術搭配人性化的設計滿足用戶感官體驗需要。

服務層的架構采用分布式的微服務架構，微服務架構去中心化加強終端的特點，讓服務免去雪崩效應等容災上的風險。同時，整體技術架構具備易于擴展、組合、部署，可支持動態伸縮、精準監控，并且可以提供灰度發布等優點。

服務層包含應用服務、中臺服務、技術服務。

應用服務與中臺服務都以微服務架構實現。

技術服務又分為PaaS層和IaaS層：

• PaaS層通過各項基礎中間件的能力向上層輸送搜索引擎、分布式文件存儲、分布式數據庫、分布式緩存等能力；
• IaaS層向用戶提供基礎資源服務。

運營管理通過埋點技術、A/B測試技術、大數據技術來進行數據采集分析和業務試錯，并通過計算結果來指導業務工作。

運維支撐將從底層對所有服務做支撐，運維體系通過對基礎設施的監控、服務升降級等措施來確保系統的容災能力與穩定性。

3. 中臺核心數據流規劃

為了簡化業務流程，根據前期的業務分析，結合0級架構的設計，我們可規劃出企業的業務數據流（以房屋租賃行業為例，多業態），如下圖所示。

基于中臺的業務數據流

客戶中心承接前臺應用租房、買房客戶的注冊信息；對于集團多業態的業務特點而言，經紀人、物管人員、企業員工都是企業客戶，都應該進行精細化管理?？蛻糁行臑榻y一認證提供賬號、密碼的驗證，為各應用提供客戶的全局唯一標識。

產品中心接收來自ERP的工程域樓盤信息、員工錄入或經紀人提供的可租樓盤營銷信息，形成每一間房的完整且統一的檔案。為前臺各應用提供全方位的樓盤信息，包括工程信息、營銷文案信息和房間信息。

交易中心接收來自WMS的庫存信息，完成購房訂單的生成、在線租房的交易等業務活動。訂單生成后，根據訂單中的商品向WMS發起發貨指令。

三、組件建模

1. 產品設計

產品設計是在業務頂層設計的指導下，逐層往下抽象的過程，主要是將業務調研的成果轉化為產品原型和需求規格說明書（主要由業務場景、業務流程構成）。

如何做應用的原型和畫出業務場景不是本節的重點，詳細內容可參看相關專業書籍，這里需要強調兩點：

1. 中臺產品的詳細設計需要以面向中心為指導思想。不僅需要設計出應用需要實現的功能，更重要的是要將需要中心支撐的功能明確標識出來，歸到中心的待實現列表里。這樣技術工程師在領域建模階段才有具體和明確的輸入。
2. 建設中臺的核心目的不是為了共享，共享只是中臺的特性。中臺是為了完成業務的核心運行機制，為前臺提供業務能力基礎的系統。確立了這個原則后，產品經理才能放開手腳，自主推動中心的建設。

2. 組件模型設計

組件模型設計承接0級架構設計，是對中心內容的展開。

通過對中心功能的分析和對中心業務實體的抽象，將具有較強依賴關系的業務實體聚合為一個組件，或者將具有相同主題的業務功能聚合為一個業務組件。最后，以結構化的形式聚合這些組件，構成中心。

如何判斷組件模型是否合理呢？

是否很好地支持業務流程、業務場景、復雜的業務規則是衡量組件模型優劣的標準。我們可以通過窮舉邊界業務場景的方法，來反證組件模型設計是否合理。

最后需要強調一點，組件是可以獨立為微服務的，只要符合微服務的條件，就可以獨立。

但是，在實踐過程中，我們發現如果微服務承載的業務規模不大，獨立帶來的業務價值不高，反而會增加運維成本。

3. 1 級架構設計

組件模型設計完成后，需要將模型轉化為應用架構。這里的應用架構是指中心內部的應用架構，我們稱為1級架構，1級架構是以組件為最小單位設計的功能層級的架構。

1級的功能架構是必不可少的，它指導著我們的設計和開發；技術層級的1級架構可視情況而定，如果技術內容比較復雜則需要輸出。

下圖為1級的功能架構圖：

4. 關鍵交互圖設計

前面已經完成了0級和1級的架構設計，有什么方法能證明設計是否可以滿足實際業務場景的需要嗎？

我們可以通過實現業務場景的動態交互圖，來反向論證設計的合理性。

如何判斷動態交互圖是否合理呢？

根據業務邏輯是否清晰、流程是否簡潔、客戶交互是否高效來判斷。

如果設計出的交互圖不合理，那就說明0級或1級架構存在設計不合理的問題。另外，通過交互圖還可以較好地將設計思想傳遞給開發團隊。

四、開發交付

我們主張采用敏捷的方法進行開發交付，將最終目標拆解為多個小目標，逐個完成。同時，又將每個小目標拆為多個子項目，每個小團隊各自負責一個子項目，所有團隊并行開發，協同向前推進。

一般來說，流程包括迭代規劃、需求反講開發、持續集成交付和回顧總結調整。

五、持續運營

項目上線后，只是產出業務價值的開始。

數字中臺需要在持續不斷的運營中，包括業務運營、內容運營、技術運營和數據運營，不斷沉淀和發展。其中，能力會逐步增強和擴展，模型會逐步調整和完善。

作者：Eric·Z；微信：zwz970321（歡迎添加交流）

本文由 @Eric·Z 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議