實戰經驗:運營后臺產品的重構
運營后臺如何進行重構呢?作者結合自身經驗,分享了自己的幾點看法。
首先先放一張文章結構圖:
運營后臺是公司內部人員使用的操作平臺,服務于產品的支撐和運營活動的展開。對于運營的同學來講簡直就是命根子,但是我們會發現絕大部分的運營后臺用起來體驗超級爛(默哀十分鐘),而且bug成筐,隨處可見反人類的交互設計。那么運營后臺為什么會如此難用。
對于絕大分的創業公司和團隊來講,為了解決生存問題,首要解決的一定是面向用戶的產品的快速迭代,先把功能迭代上去再考慮其他。這個時候會有一些零散的解決運營需求的小后臺,有的甚至連最簡陋的后臺也沒有,直接操作數據庫(開發GG內心OS),如果有些東西修改比較頻繁,開發就會編寫一段腳本,直接用腳本錄入。所以這個時候的運營后臺的演化路徑是這樣的:“開發大爺直接改動數據庫——運營用腳本錄入——一些零散的小后臺功能——一個整體的可用后臺。”
但是隨著產品的快速迭代和公司規模的擴大,運營后臺的主要矛盾已經從有沒有上升到好不好、人效高不高的層面。這時候運營后臺就不得不進行大規模改造了,我稱之為后臺重構
那么運營后臺如何進行重構呢?有沒有可以一些可以借鑒的方法和規律呢?接下來我會從運營后臺重構的基本原則、產品層面規劃來說一下。
運營后臺重構的基本原則
- 目的和預期收益明確
- 把控好節奏
- 良好的兼容性和可擴展性
- 良好的可復用性
目的和預期收益明確
首先就是要明確重構的目標和預期收益,這個對于不同的公司和團隊見仁見智??傮w來說就是一定要明確我這個后臺是“為WHO在什么情況下解決WHAT問題”,實際上給給自己的后臺建立邊界,確定燭臺需求和目標,才能夠有的放矢的區進行設計。例如我對自己的運營后臺的定義就是“為整個運營團隊提供效率支撐和業務管理工具”。
節奏的把控
資源永遠是稀缺的,所以重要的東西一定要先行。當你面臨一大堆的東西要做的時候,可能需求池都無法裝得下,這時候就要平衡成本和收益,重構產品尤其如此。對于運營后臺的重構,最重要的還是先滿足現階段的需要,在完成現有需求的同時逐步的加入重構要素,在不知不覺中完成整個后臺的重構。很多事情到了不得不做的時候才是最重要的。除非你手里的資源多的足夠支撐你大刀闊斧的改造,否則還是選擇溫水煮青蛙的方式慢慢改造吧。
良好的兼容性和可擴展性
良好的兼容和擴展性是最見功底的地方,一般到你手里的一坨后臺功能,而且這些功能往往是不同的開發大爺做出來的,除了應用層的混亂之外,底層的兼容性和可擴展性也會是一個大問題。往往你要改動一個功能,開發會說做不了,很大原因就是底層的混亂。所以在重構時要三思“和別的功能有沒有關聯和沖突、改動能不能兼容、新來的能不能擴展”,這樣的后臺系統才是一個底子硬的好后臺。
可復用性強
同時后臺還要有很強的可復用性。做運營后臺就像搭積木,而一些組件化的產品模塊就是我們手中的積木,如果我們在自己的產品中能夠提前抽象出一些組件化的產品,能夠避免重復造輪子,大大降低產品研發和后期維護的成本,達到事半功倍的效果。
原則有了,下面的就是具體的操作方法了。重構后臺會面臨一筐一筐的問題,不能被現有的問題牽著鼻子走,要仰望星空腳踏實地:上天就是做好業務層的規劃,入地就是要做好基礎設施的建設。
基礎設施
賬號和權限體系
運營后臺產品,最重要的就是賬號權限系統了。權限系統一方面控制著什么人可以操作什么事情,保證敏感的事情只有核心人員才可以做;另一方面也是業務流和業務模塊的第一道分流設施。這個模塊會根據業務場景的不同而進行不同的設計,對于內部的運營后臺產品,個人推薦用“賬戶-角色-權限”三級的權限模型,這套模型能夠滿足絕大多數的后臺產品需要,而且維護起來成本也低。權限控制一般會采用兩種模式,一種是后端API限制,另一種是前端交互層限制,這個就根據業務場景靈活使用。
列表和搜索
一般進入業務層的操作會有一個列表,例如,列表的作用是“重要信息的展示-操作結果的反饋-歷史操作的查詢”,典型的列表是這樣的:
首先我們要弄清楚列表的整體結構:
- 整體操作區:搜索、篩選、新增
- 信息展示區:即各個展示字段
- 個體操作區:查看、編輯、刪除、狀態置換等
與列表相關的還有:
- 列表字段:要明確列表字段的“字符長度、是否允許特殊字符、是否換行、是否空缺”等
- 分頁:如果數據較多的情況下,需要進行分頁展示,使得能夠快速操作數據。要考慮分頁數量,頁面跳轉等
- 排序:數據的排序,有主排序規則和次排序規則,通常采用時間軸倒序排列
- 數據加載:當數據較多的時候,需要進行分段加載,這時候要考慮分段加載和數據本身的
用戶基礎信息
用戶的基礎信息實際上就是用戶的畫像,能夠清晰的描述出你的用戶到底是什么樣。一般來說用戶的基礎信息兩部分,即用戶的自身屬性和用戶的行為屬性。
用戶的自身屬性包括:姓名、性別、學歷、收入、所在城市、畢業學校等等用戶自身的屬性信息,這類信息往往哪個是數據庫中能夠直接拿到的。
用戶行為屬性信息包括:手機型號、系統版本、APP版本、所在地理位置、瀏覽軌跡、行為標簽等,這類信息往往需要用戶激活后才能進行判斷。
應用層的設計
入口層級的設計
主要邏輯是根據運營管理的主體進行分類,并根據相似和差異進行歸類。
分類原則:
- 現有的任何一個模塊和功能點都能有自己的分類
- 一級菜單的分類為管理對象,每個一級菜單下不超過9個二級菜單,每個二級菜單下不超過9個三級菜單
- 功能越來越多,根據業務發展節奏對已有功能進行整理歸類
- 對新增加的功能進行判斷,找到對應的層級入口,如果不能,則在對應的入口下新建
業務流的合理規劃
業務流是后臺管理中非常重要的方面,最簡單直接的例子就是“審批”流,需要多個不同的角色來執行不同方面。具體還是業務導向型的,這里不贅述。這塊推薦一個好用的工具“泳道圖”來進行設計,確定不同節點不同角色的操作流程。流程圖最好能夠從兩個角度來畫,第一種是產品經理常用的動作流程圖(適用于前端交互和操作),另一種是狀態流轉圖(適用于后端的狀態基流轉),基本上這兩個圖梳理清楚,整個業務流就會梳理的比較清晰了。
業務流程的規范
這里推薦有三個我個人總結出來的好工具,僅供參考
產品辭典
產品辭典是產品的基礎信息,是進行信息同步和管理的有效手段。通常包括:重要名詞的定義、歷史迭代記錄、產品操作手冊等信息。
操作規范
凡是系統總是人用的,無論系統設計的多么完美,都可能出現人為的操作失誤。這時候操作規范就顯得尤為重要,用來規范操作人員的使用流程,做到產品的線上線下自洽,同時減小PM和運營之間的摩擦。
產品check list
check list適用于產品設計整個過程中,能夠幫我們逐條檢查問題,核對核心case,最大程度上降低風險 的工具,能夠讓我們的產品管理更加精細化,必經已經不是產品的草莽年代了。
總結
運營后臺的重構是一件長期而復雜的事情,會受到各種條件的限制而有不同的解決思路。但是總體上來說仍然是明確目標、搭好基礎設施、建立兼容性和可擴展性、做好頂層應用設計,同時平衡成本和收益,確定自己的節奏,按照節奏一步一步走。
是的,總有一些坑,你永遠踩不完。
本篇先整體介紹一下運營后臺重構的原則和方法,后面會把每一個模塊詳細的闡述。
本文由 @迅哥喝茶 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自PEXELS,基于CC0協議
配圖里的大慶實驗中學是生產環境的截圖啊??,里面的是我的老師
寫得非常好 點進去看了下您的文章 并沒有看得到后序 很期待!
說的不錯,但是感覺又什么都沒說
同感
同感
學習了,內容很棒!
不過用戶基礎信息這一塊顯得很突兀,感覺閱讀到這遇到斷層一樣。。。
贊贊贊、希望后續的模塊快快更新!如果可以的話、希望可以附帶一些圓形的截圖也好!感謝感謝、辛苦辛苦!棒棒噠
原型截圖得處理一下,工作中的原型不會外放的
先點個贊