????????產(chǎn)品人都不喜歡做后臺管理系統(tǒng)播揪，具體的原因大家都明白的贮喧。今年九月份，入職一家新公司猪狈，主要負責的是該電商項目的后臺管理系統(tǒng)箱沦。是的，一開始也覺得沒成就感雇庙。但是對于從來沒有PC端設計經(jīng)驗的我來說谓形，何嘗不是挑戰(zhàn)。現(xiàn)在這個項目也接近尾聲了（特別想撒花慶祝）我想花時間状共，寫下我的總結(jié)套耕，可能包含一些我自己查閱的資料等等，這樣我對這一部分有更加系統(tǒng)的了解和認識峡继。
????????之前接觸的是To C的產(chǎn)品冯袍，現(xiàn)在轉(zhuǎn)到To B，這兩者的區(qū)別確實很大碾牌。To B更加強調(diào)的是專業(yè)性康愤、功能的完整性，對于易用性的要求不如C端產(chǎn)品高舶吗，用戶上手是需要學習成本的征冷，但是我在想萬事萬物都有自己的規(guī)律和套路，而我們在設計后臺管理系統(tǒng)在模塊的設計和搭建上又應該遵循怎樣的一個套路呢誓琼？
一检激、清楚產(chǎn)品的本質(zhì)
????????以自己做的產(chǎn)品為例肴捉，為什么會存在這個后臺管理管理系統(tǒng)，如果沒有它叔收，前端的App就無法正常運行了齿穗，正所謂前臺一小步，后臺一大步饺律。后臺管理系統(tǒng)是為前端服務的窃页，想要了解到功能點和需求，除了需求調(diào)研以外复濒，還需要對前端的需求非常熟悉脖卖。你要知道在App上，每一個元素的出處巧颈，需要后臺系統(tǒng)去提供些什么畦木，這樣就不會漏掉需求點，導致前后臺沒銜接好洛二。所以我們是先調(diào)研App的需求馋劈，整理好后臺的需求，再跟客戶進行一個確認晾嘶，如果他們還有補充妓雾，兩端又要做什么調(diào)整。當然如果不是做為前臺服務的后臺垒迂，就另當別論械姻。
二、后臺管理系統(tǒng)的角色權(quán)限模塊
????????后臺管理系統(tǒng)机断，功能模塊雖然會根據(jù)項目的不同作出變化楷拳，但是有一個模塊是必不可少的，那就是角色權(quán)限模塊
????????為什么會提到角色權(quán)限模塊吏奸，因為它不僅是整個系統(tǒng)的一個小模塊欢揖，而且一直貫穿整個系統(tǒng)，從登錄奋蔚、操作到最后的登出她混。這一模塊應該包含用戶管理、角色管理泊碑、權(quán)限管理（角色管理和權(quán)限管理含在一起坤按，也可分開，具體情況具體分析馒过。臭脓。。）
? ? ? ? 1.參考模型——角色權(quán)限模型：（RBAC Role-Based Access Control,基于角色的訪問控制）腹忽，構(gòu)造“用戶-角色-權(quán)限”的授權(quán)模型来累。該模型的核心為功能權(quán)限控制和角色產(chǎn)生關聯(lián)砚作，角色再和用戶賬號關聯(lián)。一個用戶可以擁有若干個角色佃扼，當一個角色被賦予了某一個用戶時偎巢，該用戶就擁有了該角色所包含的權(quán)限。以自己做的產(chǎn)品為例兼耀，在創(chuàng)建角色時，需要選擇該角色的權(quán)限求冷。創(chuàng)建用戶時瘤运，需要選定該用戶的角色。
????????以上說的都是RBAC0匠题，RBAC1拯坟、RBAC2、RBAC3都是在其基礎上進行升級韭山，可根據(jù)自家產(chǎn)品的復雜程度郁季，選擇合適的角色權(quán)限模型。參看：RBAC模型
之前看到一個有意思的問題：
????????如果需要給一個特殊用戶增加某一個權(quán)限钱磅，如何處理梦裂？這里有兩種做法，一種是創(chuàng)建一個新角色盖淡，使其包含該特殊用戶所需要的權(quán)限年柠。另外種做法是在用戶管理里，可針對單個賬號二次修改權(quán)限褪迟，相當于單獨把這個賬號從用戶角色中抽離出來冗恨，單個賬號的最終擁有的權(quán)限為用戶角色權(quán)限集和二次修改權(quán)限集的并集。至于這兩種做法哪種好味赃，我一直堅信存在即合理掀抹，可根據(jù)情況而定。在用戶數(shù)量不多心俗，角色類型少的情況下傲武，第一種可以考慮，反之就第二種吧
? ? ? ? 2.后臺權(quán)限模塊的設計流程
梳理角色類型功能架構(gòu)圖——設計功能原型——細化產(chǎn)品方案另凌，形成PRD谱轨。
????????由于我們做的后臺管理系統(tǒng)不算龐大，所以整個角色權(quán)限并不復雜吠谢。只是在給不同的角色梳理功能架構(gòu)時土童，不要把權(quán)限控制到非常精細的級別（我們做到的是子tab的程度），太過精細工坊，在進行創(chuàng)建献汗、修改角色時敢订，效率會很低。
三罢吃、印象最深刻一個模塊設計
????????有點尷尬楚午，可復用的就看看上面，下面說說特別讓我抓耳撓腮的一個模塊：訂單管理尿招，為什么抓耳撓腮矾柜，就是因為感覺很簡單，不就那么幾個狀態(tài)嘛就谜，這么多電商怪蔑，照著抄唄。最開始我也這么想丧荐，So easy缆瓣，拍拍胸脯，一周妥妥的虹统。后面做得我黑眼圈都出來了弓坞，免疫系統(tǒng)受到了極大的威脅，我才不得不感嘆车荔，真心復雜渡冻。因為就算有這么多電商，每一家的業(yè)務流程夸赫、規(guī)則也不盡相同菩帝，結(jié)合自己的業(yè)務流程和相應的規(guī)則，就呵呵了茬腿。
首先奉上張流程圖呼奢，讓大家感受下，還有張更復雜切平，但是我不想打馬賽克了握础，累！
????????其實我只是想說明流程圖的重要性悴品，對于越復雜的流程禀综，就越應該先把整體的脈絡梳理清楚，這樣開發(fā)也好苔严，客戶也好才能有一個總體的把握定枷，畢竟他們真的沒有耐心一次性把你的原型看完，除了你自己...
? ? ? ? 其實就是想把自己做過的届氢，了解的欠窒，串起來，也算是個人經(jīng)驗的一個總結(jié)退子，還有很多有待提高的地方岖妄，慢慢來吧
