中臺上線半年，我總結出了「七宗罪」

中臺你們確定不會陌生，因此小胖沒必要作過多的解釋了。今年有幸參與到公司中臺項目的建設中，彈指一揮，從開始的方案設計、到上線、到推廣，也過去了接近一年的時間。

回首這段歲月，小胖總結了中臺設計、開發、推廣中的「七宗罪」，本着中臺仍是一個大方向的大前提下，你或許之後也會遇到。

第一宗罪：怎麼處理2B業務與2C業務的關係 首先，咱們很理解中臺之因此建設的意義和目的，就是要精簡系統、肅清機構，從而提升效率、下降成本。

不是全部的公司和系統都須要中臺，只有通過了幾年甚至幾十年沉澱的系統才適合作，由於面對尾大不掉的狀況，是時候進行一些創新了。

可是，這時候「歷史緣由」就每每成爲制約咱們進行再設計的一條攔路虎。咱們說中臺就是要避免「重複設計」，可是看似一樣的功能如某些營銷工具，在2B和2C的產品設計中對於規則和細節的要求是不同的。

理想與現實也每每存在較大差距。所以，在新中臺的建立和舊平臺的遷移過渡階段，有時候須要一些靈活的處理，尤爲是在資源有限的前提下，首先要保證業務的正常運行，沒必要必定要拘泥於所謂的條款和規則。

第二宗罪：帳號體系也許是整個項目中最大的坑 若是你認爲帳號只是負責登陸、很簡單的，那就大錯特錯了，可能還會受到嚴重傷害。

目前市面上的「中臺」許多都是對已有系統的重構和再組合，所以，多個系統在帳號體系上的設計是存在很大差別的，不只僅是登陸、受權、權限區分等，登陸的性能也會受到很大的挑戰。

由於按照目前按照功能模塊受權的設置方案，對於高權限的用戶來講，在打開頁面的時候須要加載不少內容出來，對性能的要求很高。

還有，必定要把全部權限相關的功能一次搞定，不論這個項目究竟是分了多少期來作，作的越早越好。

第三宗罪：多系統間技術框架和數據庫的使用 天下大勢合久必分，分久必合。中臺其實也是相似的一種理念，可是多個系統在從新解構、重構的過程當中，雖然於前端咱們經過設計、UI進行統一，可是對於中臺來講更重要的仍是後臺架構和數據庫的搭建。

小胖就遇到幾個系統居然用了不一樣系統框架和不一樣數據庫的問題，可能開始設計和開發的時候並無以爲有多麼彆扭，可是當開始使用的時候才知道有多酸爽。

第四宗罪：用戶體驗很難統一 對於一些還未造成本身統一UI和設計交互規範的公司來講，多個系統的合併簡直就是噩夢。

系統中的使用用戶是分多個的，好比商家端、用戶端、供應鏈端、財務端，等等，每一個角色都有本身所須要的一套流程，而且對於一些職能部門，他們早已經習慣了十幾年如一日的操做流程，忽然你要統一規範，還告訴人家特別好用，他信你就鬼了。

第五宗罪：利益關係的處理 這裏的利益關係主要分爲兩種，一種是原有業務的使用者，尤爲是新老業務間的利益衝突，另一種是做爲研發體系部門之間的利益分配問題。

好比，一個功能新業務覺着簡單點就好，可是老業務必定要通過幾個節點纔可使用，由於二者之間安全性和易用性的要求是不同的，這裏怎麼融合二者的利益關係相當重要。

另外，中臺做爲一個保姆式的產品，許多功能是偏向後臺的，所以前臺是看不到你的，若是有了成績那麼就是前臺的成績，若是出了問題就是後臺的鍋。

所以，怎樣分配好先後臺的利益，也是讓產品經理和老闆們頭疼的問題。

第六宗罪：項目推動如無頭之蛇 中臺的搭建是一個跨部門、跨平臺、跨業務的工做，怎樣調動各方的積極性，怎樣更好的讓各方發揮出本身的實力，怎樣保證項目能夠順利、保質保量上線，就是擺在咱們面前的一個關鍵點。

烏合之衆講人羣是缺乏統一意見的，尤爲是當不一樣利益的人彙集到一塊兒的時候。若是一件事讓一我的作，他能夠3天作完，若是同一件事讓3我的作，可能須要30天才能作完。

中臺項目推動的痛點在於你們很容易各自爲政，加上幫派之別，一件簡單的事情很容易搞得很複雜，凡事都要走流程、各類郵件確認，很是影響你們的效率。

第七宗族：項目推廣似老漢推車 咱們說產品作出來了，趕忙推廣吧。

Too Young，Too Naive！

第一代的中臺產品註定是不怎麼受待見的，由於剛作出來系統的穩定、系統的用戶量都尚未起來，反而是各類大大小小的問題接踵而來，讓你目不暇接。所以，對應這類產品的推廣便也可想而知，不會特別快，須要你要保存儘可能大的耐心。

不是爲了吐槽而吐槽，但願這些痛點你以前遇到過之後就不要再遇到了；爲了更美的之後，總結一些不美好的過往案例，必定程度上可讓後續很美好。