實戰經驗｜我總結了後台產品的６個特點

最近一直在做後台產品，我覺得相比前端產品來說，後台產品顯得沒有那麼虛，會更加務實一些，對於產品經理業務上以及相關知識上的要求也要比前端產品更加明確。在最近的工作中，我總結了幾個後台產品的特點。

1. 後台產品需求較為明確，但要求對業務更加熟悉

做後台產品，一般來說需求不會像C端那樣模糊，往往很多時候是不需要我們去做調研和分析，而是業務直接推進到需求。甚至對於一些為了配合前端所需要做的產品，比如CMS，需求會更加明確，即前端所需要配置的內容直接推到後台做相應內容即可。相對於C端產品面對用戶時需要分析用戶的行為，畫像，心理預期等等，後台產品對於這方面簡直少之又少。

但是，需求的明確並不代表需求的簡單。做後台產品，需要對業務內容十分的了解。因為後台產品的業務邏輯會更加的複雜，同時流程性會更強。大量的欄位堆積及繁瑣的操作都需要產品經理去思考，將整個流程梳理清楚。在當前操作下哪個欄位需要保留或者去除；這條記錄的狀態會流轉到哪裡，出現什麼樣的情況；閾值情況下會產生什麼，如果有前端頁面，所對應的前端頁面是否會受到影響；一個頁面的那麼多操作會不會有衝突的地方；這些都需要建立在產品經理對業務的足夠熟練上。產品經理必須得將整個業務流程了解透徹，才能在出現問題的情況下及時解決，減少錯誤的發生。

2. 後台產品欄位需要整理甄別

前文也提到了，後台產品的好多頁面往往是以列表形式，表格形式出現的，所以這一定會涉及到大量的欄位與數據。我們之前做過一個ERP系統，幾乎每一個一級二級頁面的都是以列表的形式展示的，所以欄位大概會有二十多個，並且每一條數據都會涉及到。

這個時候，如何有效的甄別欄位，讓之後的操作人員用起來不會覺得繁瑣、東西很多同時又能滿足業務需要就比較考驗產品經理了。甄別欄位，第一步就是從業務方面去推動。在ERP系統裡面，統一屬性的頁面（比如商品頁面）索引列表的欄位所需要的信息大致是相同的，比如供應商，訂單號，商品名稱，商品圖片等可以辨別商品的信息，然後不同的列表再加上這個列表相關的信息即可。但是商品信息所涉及的欄位也特別多，所以產品經理在整理列商品屬性的欄位時，也要根據當前頁面的業務選取適合這個頁面的屬性。比如在進行庫存檔點的時候，我需要了解的欄位是商品庫存，商品規格，商品圖片等，這個時候供應商等欄位就不是很必要。而進行商品入庫操作的時候，供應商又是必不可少的欄位。

所以在我們做後台產產品的時候，不要只是將欄位粘貼複製到需要的地方就好了，這樣雖然不會遺忘出錯，但是會使你的系統更加臃腫，難以使用。

3. 後台產品需要用共通的東西串接

最近在做一個關於合同相關的系統，有之前的一套老系統作為參考。看到了之前的系統特別的繁雜，所有的東西都是在一個層級全部鋪開去操作的。合同在不同的流程階段有不同的狀態，可奇葩的是這套系統並沒有一個流程的概念，所有需要流程轉化的地方都是通過合同號等相關信息去檢索，然後與之前的狀態並無相關再另外新開一條記錄來進行操作的。這無疑加大了操作者的工作量，同時誤操作的幾率也大大增加，可能會出現一個合同有多個狀態的情況，同時當操作者想要檢索該合同時，不同的狀態下都有記錄，還需要他自己去辨別。所以當操作者第一次操作這個系統的時候，一定會很懵逼。

但其實這個系統是有可以進行串接的東西的，即合同的狀態，那麼上述的所有操作流程完全可以基於合同的一個狀態流轉去進行。這樣，所有的操作都會變成有序的，流程清晰且不同的操作路徑都是唯一的，一是可以簡化操作流程同時也不會出現上述的種種情況。

我們在做後台系統的時候，不同的板塊往往由於業務原因很多時候都是可以關聯的。如果可以關聯的操作，我們在沒有特殊情況下完全可以讓它進行關聯。一方面，關聯操作可以讓操作者的工作量減少，如果有相關的欄位可以直接帶過來而不需要手動去輸，這樣也可以減少誤操作。另一方面，對於唯一性的操作尤其是狀態流轉的這種操作直接關聯操作可以極大的減少錯誤頻率。

4. 後台產品邏輯性會非常強

後台產品的邏輯性相對來說邏輯性會更強一些。因為後台會涉及到大量的數據處理，並且不同的數據進行不同的操作會產生不同的結果。各種限制條件等等也是在後台進行設置的，在不同的情景下所要涉及到的業務內容一般也會有不同。比如在用CMS配置前端頁面的時候，用戶端所看到的可能只是一個限時搶購的頁面，但是後台配置的時候，我們在考慮到最基本的時間限制條件之外，還要考慮到這個活動與其他活動發生衝突的時候怎麼辦，進行限時搶購的商品能不能進行下架處理，開始時無庫存了此時要手動配置成什麼狀態等等許多可能前端用戶並沒考慮到的情況都需要在後台體現出來。

那麼，如何有效快速的理清複雜的後台邏輯呢？我認為對於一般有狀態流轉或比較標準的流程化後台可以從以下幾個步驟去著手考慮：

• 首先將所有流程先跑通一遍，不要去管其他發生的情況以及其他與主流程無關的跳轉。
• 在將這個流程整理出來之後，根據業務將其劃分為幾個模塊，每一個模塊作為一個單獨的流程進行內容的填充。
• 最後將一些在不同模塊之間有跳轉鏈接關係的副流程鏈接在一起。

經過以上這幾個步驟，一個簡單流程的邏輯大致就可以理清楚了，然後不同業務組合到一起整體的邏輯框架就可以搭建出來了。

5. 交互細節要求不會很高

我們在做C端產品的時候，對用戶的感受特別看重，因為一些小小細節往往決定著你是否能在競品中勝出。但是後台產品的用戶對於這些細節並沒有特別在意。因為他們的最終夙願並不是希望這款產品用的有多麼爽，而是希望這款產品可以減少自己多少的勞動力，縮短了多少的工時，提高了多少的產出。所以在這個時候，產品的業務性就要比交互細節性更強。

當然，這並不是說後台產品的交互不重要，只是說對於細節方面不回要求很高，但是整體交互還是需要去認真思考的。比如這個按鈕應當放在什麼位置才能簡化操作，哪些地方需要著重處理給操作者以警示，這個操作是以彈窗的形式還是新頁面的形式去進行等等都是需要思考的交互方式。

所以一般在設計後台產品的時候，我們對於一些大的可以影響或者警示操作者的交互要比一些從心理方面出發的交互細節要更加註重。

6. 後台產品相對成型，市面上的產品參考意義很大

其實對於後台產品來說，市面上好多成熟的系統都已經做的比較好了，並且大多數可以叫的上名字的系統（CRM、CMS、ERP等等）都長得大同小異。所以一個產品經理要了解你做的東西都是比較方便且目的性都會比其他產品強太多的。比如要在做一套ERP系統的時候，就可以去了解一下SAP公司的相關係統，這種前人經過無數次試驗的打磨出的優秀系統參考意義極佳。

以上這些是我在工作中一些小的總結。做好一個後台產品對於一個產品經理的考驗程度要大於C端產品，加強自己在後台產品方面的知識和業務補充對於今後的職業生涯來說會有一定的競爭。然而，一套好的後台產品複雜程度與優秀程度肯定遠遠不止這些，要成為一個好的後台產品經理，依然任重而道遠。

作者：執迷，

本文由 @執迷 原創發佈於人人都是產品經理。未經許可，禁止轉載。