????????產品人都不喜歡做后臺管理系統，具體的原因大家都明白的。今年九月份，入職一家新公司，主要負責的是該電商項目的后臺管理系統。是的，一開始也覺得沒成就感。但是對于從來沒有PC端設計經驗的我來說，何嘗不是挑戰。現在這個項目也接近尾聲了（特別想撒花慶祝）我想花時間，寫下我的總結，可能包含一些我自己查閱的資料等等，這樣我對這一部分有更加系統的了解和認識。
????????之前接觸的是To C的產品，現在轉到To B，這兩者的區別確實很大。To B更加強調的是專業性、功能的完整性，對于易用性的要求不如C端產品高，用戶上手是需要學習成本的，但是我在想萬事萬物都有自己的規律和套路，而我們在設計后臺管理系統在模塊的設計和搭建上又應該遵循怎樣的一個套路呢？
一、清楚產品的本質
????????以自己做的產品為例，為什么會存在這個后臺管理管理系統，如果沒有它，前端的App就無法正常運行了，正所謂前臺一小步，后臺一大步。后臺管理系統是為前端服務的，想要了解到功能點和需求，除了需求調研以外，還需要對前端的需求非常熟悉。你要知道在App上，每一個元素的出處，需要后臺系統去提供些什么，這樣就不會漏掉需求點，導致前后臺沒銜接好。所以我們是先調研App的需求，整理好后臺的需求，再跟客戶進行一個確認，如果他們還有補充，兩端又要做什么調整。當然如果不是做為前臺服務的后臺，就另當別論。
二、后臺管理系統的角色權限模塊
????????后臺管理系統，功能模塊雖然會根據項目的不同作出變化，但是有一個模塊是必不可少的，那就是角色權限模塊
????????為什么會提到角色權限模塊，因為它不僅是整個系統的一個小模塊，而且一直貫穿整個系統，從登錄、操作到最后的登出。這一模塊應該包含用戶管理、角色管理、權限管理（角色管理和權限管理含在一起，也可分開，具體情況具體分析。。。）
? ? ? ? 1.參考模型——角色權限模型：（RBAC Role-Based Access Control,基于角色的訪問控制），構造“用戶-角色-權限”的授權模型。該模型的核心為功能權限控制和角色產生關聯，角色再和用戶賬號關聯。一個用戶可以擁有若干個角色，當一個角色被賦予了某一個用戶時，該用戶就擁有了該角色所包含的權限。以自己做的產品為例，在創建角色時，需要選擇該角色的權限。創建用戶時，需要選定該用戶的角色。
????????以上說的都是RBAC0，RBAC1、RBAC2、RBAC3都是在其基礎上進行升級，可根據自家產品的復雜程度，選擇合適的角色權限模型。參看：RBAC模型
之前看到一個有意思的問題：
????????如果需要給一個特殊用戶增加某一個權限，如何處理？這里有兩種做法，一種是創建一個新角色，使其包含該特殊用戶所需要的權限。另外種做法是在用戶管理里，可針對單個賬號二次修改權限，相當于單獨把這個賬號從用戶角色中抽離出來，單個賬號的最終擁有的權限為用戶角色權限集和二次修改權限集的并集。至于這兩種做法哪種好，我一直堅信存在即合理，可根據情況而定。在用戶數量不多，角色類型少的情況下，第一種可以考慮，反之就第二種吧
? ? ? ? 2.后臺權限模塊的設計流程
梳理角色類型功能架構圖——設計功能原型——細化產品方案，形成PRD。
????????由于我們做的后臺管理系統不算龐大，所以整個角色權限并不復雜。只是在給不同的角色梳理功能架構時，不要把權限控制到非常精細的級別（我們做到的是子tab的程度），太過精細，在進行創建、修改角色時，效率會很低。
三、印象最深刻一個模塊設計
????????有點尷尬，可復用的就看看上面，下面說說特別讓我抓耳撓腮的一個模塊：訂單管理，為什么抓耳撓腮，就是因為感覺很簡單，不就那么幾個狀態嘛，這么多電商，照著抄唄。最開始我也這么想，So easy，拍拍胸脯，一周妥妥的。后面做得我黑眼圈都出來了，免疫系統受到了極大的威脅，我才不得不感嘆，真心復雜。因為就算有這么多電商，每一家的業務流程、規則也不盡相同，結合自己的業務流程和相應的規則，就呵呵了。
首先奉上張流程圖，讓大家感受下，還有張更復雜，但是我不想打馬賽克了，累！
????????其實我只是想說明流程圖的重要性，對于越復雜的流程，就越應該先把整體的脈絡梳理清楚，這樣開發也好，客戶也好才能有一個總體的把握，畢竟他們真的沒有耐心一次性把你的原型看完，除了你自己...
? ? ? ? 其實就是想把自己做過的，了解的，串起來，也算是個人經驗的一個總結，還有很多有待提高的地方，慢慢來吧
