起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識小產品的“中臺思維”解決方案
對小產品來說，中臺思維同樣可以為產品與業務的發展起到幫助與推動作用，那么小產品的中臺解決方案一般要注意些什么呢？
前端時間，小汪報名了一個中臺建設的課程，覺得很是受益，于是回來就跟舍友來福嘚瑟，鼓吹中臺好啊，中臺化發展大勢所趨啊。同為產品經理的來福深思了一會兒，說到：“可是我們公司就只有一款產品啊……那要中臺來能有什么用呢？”
小汪深思了一會兒，對來福說，讓我們先看看中臺是什么吧，梳理一下些許會有什么啟發？
01 什么是中臺
相信在看本文的產品經理已經看了不知道多少遍各種中臺的來源、中臺的定義了，這里就簡述一下。
1. 基本特征
中臺提煉并沉淀了各個業務線的共性需求。
2. 中臺目的
將共性需求轉化成平臺化、標準化、模塊化的功能，以接口或服務的形式再提供給前臺各業務使用。
3. 中臺價值
對于整個公司而言，極大的減少了“重復造輪子”，同一個問題不需要每個業務線都想辦法自己解決一次。讓各業務線更關注于業務拓展與創新，研發更敏捷。
02 小產品的繁瑣問題
小汪說，中臺的目的就是為了解決那些日益增加的重復工作，你們雖然只有一款產品，但是有沒有遇到什么經常要重復的工作？
來福思考了一下，說到，我們雖然只有一款產品，核心場景明確，但是我們經常會圍繞這個場景進行拓展，搞很多形式的活動進行拉新、促活、促進用戶消費等，如果說什么事情總是要重復做，那還是有一些的：
- 活動：因為我們的活動很多，而且每個活動形式差別比較大，盡量避免用戶對相同的形式的活動感到疲乏、讓用戶每次看到都能“眼前一亮”。所以我們的活動每個都是定制開發的，研發花了大量事情在做活動上。
- 對接：為了推廣我們公司的產品，我們開始嘗試跟多個APP合作，把我們產品的功能內嵌到他們的APP中，每次對接對方都會提各種要求，如UI、用戶體系、支付訂單同步等，我們就跟要重做一套那么麻煩。
- 數據：我們的數據是用第三方公司提供的現成的數據平臺，每次加功能就做對應的埋點，但是數據平臺的功能非常有限，有些訂單數據我們又不愿意讓對方采集，所以就每個月運營定時從后臺導出訂單制作報表。
- 其他：雖然我們只有一款產品，但是我們有APP、微信H5、微信小程序三個端，里面的注冊登錄、支付、分享邏輯都是互相獨立的，但是絕大部分前端新場景，都繞不過要用到注冊登錄、支付、分享的。
來福繼續說：因為我們重運營，如果非得發展中臺，那么搭建一個活動中心出來肯定是首要任務，但是我們的技術也評估過，要做一個那種一拖活動就出來的平臺，十分復雜耗時。其次選擇應該是搭建自己的數據平臺。
03 中臺思維
盡管網絡上各種中臺知識鋪天蓋地，現實中絕大部分公司可能還處于發展期，手頭也就一款產品，對他們來說并沒有搭建中臺的必要。
對于發展期的公司而言，如何快速的解決眼前的問題經常會變得“特別重要”。俗話說，頭痛醫頭腳痛醫腳。這就會導致一個問題，等公司業務量開始爆發后，發現過往埋下了很多的“坑”，想拓展新的業務時，發現舉步維艱。
領導認為，不就是復制一個功能改改就行了嘛，技術卻發現，前人留下的代碼、功能絲毫不具可復用性，什么需求都要重新做。于是搭建中臺就在這時候順理成章的登上了舞臺。
如何避免未來少走彎路，不要等到搭建中臺的時候才后悔莫及當初為何沒規劃好，這就需要“中臺思維”。
中臺思維就是把中臺建設中的“提取共性需求”、“標準化、模塊化”、“讓業務更靈活”用于指導日常的產品設計工作。
1. 提取共性需求
就像來福描述的他們公司的產品，我們已知注冊登錄（用戶）、支付、分享這三個功能是會被一直用、重復用的，還有數據統計，未來形成規模后一定會獨立出來的。
對于活動而言，可能每個活動的表現形式都不一樣，可能有抽獎的、互動游戲的，還有豐富的邏輯規則穿插其中，想要運營在界面上一拖拉，一個活動就建好了，這是很不現實的。但是有兩點可以抽象出來的：
- 活動所需的獲取商品、訂單、用戶信息，甚至分享、支付、優惠券等功能，大部分活動都會用到，并且最終目的也就是促活或者促進用戶下單。
- 活動的“形式框架”，第一種框架是活動的形式固定下來了，每次就換個皮膚；第二種框架是將抽獎、用戶助力、集卡這種功能獨立出來，加上不同的規格，再換上不同的皮膚，然后就形成性的功能。
雖然只有一款產品，但是很多業務場景是會重復用到一些表層或者底層功能的，辨別并抽取出這些功能來，這是中臺思維的第一步。
2. 標準化、模塊化
形式標準化：
例如一個系統中存在好幾種形式的訂單，是否能進行歸類、合并，而不是多一個業務就再搞多一套訂單出來。不同的業務場景、功能下，都可能用到分享，分享后的樣式、接下來的流程可能各不相同，但不妨礙將分享樣式、分享后的行為進行歸類整理，避免又來一個新場景后又重新接一套分享，不便于樣式統一、分享行為統計，增加開發周期。
功能模塊化：
例如用戶注冊登錄，定義好用戶信息的字段、通用登錄頁面樣式后，形成用戶注冊登錄模塊，對于前端而言就是形成一個統一的登錄頁面或登錄框。任何業務場景需要用戶信息時，如果發現沒有用戶信息則引導用戶到注冊登錄界面，然后用戶注冊登錄完就返回對應的業務場景；如果業務對登錄有特殊的需要，只需要喚起注冊登錄頁時，按照標準提供所需字段、頁面配圖，注冊登錄頁就可以按業務所需呈現。
標準化和模塊化相輔相成，標準化是為了方便模塊化，而模塊化的目的就是支持標準化調用。
3. 讓業務更靈活
讓業務更靈活，不僅是個目標，更是一種思想，在產品設計的時候，就應該思考：
- 這個功能未來會不會再用得上？
- 萬一未來用戶很喜歡這個功能，功能本身具有多少發展的空間？
- 未來會不會有別的或類似需求，可以使用這個功能改改就能對付？
- 這個功能未來可不可能跟別的功能整合？
只有思考了這些，才能避免做出來的功能是“一次性的”，就為了解決某個很確切的事情“定制的”的。
04 小產品的“中臺思維”解決方案
盡管你的公司只有一款產品，業務場景也不算豐富，我們可以用如下的辦法，尋找可以優化的切入點。
1. 發掘共性需求
找到不同業務場景都會用到的功能，有些業務場景表象各不相同，需要抽絲剝繭才能發現底層相似的內核。對于小產品而言，有時候產品上功能本來就沒幾個，這就需要有前瞻性，結合業務發展方向，探尋更可能被復用的功能。
2. 評估需求痛點
研究所有可能復用的功能，與技術溝通模塊化的成本、復用模塊和每次重做一套的成本差別，與運營溝通這些功能打通對于未來業務場景、數據統計是否有利。最終根據需求本身的價值、研發成本、實現統一的可行性，確認優先級。
3. 制定標準、設計模塊
由產品牽頭，對需求程度高的功能，標準化調用的字段、前置條件、后續流程，由技術確認著手點，是在下個版本中做一個新模塊出來，又或者對已有某個流程節點的該功能進行改造，以后有用到這個功能的都調用這個模塊。
4. 持續推廣、價值復盤
在后續每個版本中，用到同樣或者類似的功能時，就調用已有的模塊并且對該模塊進行不斷的升級優化。同時與技術、運營復盤，確認該模塊對新業務、新活動的上線解決了多少時間、人力成本，進一步為運營帶來了多少價值。以作為未來持續推薦“中臺思想”的著實依據。
總結
中臺是一個實實在在的系統，而“中臺思維”就是把未來要做的事情，先在現階段打好基礎，不要等到業務或者產品技術排期遇到瓶頸時，再來想辦法解決問題。
本文由 @iCheer 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
廢物，垃圾，吃軟飯，愛吹牛