后臺權(quán)限設(shè)計法:“三位一體”

7 評論 13801 瀏覽 154 收藏 10 分鐘

如何產(chǎn)出一個相對合理的后臺權(quán)限設(shè)計?本文筆者提出了一個后臺權(quán)限設(shè)計法:三位一體法——也就是“用戶+角色+組織結(jié)構(gòu)=用戶權(quán)限”。

知乎上有個問題:“為什么很多產(chǎn)品經(jīng)理不愿意做后臺?”在各類回復(fù)中有一個聲音:“因為后臺產(chǎn)品不好抄……”

不可否認,前臺產(chǎn)品和功能大都肉眼可見,存在可以借鑒的思路,而后臺產(chǎn)品可參考的內(nèi)容不多,但也正因此,我們才需要更多的后臺產(chǎn)品設(shè)計資料。

最近幾年自己主要負責(zé)數(shù)據(jù)平臺產(chǎn)品與ERP等業(yè)務(wù)系統(tǒng)項目,這些都屬于后臺范疇,所以在后臺設(shè)計方面,有一些自己的方式方法,本文優(yōu)先將后臺權(quán)限設(shè)計相關(guān)的經(jīng)驗分享給大家,與大家一起探討。

為什么要設(shè)計后臺權(quán)限

廣義的后臺包括業(yè)務(wù)系統(tǒng)(ERP、CRM、財務(wù)與客服系統(tǒng)等)、平臺型產(chǎn)品、To B商戶端以及各類App的管理后臺等。

其中不少初創(chuàng)App的管理后臺,一個超管賬號打天下,等規(guī)模提高到需要拆分后臺用戶權(quán)限的時候,再對后臺的改造,這幾乎算是刮骨療毒了,需要付出的代價很大??梢哉f越早進行后臺權(quán)限設(shè)計,后續(xù)成本也就越低。

首先我們來看,什么是后臺權(quán)限,后臺權(quán)限主要由以下三部分組成:

  1. 頁面權(quán)限:用戶可以看到那些頁面;
  2. 操作權(quán)限:用戶可以在頁面內(nèi)進行那些操作,增刪改查等;
  3. 數(shù)據(jù)權(quán)限:用戶可以頁面內(nèi)看到那些數(shù)據(jù)或內(nèi)容,以教培ERP系統(tǒng)學(xué)員管理模塊為例,學(xué)員1為A校區(qū)學(xué)員,學(xué)員2為B學(xué)員,A校區(qū)相關(guān)工作人員登錄系統(tǒng)查看學(xué)員信息,僅可查看到學(xué)員1。

以上三種權(quán)限組合在一起,決定了當前用戶的后臺權(quán)限與其可以完成那些業(yè)務(wù)流程。

至于為什么需要設(shè)計后臺權(quán)限,或者這么說:為什么要合理的設(shè)計后臺權(quán)限?

那是因為后臺權(quán)限直接影響了系統(tǒng)的拓展性和兼容性,如果用戶權(quán)限設(shè)計不到位,極容易出現(xiàn)部分后臺用戶權(quán)限溢出,或者后臺用戶出現(xiàn)交叉權(quán)限,出現(xiàn)很多人為的操作失誤。

另外,數(shù)據(jù)權(quán)限控制不到位,容易造成數(shù)據(jù)泄露,尤其是B端系統(tǒng),可能造成內(nèi)部爭搶客戶資源等“惡性”斗爭。

如何相對合理的設(shè)計后臺權(quán)限

關(guān)于后臺權(quán)限設(shè)計也有一些現(xiàn)行的方法,比如:RBAC模型,也就是基于角色的權(quán)限訪問控制,這是一個比較常用的權(quán)限設(shè)計方法。

參考RBAC模型,結(jié)合這些年的工作經(jīng)驗,覺得可以通過以下方式實現(xiàn)對頁面權(quán)限、操作權(quán)限與數(shù)據(jù)權(quán)限的管理,我把這種方式稱作:“三位一體法“。

  • 后臺用戶,承載權(quán)限的主體,也影響部分數(shù)據(jù)權(quán)限。
  • 用戶角色,通過對角色的管理,實現(xiàn)對頁面與操作權(quán)限的管理。
  • 組織結(jié)構(gòu),部門架構(gòu)的樹形結(jié)構(gòu),實現(xiàn)對數(shù)據(jù)權(quán)限的管理。

換言之,三位一體:用戶+角色+組織結(jié)構(gòu)=用戶權(quán)限

1. 角色管理

角色是頁面操作權(quán)限的集合,是一個權(quán)限集。通過對角色權(quán)限的修改,可以實現(xiàn)對用戶權(quán)限的批量修改。

角色管理需要明確權(quán)限粒度(明確哪些操作需要設(shè)置權(quán)限),對于權(quán)限粒度的把控是很關(guān)鍵的,可以避免角色設(shè)置過于復(fù)雜。

對角色的修改和刪除,需要考慮到對現(xiàn)有用戶的影響,要明確這些操作的后置條件。

看圖說話:

結(jié)合上圖,我們大致可以明白角色管理的實現(xiàn)方式了。

下面給大家說一下這種實現(xiàn)方式的弊端

  • 角色設(shè)置要求高,設(shè)置角色的相關(guān)人員需要對業(yè)務(wù)足夠了解,一旦出現(xiàn)誤操作,會直接對線上用戶產(chǎn)生影響;
  • 新增功能與頁面時需要對角色進行重新配置,可以手動完成,也可以自動化實現(xiàn),但每次功能上線都需要將新增的功能與操作分配給對應(yīng)的角色,一旦遺忘也會產(chǎn)生影響。

當角色過多時,可以準備一個角色說明文檔,既可以幫助我們了解現(xiàn)有角色的權(quán)限,又可以減少系統(tǒng)管理人員離職等原因造成的工作交接困難。

2. 組織結(jié)構(gòu)管理

組織結(jié)構(gòu)的管理要從兩個方向來實現(xiàn):

一個是對組織結(jié)構(gòu)本身的管理,也就是對部門的增刪改等;另一個是需要對后臺各個頁面中信息進行梳理歸納,確定信息主體中存在組織結(jié)構(gòu)字段。

(1)組織結(jié)構(gòu)的實現(xiàn)

看圖說話:

如果短期之內(nèi)后臺涉及部門不多,可以暫時不在后臺實現(xiàn)該功能模塊,而是通過XML配置文件的方式來實現(xiàn),這樣可以節(jié)省開發(fā)成本。

(2)頁面數(shù)據(jù)的梳理歸納

存在了“部門”這個信息,怎么運用這些信息,是我們需要實現(xiàn)的。在需求產(chǎn)出期間,我們會完成項目整體的“數(shù)據(jù)信息結(jié)構(gòu)”,可能有不少PM都沒做過這個,還是舉例說明:

用上面提到的教培ERP-學(xué)員管理模塊,該模塊實現(xiàn)的是對學(xué)員的管理,信息主體也就是學(xué)員,我們可以看一下學(xué)員的數(shù)據(jù)信息結(jié)構(gòu)(部分):

教培ERP里的組織結(jié)構(gòu)是校區(qū)及其上級管理部門,如果當前后臺用戶是組織結(jié)構(gòu)中的校區(qū)字段與學(xué)員的授課校區(qū)字段一致,那對應(yīng)的授課校區(qū)就擁有了查看該學(xué)員信息的數(shù)據(jù)權(quán)限。

數(shù)據(jù)權(quán)限的管理,需要我們對后臺所有模塊進行分析。而且在同一個頁面,可依據(jù)的字段也不單一,就像上圖中的校區(qū)有簽約校區(qū)和授課校區(qū)兩個,實際情況中可能會有更多。

也就是說,可以通過多個字段實現(xiàn)對數(shù)據(jù)權(quán)限的管理,因此對數(shù)據(jù)權(quán)限的梳理,一定要對業(yè)務(wù)十分的熟稔。

3. 用戶管理

之所以最后再寫用戶,是因為用戶是對角色與組織結(jié)構(gòu)的承載,一個圖,大家也就都看明白了:

上圖中部門=組織結(jié)構(gòu),崗位=角色。

如果存在多個部門崗位的權(quán)限取并集,通過上述方式實現(xiàn)用戶權(quán)限管理。

一些總結(jié)的話

后臺權(quán)限“三位一體”設(shè)計法適用于普遍場景,因為各種系統(tǒng)的實際業(yè)務(wù)場景不同,所以還會有很多的特殊場景需要處理。但只要從實際業(yè)務(wù)場景出發(fā),參考上述權(quán)限設(shè)計的思路,應(yīng)該是可以產(chǎn)出一個相對合理的權(quán)限設(shè)計方案。

關(guān)于后臺權(quán)限設(shè)計還有不少需要注意的細節(jié)和小技巧,這些需要大家在實際操作過程中去發(fā)現(xiàn)與挖掘,另外哪怕是To C的產(chǎn)品也應(yīng)該提高對后臺的重視程度,后臺產(chǎn)品是前臺產(chǎn)品的支撐,在后臺產(chǎn)品中后臺權(quán)限有點像筋骨脈絡(luò),只有打通了任督二脈,才能成就絕世武功。

 

作者:張小墨,微信公眾號:月光坦克(moontank1918),某美股上市互聯(lián)網(wǎng)公司產(chǎn)品經(jīng)理。

本文由 @張小墨 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 你好作者,我在設(shè)計項目經(jīng)理這個角色時候遇到了一點問題,他可以是任何部門的某個成員,同時他是某個產(chǎn)研項目中的項目經(jīng)理,也就是他只負責(zé)項目中的團隊成員,不對部門負責(zé),怎么樣才能把權(quán)限設(shè)計清楚呢?

    來自浙江 回復(fù)
  2. 頁面權(quán)限和操作權(quán)限,是不是可以歸類為功能權(quán)限?

    來自上海 回復(fù)
    1. 可以的,這個理解相當?shù)轿?/p>

      來自北京 回復(fù)
  3. 挺好的。

    來自安徽 回復(fù)
  4. 不錯,收益很多,前段時間對后臺權(quán)限進行了重新梳理,就是采用類似的操作

    來自江蘇 回復(fù)
    1. 我在后臺權(quán)限設(shè)計的時候,就秉持著“瞻前顧后”的原則,盡量避免給以后的工作挖坑

      回復(fù)
    2. 很好

      來自北京 回復(fù)