中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)語：中臺(tái)到底是什么？要怎么做呢？本篇作者以真實(shí)的案例和個(gè)人經(jīng)歷的方式跟我們分享了作者自己對(duì)中臺(tái)的理解，講講中臺(tái)是怎么落地實(shí)施的，怎么將一個(gè)業(yè)務(wù)需求轉(zhuǎn)化成中臺(tái)需求的，好讓大家對(duì)中臺(tái)有個(gè)非常具象的認(rèn)知，一起來看一下。

中臺(tái)概念大家已經(jīng)很熟悉了，各種定義滿天飛，但是中臺(tái)到底是什么，怎么做，還是需要做了才知道。我現(xiàn)在以實(shí)實(shí)在在的案例讓大家明白中臺(tái)。當(dāng)然了，畢竟接觸中臺(tái)時(shí)間還是不夠長，免不了出現(xiàn)一些有偏差的觀點(diǎn)，有看到的中臺(tái)大佬可以指出。

一、中臺(tái)的定義和角色

中臺(tái)的定義可以從很多公開資料找到，我這里不再做贅述和解釋。我在這里期望以更白話、真實(shí)的案例和個(gè)人經(jīng)歷的方式講講對(duì)中臺(tái)的理解，講講中臺(tái)是怎么落地實(shí)施的，怎么將一個(gè)業(yè)務(wù)需求轉(zhuǎn)化成中臺(tái)需求的，好讓大家對(duì)中臺(tái)有個(gè)非常具象的認(rèn)知。

談起角色就要有對(duì)象，中臺(tái)對(duì)于前端業(yè)務(wù)來說，是業(yè)務(wù)后端。前臺(tái)業(yè)務(wù)不是很關(guān)心你怎么實(shí)現(xiàn)，也不關(guān)心是中臺(tái)實(shí)現(xiàn)還是業(yè)務(wù)系統(tǒng)自己實(shí)現(xiàn)，只關(guān)心你能否實(shí)現(xiàn)我想要的前端展示、交互、邏輯等等。

中臺(tái)對(duì)于前端業(yè)務(wù)的后端系統(tǒng)來說，類似一個(gè)有強(qiáng)大能力的第三方服務(wù)商，這個(gè)第三方服務(wù)商有某個(gè)模塊的各種接口和能力，我按照這個(gè)第三方規(guī)范的接口文檔給信息，對(duì)方就能夠?qū)崿F(xiàn)我這邊業(yè)務(wù)的這個(gè)模塊想要的底層結(jié)果，不需要我針對(duì)這個(gè)模塊再做一次開發(fā)。

所以，如果從業(yè)務(wù)角度看中臺(tái)，他承擔(dān)了一部分業(yè)務(wù)后端系統(tǒng)的角色，也承擔(dān)了一個(gè)第三方服務(wù)商的角色。

二、什么樣的人適合做中臺(tái)

我們都知道，業(yè)務(wù)系統(tǒng)如果做的不合理可以等以后重構(gòu)，也可以為了應(yīng)付緊急需求而做很多閹割版功能，甚至可以讓產(chǎn)品新人和技術(shù)新人操刀，只要實(shí)現(xiàn)業(yè)務(wù)需求就可以。

而對(duì)于中臺(tái)來說，不管多小的中臺(tái)，都需要有非常清晰的產(chǎn)品規(guī)劃，產(chǎn)品要知道業(yè)務(wù)以后可能做什么，會(huì)怎么玩，落地下來就是業(yè)務(wù)某個(gè)功能點(diǎn)以后可能怎么做，我中臺(tái)底層模型如何搭建，才能讓中臺(tái)的擴(kuò)展性很強(qiáng)很靈活很好支持多變的業(yè)務(wù)。

中臺(tái)的重構(gòu)成本相比于業(yè)務(wù)側(cè)，是翻倍的，越靈活重構(gòu)成本越高，對(duì)接的業(yè)務(wù)側(cè)越多，重構(gòu)成本也越高。

那么問題來了，你如果不懂業(yè)務(wù)，能做中臺(tái)的產(chǎn)品嗎？

答案肯定是否定的。

所以做中臺(tái)的人一定是對(duì)業(yè)務(wù)很了解的人，無論是產(chǎn)品還是研發(fā)，請(qǐng)記住懂業(yè)務(wù)是前提條件，不僅僅懂自己的業(yè)務(wù)，還要懂與自己相關(guān)的上下游業(yè)務(wù)。

由于中臺(tái)的搭建往往是圍繞一個(gè)需求考慮具體的產(chǎn)品實(shí)現(xiàn)方案和技術(shù)實(shí)現(xiàn)方案，所以中臺(tái)產(chǎn)品最好還要對(duì)技術(shù)有一定的了解，了解越多越容易切入角色，越容易產(chǎn)出更符合中臺(tái)定位的產(chǎn)品方案。

另外，搭建中臺(tái)大部分是從零到一，搭建好基礎(chǔ)后期比較好維護(hù)，而且是多個(gè)團(tuán)隊(duì)協(xié)作，涉及到模塊拆分和能力域邊界的劃分，所以最好要有經(jīng)歷過從零到一的項(xiàng)目的經(jīng)驗(yàn)，能夠知道如何跨團(tuán)隊(duì)協(xié)作。

如果產(chǎn)品或者研發(fā)只懂業(yè)務(wù)，沒做過中臺(tái)，能做中臺(tái)嗎？

也不是不能，要組一個(gè)低成本的高潛力團(tuán)隊(duì)。

如果產(chǎn)品沒有做過中臺(tái)，就要求產(chǎn)品具備較強(qiáng)的抽象能力，搭配做過中臺(tái)的研發(fā)。

如果研發(fā)沒有做過中臺(tái)，就要求研發(fā)有較強(qiáng)的抽象能力，搭配一個(gè)懂中臺(tái)的產(chǎn)品。

以上都是相對(duì)好且低成本的團(tuán)隊(duì)組合，在配合時(shí)保證大家能夠在預(yù)知未來業(yè)務(wù)走向的情況下，合理設(shè)計(jì)中臺(tái)的產(chǎn)品方案和技術(shù)實(shí)現(xiàn)方案。

前面說的是技能方面，那從個(gè)人追求上面，你適合做中臺(tái)嗎？

答案是看個(gè)人方向了。

有的小中臺(tái)配備的產(chǎn)研人員是既負(fù)責(zé)業(yè)務(wù)需求又負(fù)責(zé)中臺(tái)需求的，所以離業(yè)務(wù)可能比較近，對(duì)業(yè)務(wù)側(cè)產(chǎn)品實(shí)現(xiàn)方案是有一定決策性的。

但是相對(duì)純粹的中臺(tái)人員面向的需求方是業(yè)務(wù)側(cè)產(chǎn)研，會(huì)導(dǎo)致離業(yè)務(wù)較遠(yuǎn)，此時(shí)中臺(tái)往往無法決策業(yè)務(wù)該怎么做，只要業(yè)務(wù)有場景，有一定的合理性，中臺(tái)就應(yīng)該可以支持或提前支持，不能讓中臺(tái)成為業(yè)務(wù)的瓶頸。

在決策過程中最多也就是在討論或者接收需求的時(shí)候，質(zhì)疑一下業(yè)務(wù)對(duì)問題本質(zhì)的挖掘深度，質(zhì)疑問題的解決方案和優(yōu)先級(jí)，進(jìn)而提出更優(yōu)的解決方案和建議，但是最終的決策權(quán)并不在中臺(tái)。

或者說，因?yàn)橐粋€(gè)業(yè)務(wù)流程的完成可能被多個(gè)中臺(tái)配合或分割，如果你對(duì)業(yè)務(wù)有建議和想法，只能在和你中臺(tái)能力相關(guān)的問題上你有一定的影響力（因?yàn)槟憧梢圆煌七M(jìn)需求），而和你中臺(tái)不相關(guān)的內(nèi)容你是無法干預(yù)的。

所以中臺(tái)有時(shí)候會(huì)離實(shí)際業(yè)務(wù)比較遠(yuǎn)，決策性和影響力較小。

根據(jù)上面的情況，中臺(tái)適合非常熟悉業(yè)務(wù)，抽象能力很強(qiáng)，且在業(yè)務(wù)上面沒有過多奢求的人去做。如果你還想干預(yù)業(yè)務(wù)，還想讓業(yè)務(wù)按照你的想法落地和排期，那么你目前不適合做中臺(tái)產(chǎn)品，可以過幾年再試試。

但是貌似所有研發(fā)同學(xué)都對(duì)中臺(tái)非常感興趣，因?yàn)橹信_(tái)的實(shí)施無論是從性能還是從技術(shù)實(shí)現(xiàn)方案來說，對(duì)研發(fā)同學(xué)都是一次挑戰(zhàn)，是自己能力的體現(xiàn)。

三、中臺(tái)的劃分和交互框架

在日常業(yè)務(wù)系統(tǒng)規(guī)劃中，我們會(huì)將業(yè)務(wù)系統(tǒng)劃分為多個(gè)模塊，由不同的團(tuán)隊(duì)分工負(fù)責(zé)，模塊劃分的顆粒度取決于業(yè)務(wù)的發(fā)展程度，如果一個(gè)模塊要做重做細(xì)做好，這個(gè)模塊就會(huì)被劃分的很細(xì)，有專人負(fù)責(zé)做深做強(qiáng)。

日常業(yè)務(wù)可能會(huì)被劃分為：用戶會(huì)員模塊、商家模塊、商品模塊、營促銷模塊、交易訂單履約模塊、售后模塊、支付結(jié)算模塊等。

同理中臺(tái)也會(huì)像業(yè)務(wù)系統(tǒng)一樣，按照業(yè)務(wù)域被分割為多個(gè)中臺(tái)。按照上面的舉例，中臺(tái)會(huì)劃分成用戶會(huì)員中臺(tái)、商家中臺(tái)、商品中臺(tái)、營促銷中臺(tái)、交易中臺(tái)、訂單中臺(tái)、履約中臺(tái)、支付中臺(tái)等。

中臺(tái)的劃分在各個(gè)公司不是絕對(duì)相同的，除了按照業(yè)務(wù)域劃分之外，還有較大的公司特性和團(tuán)隊(duì)平衡問題，這里就不再深說。

中臺(tái)自身又會(huì)按照能力域被劃分為多個(gè)子域，每個(gè)子域都有不同的能力。

比如：

1. 用戶會(huì)員中臺(tái)會(huì)被劃分為：用戶域、會(huì)員域、卡券域等。
2. 商家中臺(tái)可能會(huì)被劃分為：商家域、組織架構(gòu)域、權(quán)限域等。
3. 商品中臺(tái)可能會(huì)被劃分為：商品域、價(jià)格域、庫存域等。

上面的中臺(tái)和能力域說完，大家可能也很清楚了，其實(shí)各個(gè)中臺(tái)組合起來就可以支撐一些基本的業(yè)務(wù)訴求了。

所以一個(gè)中臺(tái)存在，如果要發(fā)揮價(jià)值，他必須要和業(yè)務(wù)系統(tǒng)，和各個(gè)中臺(tái)之間共同協(xié)作，才能完成一個(gè)完整的業(yè)務(wù)流程。

和中臺(tái)交互的系統(tǒng)包括各個(gè)模塊的業(yè)務(wù)系統(tǒng)和各個(gè)中臺(tái)，由于公司和公司之間的技術(shù)約束不同、業(yè)務(wù)范疇不同，還會(huì)有些其他平臺(tái)用于支持中臺(tái)和業(yè)務(wù)系統(tǒng)間的交互，比如一個(gè)低代碼定義平臺(tái)等。這里我們不講交互細(xì)節(jié)，就從框架上講一下交互的規(guī)范類別。

從大類上來說有兩種：直接交互與通過公共平臺(tái)交互。

1. 直接交互會(huì)造成的問題是，一個(gè)業(yè)務(wù)系統(tǒng)要對(duì)接多個(gè)中臺(tái)時(shí)，需要做多次對(duì)接，成本較高。優(yōu)勢是對(duì)接自由，往往適合團(tuán)隊(duì)比較小，業(yè)務(wù)不是非常復(fù)雜的小型中臺(tái)，流程和約束不那么多。
2. 通過公共平臺(tái)交互的問題是，前期實(shí)施成本較高，實(shí)施前就要做好相應(yīng)的規(guī)劃，每個(gè)系統(tǒng)的定位要清晰，公共平臺(tái)不僅僅用于中臺(tái)和系統(tǒng)間的對(duì)接，還可能承擔(dān)低代碼產(chǎn)品融合的責(zé)任。每個(gè)業(yè)務(wù)中臺(tái)需要將自己的中臺(tái)能力和接口注冊到公共平臺(tái)上，業(yè)務(wù)系統(tǒng)按照統(tǒng)一規(guī)范進(jìn)行對(duì)接。優(yōu)勢就是即使一個(gè)系統(tǒng)要對(duì)接多個(gè)中臺(tái)，也可以在公共平臺(tái)上通過配置的方式完成，對(duì)接成本較低，而且容易塑造規(guī)范性和標(biāo)準(zhǔn)化。

1. 當(dāng)業(yè)務(wù)系統(tǒng)與中臺(tái)交互時(shí)

一種是業(yè)務(wù)系統(tǒng)直接與中臺(tái)交互，另一種是業(yè)務(wù)系統(tǒng)通過一個(gè)公共平臺(tái)與中臺(tái)交互。

2. 當(dāng)中臺(tái)與中臺(tái)之間交互時(shí)

一種是中臺(tái)之間可交互，另一種是中臺(tái)之間通過中臺(tái)對(duì)應(yīng)的業(yè)務(wù)系統(tǒng)與中臺(tái)交互。

如下圖2，中臺(tái) A 和中臺(tái) B 之間不可直接交互，如果業(yè)務(wù)系統(tǒng) A 或中臺(tái) A 有訴求，必須由業(yè)務(wù)系統(tǒng) A 發(fā)起請(qǐng)求，通過業(yè)務(wù)系統(tǒng) B 調(diào)業(yè)務(wù)中臺(tái) B 。

四、中臺(tái)產(chǎn)品架構(gòu)

當(dāng)我們在聊中臺(tái)的產(chǎn)品架構(gòu)的時(shí)候，我們其實(shí)是在聊中臺(tái)的產(chǎn)品規(guī)劃。

中臺(tái)的產(chǎn)品規(guī)劃是完全基于產(chǎn)品對(duì)業(yè)務(wù)的理解，對(duì)業(yè)務(wù)未來的發(fā)展方向的理解，進(jìn)而預(yù)測和抽象出中臺(tái)可能有哪些能力域，能力域里面包含哪些核心能力，最最重要的是我們要能夠提前規(guī)劃出核心能力域的數(shù)據(jù)流向，這樣研發(fā)人員才能夠打好底子做好模型。

前面我們講了，中臺(tái)也會(huì)像業(yè)務(wù)系統(tǒng)一樣，按照能力的業(yè)務(wù)屬性劃分內(nèi)部的能力域，除了能力域之外，中臺(tái)還會(huì)沉淀多個(gè)業(yè)務(wù)方的業(yè)務(wù)數(shù)據(jù)，還會(huì)有一些自己內(nèi)部通用的基礎(chǔ)支撐能力模塊，在做產(chǎn)品架構(gòu)規(guī)劃時(shí)，最好把這些都一并考慮進(jìn)去。

但是有一點(diǎn)要注意的是，研發(fā)在做中臺(tái)的技術(shù)規(guī)劃時(shí)，往往能夠看到比產(chǎn)品更多更廣的內(nèi)容，如果產(chǎn)品沒有做過中臺(tái)，能夠根據(jù)業(yè)務(wù)抽象出能力域、核心能力、核心數(shù)據(jù)、通用底層模塊就已經(jīng)很不錯(cuò)了，基本是很難想到還會(huì)有哪些技術(shù)相關(guān)的產(chǎn)品層和能力，所以如果產(chǎn)品經(jīng)理的中臺(tái)經(jīng)歷不多，呈現(xiàn)中臺(tái)產(chǎn)品架構(gòu)時(shí)要多和研發(fā)溝通。

這里就以銷售中臺(tái)為例，簡單展示一下中臺(tái)產(chǎn)品架構(gòu)。

五、中臺(tái)實(shí)踐舉例

可能前面無論怎么說，沒做過中臺(tái)的同學(xué)還是有些迷糊，不知道中臺(tái)到底怎么做的，這里我就以一些實(shí)際案例來講一下，怎么把一個(gè)業(yè)務(wù)需求轉(zhuǎn)化為中臺(tái)需求，可以讓大家更直觀的感受中臺(tái)是什么。

在說中臺(tái)案例前，我們先講一個(gè)定義，那就是“能力”。

用百科的解釋，能力的定義是：

完成一項(xiàng)目標(biāo)或者任務(wù)所體現(xiàn)出來的綜合素質(zhì)。

所以中臺(tái)的能力就是，為完成一項(xiàng)業(yè)務(wù)側(cè)期望的任務(wù)所具備的多種通用邏輯和流程的集合。

案例1

比如一個(gè)電商商城業(yè)務(wù)中有個(gè)流程是用戶提交訂單，提交訂單后業(yè)務(wù)系統(tǒng)經(jīng)過交易流程的多種校驗(yàn)后最終創(chuàng)建了一筆訂單，那么這個(gè)電商商城接入訂單中臺(tái)，用戶點(diǎn)擊提交訂單后，調(diào)用中臺(tái)的能力就叫做“創(chuàng)建訂單能力”。

創(chuàng)建訂單時(shí)需要根據(jù)不同的商品、用戶等等信息最終判斷是哪種訂單類型，不同訂單類型有不同的創(chuàng)建訂單的邏輯，而這些邏輯在不同業(yè)務(wù)系統(tǒng)中有很多通用的內(nèi)容，中臺(tái)就把這些通用的邏輯和流程沉淀下來，最終完成業(yè)務(wù)側(cè)期望的創(chuàng)建一筆訂單的任務(wù)，這就是【創(chuàng)建訂單能力】。

而一個(gè)業(yè)務(wù)系統(tǒng)的訂單模塊會(huì)有非常多的功能，他們就對(duì)應(yīng)了中臺(tái)的多個(gè)能力，比如取消訂單的功能對(duì)應(yīng)取消訂單的能力，在待支付狀態(tài)下商戶修改訂單對(duì)應(yīng)中臺(tái)修改訂單的能力等等。

案例2

以銷售中臺(tái)的某個(gè)需求為案例具體講解一下中臺(tái)能力的落地。

銷售中臺(tái)就是為那些圍繞銷售員的，通過銷售員進(jìn)行客戶管理、營銷觸達(dá)、客情維護(hù)的 CRM 的，銷售過程管理工具的中臺(tái)。

所以這個(gè)銷售過程管理工具需要?jiǎng)?chuàng)建銷售人員的賬號(hào)并對(duì)這個(gè)賬號(hào)進(jìn)行各種管理和維護(hù)。

這個(gè)管理和維護(hù)的過程就需要非常多的功能，比如創(chuàng)建銷售人員賬號(hào)，創(chuàng)建時(shí)提交各種資料，經(jīng)過層層審核后，最終完成銷售人員賬號(hào)的創(chuàng)建，在日常管理中還要對(duì)賬號(hào)進(jìn)行維護(hù)，比如休假了要暫時(shí)關(guān)閉賬號(hào)，犯錯(cuò)誤了要凍結(jié)賬號(hào)，離職了要?jiǎng)h除賬號(hào)等等。

那么這些功能哪些是中臺(tái)的能力呢，我們看下面的表格。

這個(gè)時(shí)候我們作為中臺(tái)，就要從以下幾個(gè)角度思考。

思考流程大概是這樣的：

解釋一下這個(gè)流程圖：

1. 哪些業(yè)務(wù)功能可以沉淀到中臺(tái)做成能力。
2. 做成能力后的系統(tǒng)交互是怎樣的，中臺(tái)的產(chǎn)品方案是什么。
3. 不沉淀到中臺(tái)的那些能力，業(yè)務(wù)側(cè)可以怎么落地，產(chǎn)品方案是什么。

所以作為一個(gè)中臺(tái)產(chǎn)品，你不僅僅要知道如何抽象成能力，還要知道和業(yè)務(wù)如何交互，才能滿足業(yè)務(wù)的訴求。

所以中臺(tái)的產(chǎn)品是所有產(chǎn)品經(jīng)理里，產(chǎn)品底層能力最強(qiáng)的。這里我們就簡單分析一下業(yè)務(wù)側(cè)的“銷售員管理”的需求和“停用刪除銷售員賬號(hào)”的兩個(gè)需求，看看如何沉淀為能力。當(dāng)我們處理一個(gè)具體需求的時(shí)候，主要從以下三個(gè)角度思考：

1. 功能和能力本身的邏輯是什么，功能邊界是什么，我的底層模型如何兼容。
2. 數(shù)據(jù)存儲(chǔ)的邊界是什么。
3. 非中臺(tái)能力的業(yè)務(wù)解決方案。

針對(duì)銷售員管理需求，我們能夠想到，業(yè)務(wù)側(cè)可能有個(gè)后臺(tái)菜單名字叫做銷售員管理，頁面是一個(gè)銷售員列表。

1. 列表內(nèi)的操作按鈕有：查看詳情、刪除銷售員、賬號(hào)禁用。
2. 列表上方按鈕分別是：添加銷售員、批量導(dǎo)入、導(dǎo)出銷售員、批量刪除的按鈕。

比如頁面可能長這個(gè)樣子：

按照業(yè)務(wù)流程，添加銷售人員賬號(hào)的界面可能如下圖：

1. 這時(shí)候我們要想到的問題是

1）功能本身的邏輯是什么

如何創(chuàng)建賬號(hào)，創(chuàng)建賬號(hào)有什么前置邏輯沒有，如果有的話，哪些邏輯可以沉淀到中臺(tái)，哪些邏輯由業(yè)務(wù)側(cè)自己完成后再調(diào)中臺(tái)創(chuàng)建賬號(hào)的接口，是如何交互的。

2）數(shù)據(jù)存儲(chǔ)的邊界是什么

創(chuàng)建賬號(hào)時(shí)有些銷售員的賬號(hào)相關(guān)的資料，這些資料在業(yè)務(wù)側(cè)都是獨(dú)立的字段，這些字段是否和我的能力域有密切的邏輯關(guān)系，如果沒有的話，銷售員的賬號(hào)數(shù)據(jù)存儲(chǔ)在中臺(tái)，那這些字段也無法存儲(chǔ)在業(yè)務(wù)側(cè)，不存在業(yè)務(wù)側(cè)的話存在哪兒，怎么存。

3）非中臺(tái)能力的業(yè)務(wù)解決方案

批量導(dǎo)入和導(dǎo)出分別是什么字段，這些字段是否都存在中臺(tái)了，不在中臺(tái)的話業(yè)務(wù)要如何實(shí)現(xiàn)導(dǎo)入導(dǎo)出。

2. 除以上三點(diǎn)和需求本身相關(guān)的思考內(nèi)容之外，我們要基于自己的業(yè)務(wù)形態(tài)和場景再進(jìn)行更深入的思考一些隱藏在需求之外的東西

1）中臺(tái)內(nèi)部的底層構(gòu)造

我們對(duì)接的業(yè)務(wù)是什么特性的業(yè)務(wù)，如果我們是做 saas 服務(wù)的，因?yàn)樯虘艚M織架構(gòu)和門店關(guān)系的復(fù)雜性，一個(gè)人可能在多個(gè)商戶開通銷售員賬號(hào)，也可能在一個(gè)商戶下開通多個(gè)賬號(hào)，我們中臺(tái)如何搭建基礎(chǔ)的賬號(hào)體系，才能知道這個(gè)人在多少個(gè)商戶下，以及在一個(gè)商戶下開通了多少個(gè)銷售員賬號(hào)？

2）底層模型的通用性

還有沒有這個(gè)業(yè)務(wù)域內(nèi)其他訴求與這個(gè)訴求非常相似的，可以用相似能力的？也就是我這個(gè)能力模型是否可以兼容相似的業(yè)務(wù)？如果有的話，我要把相似業(yè)務(wù)功能打散再重新組合，看看是一個(gè)什么樣的底層模型。

以上問題先放著，因?yàn)橘~號(hào)和賬號(hào)狀態(tài)息息相關(guān)，我們再看“停用刪除銷售員賬號(hào)”這個(gè)需求。

3. 停用、刪除銷售員賬號(hào)本質(zhì)

其實(shí)本質(zhì)上是在改變賬號(hào)的狀態(tài)屬性，而不是真的把賬號(hào)刪除了，而每個(gè)業(yè)務(wù)對(duì)賬號(hào)狀態(tài)的叫法肯定都是不一樣的，每個(gè)賬號(hào)狀態(tài)不同，對(duì)業(yè)務(wù)邏輯的影響也不同，所以我們思考的問題是：

1）功能本身的邏輯是什么

我們中臺(tái)要如何定義銷售員賬號(hào)的狀態(tài)，才能更加通用和泛化？

2）非中臺(tái)能力的業(yè)務(wù)解決方案

各種狀態(tài)帶來的不同的業(yè)務(wù)影響，是否要沉淀到中臺(tái)？

4. 通過這些思考，我們最終沉淀的能力和功能如下

1）提供創(chuàng)建賬號(hào)的原子能力

做最基礎(chǔ)的一個(gè)人在一個(gè)門店下只能創(chuàng)建一個(gè)賬號(hào)的通用校驗(yàn)，其余業(yè)務(wù)屬性較強(qiáng)的賬號(hào)數(shù)量等等的校驗(yàn)邏輯由業(yè)務(wù)自行完成，只要調(diào)接口，我們就創(chuàng)建。

2）提供與銷售員賬號(hào)屬性相關(guān)性較強(qiáng)的獨(dú)立字段的存儲(chǔ)

比如所在門店 id（但中臺(tái)不會(huì)叫門店id字段），其余字段作為擴(kuò)展字段提供存儲(chǔ)能力。一些明顯與業(yè)務(wù)域相關(guān)性較弱的字段（在導(dǎo)入導(dǎo)出中發(fā)現(xiàn)的），中臺(tái)不存儲(chǔ)，但與業(yè)務(wù)共同商討如何解決基于這些字段的查詢問題。

3）中臺(tái)的賬號(hào)體系是內(nèi)部底層能力品做好規(guī)劃，并向研發(fā)闡述清楚

4）提供通用的賬號(hào)狀態(tài)字段

為兼容大部分商戶都可能有的審核流程，提供4個(gè)賬號(hào)狀態(tài)：待激活、已激活、已凍結(jié)、已注銷。業(yè)務(wù)側(cè)自行對(duì)應(yīng)，自行控制每個(gè)狀態(tài)帶來的業(yè)務(wù)邏輯，如果業(yè)務(wù)有審核，可以考慮創(chuàng)建待激活狀態(tài)的賬號(hào)，如果沒有審核可以直接創(chuàng)建已激活狀態(tài)賬號(hào)。

本次案例中業(yè)務(wù)側(cè)的禁用和啟用可以對(duì)應(yīng)中臺(tái)的凍結(jié)和激活。

這樣，中臺(tái)落地的思路就出來了，過程中只是要更注重通用和泛化的邏輯，描述清楚哪些是中臺(tái)做，哪些是業(yè)務(wù)側(cè)自行實(shí)現(xiàn)，系統(tǒng)交互流程是什么就可以了。

六、最后

我舉的兩個(gè)案例其實(shí)比較簡單，中臺(tái)真正落地時(shí)還要考慮很多東西，產(chǎn)品的底層能力是通用的，只是中臺(tái)更注重拓展性和抽象能力。

今天只是講了一些入門，希望能讓看這個(gè)內(nèi)容的人有個(gè)具象的感知，雖然各個(gè)中臺(tái)由于領(lǐng)域不同，各自能力域和落地方法也不同，但是各個(gè)中臺(tái)依然能夠抽象出一些共性的東西，后續(xù)再具體講解。

作者：初愚，公眾號(hào)：產(chǎn)品雜談錄

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

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