后臺功能設(shè)計(jì)的起點(diǎn):權(quán)限方案設(shè)計(jì)分享
權(quán)限是一個公司信息系統(tǒng)的起點(diǎn)。我從入職以來就一直想要對公司后臺的權(quán)限系統(tǒng)進(jìn)行一個梳理(其實(shí)是老板要求的),苦于對后臺和公司業(yè)務(wù)還不夠了解,所以想法一直沒能成型。終于,經(jīng)過幾個月斷斷續(xù)續(xù)的琢磨,我趁最近需求數(shù)量不多的時(shí)候,把權(quán)限的調(diào)整方案梳理了出來。
這次梳理公司后臺的系統(tǒng),我在原有權(quán)限系統(tǒng)的基礎(chǔ)上引入了公司組織架構(gòu),形成了動態(tài)權(quán)限管理模式,使得公司的權(quán)限管理更加合理化。目前已經(jīng)把方案提交給開發(fā)進(jìn)行審核,希望可以最終落實(shí)。這里就先向大家匯報(bào)一下這幾個月以來梳理權(quán)限的成果,給同樣有權(quán)限體系設(shè)計(jì)問題的朋友們一點(diǎn)參考。
要設(shè)計(jì)權(quán)限,首先要對權(quán)限已有的成熟方案有一定認(rèn)識,其次要對業(yè)務(wù)有深入的分析,才可以在業(yè)務(wù)的基礎(chǔ)上有針對性的設(shè)計(jì)權(quán)限模型。
關(guān)于權(quán)限成熟方案,我查了很多資料,主要了解了一些關(guān)于RBAC(Role-Based Access Control)權(quán)限模型的知識。加上在前司對SharePoint的權(quán)限分配方案有一定的了解,權(quán)限的知識基本就已經(jīng)足夠了(不夠也沒有更多了,找到一篇從產(chǎn)品的角度解釋RBAC的文章,值得一讀:請點(diǎn)擊查看)
關(guān)于業(yè)務(wù)需求分析方面,我對公司后臺的權(quán)限系統(tǒng)做了梳理。
- 因?yàn)楣緦?shù)據(jù)的保密要求很高,所以后臺有大量查看項(xiàng)目、查看投資人的細(xì)致權(quán)限設(shè)置,但是缺乏一致的管理方法,導(dǎo)致經(jīng)常出現(xiàn)有需求無權(quán)限,或調(diào)動后權(quán)限沒有及時(shí)清除的問題。
- 公司后臺主要是按照RBAC設(shè)置了權(quán)限體系,另外還根據(jù)項(xiàng)目服務(wù)小組的機(jī)制為每個項(xiàng)目單獨(dú)設(shè)置了權(quán)限。
- 后臺RBAC的權(quán)限角色中,有部門角色、功能角色、臨時(shí)團(tuán)隊(duì)角色等等,相對比較混亂。
現(xiàn)在這套系統(tǒng)面對一些問題:
- 權(quán)限角色太多,分類混亂。有大量臨時(shí)建立棄而不用的分組;
- 如果員工調(diào)換部門,需要逐個刪除他已有的權(quán)限,再逐個賦予新部門的權(quán)限;
- 如果部門領(lǐng)導(dǎo)更換,需要對部門內(nèi)員工的所有成員的審批對象都進(jìn)行調(diào)整。
為了解決上述問題,我嘗試將公司的組織結(jié)構(gòu)信息引入權(quán)限管理的系統(tǒng)。
- 盡量以部門為單位分配權(quán)限,權(quán)限角色過多混亂的情況;
- 出現(xiàn)員工部門調(diào)動或領(lǐng)導(dǎo)更換,會根據(jù)其部門更改自動重新分配權(quán)限;
- 對無法按照部門分配的功能采取原有的權(quán)限分配模式,通過給不同的員工分配不同的角色實(shí)現(xiàn),保證靈活性。
從上述的思路出發(fā),我定義了新的權(quán)限管理需求。新的權(quán)限管理分為部門權(quán)限制度和非部門權(quán)限制度兩種:
1、部門權(quán)限制度
部門權(quán)限分組默認(rèn)按照組織結(jié)構(gòu)圖。
按照小組設(shè)置部門,部門分管理者權(quán)限和默認(rèn)權(quán)限兩種,默認(rèn)權(quán)限為部門管理權(quán)限的子集。
若組織架構(gòu)中的小組設(shè)置了管理者,則管理者默認(rèn)擁有管理者權(quán)限。除管理者外,所有人加入小組后默認(rèn)擁有默認(rèn)權(quán)限。
(2)管理者權(quán)限包括
- 部門權(quán)限維護(hù)類:新建子權(quán)限組、默認(rèn)權(quán)限維護(hù)、打破權(quán)限集成等權(quán)限(可以分配給部門領(lǐng)導(dǎo)使用,也可以掌握在超管手中統(tǒng)一分配)
- 審批類:所有報(bào)銷、請假和購票的申請(若小組沒有設(shè)置管理者,則小組成員所有審批事宜由上級層級中的管理者負(fù)責(zé) )
- 職能類:單個部門的全部權(quán)限
(2)權(quán)限維護(hù)類權(quán)限詳細(xì)介紹
- 子權(quán)限組:部門內(nèi)可以根據(jù)員工設(shè)置子權(quán)限組,根據(jù)子權(quán)限組,分配部門權(quán)限;
- 默認(rèn)權(quán)限維護(hù):增刪進(jìn)入部門所默認(rèn)擁有的權(quán)限;
- 打破權(quán)限繼承:使某位員工失去默認(rèn)擁有的權(quán)限,為其單獨(dú)分配權(quán)限。
2、非部門權(quán)限制度
組織方法參照原有RBAC權(quán)限管理;
超管可以為單個員工或小組開啟非部門權(quán)限。
- 可以為非部門權(quán)限設(shè)置有效時(shí)間段;
- 若員工調(diào)轉(zhuǎn)部門,則所有非部門權(quán)限默認(rèn)失效,需要超管審批以后方可重新生效。
這套規(guī)則可以基本解決原來的權(quán)限與部門沒有關(guān)聯(lián)的問題,以及權(quán)限分配混亂難以管理的問題。這僅僅只是產(chǎn)品從業(yè)務(wù)角度梳理出來的需求,具體實(shí)現(xiàn)還需要和開發(fā)商量以后解決。而且要真正能夠落實(shí)實(shí)現(xiàn)還需要很漫長的過程。
這次設(shè)計(jì)方案給我最大的體會就是,設(shè)計(jì)復(fù)雜的功能最有效的手段還是從具體是使用場景出發(fā),使用場景決定業(yè)務(wù)邏輯,業(yè)務(wù)邏輯決定功能邏輯。我在最初設(shè)計(jì)的時(shí)候執(zhí)著于尋找成熟的權(quán)限管理模式套用,后來發(fā)現(xiàn)這樣生搬硬套不能提升后臺權(quán)限分配的效率。在過后的幾個月工作中,我接觸到了不少分配權(quán)限的實(shí)際問題,比如不知道分權(quán)限給誰,或者分配出去的問題沒有辦法管理的問題。這些問題直接啟發(fā)我引入了公司組織架構(gòu)的概念,也便有了這套方案。
所以,產(chǎn)品的設(shè)計(jì)與實(shí)現(xiàn)都服務(wù)于使用場景,才是真正好的產(chǎn)品,這一點(diǎn)對業(yè)務(wù)為導(dǎo)向的后臺產(chǎn)品至關(guān)重要。與大家分享,也請大家多提意見。
作者:張玨,方創(chuàng)后臺產(chǎn)品經(jīng)理;微信公眾號:產(chǎn)品狗小張。
本文由 @張玨 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
用戶組權(quán)限,用戶加入用戶組時(shí),繼承用戶組權(quán)限
想一個問題,一個公司有多后臺,是不是不好!不同部門用不同后臺
如果部門內(nèi)部也有權(quán)限分配、這樣會不會導(dǎo)致權(quán)限設(shè)置很亂套呢?
一個部門設(shè)不同等級的權(quán)限吧
部門權(quán)限劃分,不錯
期待后續(xù)的分享,比如技術(shù)解決方案; ?? ?? ;冒昧的問一個問題,這個權(quán)限是一套系統(tǒng),對嗎?
有腦圖輔助說明一下會更好
好主意,謝謝建議