国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

用戶權(quán)限管理是平臺類產(chǎn)品的基礎，怎樣設計平臺的用戶權(quán)限對后續(xù)的場景和拓展至關重要。本文通過簡單的例子總結(jié)幾點“用戶角色權(quán)限”設計思路供大家參考。

我是在2016年的一個B端管理項目中第一次接觸到用戶權(quán)限設計，因為當時是測試+需求分析的職責，所以只是把這里面的功能梳理明白，知道怎么用，并沒有深入思考。

轉(zhuǎn)崗產(chǎn)品之后，經(jīng)常會在社群里看到有人問類似于用戶管理怎么做，權(quán)限設置怎么控之類的問題，這類問題幾句話也說不明白。

所以今天把自己對這部分的理解整體梳理出來，既能作為部門新入職同事的培訓材料，同時也希望對讀到這篇文章的你帶來一點幫助。

01 為什么進行用戶權(quán)限設計？

其實用戶權(quán)限設計對于C端產(chǎn)品也經(jīng)常遇到，比如普通用戶、VIP用戶可能看到的功能就不一樣，或者同樣的頁面看到的數(shù)據(jù)也不一樣。不過更廣泛的應用還是在B端產(chǎn)品，或者C端產(chǎn)品的管理后臺（平臺管理端）

我們以B端產(chǎn)品為例，平臺提供了200個功能菜單，500個功能按鈕，但是使用者的身份不同，或使用目的不同，有的人可能只用到其中的一小部分功能。

或者對于企業(yè)來說，不同人員的分工不同，相同部門但不同級別的人員可操作權(quán)限不同、可查看的數(shù)據(jù)不同等等，這些實際的使用場景都最終指向了產(chǎn)品中靈活的、可自定義配置的權(quán)限管理功能。

這樣說可能比較寬泛，我們代入一個實際的場景（能理解的可以直接跳過看下一小節(jié)）。

一家兩百人的互聯(lián)網(wǎng)企業(yè)，分為研發(fā)部、銷售部、財務部、人事部，這家企業(yè)采購了一個數(shù)字化辦公軟件。

• 人事部用它對企業(yè)的人員信息、招聘信息、員工的入職、轉(zhuǎn)正、調(diào)崗、離職等進行管理；
• 財務部用它制定公司的成本預算、記賬報賬、核算并發(fā)放工資、歸檔發(fā)票等；
• 而全體員工也都使用平臺進行OA辦公，線上流程發(fā)起及審批；
• 企業(yè)高管則通過平臺的各類統(tǒng)計功能監(jiān)控、查看企業(yè)的日常經(jīng)營數(shù)據(jù)。

在這個場景中，平臺的功能頁面可能有幾百個，但是針對不同的部門人員，登錄之后看到的功能菜單是不盡相同的，或者同一個菜單的操作權(quán)限也是有差異的。

• 比如【入職信息查詢】頁面，hr和行政都能查看，但是hr有【入職】的按鈕，行政卻沒有；
• 比如財務部的財務專員A和B，一個負責研發(fā)部預算，一個負責銷售部預算，雖然他們都能訪問預算功能，但看到的數(shù)據(jù)也是不一樣的；
• 而C作為財務部總監(jiān)，全公司的預算數(shù)據(jù)都可以看到。

以上提到的場景都是實際應用中最常見的，我們一起來看看如何進行設計吧

02 用戶權(quán)限設計的幾個關鍵詞

我習慣于把權(quán)限分為以下幾類：

1）頁面權(quán)限

即功能菜單的權(quán)限，以一級菜單->二級菜單->三級菜單->四級菜單的級別依次呈樹形排列。勾選上的菜單即可訪問，同時被選擇菜單的上級也默認被選擇（好比沒有單元門，你怎么找到家門？）。

2）按鈕權(quán)限

按鈕通常分為“增、刪、改、查”四大類，增的類型有很多，涉及的業(yè)務面也很廣，比如新增員工信息、新增預算信息、新增發(fā)票信息等，都屬于每個頁面權(quán)限下的“增”。對于四類操作，一定不是擁有這個頁面就一定擁有所有操作權(quán)限，因為很多人可能只有查的權(quán)限。所以要做好權(quán)限控制，一定要做按鈕的控制。

以上兩部分又可統(tǒng)稱為功能權(quán)限。

同時我準備了兩個常見的功能權(quán)限配置樣式，拋磚引玉，希望能給你帶來一點思路：

方案1

方案2

3）數(shù)據(jù)權(quán)限

最常見的數(shù)據(jù)控制手段是基于“組織架構(gòu)樹”，組織架構(gòu)（部門/分支機構(gòu)）中的上級可以查看本級及下級的所有數(shù)據(jù)，或者可以指定某個組織的數(shù)據(jù)。

4）應用權(quán)限

這是后續(xù)衍伸出來的功能組集合。我們可以把一個功能組抽象為一個應用。比如按照上面的例子，可以把產(chǎn)品內(nèi)的功能合并成以下幾類：包含了人事服務、財務服務、辦公服務、假勤服務、數(shù)據(jù)服務、客戶服務等幾大應用。我們可以先整體為這家企業(yè)賦予某些應用的權(quán)限，再在這些應用下為用戶分配不同的功能權(quán)限。

當然，如果我們把它定義為頁面權(quán)限中的一級菜單，也是可以的，只不過當平臺內(nèi)的功能越來越多時，一級菜單的個數(shù)也會很多，菜單的級別也會很深。所以再單獨抽象一個新的功能組概念，不僅從理解上更清晰，看起來也高大上了一些~而且這些功能組后續(xù)還能作為增值服務為B端客戶設置開通、付費等衍伸場景。

除了權(quán)限的分類，為了最終達成設計目標，我們還會引入【角色】的概念。

1）角色

角色是上述幾類權(quán)限的集合

我所理解角色的設計目標是：為了解耦，為了可批量配置化（具體關系請看第三小節(jié)）。

• 比如財務專員角色，包含了10個頁面，25個按鈕，數(shù)據(jù)為只能看到研發(fā)部；
• 人事專員角色，包含了20個頁面，15個按鈕，數(shù)據(jù)為全公司。

2）用戶

用戶是平臺的使用者，用戶登錄之后能夠看到的，能夠操作的數(shù)據(jù)，都來自于我們?yōu)檫@個用戶賦予了哪些角色，這些角色中擁有哪些權(quán)限。

• 比如張三和李四都是財務專員角色，就可以在10個頁面中看到研發(fā)部的相關數(shù)據(jù)，并進行25種操作；
• 比如王五和趙六是人事專員角色，就可以在20個頁面中看到全公司的相關數(shù)據(jù)，并進行15種操作。

當然，如果張三升職了，變成了統(tǒng)管財務和人事的負責人（財務主管），那么我們可以為張三同時賦予兩個角色，張三的功能權(quán)限和數(shù)據(jù)權(quán)限就變成了這兩個角色的“并集”。

（請自覺忽略我的“靈魂畫筆”）

03 基本的設計關系

通過【角色】將各類權(quán)限匯集起來，批量賦予每個【用戶】，再通過組織架構(gòu)將每個用戶的數(shù)據(jù)權(quán)限進行篩選。

最終功能權(quán)限和數(shù)據(jù)權(quán)限結(jié)合，呈現(xiàn)給用戶。

組合的方式也有兩種，我們可以根據(jù)自己產(chǎn)品的實際情況進行選擇。

方式1（功能權(quán)限+數(shù)據(jù)權(quán)限=角色->用戶）

方式2（功能權(quán)限->角色 + 數(shù)據(jù)權(quán)限 =>用戶）

無論哪種方式，都可以保證設計的關聯(lián)性和清晰度，還能在修改時減少操作環(huán)節(jié)。

比如方式1中，企業(yè)現(xiàn)在有10個人擁有財務專員的角色，如果要給財務專員增加15個新的功能，并增加對銷售部的數(shù)據(jù)管理范圍，我們只需要針對【財務專員】這個角色進行一次修改即可生效。

04 進階的設計方法

1. 對于企業(yè)多級部門的數(shù)據(jù)權(quán)限配置

上面寫到的是一些簡單的場景，實際應用中，會有很多企業(yè)存在多級部門的情況，比如研發(fā)部下分為研發(fā)一部、研發(fā)二部，研發(fā)一部又分為產(chǎn)品部、技術部。

對于擁有相同功能權(quán)限的張三和李四，在數(shù)據(jù)權(quán)限上張三需要查看研發(fā)一部所有數(shù)據(jù)，而李四只能查看研發(fā)一部本級的數(shù)據(jù)。

所以后期我們可以在數(shù)據(jù)權(quán)限設置時增加對組織架構(gòu)的設定的三種類型：

1. 只看本級
2. 可查看本級及下級
3. 指定某個級別（部門/機構(gòu)）

2. 初始化角色（預制角色）

用戶權(quán)限設置完成后，我們還需要考慮新用戶的預制角色，我們不能讓用戶從零開始一點點配置，因為這樣不僅費時費力，大部分用戶也配不明白，即便平臺提供了培訓手冊或視頻，但是又有多少用戶會認真看呢？

所以不同的平臺對于新入駐的用戶，要預制一套相對常規(guī)的規(guī)則。當然不僅是預制角色，其他的業(yè)務功能也需要按需預制，畢竟降低用戶的理解難度和操作難度，也是提高入駐率的關鍵方式。

后續(xù)我也會單獨整理我們可以采用哪些方法降低B端用戶的上手難度和準入門檻，歡迎持續(xù)關注~

3. 有些功能需要單獨維護訪問權(quán)限

有些場景不太好通過平臺級的設計來解決，建議還是針對具體的場景進行特色化設計。

比如企業(yè)的合同管理功能，人事一部只能看到員工的勞務合同，人事二部只能看到員工的保密協(xié)議。這種按業(yè)務類型區(qū)分的數(shù)據(jù)分類，參照上文的設計模式就不好實現(xiàn)，所以只能在合同管理功能中單獨增加以類型區(qū)分的數(shù)據(jù)篩選條件。

05 需要強調(diào)的兩件事

1. 盡量不要把特色化改動直接掛到“用戶”上

即便遇到一些偶現(xiàn)的用戶權(quán)限特殊處理，也盡量采用對角色的新增和配置形成權(quán)限集合后，再賦予用戶，而不是在用戶上直接進行修改。

2. 在最終測試驗證環(huán)境，一定不要只使用【超級管理員】操作

因為超管一般不會出問題，我們需要使用新維護的角色，代入用戶的實際使用場景，對平臺的功能進行全流程冒煙測試，在這個過程中才能夠發(fā)現(xiàn)更多的隱藏問題。

以上就是今天對用戶權(quán)限的設計總結(jié)。

06 寫在最后

設計思路是一回事，具體的解決方案又是另一回事，希望今天的分享能夠為你帶來一些幫助。

權(quán)限設置在后續(xù)的工作中和實際場景連接后，會演變出非常多的可能性，所以需要我們結(jié)合自身團隊的訴求，產(chǎn)品的目標和現(xiàn)狀，和研發(fā)人員一起討論出更合理的設計方案。