本次文章的主題，就是前段時間，以及接下來的工作重點——平臺化改造。平臺型產品經理也是產品經理中的一個稀缺物種，就此機會我也來聊聊平臺產品經理與一般產品經理的同與異。

由于筆者從事電商行業，因此就以電商行業舉例說明。

一、平臺化是什么

從產品角度來看，電商業務的需求有兩個特點，業務需求多且繁雜；業務需求時效要求極高。這兩個特定是由電商的特點決定的。對于電商來說：

1、消費者流失門檻低。對于電商來說，消費者流失門檻極低，因此需要時刻緊盯消費者的一舉一動去討好他們，偏偏人又都是喜新厭舊的動物，因此需要經常進行業務上的調整；

2、電商已是紅海，同時行業抄襲成風，因此有新的業務機會需要盡快上馬，戰機稍縱即逝。

面對這兩個業務上的特點，容易導致的情況是，開發同學被業務同學推著走，一見面就是這又有XX個需求，都很急啊，先做上線再說吧。這會導致的問題是，在如此短的時間內上線功能，難以進行系統性、全局的考慮，導致新的業務邏輯在原有系統邏輯上，像打補丁一樣一塊接一塊，最后系統不堪重負，從而使整體的效率及穩定性降低。面對這樣的問題，一般大家都會采用系統重構的方法來解決。

俗話說得好，船小好調頭，小的系統重構起來很簡單，大的系統上跑的業務多，依賴多，業務邏輯復雜，重構成本非常高，還是要盡量減少重構系統的次數。在不得不重構系統的情況下，怎么重構系統，才能在開發效率要求越來越高的情況下，實現可持續發展，盡量減少系統重構次數呢？這就涉及架構設計的問題。一個合理的架構，可以在提高開發效率的同時，使系統的可用性越來越高。

這就要有請我們本次文章的主角，平臺化出場了。

在我的理解，平臺化是一種底層功能的架構方案，其實現的是將業務從業務耦合，多頭管理，剛性支撐到業務分治，歸口管理，柔性支撐的架構轉變。

這么說可能不太好理解，讓我來解釋幾個概念：

1、業務耦合-業務分治

這里說的業務耦合，并不是指正常的業務耦合，而是是指過緊的，不健康的耦合。

與其對應的概念是業務分治，指的是業務分別治理，依賴業務之間保持較松的，健康的耦合關系。在業務發展初期業務較少的情況下，新業務處于摸索階段或者業務邊界模糊不清的情況下很容易出現業務耦合的情況。后續隨著新業務、模糊業務中的雙方都越來越復雜之時，若沒有及時解耦，耦合就會越來越緊，系統維護成本原來越大，最終影響到兩方各自的發展。

平臺化，目標之一實現的是從業務的不健康耦合到健康耦合的轉變，這就要求要劃清業務邊界，同時推動耦合雙方共同完成解耦。

2、多頭管理-歸口管理??

多頭管理是一個下級同時接受多個上級領導的現象，在實際業務場景中，表現為一塊業務，由多個團隊進行維護的現象。這種情況導致的弊端主要有三個：

1. 負責團隊多，互相踢皮球；
2. 不同團隊之間團隊墻導致的溝通成本過高；
3. 業務難以標準化，業務方接入成本高。

無論如何，都是弊大于利。而歸口管理，則是按業務范疇進行分工管理，不同團隊，不同系統，不同模塊各司其職，業務邊界分明。平臺化，目標之二是實現業務歸屬從多頭管理到歸口管理的轉變，這要求明確業務功能，明確團隊職責，確定接口團隊，統一維護業務。

3、剛性支撐-柔性支撐

先來說柔性支撐。柔性支撐是從柔性供應鏈借鑒來的一個概念，是指外部的需求在需求小批量，多批次，時效要求高的情況下，以合理的成本水平迅速滿足業務方需求的能力，需求完成的越迅速，付出的成本越低，其具有的支撐柔性越好。柔性的基礎，是復用性，可拓展性，模塊式的設計方式。其對應的是剛性支撐，即沒有考慮系統柔性的支撐。在業務初期，剛性支撐能快速滿足業務方的需求，但長此以往系統整體效率下降，開發的邊際成本越來越高，顯然無法適應業務的快速發展。平臺化目標之三，就是實現業務的柔性支撐，這就要求抽象出業務模型，從此前的以點為維度的支撐，換為以面為維度的支撐。

二、為什么要做平臺化

以上是我對平臺化的理解，接下來說下做了平臺化，我們能收獲什么？

在我看來，平臺化的效果主要有三點：

1、降本增效，提高效率。

電商作為輕資產行業，最重的資產其實是人才，而人才中，占比最大的往往是我們的技術同學們。在實行平臺化之后，由于實現了柔性支撐的關系，能極大解放技術同學，使其快速能完成業務需求，有更多精力投入到比如穩定性，性能提高，技術改造，技術學習等其他重要事項中，這也提高了人效，從另一個方面降低了公司的成本。

2、快速支撐，響應業務。

平臺化之后，由于能夠快速支撐業務方的日常需求，也使得我們能更快把握住戰機，同時在對外合作上，也更有談判的籌碼。

3、邊界清晰，管理規范。

平臺化會進行業務分治及歸口管理，這需要對現有的業務進行梳理，業務邊界會變得更加清晰。同時由于歸口管理，各個團隊對業務能進行更規范的管理，提高溝通效率，避免一件小事找了半天都沒有人敢拍板的情況。

三、平臺化誤區

對于平臺化，在推行的過程中由于概念較為抽象，不同業務線應用場景差異較大，因此在理解有很多誤區，我也和大家溝通下我個人的一些看法：

1、平臺化一定要有旗下很多應用，才可以做平臺化？

平臺化是一種架構方式的叫法，而不是做大的通用平臺才叫平臺化。在我的理解，只要被多應用場景，多業務方需求，高需求時效要求，不明確的業務邊界搞得系統快hold不住的業務，就可以考慮進行平臺化改造。

2、做個大的業務平臺，就完成了平臺化改造了？

做了大的業務平臺，實現了業務分治，我個人感覺，是平臺化的開始。業務分治，歸口管理以及柔性支撐，其實是平臺化由淺及深的三個階段。每個階段對生產效率都會有一定程度的提高，但全部實現之后，對生產效率的提升會達到一個全新的高度。路漫漫其修遠，大家仍需加油。

3、無論什么業務都適合進行平臺化？

并不是所有業務都適合進行平臺化，我們也不提倡為了平臺化而平臺化。有一些業務，面對的業務方較少，業務變化少，系統壓力小，此時是否需要做平臺化，就需要討論一下了。畢竟平臺化改造，需要投入的資源，時間較多，如果投入產出比較低，則不一定要做。

四、平臺化產品模型思考

這段時間，通過對于平臺化的思考，我總結了平臺化的通用產品模型，在此拋磚引玉，希望大家一起討論下：

這個模型主要分4層，分為業務層，功能層，接口層，應用層。

1.業務層，是指業務分治后，劃分清晰的不同業務。

這一層主要對應的是平臺化中的業務分治的要求，要求業務邊界劃分明確，專業的人干專業的事。

2.功能層，是指為實現該業務運轉需要的業務功能。

這一層主要對應的是平臺化中的柔性支撐的要求。

我個人覺得業務功能可以由三種要素組合合成，分別為前端能力，后端能力以及業務規則組成，因此柔性支撐應該在這三種要素中均進行體現。具體的做法，就是通過前端的模塊化，后端的流程可配置化以及業務規則的可配置化，來實現業務功能的柔性支撐。

3.接口層，是指對底層功能的封裝層。

這一層主要對應的平臺化中的歸口管理的要求。通過接口層，由一個底層服務團隊對多個業務方統一提供服務，從而做到底層功能的歸口管理。

4.應用層，是指業務方的應用層面。

業務方只需要對應接口層，即可實現想要的功能，對他們來說，底部的功能實現都是黑箱的，他們是需要用類似SDK的形式來與接口層進行交互即可。

以上是我對于平臺化的理解。綜上，平臺化架構是一個在面對需求小批量、多批次、時效要求高的業務場景下的好選擇，對于生產效率的提高是有極大好處的。

本文由 @啟辰菌 原創發布于人人都是產品經理。未經許可，禁止轉載。