中臺的概念到處都是，筆者所在的公司玩出了一個“偽中臺”，針對這個偽中臺，筆者該如何進行產品設計呢？

愿景： 在筆者的產品工作中經理的一些比較有意思的坑，分享出來，可以給大家一點思考，一點啟發(fā)。

目標人群：產品人&年齡<2歲

idea：分享一些實際的產品設計案例

競爭對手：個人興趣、時間、惰性

預計耗時：閱讀本文預計耗時7分鐘

寫在前面的話：

其實隨著做產品的不斷深入，我們都會遇到各種各樣的坑。比如同事的不靠譜、領導的錯誤抉擇又或者是雞肋的產品架構或者不清晰的產品定位，這些都可能會導致我們在進行產品設計的時候感到無奈和超級想吐槽。

但是吐槽完了之后，還是得按照客觀條件進行設計產品，不然，你的產品方案可能就無法落地。

所以，筆者認為，我們的產品工作，其實限制蠻大的，也需要在這樣的限制下，去做好一些微創(chuàng)新，通過一些微創(chuàng)新的方式來平衡我們的產品認知和現實客觀條件的矛盾。

好了，接下來我們開始進入正題，如何基于偽中臺做好產品設計。在這里，筆者將會結合自己的實際案例，給大家進行解剖。

一、中臺概述

1.?中臺是什么

這里，筆者首先為大家列舉幾個常見的中臺名稱：微服務開發(fā)框架、容器云、Paas平臺、用戶中心、訂單中心等。

是否覺得這幾個名稱很熟悉？

其實如果名稱再包裝一下，就是我們所熟悉的技術中臺又或者是業(yè)務中臺，所以中臺并不是什么很稀奇的概念。

但業(yè)內其實并沒有一個對中臺的準確定義，所以筆者選取其中一個比較靠譜的定義供讀者們認知“中臺是真正為前臺而生的平臺（可以是技術平臺，業(yè)務能力甚至是組織機構）。

它存在的唯一目的，就是更好的服務前臺規(guī)模化創(chuàng)新，進而更好的響應服務引領用戶，使企業(yè)真正做到自身能力與用戶需求的持續(xù)對接”。

2. 中臺的價值是什么

從定義中，我們就能知道，中臺的價值就是進一步提高服務用戶的效率和質量。

但為什么這么說呢？

這是由于在傳統的架構中，我們只是將產品分為前臺和后臺。前臺就是和用戶的觸電，類似于網頁、APP、小程序、公眾號等，而后臺就是對企業(yè)資源的管理，類似與CRM系統、ERP系統等等。

其實在這里我們可以了解到，前臺和后臺并非一一對應，前臺主要是服務于用戶；而后臺更多的是服務于企業(yè)的管理，提高企業(yè)管理效率和降低成本。

因此，會出現一個現象，前臺變化快而后臺變化慢且穩(wěn)定。所以這個時候，很多為了服務于用戶的需求，都堆積在前臺，使得前臺越來越臃腫，而換一個行業(yè)的用戶，又需要重新起一個前臺，重復工作量大。

所以，中臺的出現，實際上就可以將臃腫的前臺系統中的穩(wěn)定通用業(yè)務能力“沉降”到中臺層，恢復前臺的響應?；又可以將后臺系統中需要頻繁變化或是需要被前臺直接使用的業(yè)務能力“提取”到中臺層，賦予這些業(yè)務能力更強的靈活度和更低的變更成本，從而為前臺提供更強大的支撐能力。

所以，企業(yè)在平臺化的過程中，需要建設自己的中臺層，這里強調一下，是平臺化的過程中，而非一定要建設中臺。

二、筆者接觸的偽中臺

筆者所在公司，今年提出了中臺戰(zhàn)略，但是筆者很不能理解為什么要做中臺。筆者的理由如下：

• 公司的業(yè)務都還沒有做透，就急于做中臺，包裝公司的產品；
• 公司業(yè)務目前還很簡單，技術團隊規(guī)模并不大，服務需求的響應效率也非常及時，完全沒必要建設中臺；
• 公司當前的技術團隊的技術沉淀不足，無人進行技術架構，進行中臺建設。

但是，我們產品經理，在無法說服金主爸爸的時候，也不得不按照金主爸爸的要求進行產品設計。

在公司內部，直接拉了一個團隊過來，建設公司的用戶中臺、資源中臺。

雖然筆者沒有直接參與中臺建設，但是筆者所建設的產品是要直接于中臺進行對接的。筆者了解到，建設出來的中臺是這樣的。

1.?用戶中臺

首先，筆者的產品需要進行用戶注冊，根據用戶屬性不同，注冊方式不同，達到的效果也不一樣。

如果是A類用戶，該用戶如果需要同時使用2個產品，那么首先要在用戶中臺進行用戶信息注冊，然后再到筆者的產品這邊，再次錄入用戶信息。兩個產品都需要是手工錄入，無法進行同步，而且錄入的信息不一致，也會有沖突。

如果是B類用戶，該用戶僅需要使用筆者的產品，那么就可以直接在筆者的產品里面錄入用戶信息，這里錄入之后就會直接同步到用戶中臺進行用戶信息保存。

但是如果想要再申請使用其他產品，這里無法在筆者的產品進行權限更改，也無法在用戶中臺進行權限更改。

因為用戶中臺認為筆者產品同步過來的信息字段不足，需要特殊處理，不允許進行用戶權限更改。

其次，筆者的產品需要進行登陸，但是登陸的流程需要經歷2個關卡。通過筆者的產品登陸入口，是直接進入到用戶中心的用戶登陸頁面。

在該頁面進行用戶登陸，登陸成功之后，由用戶中心通知筆者的產品，用戶登陸成功，而筆者的產品還需要進行一次登陸驗證。因為有可能這個用戶是其他產品的用戶，但不是筆者產品的用戶（所以，這里讀者可以考慮下如何建設好用戶中臺）。

最后，筆者的產品如果需要更改用戶的賬戶信息，比如進行手機號變更、微信綁定等，都需要拉著所有使用用戶中臺的產品進行一起討論，這樣的改動會不會影響到其他產品。

筆者認為，中臺是服務于產品業(yè)務的，既然都建設成了中臺，那么就應該屏蔽筆者的產品與其他的產品關聯，筆者只是需要使用中臺的某些業(yè)務服務，而不需要關心和其他產品的關系。

2.?資源中臺

資源中臺，是負責管理公司所產生的所有供業(yè)務使用的資源，包括視頻、文檔、PPT、Excel，文件包等等。但是這一類的資源，資源中臺又要求筆者的產品按照他們的規(guī)則進行資源設計。

但是，這樣的規(guī)則又不符合筆者的業(yè)務要求。

如果，強行按照資源中臺的規(guī)則去設計的話，實際上，在筆者的產品運行使用過程中，用戶反饋是非常糟糕的體驗，要求更改資源的設計規(guī)則。

所以，如果是一個建設失敗的偽中臺，實際上并不能達到快速響應用戶需求的效果，反而會大大降低服務效率，增加產品設計、開發(fā)的工作量、增加公司的成本，得不償失。

三、如何適配偽中臺做好產品設計

筆者還是得適配公司的偽中臺進行產品設計，不然產品方案就無法落地，也沒有按照公司的大方向走，恐怕產品經理的日子也會很快到頭（開個玩笑）。

這里筆者就以設計的微信解綁為案例，進行講解，如何根據偽中臺做好產品設計，以及如何把控產品需求。

微信解綁原始需求:

• 微信解綁，只能由公司運營在后臺進行解綁，禁止B端用戶自行進行解綁（為了防止賬號公用）；
• 用戶更換了手機號，需要重新設置賬號內容，進行微信重新綁定，就需要對該用戶進行解綁；
• 用戶可能綁定的是組織或者部門提供的分配賬號，但是需要更換賬號綁定，就需要進行微信解綁，但是用戶不知道自己綁定的賬號是什么；
• 如果運營在筆者產品這邊把用戶刪除了（是允許未解綁進行刪除的，但綁定關系還在），用戶要求進行微信解綁，無法進行解綁，只能通過刷數據庫的方式。

這里，就需要結合筆者上訴所說的偽中臺的現狀，進行設計，畢竟用戶的微信賬號綁定關系，也是存放在用戶中臺的。

所以，筆者設計的思路就是，盡可能減少和中臺的交互！

1. 用戶中臺僅需要提供針對單個或者多個userid進行解綁的接口接口，只需要給筆者的產品返回解綁成功的code碼即可。
2. 解綁的用戶，全部從筆者的產品這邊查詢出來，不依賴用戶中臺，在筆者產品中的成員管理列表，增加要給操作“解綁”和“批量解綁”。
3. 不設計用戶的微信綁定狀態(tài)，原因是用戶中臺的微信綁定關系不會通知到筆者的產品端，在筆者產品端進行微信解綁的操作可以感知到微信綁定狀態(tài)。但是，如果微信綁定操作是從其他產品入口進行操作，筆者的產品端是無法及時感知到的，會誤導使用者（也就是，筆者也放棄了從用戶中臺查詢用戶綁定關系的功能）。
4. 產品設計的一點原則是，每一個操作都有響應。因此，筆者設計了一個微信解綁記錄給使用者，凡是解綁成功的賬戶信息都會記錄到這個微信解綁記錄中。使用者進行解綁操作之后，就能知道哪些賬號是解綁成功的，哪些失敗了，系統也會有微信解綁操作響應。
5. 由于微信的安全性，不會將用戶的微信賬號信息返回給第三方，所以筆者的產品是無法拿到用戶的微信信息的，因此也就無法根據微信賬號進行解綁，只能根據綁定的賬號信息進行解綁。
6. 針對用戶不知道自己綁定的賬號是什么，所以在用戶的賬戶信息中，增加綁定賬號信息內容，提供給用戶；用戶需要進行解綁，首先登陸查詢到綁定的賬號信息，然后再將該賬號信息告知到公司運營進行解綁。
7. 針對刪除的用戶，筆者無法設計，刪除即解除綁定關系的功能在產品里面。因為，有可能該用戶使用多個公司產品，TA只是不使用筆者的產品，但依然使用其他產品，那么就會影響用戶使用。
8. 針對刪除用戶，為了滿足運營，筆者設計了刪除記錄，可以通過查詢賬戶信息的內容，查詢到刪除的用戶信息；通過重新添加到筆者產品中，進行微信解綁，然后再次刪除即可。

綜上，筆者就根據微信解綁的使用場景，設計了這8條原則，從而滿足微信解綁的需要。

四、總結

筆者實際上是依據問題拆分的方法，將微信解綁的一個大的問題拆解，拆分成多個小場景，并根據每個小場景，設計解決方案，從而解決這個大問題。

另外，通過減少和中臺的交互，舍棄一些不是必要的需要，從而能夠快速的進行版本迭代，響應用戶的需求。

所以，我們所能做的，就是在大原則下，不斷包裝自己，進行微創(chuàng)新，提高自己的效率。

本文由 @蕭羽 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議