實戰經驗:運營后臺產品的重構

9 評論 31280 瀏覽 172 收藏 12 分鐘

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

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

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

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

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

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

運營后臺重構的基本原則

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

目的和預期收益明確

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

節奏的把控

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

良好的兼容性和可擴展性

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

可復用性強

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

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

基礎設施

賬號和權限體系

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

列表和搜索

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

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

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

與列表相關的還有:

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

用戶基礎信息

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

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

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

應用層的設計

入口層級的設計

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

分類原則:

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

業務流的合理規劃

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

業務流程的規范

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

產品辭典

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

操作規范

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

產品check list

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

總結

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

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

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

 

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

題圖來自PEXELS,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 配圖里的大慶實驗中學是生產環境的截圖啊??,里面的是我的老師

    來自四川 回復
  2. 寫得非常好 點進去看了下您的文章 并沒有看得到后序 很期待!

    來自上海 回復
  3. 說的不錯,但是感覺又什么都沒說

    來自天津 回復
    1. 同感

      來自浙江 回復
    2. 同感

      來自北京 回復
  4. 學習了,內容很棒!
    不過用戶基礎信息這一塊顯得很突兀,感覺閱讀到這遇到斷層一樣。。。

    來自廣東 回復
  5. 贊贊贊、希望后續的模塊快快更新!如果可以的話、希望可以附帶一些圓形的截圖也好!感謝感謝、辛苦辛苦!棒棒噠

    回復
    1. 原型截圖得處理一下,工作中的原型不會外放的

      來自北京 回復
  6. 先點個贊

    來自廣東 回復