業(yè)務(wù)系統(tǒng)用戶權(quán)限設(shè)計踩過的坑!
做后臺系統(tǒng),難免會遇到用戶權(quán)限設(shè)計,而此處每個公司會根據(jù)自己的實際業(yè)務(wù)情況來劃分設(shè)計權(quán)限,尤其是成熟的電商公司,恰好前段時間做過用戶權(quán)限這的設(shè)計,今天就做一次復(fù)盤總結(jié)?。。?/p>
后臺產(chǎn)品經(jīng)理,做后臺業(yè)務(wù)系統(tǒng)的權(quán)限設(shè)計,一般會從兩個方面來考慮權(quán)限問題:一個是數(shù)據(jù)權(quán)限,還有一個是功能權(quán)限。
- 對于功能權(quán)限,會根據(jù)業(yè)務(wù)顆粒度來調(diào)整,可以細化到菜單項,也可以細化到具體的功能點。
- 而至于數(shù)據(jù)權(quán)限,每個公司會根據(jù)自己的實際業(yè)務(wù)需要來進行考慮。一般像運營、客服系統(tǒng)、采購、O2O系統(tǒng)會使用的多些;當(dāng)然公司也可以做一套共用的用戶權(quán)限,方便于管理。
一、權(quán)限設(shè)計模塊劃分
用戶權(quán)限模塊一般分為:用戶管理、模塊管理、角色管理、機構(gòu)管理、部門管理等。具體如圖:
- 用戶管理包括了新增、刪除、編輯、角色授權(quán)、禁用、啟用等;
- 模塊管理可以根據(jù)實際業(yè)務(wù)場景需要,可以管理到功能點,也可以只管理到頁面;功能點包括新增,編輯,刪除等;
- 角色管理可以分為數(shù)據(jù)角色和功能角色類型,功能點包括新增、編輯、刪除、授權(quán)權(quán)限等;
- 機構(gòu)管理對于只有一個總公司的不牽涉,可以無該模塊;但是如果有分公司、區(qū)域公司等,需要考慮該模塊,一般這塊和用戶關(guān)聯(lián),也有可能根據(jù)業(yè)務(wù)需要和數(shù)據(jù)角色有所關(guān)聯(lián);
- 部門管理某個機構(gòu)下的部門,和機構(gòu)是有所關(guān)聯(lián);但是如果是針對某一業(yè)務(wù)部門使用的系統(tǒng),可以考慮無該部門管理模塊。
二、權(quán)限設(shè)計功能點設(shè)計的注意點
1. 新增用戶時,角色授權(quán)需要授權(quán)功能權(quán)限和數(shù)據(jù)權(quán)限
- 一個用戶賬號可以關(guān)聯(lián)多個功能角色。如果所授權(quán)的功能角色有沖突,取并集。如:角色1有A模塊的新增、編輯權(quán)限;角色2有A模塊的刪除權(quán)限;那么這個用戶賬號有的權(quán)限包括了新增、編輯和刪除;因此數(shù)據(jù)權(quán)限同理。
- 數(shù)據(jù)權(quán)限授權(quán)可根據(jù)機構(gòu)、部門、不同的業(yè)務(wù)、區(qū)域等來授權(quán)數(shù)據(jù)權(quán)限;根據(jù)公司的實際業(yè)務(wù)需要來設(shè)計即可。
2. 機構(gòu)管理
- 對于機構(gòu)類型,是否要有歸屬關(guān)系等都需要根據(jù)公司的實際組織結(jié)構(gòu)和系統(tǒng)使用角色來確定;
- 該模塊的管理,是為了后期每個組織機構(gòu)賬號的方便管理來設(shè)計使用,最終還是以公司的實際業(yè)務(wù)場景來取舍;當(dāng)然上述提到的部門管理模塊也是同理。
3. 角色管理
角色類型一般會分為功能角色和數(shù)據(jù)角色:
- 功能角色顧名思義,是用戶可以操作系統(tǒng)中的哪些具體的功能點或者是頁面中所有的功能點;
- 而數(shù)據(jù)角色指的是可以看到該系統(tǒng)哪部分的數(shù)據(jù),設(shè)置是字段的限制等等;數(shù)據(jù)角色的權(quán)限劃分一般會從地區(qū)、公司機構(gòu)、部門等維度來限制。
4. 模塊管理
模塊管理新增權(quán)限時顆粒度是限制到頁面上還是是具體的功能點上,根據(jù)實際需要來決定:
- 一般對于成熟型的公司,因為業(yè)務(wù)已經(jīng)規(guī)范化,就需要具體的某一功能點;
- 而對于初創(chuàng)型公司,人員配比,業(yè)務(wù)規(guī)范性考慮,前期權(quán)限可只限制到具體的頁面上;不過考慮到后期的系統(tǒng)的擴展性問題,可以在前期的評審過程中告知研發(fā)同事,將可擴展的口先預(yù)留,防止釜底抽薪的改動發(fā)生。
總結(jié)
用戶權(quán)限看著簡單,但是牽涉到底層權(quán)限的設(shè)計,一定要調(diào)研充分。
功能權(quán)限的顆粒度確定和是否要有數(shù)據(jù)權(quán)限,以及數(shù)據(jù)權(quán)限應(yīng)該從哪一維度設(shè)計,都需要和業(yè)務(wù)溝通,充分了解各個業(yè)務(wù)部門的日常工作職責(zé)和管理。否則后期上線后不滿足業(yè)務(wù)需要再做改動是很麻煩的一件事,一旦有考慮不到的地方,就會踩坑。
因此在產(chǎn)品設(shè)計初期,就要調(diào)研盡量充分。
#專欄作家#
簡之箐(微信公眾號:簡之箐),人人都是產(chǎn)品經(jīng)理專欄作家,5年互聯(lián)網(wǎng)產(chǎn)品經(jīng)理,曾擔(dān)任醫(yī)藥產(chǎn)品經(jīng)理和電商產(chǎn)品經(jīng)理,經(jīng)歷主導(dǎo)過電商平臺的系統(tǒng)整合規(guī)劃。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 Pexels,基于 CC0 協(xié)議
功能授權(quán)采用下拉樹的方式展現(xiàn)用戶體驗不太好吧,建議角色授權(quán)最好以單獨頁面的形式展示吧
關(guān)于數(shù)據(jù)權(quán)限有些問題想問下:我們公司存在2個平級部門:銷售部、風(fēng)控部,銷售部下有多個小組?,F(xiàn)在期望的是:銷售部經(jīng)理能查看所有銷售人員的數(shù)據(jù)、銷售組長能查看自己組內(nèi)人員的數(shù)據(jù);但風(fēng)控部的所有人均能查看銷售部所有人員的數(shù)據(jù)。
也就是說,某個用戶能查看的數(shù)據(jù)不一定是自己和下級的數(shù)據(jù),而是平級部門內(nèi)所有人的數(shù)據(jù)。目前我們是這樣配置的:給某個用戶配置數(shù)據(jù)權(quán)限時,可以勾選多個組織,只要勾選,就能查看該組織成員的數(shù)據(jù)。
請問這種設(shè)計方式是否合理?是否有其他解決辦法?
具體要以公司的實際情況來設(shè)計。你描述的是屬于查看數(shù)據(jù)權(quán)限這塊,有些公司可能會按部門區(qū)分,但靈活性有限。也可以將數(shù)據(jù)分組,授權(quán)查看權(quán)限。
數(shù)據(jù)權(quán)限設(shè)計是否可以舉個例子呢?
請教下~頁面與接口的關(guān)聯(lián)關(guān)系,需要建立么?
有幾個問題:
1、數(shù)據(jù)角色是否可以理解為,如果我是一個集團公司,四川分公司的賬號關(guān)聯(lián)的數(shù)據(jù)角色,在具體用戶省市就只能看到四川的?
2、關(guān)于某一賬號有賬號列表的增刪改查的權(quán)限,那這個賬號是否可以對創(chuàng)建他的賬號進行刪除操作等?
3、模塊管理,用列表單獨列出的好處是什么?
如果給用戶配置角色后可在角色擁有的權(quán)限上再做一些權(quán)限個性化配置會不會更好?
感覺作者寫得比較籠統(tǒng),我們剛剛?cè)氲囊粋€坑,數(shù)據(jù)權(quán)限非常的復(fù)雜,而且配置起來非常繁瑣,根本不適合客戶的使用,只能是我們配置好再交給客戶,不知道作者是否有遇到這樣的問題?
暫時沒有。數(shù)據(jù)權(quán)限配置繁瑣不太清楚你指得是??我們做得配置得時候還好,有問題可以微信溝通!
每一個大的模塊,細分到最小的功能就是增刪改查對吧?增要設(shè)置能增加什么數(shù)據(jù),不能增加什么數(shù)據(jù),平臺上有很多的數(shù)據(jù)范圍,然后刪改查也一樣,是這樣嗎?
平臺端預(yù)設(shè)一些角色給用戶使用,and 客戶端也支持自定義授權(quán),and 權(quán)限只見要有并集也有差集~