編輯導(dǎo)語：權(quán)限管理是所有后臺系統(tǒng)的都會涉及的一個重要組成部分，在管理后臺中對于權(quán)限的標(biāo)準(zhǔn)需要準(zhǔn)確地把握，并且根據(jù)各種需求進(jìn)行設(shè)計(jì)，達(dá)到最終目的；本文作者分享了關(guān)于權(quán)限系統(tǒng)的設(shè)計(jì)，我們一起來了解一下。

寫在前面，為什么要寫權(quán)限系統(tǒng)的設(shè)計(jì)呢？

因?yàn)槊恳粋€項(xiàng)目，有管理后臺，90%會有權(quán)限管理。在我自己歷史以往的項(xiàng)目，其實(shí)對于權(quán)限始終是一個相對表面的認(rèn)知。直到我去年研究了釘釘?shù)墓芾硐到y(tǒng)、以及今年做了產(chǎn)品重構(gòu)，讓我對權(quán)限有了一個深度的認(rèn)知。

一、權(quán)限是什么

我對于權(quán)限的理解，一開始是一個賬號，管理著后臺的某些模塊；這個時候，權(quán)限很簡單，他是一個賬號列表，可以編輯賬號信息以及設(shè)置賬號查看菜單，即賬號yimi可以管理訂單列表。

后面接了一些門店端的項(xiàng)目，在區(qū)分菜單查看上，也加上了數(shù)據(jù)區(qū)分，即賬號yimi可以管理**門店的訂單列表數(shù)據(jù)；上面這兩項(xiàng)，我覺得可以基本可以支持中小型的項(xiàng)目是足夠使用的。

然后更深一個層級的，當(dāng)你接了一個大型的項(xiàng)目，你的后臺管理員是一個集團(tuán)的人，或者是上百人，這個時候一個賬號區(qū)分是遠(yuǎn)遠(yuǎn)不能滿足的；也延伸了在做CRM系統(tǒng)的時候研究了釘釘?shù)倪壿嫞瑱?quán)限不僅僅是開通一個賬號（僅有賬號+密碼）這么簡單，權(quán)限是對于不同部門的人的管理。那么這個時候會將賬號跟菜單權(quán)限獨(dú)立開來。

賬號即部門下面的某個成員，可通過手機(jī)號作為唯一標(biāo)識。菜單權(quán)限按照不同角色去區(qū)分，財(cái)務(wù)有擁有什么菜單、采購擁有哪幾個菜單。

聽到這里，權(quán)限就涉及了：部門、成員、角色、菜單。那我會覺得，權(quán)限可復(fù)雜可簡化，其實(shí)無非是人管事。那么不同的權(quán)限設(shè)計(jì)會有什么區(qū)別呢？

二、最小權(quán)限設(shè)計(jì)

最小的權(quán)限設(shè)計(jì)，如下圖所示，有登錄賬號、密碼、以及菜單勾選。其實(shí)還有個XS版本的，即僅有賬號，無菜單權(quán)限分隔。

最小權(quán)限設(shè)計(jì)-圖示1

那什么情況會使用這種最小的權(quán)限設(shè)計(jì)，我個人的理解是小型的項(xiàng)目，或者說客戶內(nèi)部運(yùn)營結(jié)構(gòu)相對簡單；這個時候需要注意幾點(diǎn)，第一個擁有整個菜單即擁有菜單所有操作，第二點(diǎn)是沒有數(shù)據(jù)隔離，即每個擁有菜單權(quán)限的管理員查看內(nèi)容一致。

對于需求梳理如下所示：

三、中型項(xiàng)目權(quán)限設(shè)計(jì)

中型大小的項(xiàng)目，類似于多門店、或者是負(fù)責(zé)角色不同，同個模塊需要查看不同數(shù)據(jù)、進(jìn)行不同的操作。如下圖所示：

中型項(xiàng)目權(quán)限設(shè)計(jì)-編輯管理員-圖示2

中型項(xiàng)目權(quán)限設(shè)計(jì)-編輯角色-圖示3

相對于最小權(quán)限設(shè)計(jì)，你可以理解為菜單+賬號的拆分，并且在菜單的基礎(chǔ)上，擴(kuò)展了操作權(quán)限；也通過角色的區(qū)分，擴(kuò)展了數(shù)據(jù)權(quán)限，此時的權(quán)限=菜單權(quán)限+操作權(quán)限+數(shù)據(jù)權(quán)限。

相對于上一個會復(fù)雜很多，為什么我前面會說建議按照產(chǎn)品體系，再去做這一套中型的權(quán)限系統(tǒng)？

一方面，眾所周知是由于開發(fā)工作量以及難度，對應(yīng)報(bào)價會高；另一方面是，這個的復(fù)雜度也提高了他使用難度，如果是沒有這種業(yè)務(wù)情況需求(類似于多門店、或者是負(fù)責(zé)角色不同)，就不建議用了。

最后也是最重要一個方面，針對不可持續(xù)性產(chǎn)品的說明：不斷向軟件增加功能，是不可持續(xù)的。增加復(fù)雜性意味著遺留代碼越來越沉重，導(dǎo)致產(chǎn)品維護(hù)成本越來越高，而且也越來越難以靈活應(yīng)對市場變化；這個道理我想不僅僅適用于用戶前端，對管理后臺也同樣適用。

對應(yīng)的需求梳理如下：

四、大型項(xiàng)目權(quán)限設(shè)計(jì)

大型項(xiàng)目的權(quán)限，最大的一個變化，是有部門組織架構(gòu)，不同部門的人使用系統(tǒng)，即將管理員管理拆解為部門管理+成員管理，但是又不僅僅于此。

在一個接入審批的系統(tǒng)、或者CRM中，往往數(shù)據(jù)是相對獨(dú)立的，可以按照部門組織架構(gòu)數(shù)，去區(qū)分?jǐn)?shù)據(jù)的權(quán)限。如下圖所示：

大型項(xiàng)目權(quán)限設(shè)計(jì)-部門組織架構(gòu)-圖示4

如果說，中型項(xiàng)目的數(shù)據(jù)權(quán)限是按照門店或者區(qū)域劃分，那么部門樹則是數(shù)據(jù)權(quán)限的另一個維度。按照創(chuàng)建者所在部門，將這條數(shù)據(jù)歸屬于某個成員某個部門（此處還要考慮成員存在多部門的情況），同個部門間數(shù)據(jù)獨(dú)立，而主管可以查看所有人的數(shù)據(jù)。

則這個數(shù)據(jù)劃分，并不適用于后臺管理的所有列表，例如用戶列表、訂單列表此類數(shù)據(jù)來源并非后臺的，或者是一些文案管理的列表，并沒有必要做數(shù)據(jù)的區(qū)分；所以在開發(fā)的時候，還需要在每個列表列出說明，是否使用；這個邏輯實(shí)現(xiàn)的確是相對比較復(fù)雜的，整個權(quán)限系統(tǒng)可以相當(dāng)于一個小型項(xiàng)目了，這個需求我大概寫了一下功能點(diǎn)，有需要的小伙伴可以再問我要。

五、總結(jié)

權(quán)限還是一個可簡單可復(fù)雜的系統(tǒng)模塊，但是還是要按照需求，進(jìn)行設(shè)計(jì)。

熟悉產(chǎn)品體系跟需求后，提出的方案才能更貼合、更有說服力，才能真正解決問題；所以也建議，對權(quán)限系統(tǒng)感興趣的話，有空的時候多研究一下釘釘、飛書這類型的軟件，雖然并不能完全復(fù)用，大廠的解決方案，每個模塊甚至于每個文案內(nèi)容，都凝聚著一整個技術(shù)團(tuán)隊(duì)的心血，還是很值得我們學(xué)習(xí)的。

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

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