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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于需求梳理如下所示：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、總結(jié)

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

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

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

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