在系統(tǒng)設計中，賬號的用戶權限設計是最令人頭痛的，但又有著至關重要的作用。本文就B端產品后臺的用戶權限該如何設計展開探討，總結了自己在實戰(zhàn)中的相關經驗，希望對你有所啟發(fā)。

前一篇文章賬號篇跟大家聊了聊產品后臺的基本邏輯和賬號體系設計相關的經驗。本文繼續(xù)聊最讓人頭痛的用戶權限設計。

開始之前，先回顧一下后臺信息的分類，對于理解用戶權限設計有至關重要的作用。后臺最核心的對象就是數據，B端后臺一切的操作行為，本質上是對數據增、刪、改、查的操作。

數據可以大體分為：

• 產品數據（文圖音視等數字內容、實體商品、算法模型等）。
• 用戶信息（個人資料、賬號、權限、組織等）。
• 用戶行為數據（PV、UV、點擊、用戶反饋等）。
• 業(yè)務數據（如用戶的訂單、商家的庫存、發(fā)布的內容等）。

帶有用戶信息的賬號訪問、使用服務商提供的產品數據，在整個過程中會留存大量的訪問、點擊、跳出等用戶行為數據，用戶購買產品、發(fā)布內容、提交表單等行為會產生業(yè)務數據。

一、系統(tǒng)權限的分類

根據筆者的經驗，后臺的系統(tǒng)權限可以大致分為三類：

1. 功能權限：該用戶在系統(tǒng)中，可以使用哪些功能模塊，使用哪些具體的功能。
2. 數據權限：該用戶在系統(tǒng)中，可以訪問哪些數據，是否可以對數據進行增、刪改、查等操作。
3. 組織權限：對于B端產品來說，往往也涉及到組織架構。該用戶在不同的組織和不同的位置上，天然具有某些權限。比如在OA系統(tǒng)中的審批權限。與功能和數據權限有一些交叉，但是比較重要，所以單獨歸為一類。

為什么說權限系統(tǒng)復雜呢？有過權限系統(tǒng)設計經驗的同仁可能深有體會。

首先，用戶前端、用戶后臺、系統(tǒng)后臺都有自己的一套權限體系，而且三者之間也會存在一定的關聯(lián)關系。三個系統(tǒng)的權限交織在一起，相互依存、相互限制，會導致整體的權限系統(tǒng)極其難以設計。

其次，功能權限、數據權限和組織權限同樣是密不可分的。在一個組織特定位置的用戶，其權限一定涉及功能權限和數據權限。訪問功能的同時，一定會涉及到調取數據。而數據的訪問，也必然也要依賴數據查詢相關功能的支持。

最后，權限系統(tǒng)是要為業(yè)務服務的。需要根據業(yè)務合理設計權限系統(tǒng)，為相應的賬號賦予滿足業(yè)務需求的權限。但是不同的業(yè)務有不同的特點、流程、客戶&用戶需求，那么權限系統(tǒng)必然也會因此產生各種個性化、定制化的需求。

二、系統(tǒng)權限的設計原則

既然后臺權限的設計如此復雜和困難，那么我們如何掌握設計后臺權限的方法論呢？

筆者先介紹幾個設計原則，然后各位讀者可以結合后續(xù)的具體方法論進行實際的體會。

原則1 權限系統(tǒng)要為業(yè)務服務

這一條原則不證自明，也是最重要的設計原則。因此也自然要求涉及權限系統(tǒng)之前，一定要把業(yè)務邏輯梳理清楚。

原則2 權限系統(tǒng)設計一定要解耦合

無論在產品設計上還是技術架構上，務必注意功能權限、數據權限、組織權限之間和內部的解耦合。如果設計和技術架構不合理，將不同的權限耦合在一起，可能在未來業(yè)務變更的時候，出現(xiàn)大坑。

比如，如果將業(yè)務入口的權限和其內部具體功能模塊的權限耦合起來。一旦頁面需要調整業(yè)務入口，那么其內部功能模塊都可能會受到影響。

原則3 權限系統(tǒng)設計要有兼容性

業(yè)務是不斷變化的，其相應的權限也一定會隨之變化，因此權限系統(tǒng)設計要保證兼容性，避免因為寫死、沒有為新功能留后路等導致無法適應業(yè)務的發(fā)展。

原則4 權限系統(tǒng)設計要盡量簡潔

奧卡姆剃刀原理告訴我們，“如非必要，勿增實體?！睓嘞尴到y(tǒng)本身就是復雜性很高的系統(tǒng)，每增加一個要素，其設計和開發(fā)、測試復雜度都會激增。因此在滿足解耦合和兼容性的基礎上，權限系統(tǒng)設計要盡量簡潔。在成本和效率、長期和短期等之間尋找平衡。

原則5 從前臺到后臺依次設計

建議從用戶前端、用戶后臺、系統(tǒng)后臺的順序，從前到后、由易到難的順序設計權限系統(tǒng)。從簡單的權限開始設計，上手會比較容易，而且在設計過程中也能為更復雜權限的設計提供思路。而且一旦設計出現(xiàn)問題，局部優(yōu)化或推翻重構的成本會更小。

各位讀者可以看出，以上的五個設計原則其實也是產品設計原則通用的一些原則。符合用戶習慣、易用性、可讀性、即時反饋等設計原則權限系統(tǒng)設計同樣要遵守。
不過在筆者的過往經歷中，認為以上五個原則是最重要的且容易踩坑的地方，因此特意拎出來加以強調。

三、系統(tǒng)權限的設計方法

權限系統(tǒng)的設計一般可以分成如下幾種思路：

• 完全寫死。對于非常簡單、基本不需要迭代的系統(tǒng)，可以直接寫死權限。
• 設置可選模板。固定幾種權限角色，比如超級管理員、管理員、一般用戶等，直接將模板關聯(lián)給賬號。適用于權限劃分清晰、業(yè)務相對簡單的系統(tǒng)使用。
• 可配置的模塊化權限系統(tǒng)。將權限通過梳理、歸納，設計為一個個獨立的可配置項，允許為每個賬號靈活配置權限。該方法最為靈活、普適，但是設計和開發(fā)難度最大。

筆者選取難度最大的可配置的模塊化權限系統(tǒng)，并且綜合功能權限、數據權限、組織權限，講解權限系統(tǒng)的設計思路。

掌握了最復雜的情況，其它相對簡單的權限系統(tǒng)設計自然手到擒來。

1. 系統(tǒng)權限分析

在著手設計之前，建議首先對系統(tǒng)的業(yè)務流程和需求、并結合權限進行完整的系統(tǒng)權限分析。

如何合理地分析系統(tǒng)的業(yè)務流程和需求，計劃放到后續(xù)的業(yè)務系統(tǒng)重點講解。如果該系列大家喜歡、且投票踴躍，筆者會堅持繼續(xù)更新。
分析腦圖的樣例如下。

腦圖中涉及的概念解釋如下。

• 部門：服務客戶的組織架構，可能存在多個層級。部門內的員工賬號關聯(lián)到對應的部門下，以和實際的組織架構保持一致。
• 角色：每種角色作為一種權限設置的集合?？梢酝ㄟ^為賬號配置角色，讓賬號獲得相應的權限。
  系統(tǒng)：提供服務不同的系統(tǒng)，可能為用戶前端、用戶后臺、系統(tǒng)后臺。
• 模塊：系統(tǒng)中的功能模塊?？赡艽嬖诙鄠€層級。比如旅行軟件，可以分為機票、酒店、火車票出行等，出行又可以分為網約車、租車等。
• 功能：根據業(yè)務需求，需要管控功能的最小顆粒度，比如網約車可以分為快車、專車、拼車，以及因公付款、個人墊付等。注意功能拆分一定要遵循MECE原則，完整且獨立。
• 數據：某些功能可能涉及到數據的增、刪、改、查，比如說賬號管理、用戶發(fā)布內容管理等權限。

需要特殊說明的是，考慮到組織是客戶實際存在的組織架構，且有可能用到多個系統(tǒng)。因此把部門作為第一層級。

這樣去做梳理，可能對產品經理的全局觀和邏輯思維能力要求比較高，但是更符合實際業(yè)務情況。最終完成的權限系統(tǒng)兼容性也更強。
如果只負責一個系統(tǒng)，那么也可以以系統(tǒng)為第一層級，先把自己負責系統(tǒng)的權限梳理清楚。
注意如果多個系統(tǒng)是統(tǒng)一的賬號體系、且存在一個部門使用多個系統(tǒng)的情況，也需要與相關的產品同時做好同步，保證大家都設計思路一致。否則萬一后續(xù)要做系統(tǒng)之間的整合，那么重構的工作量會大大增加。

2. 系統(tǒng)權限設計

根據梳理出的權限系統(tǒng)腦圖，就可以比較清晰、方便地完成系統(tǒng)權限的產品設計工作。

筆者簡單模擬了一個系統(tǒng)權限的線框圖，以方便各位讀者理解。

首先設計部門列表，根據客戶的組織架構設計各級部門的列表和顯示重要的字段即可。對部門的操作同樣包括增、刪、改、查。

然后是部門下的員工列表。每一個員工即代表一個可使用系統(tǒng)的實際賬號。那么如何快速為不同的賬號配置權限呢？

關鍵在于角色這個字段的設計。在實際組織中，雖然一個部門內有很多的員工組成，但是可以按照其工作屬性進行分類。比如從職級維度，部門長、組長、員工、實習生等等。從職能上劃分，財務、會計、銷售、售前、售后等等。
有了角色，我們便可以根據該角色在系統(tǒng)中承擔的業(yè)務范圍，為其分配不同的系統(tǒng)權限，避免相同權限的賬號要重復配置。

下一步就是角色管理?。根據業(yè)務需要，可以為該部門在不同的系統(tǒng)中設置角色，以滿足該部門員工在不同系統(tǒng)中的?業(yè)務需求。

為了使用方便，可以提供一些系統(tǒng)中最常見的角色模板，方便客戶的管理員直接使用，比如超級管理員、管理員等?。

其中比較特殊的是超級管理員，其是一個系統(tǒng)中配置賬號的最基本、默認要有的角色?。其最起碼應當有最全的賬號管理權限，以為其它同事創(chuàng)建賬號、分配權限?。故該角色不應當被編輯和刪除?。

如果默認的角色模板不能滿足業(yè)務需求，還可以再新增角色?，完成個性化的權限設置。

最后也是最重要的，就是角色?具體的權限設置。包括角色名稱、角色權限配置、角色備注等?字段。

權限配置就是將腦圖中拆解的各模塊的功能權限和數據權限羅列出來，以為該角色勾選需要的權限?。

為了使用方便，還可以有復制角色權限的功能（也可以放到角色列表中）?，可以直接沿用已有的、近似的角色權限?，再進行微調，就可以快速完成一種新角色的添加。

3. 系統(tǒng)權限拾遺

本文主要講統(tǒng)一的設計方法論，也不宜結合具體的?業(yè)務案例講。因為不同業(yè)務的差別太大，一旦過于具體，通用性和可遷移性就比較差?。

“授人以漁，而不是授人以魚”，一直是筆者的經驗分享之一。

雖然本文看起來可能也沒有想象的那么復雜。但是等到結合具體業(yè)務執(zhí)行的時候，各位同仁就能發(fā)現(xiàn)很多困擾和?難以取舍的點。

就比如做系統(tǒng)權限分析時，功能權限拆分到什么顆粒度？如何做到MECE原則要求的完整性和獨立性?？

拆得越細，自然越靈活，但是開發(fā)成本越高，也越容易出現(xiàn)功能耦合的情況?；但是拆得過粗，可能無法滿足業(yè)務權限的精確管控?，后續(xù)需要拓展時，就需要考慮到新老數據的兼容性問題。

還有賬號的角色變更或角色權限變更的時候，是否要即時生效？

如果需要即時生效，就需要每個功能在執(zhí)行的時候都要校驗權限，系統(tǒng)開銷?會很高、效率也會很低。

如果只在登錄時候訪問權限，那么系統(tǒng)權限變更就會存在較大的延遲?。

折中的方案可能是定時刷新賬號的權限，那么也可能涉及到主動通知系統(tǒng)前端時機的問題?。

而且當賬號使用過程中出現(xiàn)了權限變更的情況?，那么該如何處理？刷新頁面隱藏功能還是有新的請求時候報錯？

管理員做刪除和禁用操作的時候也存在類似的問題。而且刪除和禁用的時候一定要判斷是否滿足刪除的條件。

比如刪除部門時，要考慮部門下是否還有子部門和賬號?，如果有是否允許刪除？

再比如刪除角色時，如果有賬號關聯(lián)著該角色，是否允許刪除?？如果需要先取消所有賬號的關聯(lián)才允許刪除，那么如何?方便地批量操作？如果允許直接刪除，那么如何方便地為受影響賬號分配新的角色？

這些問題，筆者也很難給出標準的、普適的答案，要根據具體的業(yè)務情況具體分析?。

本次關系到系統(tǒng)權限的設計經驗就分享到這里?。相信大家都能看到筆者的用心，不僅毫無保留地介紹經驗，還?貼心地自己畫了線框圖，以幫助大家理解。碼字不易，?請大家投票支持，給筆者繼續(xù)分享下去的動力！

為我投票

我在參加人人都是產品經理2022年度作者評選，希望喜歡我的文章的朋友都能來支持我一下~

點擊下方鏈接進入我的個人參選頁面，點擊紅心即可為我投票。

每人每天最多可投35票，投票即可獲得抽獎機會，抽取書籍、人人都是產品經理紀念周邊和起點課堂會員等好禮哦！

投票傳送門：https://996.pm/YyDmr