運營后臺如何進行重構呢？作者結合自身經驗，分享了自己的幾點看法。

首先先放一張文章結構圖：

運營后臺是公司內部人員使用的操作平臺，服務于產品的支撐和運營活動的展開。對于運營的同學來講簡直就是命根子，但是我們會發現絕大部分的運營后臺用起來體驗超級爛（默哀十分鐘），而且bug成筐，隨處可見反人類的交互設計。那么運營后臺為什么會如此難用。

對于絕大分的創業公司和團隊來講，為了解決生存問題，首要解決的一定是面向用戶的產品的快速迭代，先把功能迭代上去再考慮其他。這個時候會有一些零散的解決運營需求的小后臺，有的甚至連最簡陋的后臺也沒有，直接操作數據庫（開發GG內心OS），如果有些東西修改比較頻繁，開發就會編寫一段腳本，直接用腳本錄入。所以這個時候的運營后臺的演化路徑是這樣的：“開發大爺直接改動數據庫——運營用腳本錄入——一些零散的小后臺功能——一個整體的可用后臺?！?/p>

但是隨著產品的快速迭代和公司規模的擴大，運營后臺的主要矛盾已經從有沒有上升到好不好、人效高不高的層面。這時候運營后臺就不得不進行大規模改造了，我稱之為后臺重構

那么運營后臺如何進行重構呢？有沒有可以一些可以借鑒的方法和規律呢？接下來我會從運營后臺重構的基本原則、產品層面規劃來說一下。

運營后臺重構的基本原則

• 目的和預期收益明確
• 把控好節奏
• 良好的兼容性和可擴展性
• 良好的可復用性

目的和預期收益明確

首先就是要明確重構的目標和預期收益，這個對于不同的公司和團隊見仁見智?？傮w來說就是一定要明確我這個后臺是“為WHO在什么情況下解決WHAT問題”，實際上給給自己的后臺建立邊界，確定燭臺需求和目標，才能夠有的放矢的區進行設計。例如我對自己的運營后臺的定義就是“為整個運營團隊提供效率支撐和業務管理工具”。

節奏的把控

資源永遠是稀缺的，所以重要的東西一定要先行。當你面臨一大堆的東西要做的時候，可能需求池都無法裝得下，這時候就要平衡成本和收益，重構產品尤其如此。對于運營后臺的重構，最重要的還是先滿足現階段的需要，在完成現有需求的同時逐步的加入重構要素，在不知不覺中完成整個后臺的重構。很多事情到了不得不做的時候才是最重要的。除非你手里的資源多的足夠支撐你大刀闊斧的改造，否則還是選擇溫水煮青蛙的方式慢慢改造吧。

良好的兼容性和可擴展性

良好的兼容和擴展性是最見功底的地方，一般到你手里的一坨后臺功能，而且這些功能往往是不同的開發大爺做出來的，除了應用層的混亂之外，底層的兼容性和可擴展性也會是一個大問題。往往你要改動一個功能，開發會說做不了，很大原因就是底層的混亂。所以在重構時要三思“和別的功能有沒有關聯和沖突、改動能不能兼容、新來的能不能擴展”，這樣的后臺系統才是一個底子硬的好后臺。

可復用性強

同時后臺還要有很強的可復用性。做運營后臺就像搭積木，而一些組件化的產品模塊就是我們手中的積木，如果我們在自己的產品中能夠提前抽象出一些組件化的產品，能夠避免重復造輪子，大大降低產品研發和后期維護的成本，達到事半功倍的效果。

原則有了，下面的就是具體的操作方法了。重構后臺會面臨一筐一筐的問題，不能被現有的問題牽著鼻子走，要仰望星空腳踏實地：上天就是做好業務層的規劃，入地就是要做好基礎設施的建設。

基礎設施

賬號和權限體系

運營后臺產品，最重要的就是賬號權限系統了。權限系統一方面控制著什么人可以操作什么事情，保證敏感的事情只有核心人員才可以做；另一方面也是業務流和業務模塊的第一道分流設施。這個模塊會根據業務場景的不同而進行不同的設計，對于內部的運營后臺產品，個人推薦用“賬戶-角色-權限”三級的權限模型，這套模型能夠滿足絕大多數的后臺產品需要，而且維護起來成本也低。權限控制一般會采用兩種模式，一種是后端API限制，另一種是前端交互層限制，這個就根據業務場景靈活使用。

列表和搜索

一般進入業務層的操作會有一個列表，例如，列表的作用是“重要信息的展示-操作結果的反饋-歷史操作的查詢”，典型的列表是這樣的：

首先我們要弄清楚列表的整體結構：

• 整體操作區：搜索、篩選、新增
• 信息展示區：即各個展示字段
• 個體操作區：查看、編輯、刪除、狀態置換等

與列表相關的還有：

• 列表字段：要明確列表字段的“字符長度、是否允許特殊字符、是否換行、是否空缺”等
• 分頁：如果數據較多的情況下，需要進行分頁展示，使得能夠快速操作數據。要考慮分頁數量，頁面跳轉等
• 排序：數據的排序，有主排序規則和次排序規則，通常采用時間軸倒序排列
• 數據加載：當數據較多的時候，需要進行分段加載，這時候要考慮分段加載和數據本身的

用戶基礎信息

用戶的基礎信息實際上就是用戶的畫像，能夠清晰的描述出你的用戶到底是什么樣。一般來說用戶的基礎信息兩部分，即用戶的自身屬性和用戶的行為屬性。

用戶的自身屬性包括：姓名、性別、學歷、收入、所在城市、畢業學校等等用戶自身的屬性信息，這類信息往往哪個是數據庫中能夠直接拿到的。

用戶行為屬性信息包括：手機型號、系統版本、APP版本、所在地理位置、瀏覽軌跡、行為標簽等，這類信息往往需要用戶激活后才能進行判斷。

應用層的設計

入口層級的設計

主要邏輯是根據運營管理的主體進行分類，并根據相似和差異進行歸類。

分類原則：

• 現有的任何一個模塊和功能點都能有自己的分類
• 一級菜單的分類為管理對象，每個一級菜單下不超過9個二級菜單，每個二級菜單下不超過9個三級菜單
• 功能越來越多，根據業務發展節奏對已有功能進行整理歸類
• 對新增加的功能進行判斷，找到對應的層級入口，如果不能，則在對應的入口下新建

業務流的合理規劃

業務流是后臺管理中非常重要的方面，最簡單直接的例子就是“審批”流，需要多個不同的角色來執行不同方面。具體還是業務導向型的，這里不贅述。這塊推薦一個好用的工具“泳道圖”來進行設計，確定不同節點不同角色的操作流程。流程圖最好能夠從兩個角度來畫，第一種是產品經理常用的動作流程圖（適用于前端交互和操作），另一種是狀態流轉圖（適用于后端的狀態基流轉），基本上這兩個圖梳理清楚，整個業務流就會梳理的比較清晰了。

業務流程的規范

這里推薦有三個我個人總結出來的好工具，僅供參考

產品辭典

產品辭典是產品的基礎信息，是進行信息同步和管理的有效手段。通常包括：重要名詞的定義、歷史迭代記錄、產品操作手冊等信息。

操作規范

凡是系統總是人用的，無論系統設計的多么完美，都可能出現人為的操作失誤。這時候操作規范就顯得尤為重要，用來規范操作人員的使用流程，做到產品的線上線下自洽，同時減小PM和運營之間的摩擦。

產品check list

check list適用于產品設計整個過程中，能夠幫我們逐條檢查問題，核對核心case，最大程度上降低風險 的工具，能夠讓我們的產品管理更加精細化，必經已經不是產品的草莽年代了。

總結

運營后臺的重構是一件長期而復雜的事情，會受到各種條件的限制而有不同的解決思路。但是總體上來說仍然是明確目標、搭好基礎設施、建立兼容性和可擴展性、做好頂層應用設計，同時平衡成本和收益，確定自己的節奏，按照節奏一步一步走。

是的，總有一些坑，你永遠踩不完。

本篇先整體介紹一下運營后臺重構的原則和方法，后面會把每一個模塊詳細的闡述。

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

題圖來自PEXELS，基于CC0協議