中臺詳解(上)——什么是中臺
編輯導(dǎo)語:中臺這一概念,這兩年在國內(nèi)大熱,不少企業(yè)接連開始組織架構(gòu)的調(diào)整,意圖建設(shè)中臺;中臺到底是什么?哪類企業(yè)可以搭建中臺?本文作者對中臺進行了非常詳細的分析,我們一起來看一下。
《中臺詳解系列》共分上下兩篇,本文為上篇,總計約8100字,因為文中涉及知識體系較為廣泛,建議預(yù)留20—25分鐘進行閱讀。
目前市場僅對“中臺”和“平臺”間的繼承和發(fā)展關(guān)系有一定共識,“中臺”的定義及建設(shè)規(guī)范尚未有明確定論;本系列文章旨在基于“以終為始”的思維模式,及“軟件對現(xiàn)實世界建?!钡幕A(chǔ)條件,梳理傳統(tǒng)軟件“平臺”所面臨的問題;并以此為起點,結(jié)合經(jīng)濟學(xué)中專業(yè)化分工協(xié)作理論,為“中臺”進行職能定義,再通過“中臺”的職能定義給出“中臺”建設(shè)的建議方案。
18年初,我初次接觸到“中臺”概念的時候,也不免心馳神往了一番,畢竟即使在概念漫天飛的國內(nèi)IT圈,“中臺”也算是天空中最亮的那顆星;現(xiàn)在臨近2020年末,近3年的時間如白駒過隙,期間我有幸參與了多個“中臺”項目,其中吉利汽車全球營銷業(yè)務(wù)“中臺”項目在整個阿里云“中臺”戰(zhàn)略中也算是比較成功的案例。
然而遺憾的是,“中臺”也未能逃脫國內(nèi)IT圈大熱概念“站得越高,摔得越疼”的魔咒,年初茅臺拆除“中臺”的消息像一把利劍,戳破了“中臺”的泡沫;一時間各種“馬后炮”震耳欲聾,這也算對得起“中臺”一直以來的熱度,只是其中內(nèi)容漏洞百出,讓人啼笑皆非。
有“顧名思義”說“中臺”是夾在前臺和后臺之間,起到承上啟下作用的:
有引用美國經(jīng)濟學(xué)出版圖書《平臺戰(zhàn)略》來解釋“中臺”的:
節(jié)選自科技自媒體“技術(shù)領(lǐng)導(dǎo)力”推文
而作為一個過來人,我覺得有必要聊一聊自己的心得,以使得大家可以對“中臺”有更加客觀的理解。
老規(guī)矩,咱們還是按照“是什么”、“有什么價值”、“怎么做”的順序來聊。
一、什么是“中臺”?為什么要搞“中臺”?
有人說:現(xiàn)在大家爭論“中臺”樣子,跟當(dāng)年爭論“云”一模一樣;顯然什么是“中臺”,市面上還沒有一個統(tǒng)一的說法,所以這里我自己給“中臺”下了一個定義:
“中臺”是對傳統(tǒng)“軟件平臺”的升級和加強,通過在企業(yè)層面引入新的專業(yè)化職能分工、數(shù)據(jù)唯一性建模等規(guī)則;在解決軟件行業(yè)“重復(fù)造輪子”問題的基礎(chǔ)上,進一步解決了傳統(tǒng)“軟件平臺”未能解決的“軟件平臺間職能邊界劃分問題”及“數(shù)據(jù)孤島問題”。
這里有幾個關(guān)鍵詞——“企業(yè)層面”、“軟件平臺”、“專業(yè)化職能分工”、“數(shù)據(jù)唯一性建?!?。
“中臺”是對“軟件平臺”的自然演進這一觀點,可以說在IT業(yè)界已經(jīng)得到了初步的共識,阿里云的架構(gòu)師也通過科技自媒體透露過阿里云對于這一問題的認(rèn)知。
那“軟件平臺”到底是怎么演進成“中臺”的呢?“軟件平臺”又到底為什么要演進成“中臺”呢?相關(guān)工作又為什么要在企業(yè)層面完成?“專業(yè)化職能分工”、“數(shù)據(jù)唯一性建?!庇质鞘裁垂??
鑒于所有的軟件及其背后的理論、原理、概念、技術(shù)都是為了解決業(yè)務(wù)問題而產(chǎn)生的,就讓我?guī)е蠹乙贿吺崂怼爸信_”產(chǎn)生的業(yè)務(wù)背景,一邊揭開“中臺”的面紗。
圖片來自于阿里云業(yè)務(wù)中臺&云原生架構(gòu)師“宇升”在自媒體上發(fā)表的《我們阿里內(nèi)部是怎么做業(yè)務(wù)中臺的?》一文。
1. 信息化帶來甜蜜的煩惱
信息技術(shù)的發(fā)展對人類的影響是空前的,但對于效率的極致追求,使得人類在信息技術(shù)大規(guī)模應(yīng)用后,又發(fā)掘出了一系列新的待解決問題;比如大家一致認(rèn)為“中臺”核心要解決的問題——重復(fù)造輪子。
軟件研發(fā)重復(fù)造輪子的問題:
為了應(yīng)對市場發(fā)展及用戶成長對業(yè)務(wù)增長帶來的負面沖擊,企業(yè)會拓展新業(yè)務(wù),或?qū)⒁呀?jīng)較為成熟的業(yè)務(wù)線拆分為若干條子業(yè)務(wù)線、若干子環(huán)節(jié)以開展精細化運營。
這些業(yè)務(wù)線、業(yè)務(wù)環(huán)節(jié)中,會有很多相似的業(yè)務(wù)內(nèi)容,比如可能都需要廣告投放、商品展示、用戶激勵、訂單交易、支付收款等;不過不同業(yè)務(wù)線中相似業(yè)務(wù)的發(fā)生時間和細節(jié)要求并不一致。
以往為了追求效率,很多企業(yè)是通過不斷為不同業(yè)務(wù)線中的相似業(yè)務(wù)定制開發(fā)相似的功能來解決這個問題的——這就產(chǎn)生了重復(fù)勞動,會造成研發(fā)資源的極大浪費。
更要命的是,重復(fù)造輪子還會造成“次生災(zāi)害”——運維成本的爆炸性增長。
重復(fù)造輪子造成高運維成本的問題:
一方面,針對不同業(yè)務(wù)線中的相似業(yè)務(wù)定制開發(fā)相似的功能,會導(dǎo)致相似功能的模型及代碼有很多份,技術(shù)框架不一致,就像汽車的零件型號一樣,從數(shù)量上增加了運維難度;另一方面,在實際運維工作過程中,軟件中相似功能過多也很容易讓運維人員記錯,導(dǎo)致二次事故。
2. 求助現(xiàn)實,見招拆招
幸運的是,因為軟件的本質(zhì)是“對現(xiàn)實世界建?!保栽谲浖ㄔO(shè)和應(yīng)用過程中,遇到的很多問題都可以在現(xiàn)實世界中找到類似情況及解決方案。
為了應(yīng)對“重復(fù)造輪”的問題,軟件開發(fā)領(lǐng)域很早就引入了“平臺化”模式。
平臺化:
“平臺化”概念最早出現(xiàn)在工業(yè)制造領(lǐng)域,更廣為大眾所熟知的則是汽車生產(chǎn)平臺。
汽車上零件眾多,開發(fā)一個車型涉及技術(shù)集成、零部件設(shè)計、試驗驗證等繁雜環(huán)節(jié),出了名的耗資大、周期長、風(fēng)險高;而絕大多數(shù)消費者,在拿到車之后,并不關(guān)心車的底盤是怎么設(shè)計的,發(fā)動機是橫置的還是豎置的;他們可能更關(guān)心車是什么顏色的,座椅是不是真皮的,保險杠上的大燈好不好看。
于是乎,絕大多數(shù)汽車企業(yè)會使用相似底盤和下車體的公共架構(gòu),在這個平臺結(jié)構(gòu)上生產(chǎn)出外形功能都不盡相同的產(chǎn)品。這就是汽車的平臺化/模塊化戰(zhàn)略。
汽車的平臺化
軟件的“平臺化”也是類似,將可復(fù)用部分抽象成模塊組件,再基于這些模塊組件進行業(yè)務(wù)化串聯(lián)、增量包裝,就可以適應(yīng)不斷變化的業(yè)務(wù)需求。
不過需要說明的是,“平臺”本身是個多義詞,《平臺革命》中的“平臺”說好聽點叫做掌握市場入口,說難聽點就是中介,跟這里說的“平臺”一點關(guān)系都沒有,只怪古早時期的譯制工作太粗糙。
平臺是個多義詞
然而對于效率的極致追求,又使得人們很快發(fā)現(xiàn),就像電影、唱片、磁帶等文化產(chǎn)品與一般的商品在生產(chǎn)、流轉(zhuǎn)和使用過程中有著很大的差別一樣,完全照搬工業(yè)制造領(lǐng)域的“平臺化”理論好像也有問題。
軟件“平臺”間的職能邊界問題:
“平臺”的本質(zhì)是模塊組件,模塊組件多數(shù)情況下是必須與其他模塊組件進行業(yè)務(wù)化串聯(lián),甚至還需要進行增量的個性化定制包裝,才能夠真正解決業(yè)務(wù)問題的。
這就帶來了“平臺”間如何協(xié)作的問題,即“軟件平臺”間的職能邊界是什么?
如不解決這個問題就很容易出現(xiàn)以下兩種情況:
- 各協(xié)作的模塊組件都不集成某一可復(fù)用能力——出現(xiàn)這種情況,就解決不了“重復(fù)造輪子”的問題。
- 各協(xié)作的模塊組件同時集成了某一可復(fù)用能力——出現(xiàn)這種情況,則會導(dǎo)致“軟件平臺”間面臨類似企業(yè)組織分工常常面對的多頭管理的情況:職能上,你也能干,我也能干;解決問題時,你不想干,我也不相干,最終結(jié)果就是兩個模塊組件都難以使用、難以迭代;這一點,做過大型軟件1-n迭代的朋友應(yīng)該都深有感觸。
在模塊組件間協(xié)作時,實物產(chǎn)品先天有空間限制條件作為基準(zhǔn),比如汽車前車燈和車尾燈,就可以根據(jù)空間位置不同而解決不同的問題;而軟件產(chǎn)品的各“平臺”間就和企業(yè)的組織機構(gòu)一樣缺乏這種天然的協(xié)作標(biāo)準(zhǔn)。
數(shù)據(jù)孤島問題:
“數(shù)據(jù)孤島”這個詞看起來唬人,實際上它只不過是以下3種原因造成業(yè)務(wù)數(shù)據(jù)難以統(tǒng)一分析、管理情況:
- 針對不同業(yè)務(wù)線中的相似業(yè)務(wù)定制開發(fā)相似的功能,使得不同業(yè)務(wù)線的相似功能的數(shù)據(jù)天然隔離。
- 在針對不同業(yè)務(wù)線中的相似業(yè)務(wù)定制開發(fā)相似的功能過程中,沒有對數(shù)據(jù)模型做出統(tǒng)一標(biāo)準(zhǔn)要求,上線后的產(chǎn)生的業(yè)務(wù)數(shù)據(jù)字段的命名/排序/格式/注釋等不一致。
- 在同一業(yè)務(wù)線不同功能的開發(fā)過程中,未對不同業(yè)務(wù)之間的關(guān)系進行建模,上線后的產(chǎn)生的業(yè)務(wù)之間的關(guān)系數(shù)據(jù)沒有保存下來,以至于難以判斷同一業(yè)務(wù)線不同業(yè)務(wù)之間的關(guān)聯(lián)性。
而原有的“平臺化”理論起源于工業(yè)制造領(lǐng)域,顯然沒有專門考慮過數(shù)據(jù)治理的問題。
雖然很多開發(fā)者在構(gòu)建“軟件平臺”時,也會關(guān)注數(shù)據(jù)治理,使得軟件的“平臺化”可以在一定程度上緩解“數(shù)據(jù)孤島”;但因為“軟件平臺”本身還面臨著職能邊界的問題,即不同“軟件平臺”可能集成同一可復(fù)用能力,所以其無法從根本上解決問題。
為此,市場上長時間流行著一套“臨時解決方案”——外接“數(shù)倉”,具體步驟是:
- 先進行業(yè)務(wù)分析;
- 再梳理原有各系統(tǒng)的數(shù)據(jù)結(jié)構(gòu);
- 然后在新的“數(shù)據(jù)倉庫”中重新建模;
- 接下來將原有各系統(tǒng)中的數(shù)據(jù)字段與新的“數(shù)據(jù)倉庫”中數(shù)據(jù)字段建立映射關(guān)系;
- 然后再執(zhí)行腳本提取歷史數(shù)據(jù);
- 最后啟動定時器定時提取原有各系統(tǒng)中增量數(shù)據(jù)。
看這個過程就知道,這一通操作下來的成本肯定是低不的,實際上這么浩大的工程確實也只有那些銀行或大型上市公司才能負擔(dān)的起。
另外這個解決方案還有著一堆的毛病,比如說,這個新的“數(shù)據(jù)倉庫”不直接支持業(yè)務(wù),里面的建模合理嗎?原有各系統(tǒng)都不知道哪一年、那個團隊、根據(jù)什么樣的業(yè)務(wù)規(guī)則、用哪種語言和技術(shù)框架做的,還能梳理清楚嗎?數(shù)據(jù)遷移時的數(shù)據(jù)映射關(guān)系寫錯了是不是一定要等錯誤的數(shù)據(jù)阻塞業(yè)務(wù)了才能夠發(fā)現(xiàn)?定時取增量數(shù)據(jù)的時效性如何保障?取數(shù)時如何保障數(shù)據(jù)不會丟失?未來的新系統(tǒng)咋辦?
3. “中臺”崛起
這個世界上的概念從來都不是沒來由的,就像前人們會引入“平臺”理論來解決“重復(fù)造輪子”的問題一樣,背負著解決“軟件平臺間職能邊界劃分問題”、“數(shù)據(jù)孤島問題”的使命,中臺誕生了。
在解決“軟件平臺間職能邊界劃分問題”上,“軟件平臺”間缺乏先天條件作為協(xié)作基準(zhǔn);但萬幸的是我們還可以求助現(xiàn)實世界,這里推薦的是“微觀經(jīng)濟學(xué)”領(lǐng)域中的“協(xié)作理論”,它是經(jīng)過了高度總結(jié)的,在各個領(lǐng)域中都有著豐富且成功的應(yīng)用案例。
協(xié)作:
定義:個體組合在一起協(xié)力完成工作,協(xié)作分為簡單協(xié)作和復(fù)雜協(xié)作;簡單協(xié)作是沒有專業(yè)分工的協(xié)作,復(fù)雜協(xié)作則是建立在專業(yè)分工基礎(chǔ)上的。(摘自現(xiàn)代經(jīng)濟詞典)
從定義中我們可以看出,傳統(tǒng)情況下“軟件平臺”間的協(xié)作即是“簡單協(xié)作”,而“中臺”則需要采用“復(fù)雜協(xié)作”,即專業(yè)化分工協(xié)作,來解決“軟件平臺”間“簡單協(xié)作”所暴露出的問題。專業(yè)化分工有以下兩種原則。
工藝專業(yè)化:按照工藝階段或工藝設(shè)備相同性的原則來建立生產(chǎn)單位,即按不同的生產(chǎn)工藝特征,建立不同的生產(chǎn)單位。
特點:“三同一不”;三同——同類型的機器設(shè)備、同工種工人 、相同工藝方法;一不——不同的勞動對象。(摘自現(xiàn)代經(jīng)濟詞典)
對象專業(yè)化:按照業(yè)務(wù)對象來劃分生產(chǎn)單位的原則,即按不同的勞動對象,建立不同的生產(chǎn)單位。
特點:“三不一同”;三不——不同類型的機器設(shè)備、不同工種工人、不同工藝方法;一同——相同的勞動對象。(摘自現(xiàn)代經(jīng)濟詞典)
因為相關(guān)經(jīng)濟學(xué)原理比較早的應(yīng)用于實物領(lǐng)域,所以這兩個原則中的各名詞都是比較貼近實物場景的,不過這不影響我們理解其中含義。
我們可以基于軟件行業(yè)的要素特征對上述原則進行名詞上的替換:
能力專業(yè)化:按照業(yè)務(wù)方案階段或模型、方法相同性的原則來建立生產(chǎn)單位,即按不同的業(yè)務(wù)能力方案特征,建立不同的生產(chǎn)單位。
特點:“多同一不”;多同——相同模型 、相同方法、相同服務(wù)等;一不——不同的業(yè)務(wù)對象。
對象專業(yè)化:按照業(yè)務(wù)對象來劃分生產(chǎn)單位的原則,即按不同的業(yè)務(wù)對象,建立不同的生產(chǎn)單位。
特點:“多不一同”;多不——不同模型 、不同方法、相同服務(wù)等;一同——相同的業(yè)務(wù)對象。
在解決“數(shù)據(jù)孤島問題”上,業(yè)務(wù)間關(guān)系數(shù)據(jù)缺失的情況比較好解決,也不影響“中臺”理論的構(gòu)建,就暫且不討論了;而從其余情況的產(chǎn)生原因上我們就可以看出,要解決它們最好的辦法就是“從頭到尾相似的數(shù)據(jù)就只有一份”。
在“軟件平臺”間“簡單協(xié)作”的情況下,很難達成這個目標(biāo);而如果 “軟件平臺”間采用“復(fù)雜協(xié)作”,即專業(yè)化職能分工,我們只要將分工后的“軟件平臺”進行數(shù)據(jù)唯一性建模,就可以達成“從頭到尾相似的數(shù)據(jù)就只有一份”的目標(biāo)。
而不管是要進行“軟件平臺專業(yè)化分工”,還是“數(shù)據(jù)唯一性”建模,顯然都要在企業(yè)層面進行拉通,而不是各個子產(chǎn)品間各自為政。
綜上所屬,我給“中臺”下了本章節(jié)開頭的定義:即“中臺”是對“平臺”的升級,承擔(dān)著企業(yè)層面軟件能力資源的專業(yè)化、職能化管理,生產(chǎn)數(shù)據(jù)歸一的職責(zé)。
二、“中臺”帶來新的機會
新事物必然帶來新的機會。
這里我們就先來聊一聊“中臺”給市場內(nèi)主要參與角色——“企業(yè)”和“云服務(wù)商”帶來的機會;另外,因為我自己是產(chǎn)品經(jīng)理,所以也會聊一聊產(chǎn)品經(jīng)理之于“中臺”的角色定位。
1. 企業(yè)——“中臺”是什么不重要,能解決什么問題最重要
“thought works”的首席咨詢師王健在談?wù)撍麑Α爸信_”的看法時說到:“中臺是什么不重要,能解決什么問題最重要?!睂τ谶@句話我深以為然。
而令人遺憾的是,以“茅臺中臺項目”為代表的一系列失敗的“中臺”項目案例,似乎讓場內(nèi)玩家在“中臺能解決什么問題”上紛紛失去了方寸;甚至連阿里巴巴CEO逍遙子也公開表示:“中臺”并不適用于每家公司的每個階段;在獨立業(yè)務(wù)拓展期、突破期,一定用獨立團、獨立師、獨立旅建制來做,否則就會變成瓶頸;但發(fā)展到一定階段,出現(xiàn)太多山頭時,就要關(guān)停并轉(zhuǎn)、要合并同類項;問管理要效率,取消重復(fù)性建設(shè)。(消息來自36氪)
對于這樣的觀點我并不能認(rèn)同,原因有3:
1)無論是阿里云還是其他場內(nèi)玩家,對于“中臺”這么重視,不都是因為其可以解決“重復(fù)造輪子”的問題,從而解放研發(fā)人力,最終保障創(chuàng)新業(yè)務(wù)有足夠的人力資源支持嗎?那什么樣的企業(yè)業(yè)務(wù)發(fā)展速度最快?人力成本壓力最大呢?當(dāng)然是創(chuàng)業(yè)期和拓展期的企業(yè)。
2)在很多企業(yè)進行產(chǎn)品經(jīng)理或架構(gòu)師招聘時,都有這么一條——能夠設(shè)計可拓展型系統(tǒng),而要保障系統(tǒng)的拓展性,系統(tǒng)模塊間的專業(yè)化分工設(shè)計必不可少;實際上,為了追求效率而繞開軟件各模塊的職能劃分環(huán)節(jié),直接采用砌式產(chǎn)品研發(fā),使得軟件系統(tǒng)功能耦合嚴(yán)重,最終導(dǎo)致系統(tǒng)難以迭代必須重構(gòu)的情況,在IT業(yè)界比妹子還常見;對于一些創(chuàng)業(yè)期和拓展期來說,這種問題的影響是近乎致命的。
3)“數(shù)據(jù)孤島問題”很可能會讓創(chuàng)業(yè)期和拓展期的企業(yè)辛苦收集的業(yè)務(wù)數(shù)據(jù)一文不值,亡羊補牢式的數(shù)據(jù)采集及治理方案所需的人力和資金成本,很可能高于前期軟件各模塊間的專業(yè)化分工設(shè)計和數(shù)據(jù)唯一性建模;而如果采用“中臺”方案,即便一開始的建模合理性不足,也會因為數(shù)據(jù)就一份而很容易進行遷移或字段的升級。
所以我認(rèn)為不管你的項目是to?b還是to?c的,只要不是單純to?vc圈錢的,且具備以下兩點條件,在進行IT建設(shè)時就可以、也應(yīng)該考慮“中臺”。
- 有明確的商業(yè)規(guī)劃。
- 遠期目標(biāo)包含業(yè)務(wù)線的拓展或業(yè)務(wù)線的細分。
而包括阿里巴巴CEO逍遙子在內(nèi)的很多人,認(rèn)為創(chuàng)業(yè)期和拓展期的企業(yè)不適合上“中臺”,本質(zhì)上是對初創(chuàng)企業(yè)IT建設(shè)能力低下與“中臺”建設(shè)成本高昂之間難以調(diào)和的矛盾的擔(dān)心。
但軟件作為信息技術(shù)的一種應(yīng)用形態(tài),它的核心特點之一就是邊際成本會越來越低,創(chuàng)業(yè)期和拓展期的企業(yè)就算做不起“中臺”,難道還買不起嗎?就算買不起,難道還租不起嗎?而這就給云服務(wù)商在“中臺”市場上的發(fā)揮留下了充足的想象空間。
2. 云服務(wù)商——彎道超車,在此一舉
包括阿里云、騰訊云在內(nèi)的眾多云服務(wù)商,近年來一直都是在硬件和基礎(chǔ)組件的基礎(chǔ)上,盡可能豐富自己的工具生態(tài),以提高自身在客戶面前的競爭力。
比如阿里云就陸續(xù)推出了quick?bi、quick?audience等一系列工具產(chǎn)品;如果云服務(wù)商能夠提供“中臺”相關(guān)saas、paas產(chǎn)品,無疑可以將自身的競爭力提升到頂點。
原因也有3:
1)“中臺”本身就帶有強烈的業(yè)務(wù)屬性,企業(yè)進行對“中臺”的各項能力進行串聯(lián)即可完成產(chǎn)品的搭建,這對企業(yè)人力的解放是空前的,無疑具備極大的市場需求。
并且我想說,這才是一般企業(yè)與信息技術(shù)之間最合理的關(guān)系;說到底信息技術(shù)也只是一個工具,就像當(dāng)年的電話,也沒見哪家企業(yè)自己建基站、造電話機,企業(yè)核心要做的是研究“怎么用電話幫助自己的業(yè)務(wù)增長”,并將相關(guān)方法落地。
2)就像不同的企業(yè)在部門專業(yè)化職能分工上有一定區(qū)別一樣,“中臺”模塊間的專業(yè)化職能分工業(yè)務(wù)可以按照不同原則進行劃分,只要合理就好;比如我司會因為部署需要,把權(quán)益中心在拆分為會員卡中心、積分中心、卡券中心等——這使得企業(yè)在使用云服務(wù)商的“中臺”服務(wù)進行業(yè)務(wù)編排時寫得“膠水代碼”變成了命題作文,難以復(fù)用;這可以提高企業(yè)更換云服務(wù)商的成本,換句話說就是可以提高云服務(wù)商的客戶粘性。
3)而在業(yè)務(wù)域數(shù)據(jù)唯一性建模時,云服務(wù)商可以采用獨特的數(shù)據(jù)字段命名、排序、格式、注釋等方式,甚至采用獨特的數(shù)據(jù)存儲環(huán)境;這也可以提高企業(yè)更換云服務(wù)商的成本,同時自身的中臺產(chǎn)品迭代時客戶的數(shù)據(jù)卻可以便捷的進行遷移。
在具體操作上,針對創(chuàng)業(yè)期和拓展期的企業(yè)可提供saas產(chǎn)品,開箱即用,讓其輕裝上陣;針對發(fā)展到一定階段的企業(yè),也可以像華為買斷ARM的芯片架構(gòu)使用授權(quán)一樣,支持其買斷產(chǎn)品使用權(quán)限,甚至進行本地化部署。
3. 產(chǎn)品經(jīng)理——虎口奪食,咱們一起建模吧
最近,產(chǎn)品經(jīng)理圈子彌漫著一股悲觀情緒——“互聯(lián)網(wǎng)的下半場不需要產(chǎn)品經(jīng)理”,究其原因是因為大量編輯器的出現(xiàn),使得很多“界面經(jīng)理”感受到了威脅。
我一貫認(rèn)為后臺產(chǎn)品經(jīng)理需要重點關(guān)注業(yè)務(wù)結(jié)構(gòu),交互界面次之;而“中臺”對于“專業(yè)化職能分工”及“數(shù)據(jù)唯一性建模”的強烈需求,勢必會將業(yè)務(wù)結(jié)構(gòu)設(shè)計推向軟件行業(yè)舞臺的中心。
“軟件平臺”的“專業(yè)化職能分工”加“數(shù)據(jù)唯一性建?!蔽覀児们医y(tǒng)稱為業(yè)務(wù)建模。
關(guān)于業(yè)務(wù)建模是否需要產(chǎn)品經(jīng)理參與這件事,我思考了很久,也與身邊的多位技術(shù)架構(gòu)師進行了多次深入討論,最終我的結(jié)論是——業(yè)務(wù)建模是需要產(chǎn)品經(jīng)理的參與。
“中臺”所承載的進行“軟件平臺”的“專業(yè)化職能分工”的使命,具有強烈的業(yè)務(wù)屬性;而軟件產(chǎn)品經(jīng)理這一角色,設(shè)立的核心目的之一就是將研發(fā)人員從痛苦的業(yè)務(wù)研究中解放出來。
就像我一位現(xiàn)就職于菜鳥的前同事(技術(shù)架構(gòu)師)在懟“界面經(jīng)理”時所說的:“都說軟件是對現(xiàn)實世界建模,我哪有空了解現(xiàn)實世界是什么樣子的?如果我把現(xiàn)實世界摸清楚了,我不就是產(chǎn)品經(jīng)理了嗎?”
換個角度來說,作為將研發(fā)人員從業(yè)務(wù)研究中解放出來的角色,產(chǎn)品經(jīng)理本身就沒有辦法把真實世界直接搬到研發(fā)人員面前。
產(chǎn)品經(jīng)理所提供的的業(yè)務(wù)流程圖、規(guī)格清單、功能流程圖、RP原型稿、PRD說明文檔等本質(zhì)上都是對顯示世界的一種模型化表達,只不過“中臺”對于“專業(yè)化職能分工”加“數(shù)據(jù)唯一性建模”的需求,使其對產(chǎn)品經(jīng)理業(yè)務(wù)建模能力的要求提高了很多。
現(xiàn)實世界、業(yè)務(wù)模型、技術(shù)模型
之前就有消息說,國內(nèi)某大型企業(yè)內(nèi)部要求旗下所有產(chǎn)品經(jīng)理必須懂技術(shù),現(xiàn)在想來,應(yīng)該是管理層發(fā)現(xiàn)了產(chǎn)品經(jīng)理建模能力的重要性,而粗暴的將其解讀為需要產(chǎn)品經(jīng)理懂技術(shù)吧?
不過,不管“中臺”產(chǎn)品的建設(shè)對產(chǎn)品經(jīng)理的業(yè)務(wù)建模能力要求有多高, 業(yè)務(wù)建模需要掌握的只是無外乎都是要掌握如下知識:
- 建模思想:對現(xiàn)實世界的認(rèn)知視角,如面向過程、面向?qū)ο笠约胺庋b概念等。
- 建模方法:對現(xiàn)實世界的描述方法,如領(lǐng)驅(qū)動設(shè)計等。
- 建模工具:對現(xiàn)實世界的描述工具,以及輸出物載體,如UML等。
- 建模方案:什么情況下采用什么思想什么方法什么工具進行建模,輸出物需要怎么展示的案例。
國內(nèi)目前還缺乏針對業(yè)務(wù)建模系統(tǒng)化的方法論,我自己通過一直以來對各種建模思想的研究,摸索了一套相對適合產(chǎn)品經(jīng)理的業(yè)務(wù)建模方法論,相關(guān)內(nèi)容我后面都會單獨寫專題文章介紹。
三、說句心里話
軟件是對現(xiàn)實世界的一種數(shù)據(jù)化呈現(xiàn),而現(xiàn)實世界中的人類文明發(fā)展了幾千年,有很多基礎(chǔ)理論可以支持軟件理論的發(fā)展,比如文章一開始提到的“平臺”,又比如“面向?qū)ο蟆闭J(rèn)知模式。
1. 面向?qū)ο?/h3>
人類認(rèn)識世界的一種視角,比如:張三交了一個新朋友,張三關(guān)注到這位新朋友的職業(yè)是醫(yī)生,就想著以后生病了可以找這位朋友,這就是典型的面向?qū)ο笏季S;如今面向?qū)ο笏季S廣泛應(yīng)用于軟件設(shè)計領(lǐng)域。
而目前市場中對“中臺”的種種解讀,大多缺乏基礎(chǔ)原理支持,并且這種情況在IT行業(yè)并不鮮見,比如所謂的用戶心理學(xué)。
2. 用戶心理學(xué)
我翻遍了整個網(wǎng)絡(luò),也沒能找到這個概念的系統(tǒng)化解釋;而我本專業(yè)有一門學(xué)科叫做“微觀經(jīng)濟學(xué)”,學(xué)科定義就是:研究經(jīng)濟個體(個人或團隊)如何支配自己的稀缺資源,比如時間、人脈、資金等。
作為入行多年的產(chǎn)品經(jīng)理,我能夠理解“對于營銷概念的爭吵可以增加熱度”的邏輯。
但“中臺”概念已經(jīng)夠火了,“中臺”概念火熱的背后是市場對于效率的渴求,而目前這些缺乏基礎(chǔ)原理支持的解讀顯然與這樣的目標(biāo)背道而馳,這會進一步增加市場對“中臺”概念的誤解。
本文也只是我的一家之言,不過我想只有基礎(chǔ)理論嚴(yán)肅分析,實實在在的解決問題,形成案例,才能保障一個“概念”可以長久的產(chǎn)出價值。
本文由 @阿魏 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
真的不錯,尤其是「數(shù)據(jù)唯一性建模」,和我之前的一些模糊理解不謀而合,但你系統(tǒng)性地輸出了,非常厲害。
謝謝哦。4年前寫的了,當(dāng)時很多名詞用的還不專業(yè),希望最近可以有時間可以將本文優(yōu)化一下,
業(yè)務(wù)建模,可以參考一下TOGAF標(biāo)準(zhǔn),里面包括了企業(yè)架構(gòu)的方方面面,不僅僅是互聯(lián)網(wǎng)關(guān)注的單一技術(shù)架構(gòu)。
是的,TOGAF標(biāo)準(zhǔn)本質(zhì)上也是基于文中相同目標(biāo)制定出的相對最佳實踐。
不過一方面TOGAF標(biāo)準(zhǔn)在國內(nèi)的落地性較弱,另一方面TOGAF標(biāo)準(zhǔn)基于經(jīng)驗主義得出的階段性相對最優(yōu)解。所以國內(nèi)在做產(chǎn)品設(shè)計時也需要理解TOGAF標(biāo)準(zhǔn)是如何制定出來的,以及基于相同規(guī)律未來可能會有哪些拓展、變化,這里可能會涉及一些認(rèn)知論層面的理論、方法。
寫得很好,本來想關(guān)注一下你,發(fā)現(xiàn)2020年就斷更了
這么好的文章,可惜不更新了,555
感謝阿魏
“國內(nèi)目前還缺乏針對業(yè)務(wù)建模系統(tǒng)化的方法論,我自己通過一直以來對各種建模思想的研究,摸索了一套相對適合產(chǎn)品經(jīng)理的業(yè)務(wù)建模方法論,相關(guān)內(nèi)容我后面都會單獨寫專題文章介紹?!薄裁磿r候來填坑?
呃~~早知今日,何必挖坑額。在整理了,后面會通過文章+視頻的方式發(fā)出來。
看了這么多介紹中臺的文章,終于有一篇能讓我在腦子里大概構(gòu)想出自己要做的產(chǎn)品的樣子了。以前只對中臺產(chǎn)品有模糊的概念,看了很多文章只宏觀介紹了中臺概念,對于為什么要做中臺,具體怎么應(yīng)用中臺完成目標(biāo)都沒有什么概念。這篇文章簡直太全面啦。
很高興能夠給你一點啟發(fā),最近準(zhǔn)備回來填坑了。
對于初創(chuàng)企業(yè),首先解決“活下來”的問題,然后是“發(fā)展”問題。故:
1.如果企業(yè)在“活下來”階段,并沒有業(yè)務(wù)拓展/細分的需求,就不要做中臺,哪怕將來“發(fā)展”階段會投入更多成本來做中臺——本質(zhì)上是透支“發(fā)展”階段的成本來提升“活下來”的成功率,類似貸款要付利息
2.如果企業(yè)在“活下來”階段,就有業(yè)務(wù)拓展的需求,就可以做中臺來降低整個“活下來”階段的成本
但大部分初創(chuàng)企業(yè)都是盯著一個點打透,所以在“活下來”階段都沒有業(yè)務(wù)拓展的需求,因此大部分創(chuàng)業(yè)者不會在早期做中臺(畢竟不敢“貸款”的創(chuàng)業(yè)者不是好的創(chuàng)業(yè)者)
所以需要云服務(wù)商的SAAS化中臺產(chǎn)品。
非常同意~~
起步期,定制化系統(tǒng)是較于中臺建設(shè)更優(yōu)的選擇,在沒有商業(yè)化SAAS產(chǎn)品出現(xiàn)的時候,對于企業(yè)本身來說,確實不應(yīng)該選擇中臺
期待作者的《產(chǎn)品經(jīng)理的業(yè)務(wù)建模方法論》
阿魏老師,我沒讀過書,只會說:蕪湖~臥槽,牛逼!
催更催更
哥,你來看我笑話了。
催更催更!?。?br /> PS:入門級產(chǎn)品小白,不指望靠著看幾篇“中臺”文章就能懂個所以然,但是希望能看到好的文章能讓我對“中臺”有一個較為清晰的認(rèn)知
編輯應(yīng)該在發(fā)下篇了。剛?cè)胄械脑捒梢匀タ纯次业牧硗庖黄恼隆段医o生鮮電商的一些建議:互聯(lián)網(wǎng)是標(biāo)準(zhǔn)化產(chǎn)品的天下》,里面有用戶預(yù)期管理、用戶滿意度管理方面原理性的介紹。后面我也會不定期寫一些面向初中級產(chǎn)品經(jīng)理的內(nèi)容,歡迎持續(xù)關(guān)注本專欄。
“界面經(jīng)理”很不友好哈哈哈哈
很贊同作者觀點,確實現(xiàn)在搭建中臺的成本還是很高,SaaS的概念也出來很久了,而能夠普遍適用于各個行業(yè)的ToB中臺商業(yè)軟件還是很少,甚至適用于一個行業(yè)的中臺商業(yè)軟件都很罕見,多數(shù)都是在自己搭建。
拋開商業(yè)中臺軟件不談,企業(yè)自己搭建的路確實也挺遙遠的,首先能夠為初創(chuàng)企業(yè)規(guī)劃搭建信息化中臺的從業(yè)人員就很少,又很難說服初創(chuàng)企業(yè)主在起步階段就做這項投資。
是的。實操過的應(yīng)該都能理解,不同企業(yè)對于“平臺”或“中臺”的需求是類似的,畢竟相對于上層系統(tǒng)會更抽象,所以說起來“中臺”應(yīng)該是非常適合saas化的。不過估計是國內(nèi)堆砌式開發(fā)搞慣了,比較缺乏體系化構(gòu)建系統(tǒng)得經(jīng)驗,國內(nèi)某巨頭的系統(tǒng)都是堆砌式的。體系化建設(shè)是一個大課題,不只是中臺,像國內(nèi)很多巨頭企業(yè)組織架構(gòu)都會大幅調(diào)整,簡直不可思議。
對文章中初創(chuàng)型企業(yè)是否要搭建中臺,我覺得作者沒有考慮全面,成本是初創(chuàng)型企業(yè)是否搭建中臺的原因之一,但是是否搭建中臺最重要的考慮應(yīng)該是:業(yè)務(wù)是否多元化,換而言之是否存在重復(fù)造輪子的情況。初創(chuàng)型的企業(yè)業(yè)務(wù)一般比較單一,都是在做自己的拳頭產(chǎn)品,沒有哪個初創(chuàng)型的公司會同時做很多條業(yè)務(wù)線。所以無論從成本還是業(yè)務(wù)角度,我是認(rèn)同中臺并不適用于每家公司的每個階段。以上僅代表我個人意見~
第2章第1節(jié)有說明如果企業(yè)未來的發(fā)展有涉及業(yè)務(wù)線拓展和細分的需要考慮中臺。另外,文章的觀點是初創(chuàng)公司在中臺的應(yīng)用上有明確的痛點,但是并不需要自己去做,第2章第2節(jié)即是說明云服務(wù)商在這其中應(yīng)該扮演的角色。
并且從實操經(jīng)驗上來說,我不建議亡羊補牢式的上中臺,相關(guān)原因文中又都描述。不過確實不是所有的企業(yè)都應(yīng)該上中臺,主要還是要看企業(yè)自身的藍圖規(guī)劃,但這又會扯出一個問題——創(chuàng)業(yè)者一開始就能知道自己的企業(yè)未來是什么樣子嗎?我認(rèn)為可以的,也必須要,這個扯的遠了,就不展開了。不過本系列文章的下篇有業(yè)務(wù)拓展的規(guī)則介紹,理論上在初創(chuàng)階段進行業(yè)務(wù)規(guī)劃的時候就可以通過相關(guān)規(guī)則進行藍圖規(guī)劃。
確實是如此,初創(chuàng)公司的發(fā)展其實是不確定的,誰能保證自己的拳頭產(chǎn)品走下去之后會不會拓寬出更多的業(yè)務(wù)線出來,多元化的業(yè)務(wù)就很容易造很多重復(fù)的輪子。但是創(chuàng)業(yè)公司一開始就搭建中臺的話,個人認(rèn)為會有幾點問題:首先是初創(chuàng)公司的未來業(yè)務(wù)是不明確的,中臺的搭建到底有沒有實際作用;其次,在公司的起步階段,大概率會以業(yè)務(wù)會核心發(fā)展自己的核心產(chǎn)品,對這方面的建設(shè)投入會相對較少,這樣會拉大開發(fā)周期不利于公司運轉(zhuǎn),但是投入較大資金人力的話,對起步階段的公司又會不太友好(非常有錢的除外)。
其實還是投入產(chǎn)出比的問題,初創(chuàng)型企業(yè)到底有沒有足夠的支持,成功地過渡到穩(wěn)定發(fā)展期。
針對您說明的情況,文中第二章1、2兩節(jié)是有明確的解決方案的——由云服務(wù)商為其提供saas化服務(wù)。這個成本可以做的很低很低。
另外,其實業(yè)務(wù)藍圖規(guī)劃并沒有想象中的復(fù)雜,相關(guān)方法下篇文章中會有描述,只不過國內(nèi)無論是大中小型企業(yè)的決策層都喜歡“腳踩西瓜皮,滑到哪里算哪里”,美其名曰隨機應(yīng)變,殊不知正是因為其沒有很好的洞見風(fēng)險才導(dǎo)致項目失敗,各大內(nèi)容平臺中,吐槽類似問題的文章也挺多的。歡迎持續(xù)關(guān)注本專欄哦。