編輯導語：后臺系統(tǒng)雖然很重要，但由于績效方面性價比不高，很少得到足夠的重視。本文簡述了后臺的概念、類別、設(shè)計的方法要求和需要注意的事項等，并對“應(yīng)不應(yīng)該做后臺產(chǎn)品經(jīng)理”這個問題作出了解答，推薦對后臺系統(tǒng)設(shè)計感興趣的朋友閱讀。

做后臺系統(tǒng)其實很重要，能夠比較好的提升系統(tǒng)架構(gòu)的能力。但是產(chǎn)品人很少討論后臺怎么做，一是因為相比app端變化并不多，二是因為后臺并不能提升業(yè)績，在績效上也無法合理體現(xiàn)。雖然能夠提供效率、降低成本，但是其實很多情況下并不被重視。

我最近又開始做數(shù)據(jù)后臺，折騰得很，想了想，就正好分享一下做后臺的一些簡單經(jīng)驗，希望對大家有個啟發(fā)。

一、什么是后臺

后臺其實有兩種理解的方式：

一種是最常見的解釋，表示這是一個產(chǎn)品或者服務(wù)，是給內(nèi)部用戶使用的，譬如打開一個操作后臺所指的后臺；

一種是專業(yè)視角的后臺，譬如后臺產(chǎn)品經(jīng)理，指的是做后臺系統(tǒng)的產(chǎn)品經(jīng)理，這里的后臺系統(tǒng)不僅僅包含操作界面，還包含了信息流和業(yè)務(wù)流，很多時候未必在界面上體現(xiàn)。

譬如電商物流，你買了東西，你就知道商家會打包并把快遞委托給快遞公司進行運輸和投遞，這種業(yè)務(wù)流程在任何界面中都是不可見的，但大家都知道流程是這樣的，這也是后臺系統(tǒng)的一部分。

我認知里面的后臺其實更傾向于是第二種解釋，這是一個產(chǎn)品經(jīng)理應(yīng)該認知到的后臺。

當然如果是和業(yè)務(wù)人員進行交流的時候，說后臺那就指的是界面意義的后臺，我們今天聊的也是和界面后臺相關(guān)的問題。

二、后臺怎么分類

一般來說后臺分成兩大類：功能后臺和數(shù)據(jù)后臺。

功能后臺就是提供給特定人員進行操作使用的，它影響的是在app端展示的內(nèi)容和服務(wù)。數(shù)據(jù)后臺就是給特定人員查看數(shù)據(jù)的，它主要是統(tǒng)計和反應(yīng)業(yè)務(wù)的運營情況。

對于一家公司來說其實這兩種后臺都是必須有的。

三、后臺怎么設(shè)計

后臺的設(shè)計其實也是需要遵循產(chǎn)品的設(shè)計理論的，一般是根據(jù)使用對象和功能類型進行聚合分類。

我們先說說功能后臺。

功能后臺一般先根據(jù)內(nèi)部部門的劃分，把各部門需要使用的功能列出來。像運營部門需要操作app內(nèi)部各種資源位(banner和icon)的配置，所以必然會有單獨的運營管理模塊。

那么資源位又有在app上的位置(首頁還是我的)、資源位的類型(banner還是icon)的區(qū)別，那你怎么設(shè)計這個架構(gòu)？是按照app的位置分成多個二級頁面？還是按照類型，分成banner和icon兩類進行設(shè)計？還是不區(qū)分，按照統(tǒng)一框架設(shè)計？

這都是有區(qū)別的，不同的分類邏輯決定了怎么設(shè)計架構(gòu)和界面。一般來說按照類型區(qū)分或者不區(qū)分會合適一點。有些功能可能涉及到多個部門同時使用的問題，這就看職責和重要程度，一般看這個功能誰用得多就劃給誰。

譬如獲客投放，有的公司會把付費投放的放在市場部門，免費投放的放在運營部門(通常是內(nèi)部其他產(chǎn)品投放或者公眾號投放)，但是從功能上來說，一般是放在市場部門的所屬模塊下面的，因為實際上這個功能對于市場部門來說更重要，以及最主要的還是市場部門在使用。

數(shù)據(jù)后臺比功能后臺好處理，一般是按照各部門的數(shù)據(jù)需求來處理。

當然如果是產(chǎn)品的角度進行規(guī)劃的話，可以先根據(jù)各部門的指標和業(yè)務(wù)鏈路進行拆分設(shè)計。不過從我的經(jīng)驗來看還是以各部門的需求為基礎(chǔ)進行設(shè)計比較好，因為在看報表這件事情上每個人的想法是不一樣的，細分程度和特殊要求還是差別很大的，沒必要自己做一個規(guī)劃，適用性不好。

數(shù)據(jù)后臺按照大盤和各部門分表設(shè)計就行，但需要對數(shù)據(jù)的可靠性做大量驗證。

首先是需要確保統(tǒng)計口徑是對的，這個的話在給定義的時候不能有含糊的地方。其次是在每個頁面都加一下統(tǒng)計口徑的說明，有的情況下會出現(xiàn)同樣的一個統(tǒng)計字段，但是統(tǒng)計口徑是不一樣的。這個時候光看字段名是不行的，沒有說明就區(qū)分不出來，使用的人就會覺得有問題。最后是需要根據(jù)明細去對一下統(tǒng)計數(shù)據(jù)是否準確，做一下數(shù)據(jù)校驗。

這是一個非常細致和工作量非常大的活，做的時候其實比較麻煩。如果公司流程合理留了足夠的測試時間，那么就在測試環(huán)節(jié)驗數(shù)據(jù)，如果測試環(huán)節(jié)沒法驗或者沒有留時間，那就直接發(fā)布，然后在線上對數(shù)據(jù)，一邊對一邊修bug。

如果是在小公司其實后面那種情況遇到的概率會非常大，業(yè)務(wù)領(lǐng)導都是上來就問明天能不能上，完全沒有合理性的概念，不必糾結(jié)。如果技術(shù)靠譜點問題就少，如果不是很靠譜那就問題非常多。

我最近的經(jīng)驗就是開發(fā)了2天，bug斷斷續(xù)續(xù)修了3天。你感受一下。

四、后臺設(shè)計需要注意哪些問題

1. 后臺要好用

因為是內(nèi)部使用的后臺，其實很多小公司都是很不重視后臺的可用性的，界面難看、難用，模塊劃分不清晰。如果遇到這種情況可以讓技術(shù)選一個好的框架，在開發(fā)的時候注意一下頁面干凈和布局清晰一點。

我就遇到了這種情況，后臺整個界面扭七扭八的，非常難看。

2. 后臺盡可能少

我現(xiàn)在的公司功能后臺有6個，更新一下app版本要同時登錄3個后臺修改數(shù)據(jù)，這TM真是絕了。如果有條件的話盡可能合并成1-2個后臺，或者在設(shè)計的時候就不用分開設(shè)計。

但也不是說合并成一個最好，譬如如果涉及到電銷系統(tǒng)，系統(tǒng)本身就很復雜且只有電銷部門使用，這種情況下其實是可以單獨做后臺的。

從實際的情況來看其實合并后臺是不大現(xiàn)實的，因為成本高、周期長、風險大以及對于業(yè)績的提升難以估量，公司層面比較難通過。我做過一次后臺合并，開發(fā)了3個月，修bug斷斷續(xù)續(xù)修了2個月，慘不忍睹。

所以如果不是領(lǐng)導提這個事情，盡量不要主動提，因為績效上來說很難給你加分，甚至搞不好會減分。

3. 權(quán)限設(shè)計要合理

權(quán)限設(shè)計有兩種方式：

一種是根據(jù)崗位設(shè)計，不同的崗位權(quán)限不同，同一個崗位權(quán)限一致。這種方式的好處是設(shè)置一次后，來新人只要掛一下部門，權(quán)限就有了，比較適合規(guī)模比較大的公司，職能比較清晰，變動也比較少；

一種是根據(jù)用戶進行選擇，每次來一個人都需要配置權(quán)限，好處是非常靈活，比較適合初創(chuàng)型企業(yè)，一切都還在變化，人員也不多，所以需要這種方式。

這里面可能需要注意一下，在頁面內(nèi)可能還會細分權(quán)限，譬如頁面上有導出按鈕，有的公司要求比較細就會針對這個導出功能也會有單獨的權(quán)限。

有的公司會做成和釘釘?shù)慕M織架構(gòu)關(guān)聯(lián)的方式，也可以，掃一下登錄，安全性也挺好，而且產(chǎn)品經(jīng)理就不需要設(shè)計權(quán)限系統(tǒng)了。

4. 分類要合理

這個比較容易把握，一般是按部門和職能組合后臺就行。

但是一定要說明的是，最好不要把數(shù)據(jù)和功能混在一個后臺上，不倫不類的。倒不是說實現(xiàn)上有問題，但是這就會導致分散在不同的地方，使用起來并不方便的問題。以及很多公司都有單獨的BI系統(tǒng)，然后就會導致兩邊都有數(shù)據(jù)，兩邊還不一定對的上的問題，處理起來更麻煩。

然后一定要注意的是對原有功能的適配。

大量的情況下并不是新增全新的功能，而是針對原有功能進行優(yōu)化和新增，這就涉及到對原有功能的適配問題，如果產(chǎn)品不提的話技術(shù)很可能是不會做額外的處理的，建議在提需求的時候提一下適配問題。

我最近的經(jīng)驗就是在原有功能上加了一個新功能點，但是技術(shù)發(fā)布之后沒有任何說明，等到業(yè)務(wù)部門觀察數(shù)據(jù)的時候才知道，需要做一次更新保存新功能才會生效，我真的是服了，沒做處理沒關(guān)系，連個說明都沒有。

5. 最好有一個后臺功能使用說明書

因為總是會有新人來，一些功能可能會更新，沒有記錄就每次都會問產(chǎn)品經(jīng)理，還不如寫一個說明文檔，讓各部門查看使用比較好。

當然我也知道會遇到有些同事就是不看文檔，就喜歡問你，這也是很煩人的。你看情況處理，關(guān)系還行就說一下，關(guān)系一般就告訴他文檔里面有，可以自行查閱。

五、應(yīng)不應(yīng)該做后臺產(chǎn)品經(jīng)理

最后聊一下這個問題，可能還是有朋友是有點困惑的。

這個問題每個人的見解不一樣，但我們認為判斷的標準在于可遷移性好不好，也就是你這個經(jīng)驗?zāi)玫狡渌臼欠窨梢匝赜茫绻豢梢阅蔷筒恍?，如果可以那就行。這個其實和是什么類型的產(chǎn)品經(jīng)理沒關(guān)系，主要是考慮經(jīng)驗和技能的可遷移性。

舉個例子，在電商做倉儲履約的產(chǎn)品經(jīng)理，就是歸屬到后臺產(chǎn)品的大類下面的，這種產(chǎn)品經(jīng)理目前還是蠻吃香的，經(jīng)驗和技能的可遷移性也很好。這種需要考慮系統(tǒng)和現(xiàn)場人員如何互動的產(chǎn)品經(jīng)理其實蠻考驗經(jīng)驗和洞察的，核心是優(yōu)化流程提升效率，沒有足夠的經(jīng)驗是不可能做好的。

做后臺在大部分時候都是一件重要但對于績效來說性價比不高的一件事情，所以大部分情況下也沒辦法投入大多精力去做。盡可能的在設(shè)計的時候就把架構(gòu)設(shè)計的好一點，然后在框架里設(shè)計，做了之后如非必要不改動，一改動的話就涉及到對于歷史功能的適配問題，其實很麻煩。

今天想聊的就這么多，希望對你有個啟發(fā)。

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

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