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

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

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

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

2. 后臺產品字段需要整理甄別

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

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

所以在我們做后臺產產品的時候，不要只是將字段粘貼復制到需要的地方就好了，這樣雖然不會遺忘出錯，但是會使你的系統更加臃腫，難以使用。

3. 后臺產品需要用共通的東西串接

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

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

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

4. 后臺產品邏輯性會非常強

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

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

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

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

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

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

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

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

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

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

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

作者：執迷，公眾號：執迷有悟

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