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

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

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

一、什么是后臺

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

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

一種是專業視角的后臺，譬如后臺產品經理，指的是做后臺系統的產品經理，這里的后臺系統不僅僅包含操作界面，還包含了信息流和業務流，很多時候未必在界面上體現。

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

我認知里面的后臺其實更傾向于是第二種解釋，這是一個產品經理應該認知到的后臺。

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

二、后臺怎么分類

一般來說后臺分成兩大類：功能后臺和數據后臺。

功能后臺就是提供給特定人員進行操作使用的，它影響的是在app端展示的內容和服務。數據后臺就是給特定人員查看數據的，它主要是統計和反應業務的運營情況。

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

三、后臺怎么設計

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

我們先說說功能后臺。

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

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

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

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

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

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

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

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

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

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

我最近的經驗就是開發了2天，bug斷斷續續修了3天。你感受一下。

四、后臺設計需要注意哪些問題

1. 后臺要好用

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

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

2. 后臺盡可能少

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

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

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

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

3. 權限設計要合理

權限設計有兩種方式：

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

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

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

有的公司會做成和釘釘的組織架構關聯的方式，也可以，掃一下登錄，安全性也挺好，而且產品經理就不需要設計權限系統了。

4. 分類要合理

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

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

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

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

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

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

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

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

五、應不應該做后臺產品經理

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

這個問題每個人的見解不一樣，但我們認為判斷的標準在于可遷移性好不好，也就是你這個經驗拿到其他公司是否可以沿用，如果不可以那就不行，如果可以那就行。這個其實和是什么類型的產品經理沒關系，主要是考慮經驗和技能的可遷移性。

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

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

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

本文由 @產品人玄青 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議