對小產(chǎn)品來說，中臺思維同樣可以為產(chǎn)品與業(yè)務(wù)的發(fā)展起到幫助與推動作用，那么小產(chǎn)品的中臺解決方案一般要注意些什么呢？

前端時間，小汪報名了一個中臺建設(shè)的課程，覺得很是受益，于是回來就跟舍友來福嘚瑟，鼓吹中臺好啊，中臺化發(fā)展大勢所趨啊。同為產(chǎn)品經(jīng)理的來福深思了一會兒，說到：“可是我們公司就只有一款產(chǎn)品啊……那要中臺來能有什么用呢？”

小汪深思了一會兒，對來福說，讓我們先看看中臺是什么吧，梳理一下些許會有什么啟發(fā)？

01 什么是中臺

相信在看本文的產(chǎn)品經(jīng)理已經(jīng)看了不知道多少遍各種中臺的來源、中臺的定義了，這里就簡述一下。

1. 基本特征

中臺提煉并沉淀了各個業(yè)務(wù)線的共性需求。

2. 中臺目的

將共性需求轉(zhuǎn)化成平臺化、標準化、模塊化的功能，以接口或服務(wù)的形式再提供給前臺各業(yè)務(wù)使用。

3. 中臺價值

對于整個公司而言，極大的減少了“重復(fù)造輪子”，同一個問題不需要每個業(yè)務(wù)線都想辦法自己解決一次。讓各業(yè)務(wù)線更關(guān)注于業(yè)務(wù)拓展與創(chuàng)新，研發(fā)更敏捷。

02 小產(chǎn)品的繁瑣問題

小汪說，中臺的目的就是為了解決那些日益增加的重復(fù)工作，你們雖然只有一款產(chǎn)品，但是有沒有遇到什么經(jīng)常要重復(fù)的工作？

來福思考了一下，說到，我們雖然只有一款產(chǎn)品，核心場景明確，但是我們經(jīng)常會圍繞這個場景進行拓展，搞很多形式的活動進行拉新、促活、促進用戶消費等，如果說什么事情總是要重復(fù)做，那還是有一些的：

• 活動：因為我們的活動很多，而且每個活動形式差別比較大，盡量避免用戶對相同的形式的活動感到疲乏、讓用戶每次看到都能“眼前一亮”。所以我們的活動每個都是定制開發(fā)的，研發(fā)花了大量事情在做活動上。
• 對接：為了推廣我們公司的產(chǎn)品，我們開始嘗試跟多個APP合作，把我們產(chǎn)品的功能內(nèi)嵌到他們的APP中，每次對接對方都會提各種要求，如UI、用戶體系、支付訂單同步等，我們就跟要重做一套那么麻煩。
• 數(shù)據(jù)：我們的數(shù)據(jù)是用第三方公司提供的現(xiàn)成的數(shù)據(jù)平臺，每次加功能就做對應(yīng)的埋點，但是數(shù)據(jù)平臺的功能非常有限，有些訂單數(shù)據(jù)我們又不愿意讓對方采集，所以就每個月運營定時從后臺導出訂單制作報表。
• 其他：雖然我們只有一款產(chǎn)品，但是我們有APP、微信H5、微信小程序三個端，里面的注冊登錄、支付、分享邏輯都是互相獨立的，但是絕大部分前端新場景，都繞不過要用到注冊登錄、支付、分享的。

來福繼續(xù)說：因為我們重運營，如果非得發(fā)展中臺，那么搭建一個活動中心出來肯定是首要任務(wù)，但是我們的技術(shù)也評估過，要做一個那種一拖活動就出來的平臺，十分復(fù)雜耗時。其次選擇應(yīng)該是搭建自己的數(shù)據(jù)平臺。

03 中臺思維

盡管網(wǎng)絡(luò)上各種中臺知識鋪天蓋地，現(xiàn)實中絕大部分公司可能還處于發(fā)展期，手頭也就一款產(chǎn)品，對他們來說并沒有搭建中臺的必要。

對于發(fā)展期的公司而言，如何快速的解決眼前的問題經(jīng)常會變得“特別重要”。俗話說，頭痛醫(yī)頭腳痛醫(yī)腳。這就會導致一個問題，等公司業(yè)務(wù)量開始爆發(fā)后，發(fā)現(xiàn)過往埋下了很多的“坑”，想拓展新的業(yè)務(wù)時，發(fā)現(xiàn)舉步維艱。

領(lǐng)導認為，不就是復(fù)制一個功能改改就行了嘛，技術(shù)卻發(fā)現(xiàn)，前人留下的代碼、功能絲毫不具可復(fù)用性，什么需求都要重新做。于是搭建中臺就在這時候順理成章的登上了舞臺。

如何避免未來少走彎路，不要等到搭建中臺的時候才后悔莫及當初為何沒規(guī)劃好，這就需要“中臺思維”。

中臺思維就是把中臺建設(shè)中的“提取共性需求”、“標準化、模塊化”、“讓業(yè)務(wù)更靈活”用于指導日常的產(chǎn)品設(shè)計工作。

1. 提取共性需求

就像來福描述的他們公司的產(chǎn)品，我們已知注冊登錄（用戶）、支付、分享這三個功能是會被一直用、重復(fù)用的，還有數(shù)據(jù)統(tǒng)計，未來形成規(guī)模后一定會獨立出來的。

對于活動而言，可能每個活動的表現(xiàn)形式都不一樣，可能有抽獎的、互動游戲的，還有豐富的邏輯規(guī)則穿插其中，想要運營在界面上一拖拉，一個活動就建好了，這是很不現(xiàn)實的。但是有兩點可以抽象出來的：

• 活動所需的獲取商品、訂單、用戶信息，甚至分享、支付、優(yōu)惠券等功能，大部分活動都會用到，并且最終目的也就是促活或者促進用戶下單。
• 活動的“形式框架”，第一種框架是活動的形式固定下來了，每次就換個皮膚；第二種框架是將抽獎、用戶助力、集卡這種功能獨立出來，加上不同的規(guī)格，再換上不同的皮膚，然后就形成性的功能。

雖然只有一款產(chǎn)品，但是很多業(yè)務(wù)場景是會重復(fù)用到一些表層或者底層功能的，辨別并抽取出這些功能來，這是中臺思維的第一步。

2. 標準化、模塊化

形式標準化：

例如一個系統(tǒng)中存在好幾種形式的訂單，是否能進行歸類、合并，而不是多一個業(yè)務(wù)就再搞多一套訂單出來。不同的業(yè)務(wù)場景、功能下，都可能用到分享，分享后的樣式、接下來的流程可能各不相同，但不妨礙將分享樣式、分享后的行為進行歸類整理，避免又來一個新場景后又重新接一套分享，不便于樣式統(tǒng)一、分享行為統(tǒng)計，增加開發(fā)周期。

功能模塊化：

例如用戶注冊登錄，定義好用戶信息的字段、通用登錄頁面樣式后，形成用戶注冊登錄模塊，對于前端而言就是形成一個統(tǒng)一的登錄頁面或登錄框。任何業(yè)務(wù)場景需要用戶信息時，如果發(fā)現(xiàn)沒有用戶信息則引導用戶到注冊登錄界面，然后用戶注冊登錄完就返回對應(yīng)的業(yè)務(wù)場景；如果業(yè)務(wù)對登錄有特殊的需要，只需要喚起注冊登錄頁時，按照標準提供所需字段、頁面配圖，注冊登錄頁就可以按業(yè)務(wù)所需呈現(xiàn)。

標準化和模塊化相輔相成，標準化是為了方便模塊化，而模塊化的目的就是支持標準化調(diào)用。

3. 讓業(yè)務(wù)更靈活

讓業(yè)務(wù)更靈活，不僅是個目標，更是一種思想，在產(chǎn)品設(shè)計的時候，就應(yīng)該思考：

1. 這個功能未來會不會再用得上？
2. 萬一未來用戶很喜歡這個功能，功能本身具有多少發(fā)展的空間？
3. 未來會不會有別的或類似需求，可以使用這個功能改改就能對付？
4. 這個功能未來可不可能跟別的功能整合？

只有思考了這些，才能避免做出來的功能是“一次性的”，就為了解決某個很確切的事情“定制的”的。

04 小產(chǎn)品的“中臺思維”解決方案

盡管你的公司只有一款產(chǎn)品，業(yè)務(wù)場景也不算豐富，我們可以用如下的辦法，尋找可以優(yōu)化的切入點。

1. 發(fā)掘共性需求

找到不同業(yè)務(wù)場景都會用到的功能，有些業(yè)務(wù)場景表象各不相同，需要抽絲剝繭才能發(fā)現(xiàn)底層相似的內(nèi)核。對于小產(chǎn)品而言，有時候產(chǎn)品上功能本來就沒幾個，這就需要有前瞻性，結(jié)合業(yè)務(wù)發(fā)展方向，探尋更可能被復(fù)用的功能。

2. 評估需求痛點

研究所有可能復(fù)用的功能，與技術(shù)溝通模塊化的成本、復(fù)用模塊和每次重做一套的成本差別，與運營溝通這些功能打通對于未來業(yè)務(wù)場景、數(shù)據(jù)統(tǒng)計是否有利。最終根據(jù)需求本身的價值、研發(fā)成本、實現(xiàn)統(tǒng)一的可行性，確認優(yōu)先級。

3. 制定標準、設(shè)計模塊

由產(chǎn)品牽頭，對需求程度高的功能，標準化調(diào)用的字段、前置條件、后續(xù)流程，由技術(shù)確認著手點，是在下個版本中做一個新模塊出來，又或者對已有某個流程節(jié)點的該功能進行改造，以后有用到這個功能的都調(diào)用這個模塊。

4. 持續(xù)推廣、價值復(fù)盤

在后續(xù)每個版本中，用到同樣或者類似的功能時，就調(diào)用已有的模塊并且對該模塊進行不斷的升級優(yōu)化。同時與技術(shù)、運營復(fù)盤，確認該模塊對新業(yè)務(wù)、新活動的上線解決了多少時間、人力成本，進一步為運營帶來了多少價值。以作為未來持續(xù)推薦“中臺思想”的著實依據(jù)。

總結(jié)

中臺是一個實實在在的系統(tǒng)，而“中臺思維”就是把未來要做的事情，先在現(xiàn)階段打好基礎(chǔ)，不要等到業(yè)務(wù)或者產(chǎn)品技術(shù)排期遇到瓶頸時，再來想辦法解決問題。

本文由 @iCheer 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議