2分鐘快速瞭解企業用戶權限

做者|小菜

Hello，你們好，今天給你們講講用戶權限。可能有人會以爲用戶權限有什麼好講的，市面上通用的RBAC權限模型多了去了，還須要你個小菜鳥來說。說這話的，可能沒看到我背上紋的小豬佩奇，信不信我這個社會人給你來點狠的——求着你看完。咳咳…嚴肅嚴肅，相信我，看完你會有收穫的，沒有收穫的來砍我，千萬不要砍需求。

1、什麼是權限

不論是B端產品仍是C端產品，權限基本都會出現。常見的好比說知乎、簡書等內容類產品，你只有登陸才能評論、點贊，不登陸你只能瀏覽；再好比知識付費或視頻類產品中，你只有付費了才能完整查看專欄裏的內容，不付費你只能試看幾分鐘；再複雜一點的，就是企業級產品中，各部門，各崗位，不一樣用戶能操做的權限都不盡相同。

百度百科中對權限的解釋是：「爲了保證職責的有效履行，任職者必須具有的，對某事項進行決策的範圍和程度」。有點拗口，用個人話來理解就是「能不能幹」。想污了的同窗請遵照交通規則，繫好安全帶，謹防疲勞駕駛。

權限按類型劃分爲三類：頁面權限、操做權限和數據權限。頁面權限很好理解就是能不能進這個頁面；操做權限就是對於這個頁面中的增刪改查按鈕以及其餘按鈕能不能操做；至於數據權限，就是不一樣用戶進來看到的數據不同，好比說研發部門只能看到研發部的數據，產品部只能看到產品部的數據。

用戶權限其實是控制用戶可用的功能點。換句話說，權限的最小單元是功能點。若是把一個產品或者系統比做一幢房子，那功能點就是房子裏的一個個上了鎖的房間，用戶只有拿到相應的鑰匙纔可使用產品。

瞭解以上信息後，咱們開始以產品化的思惟去設計這個產品，根據MVP原理先推出個用戶權限1.0版本。

2、用戶權限V1.0

最簡單的用戶權限，就是把用戶和功能點直接關聯起來。

經過這種方式咱們能夠很靈活的控制用戶權限。用戶想要什麼權限，咱們就把對應的功能點分配給用戶，用戶拿着對應的鑰匙就能夠打開一個個房間。

這種權限模型在實際應用場景中，每每適合功能點較少的產品，好比說只有登陸限制、付費限制等。若是一個產品的功能點過多，那麼這種模型就會給用戶帶來很是繁瑣的操做。

想象這樣一個場景，假設你的一幢5層樓酒店有50間上了鎖的房間，每一層都是不一樣的×××員負責房間衛生。你每次都要從一堆鑰匙中找到對應樓層房間的鑰匙，交給對應樓層的×××員，光是找找就很是麻煩了。若是房間再多一些，你的操做就會被幾何倍數放大，到時候你就會崩潰了。

難道就沒有更聰明的方法了嗎？

天然是有的，基於這個需求咱們對原有的權限模型進行迭代。

3、用戶權限V2.0

做爲酒店負責人，我能夠把一樓全部房間鑰匙串在一塊兒，交給一樓的×××員；二樓的串在一塊兒，交給二樓的×××員；後面的依次類推，這樣我就不須要每次那麼費勁地從一堆鑰匙裏去找了。

咱們把一些功能點的集合叫作角色，再把相應的角色分配給用戶，從而讓用戶擁有相應的功能權限。這種模型就是市面上常見的RBAC權限模型。

這種權限模型在實際應用場景中，適合功能點較多但用戶規模不大的產品。功能點較少，用V1.0版本的更方便更靈活，那爲何說適合用戶規模不大呢？

再來想象一個場景，仍是那個酒店，如今每層×××員投訴你壓榨他們勞動力，工做七天，整年無休，太累了。爲了平息衆怒，你決定每層都由10個×××員來負責房間衛生，這樣一來你就要分配50次鑰匙串。若是每層20個呢，50個呢，100個呢，你立刻又會吐槽了，TMD破產品，把這個產品經理給我拖出去祭天。

別急別急，立刻迭代。

4、用戶權限V3.0

爲了減小你的工做量，你決定把1樓的全部鑰匙串都放在1樓×××員工做室，2樓的放在2樓×××員工做室…依次類推（固然每一個樓層的×××員只能進本樓層的工做室）。這樣只要是某個樓層工做室的×××員，均可以快速拿到負責區域的鑰匙串，而再也不須要你耗費精力去分配了。

咱們把擁有相同權限的用戶進行組合，叫作用戶組，以後只要對用戶組分配角色就行了，這樣一來，只要是這個用戶組下的用戶就具有了相同的權限，減小用戶繁瑣的配置過程。

這種權限模型適合功能點比較多、用戶規模比較大，並且產品單一的狀況。爲何要強調產品比較單一呢？

好咱們再來想象一下…爲何我要想，再想寶寶就要有脾氣了，我刀呢。

OKOKOK，Anyway，我講一個真實的案例。

去年我接手過一個湖北某市的項目，整個項目包含20多個教育類應用，給整個城市下的1000多所學校上百萬學生、教師、家長使用。實施同窗在配權限的時候直接崩潰了，每所學校20多個應用都要配對應的角色，而每次配的角色仍是如出一轍。你能夠算一算，大概要操做多少次，反正個人手指頭是不夠用的。

同窗同窗，不要激動不要激動，立刻迭代，如今能夠把刀拿走了嗎！

5、用戶權限V4.0

咱們把不一樣產品下的角色進行組合，叫作角色組，經過把角色組賦予用戶組，達到快速配置權限的目的。

這種權限模型適合用戶規模較大，產品線衆多，功能點較多的狀況。放心放心，我就再也不繼續假設，再假設下去估計刀就砍下來了。

6、總結

分析了那麼多，其實你們能夠發現，永遠不存在通用的權限模型，只有最合適的，作產品也同樣，不基於用戶需求出發，隨意套用公式模板，帶來的危害是不可思議的。

細心的同窗應該會發現，哪怕多麼複雜的場景，用戶權限V1.0版本均可以解決，無非用戶須要多操做罷了。可是咱們作產品的，永遠是把複雜的留給本身，簡單的留給用戶，因此請相信數瀾，這一直都是咱們的最低產出標準。

最後，再想象一個場景，實際應用中，同一個部門（用戶組）不一樣人員權限是不同的，好比說產品總監和普通產品經理的權限就會不同，怎麼解決？