如何產(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é)議