4個步驟教你建立后臺角色權限系統(tǒng)
角色權限系統(tǒng)設計可以更好的優(yōu)化工作的流程步驟,本文分享角色權限系統(tǒng)設計的幾個主要步驟。
公司的商戶后臺剛建立不久,之前僅能支持系統(tǒng)管理員和商戶管理員兩種角色使用,隨著產(chǎn)品和業(yè)務線逐漸成熟,參與到整個產(chǎn)品中的人員越來越多了,涉及的部門和角色也由從前的一兩種變成了多種,故由我主導了角色權限系統(tǒng)的重構(gòu)升級。在此將工作心得記錄下來,分享給需要用到的人。
先簡單介紹下我司的后臺產(chǎn)品功能,我司主要業(yè)務是向B端企業(yè)客戶銷售一些智能硬件,客戶買到產(chǎn)品之后會將產(chǎn)品關聯(lián)到自己的商戶后臺,硬件會上傳一些核心數(shù)據(jù)到后臺供商戶管理查看,所以我們的后臺核心功能是:設備管理、商戶管理、用戶管理、數(shù)據(jù)管理、產(chǎn)品銷售管理。
角色權限系統(tǒng)
了解完我司后臺的大概功能后,我們來聊下角色權限系統(tǒng)。
角色權限系統(tǒng)屬于策略設計范疇,它的設計非??简炓粋€PM對業(yè)務的理解力以及對自己后臺所有功能的熟悉程度。做角色權限系統(tǒng)之前一定要先深度了解業(yè)務流程以及后臺的所有功能模塊,在不了解的情況下,多向相關同事請教,避免角色權限系統(tǒng)設計過程中出差錯和邏輯漏洞。由于角色權限系統(tǒng)屬于功能底層系統(tǒng),很多的業(yè)務功能、前端功能都深度依賴角色權限系統(tǒng),所以盡量在第一次出產(chǎn)品方案時就盡可能的考慮全面,減少后續(xù)不必要的返工,如果前期產(chǎn)品方案不夠縝密,后期改動成本會非常大。
目前市場主流的角色權限模型是RBAC權限模型,具體技術原理可以閱讀下這個博客http://www.cnblogs.com/lhyqzx/p/5962826.html,有人好奇為什么做角色權限系統(tǒng)設計還要了解技術架構(gòu)呢?這個是為了讓設計者能夠設計出高效、安全、靈活且技術可實現(xiàn)的角色權限系統(tǒng)。
RBAC權限模型核心就是功能權限控制和角色產(chǎn)生關聯(lián),角色再和用戶賬號關聯(lián),即創(chuàng)建用戶賬號時選定一種角色,該角色里已經(jīng)分配好了功能和權限。拿我們系統(tǒng)為例,由于有系統(tǒng)管理員和商戶管理員的區(qū)別,即系統(tǒng)管理員可以查看所有的商戶和設備數(shù)據(jù),商戶管理員邏輯上只允許查看自己商戶下 的設備數(shù)據(jù)。所以我為了更靈活高效的去創(chuàng)建用戶角色(比如:商務經(jīng)理、商務專員、客服經(jīng)理、客服專員等),我在用戶角色之前又設置了角色類型,詳見下圖:
關于用戶角色的創(chuàng)建權限上這里需要說明的是:如果貴司組織結(jié)構(gòu)比較龐大,使用后臺的角色人員涉及到各個職能部門,且不同職能部門又有不同的角色,那么創(chuàng)建、管理角色的權限應該下放到各個部門的leader,便于管理系統(tǒng)用戶的效率。由于我司業(yè)務的特殊性,可以預估到會參與使用后臺的角色大概十來種,所以我為了更加集中、高效、安全的管理用戶角色,設定的只有超級管理員可以創(chuàng)建和修改角色。
角色權限系統(tǒng)設計流程
角色權限系統(tǒng)設計的大概流程如下:
一、工具準備
思維導圖工具(mindmanager、Xmind都可,我用的Xmind)、word ?、Axure.
二、給每個角色類型梳理功能架構(gòu)圖
功能架構(gòu)圖梳理是為了讓設計者清晰理解后臺所有的產(chǎn)品功能模塊,以及各個產(chǎn)品功能之間層級關系,給每個角色類型都梳理一份功能架構(gòu)圖,可以讓產(chǎn)品自身和開發(fā)以及項目成員都了解每個角色類型的區(qū)別。
- 比如:超級管理員這個角色類型,它應該可以管理后臺的所有產(chǎn)品功能,并且擁有一些自己獨有的功能權限;
- 比如:角色管理和賬號管理功能我設定的只讓超級管理員有權訪問,其他角色類型全部訪問不了,所以也不需要配置;
- 再比如:高級全局管理員應該有管理低級別角色類型的權限,而低級別角色類型不能管理高級別角色類型。
梳理功能架構(gòu)圖時可以根據(jù)一、二、三級這樣的功能層次來畫思維導圖,有的后臺系統(tǒng)可能非常龐大,那么是否需要把一級功能到一直到末級的所有功能包括界面按鈕都全部羅列出來呢?這個需要看業(yè)務需求,看公司組織架構(gòu),多方面綜合考慮再決定權限控制到哪一層,羅列到哪一級別的產(chǎn)品功能。通常情況下,權限控制到二/三層級基本能滿足一個中小型公司的權限管理需求,再大型一點的公司,可以控制到更深層級的功能權限。
此外,我并不建議將權限控制到非常精細的級別,精細到可以控制前端頁面上的每一個按鈕,甚至每一個按鈕的顏色以及交互效果,因為后臺產(chǎn)品的核心是管理平臺。管理無非增刪改查四個操作,對于后臺而言,管理的效率非常重要,如果權限控制的過于精細,在進行創(chuàng)建、修改角色時,效率會非常低。并且,如果不是系統(tǒng)的設計者理解起來會非常困難,對于頁面上的一些關鍵按鈕和操作可以加以控制。
注意事項:
- 層級劃分清晰,不同級別的功能盡量用不同的字體區(qū)分開。
- 同類型的功能權限用不同的色塊兒填充,一般來講每種角色類型都至少會有兩種類型的功能權限,(1)默認該角色類型擁有的功能權限,無須配置 (2)需要配置的功能權限。
之所以給不同角色類型的默認設定了一些功能權限,是為了創(chuàng)建角色和維護角色更加方便。比如:高級全局管理員角色類型對應的用戶角色可能是各部門leader,像研發(fā)總監(jiān)、客服經(jīng)理、商務總監(jiān)這樣的用戶角色,這些用戶角色普遍會擁有較大的權限,同時又有所區(qū)分。假設系統(tǒng)有100個功能,那么我默認將這些角色可能會共同擁有的70個權限全部默認設定給高級全局管理員,將其余的功能設定為可自由配置的功能,那么當超級管理員去創(chuàng)建一個客服經(jīng)理角色時,就只要配置剩余的30個權限即可。
三、設計功能原型
角色權限的內(nèi)在規(guī)則邏輯設計好了,先和組內(nèi)討論,通過產(chǎn)品評審后可以考慮出產(chǎn)品功能原型了。
角色權限系統(tǒng)的開發(fā)一定是角色和功能是獨立的兩個模塊,他們二者通過配置關系產(chǎn)生關聯(lián)繼而會出現(xiàn)不同的用戶角色登錄系統(tǒng)后會看到不同的功能界面,所以在畫原型時只需要畫出最全的功能即可。當系統(tǒng)內(nèi)功能和角色數(shù)量相對而言都比較少的時候,角色權限管理功能可以考慮用橫豎列表形式展現(xiàn)。當系統(tǒng)內(nèi)的角色和功能數(shù)量比較多的時候,可以考慮模仿windows文件夾展開的交互用多面板形式來展現(xiàn)角色和功能的關系。
四、細化產(chǎn)品方案,形成PRD
將原型和腦圖都梳理完畢后,最后就是把流程、細節(jié)從頭捋一遍,將要點全部整理到PRD里,最后拿著PRD去和技術同學開技術評審會了。
完成以上四個步驟,基本就完成了一套后臺角色權限系統(tǒng)的設計,如果覺得有用,請轉(zhuǎn)發(fā)分享。
作者:Michael,Sensoro高級產(chǎn)品經(jīng)理,產(chǎn)品設計經(jīng)驗豐富,主導過移動產(chǎn)品、IM產(chǎn)品、web前后臺產(chǎn)品的多次重大升級。
本文由 @Michael 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
草草收尾,數(shù)據(jù)權限這個重點都沒有講,前面的浮于表面
這么水的文章。來我們一起討論下統(tǒng)一權限平臺。
一般,最核心的數(shù)據(jù)權限都沒有說,還自稱高級PC,呵呵。
剛好設計完我司的后臺權限系統(tǒng) 基本上都是一樣的套路
開了個頭就結(jié)束了 ??
感覺開了個頭就結(jié)束,這斷尾來的措手不及
我也這么覺得,剛開始就結(jié)束了…
同感。。。干貨太少。。。。
同感,以為會有案例展示,措不及防就結(jié)束了
同感呀,看到那個【注意事項】以為干貨來了,結(jié)果結(jié)束了。。
求功能架構(gòu)圖
邏輯關系圖?。。”硎静恢?!
在賬號添加時加一個 額外權限添加
如果需要給一個特殊用戶添加某個權限又該怎么辦,權限是是基于角色,但一個只有一個角色,
在賬號添加時加一個 額外權限添加,一個角色對應的是多個賬號
你要添加的這個權限如果是屬于這個角色中擁有但是未分配的權限,你又不想改角色的權限怕影響其他賬號,可以考慮做一個和角色管理平級的賬號管理功能,可針對單個賬號二次修改權限,修改后的權限不影響用戶角色的權限,相當于單獨把這個賬號從用戶角色中抽離出來,單個賬號最終擁有的權限為 用戶角色權限集和二次修改權限集的并集
嗯,這樣算是解決這樣的問題了
感覺不用這么麻煩吧,而且兩個地方可以對賬號的權限做處理本身就不好。既然基于 RBAC 就不要想著再搞一個什么賬號管理了,仿照 Axure 復制狀態(tài)操作復制角色,然后再做對這個角色單獨做處理就完了啊。個人看法,寧愿有十幾個角色也比再做一個賬號管理好的多。
說的很對,多一個角色比再做個賬號管理好,邏輯層面也不容易亂!
您的處理辦法是新建一個角色嗎?在原來角色的權限集基礎上添加新的權限,成為一個新的角色。
一個角色可以對應多個用戶,同時一個用戶也可以對應多個角色,先有角色權限,后有用戶權限。
??
學習了