品牌行銷策略，產品行銷與設計，各類型行銷推廣案例分享-品牌行銷點點讚
編輯導語：權限管理是所有后臺系統的都會涉及的一個重要組成部分，在管理后臺中對于權限的標準需要準確地把握，并且根據各種需求進行設計，達到最終目的；本文作者分享了關于權限系統的設計，我們一起來了解一下。
寫在前面，為什么要寫權限系統的設計呢？
因為每一個項目，有管理后臺，90%會有權限管理。在我自己歷史以往的項目，其實對于權限始終是一個相對表面的認知。直到我去年研究了釘釘的管理系統、以及今年做了產品重構，讓我對權限有了一個深度的認知。
一、權限是什么
我對于權限的理解，一開始是一個賬號，管理著后臺的某些模塊；這個時候，權限很簡單，他是一個賬號列表，可以編輯賬號信息以及設置賬號查看菜單，即賬號yimi可以管理訂單列表。
后面接了一些門店端的項目，在區分菜單查看上，也加上了數據區分，即賬號yimi可以管理**門店的訂單列表數據；上面這兩項，我覺得可以基本可以支持中小型的項目是足夠使用的。
然后更深一個層級的，當你接了一個大型的項目，你的后臺管理員是一個集團的人，或者是上百人，這個時候一個賬號區分是遠遠不能滿足的；也延伸了在做CRM系統的時候研究了釘釘的邏輯，權限不僅僅是開通一個賬號（僅有賬號+密碼）這么簡單，權限是對于不同部門的人的管理。那么這個時候會將賬號跟菜單權限獨立開來。
賬號即部門下面的某個成員，可通過手機號作為唯一標識。菜單權限按照不同角色去區分，財務有擁有什么菜單、采購擁有哪幾個菜單。
聽到這里，權限就涉及了：部門、成員、角色、菜單。那我會覺得，權限可復雜可簡化，其實無非是人管事。那么不同的權限設計會有什么區別呢？
二、最小權限設計
最小的權限設計，如下圖所示，有登錄賬號、密碼、以及菜單勾選。其實還有個XS版本的，即僅有賬號，無菜單權限分隔。
最小權限設計-圖示1
那什么情況會使用這種最小的權限設計，我個人的理解是小型的項目，或者說客戶內部運營結構相對簡單；這個時候需要注意幾點，第一個擁有整個菜單即擁有菜單所有操作，第二點是沒有數據隔離，即每個擁有菜單權限的管理員查看內容一致。
對于需求梳理如下所示：
三、中型項目權限設計
中型大小的項目，類似于多門店、或者是負責角色不同，同個模塊需要查看不同數據、進行不同的操作。如下圖所示：
中型項目權限設計-編輯管理員-圖示2
中型項目權限設計-編輯角色-圖示3
相對于最小權限設計，你可以理解為菜單+賬號的拆分，并且在菜單的基礎上，擴展了操作權限；也通過角色的區分，擴展了數據權限，此時的權限=菜單權限+操作權限+數據權限。
相對于上一個會復雜很多，為什么我前面會說建議按照產品體系，再去做這一套中型的權限系統？
一方面，眾所周知是由于開發工作量以及難度，對應報價會高；另一方面是，這個的復雜度也提高了他使用難度，如果是沒有這種業務情況需求(類似于多門店、或者是負責角色不同)，就不建議用了。
最后也是最重要一個方面，針對不可持續性產品的說明：不斷向軟件增加功能，是不可持續的。增加復雜性意味著遺留代碼越來越沉重，導致產品維護成本越來越高，而且也越來越難以靈活應對市場變化；這個道理我想不僅僅適用于用戶前端，對管理后臺也同樣適用。
對應的需求梳理如下：
四、大型項目權限設計
大型項目的權限，最大的一個變化，是有部門組織架構，不同部門的人使用系統，即將管理員管理拆解為部門管理+成員管理，但是又不僅僅于此。
在一個接入審批的系統、或者CRM中，往往數據是相對獨立的，可以按照部門組織架構數，去區分數據的權限。如下圖所示：
大型項目權限設計-部門組織架構-圖示4
如果說，中型項目的數據權限是按照門店或者區域劃分，那么部門樹則是數據權限的另一個維度。按照創建者所在部門，將這條數據歸屬于某個成員某個部門（此處還要考慮成員存在多部門的情況），同個部門間數據獨立，而主管可以查看所有人的數據。
則這個數據劃分，并不適用于后臺管理的所有列表，例如用戶列表、訂單列表此類數據來源并非后臺的，或者是一些文案管理的列表，并沒有必要做數據的區分；所以在開發的時候，還需要在每個列表列出說明，是否使用；這個邏輯實現的確是相對比較復雜的，整個權限系統可以相當于一個小型項目了，這個需求我大概寫了一下功能點，有需要的小伙伴可以再問我要。
五、總結
權限還是一個可簡單可復雜的系統模塊，但是還是要按照需求，進行設計。
熟悉產品體系跟需求后，提出的方案才能更貼合、更有說服力，才能真正解決問題；所以也建議，對權限系統感興趣的話，有空的時候多研究一下釘釘、飛書這類型的軟件，雖然并不能完全復用，大廠的解決方案，每個模塊甚至于每個文案內容，都凝聚著一整個技術團隊的心血，還是很值得我們學習的。
本文由 @yimi 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議