一個案例,三個角色,簡單說下B端產(chǎn)品的權(quán)限設(shè)計
理論性的內(nèi)容我個人也是不擅長,所以就簡單的說說權(quán)限設(shè)計,忘同行不吝指教。
入行以來也接觸過一些B端產(chǎn)品,這些產(chǎn)品之中權(quán)限管理是重中之重,權(quán)限管理不僅僅是整個系統(tǒng)的一個小小的模塊,它一直貫穿整個系統(tǒng),從登陸到操作到最后的登出。說它相當(dāng)?shù)膹?fù)雜真不為過。
對于權(quán)限,如果從控制力來分的話,可以分為功能級權(quán)限和數(shù)據(jù)級權(quán)限。從控制方向來分的話又可以分為從系統(tǒng)獲取數(shù)據(jù)和向系統(tǒng)提交數(shù)據(jù)。一般來說,權(quán)限管理無非是圍繞著用戶,角色和資源三個方面來進(jìn)行權(quán)限管理操作。
首先,設(shè)計的時候要面向開發(fā)人員友好,讓他們能夠很好的理解需求和流程。不至于因?yàn)闄?quán)限的問題影響開發(fā)。實(shí)際上,一般權(quán)限設(shè)計都會讓在最后進(jìn)行實(shí)現(xiàn)。因?yàn)榍捌诳紤]太多的權(quán)限會嚴(yán)重影響產(chǎn)品開發(fā)的流暢性。當(dāng)然最重要的還是面向用戶友好,畢竟產(chǎn)品的使用者是用戶,所以邏輯清晰,結(jié)構(gòu)完整的權(quán)限體系就顯得越發(fā)重要。
舉例:
派單系統(tǒng)
業(yè)務(wù):系統(tǒng)的客戶在前臺提交一個訂單,后臺對應(yīng)的接收到該訂單并分派給業(yè)務(wù)員給客戶完成服務(wù)。
角色:
- 老板—查看報表和人員角色修改
- 業(yè)務(wù)經(jīng)理—1.業(yè)務(wù)管理(接單后對訂單進(jìn)行派發(fā))。2.對業(yè)務(wù)員進(jìn)行行政管理(增刪改查)
- 業(yè)務(wù)員—接單處理,反饋訂單信息
第一種情況,簡單的完成權(quán)限設(shè)計
整理一下,從業(yè)務(wù)流程來看,涉及到的角色其實(shí)就是前臺的用戶,業(yè)務(wù)經(jīng)理和業(yè)務(wù)員。
然后從功能來看:
這樣子系統(tǒng)的架構(gòu)就能夠比較清晰的進(jìn)行設(shè)計了。
菜單的總體結(jié)構(gòu)如下:
1 訂單管理
- 1.1未處理訂單
- 1.2已派發(fā)訂單
- 1.3已處理訂單
- 1.4處理下派訂單
- 1.5提交已完成的下派訂單
2 系統(tǒng)設(shè)置
- 2.1密碼修改
- 2.2個人信息設(shè)置
3員工管理
- 3.1查看下級員工信息
- 3.2修改下級員工信息
- 3.3員工角色設(shè)置
4 報表管理
- 4.1查看報表
通過登錄的時候對賬號類型進(jìn)行判斷或者不同角色通過不同的登錄頁面進(jìn)入相應(yīng)的系統(tǒng)頁面
老板的菜單顯示為:
2系統(tǒng)設(shè)置
- 2.1密碼修改
- 2.2個人信息設(shè)置
3員工管理
- 3.1查看員工信息
- 3.2修改員工信息
- 3.3員工角色設(shè)置
4報表管理
- 4.1查看報表
業(yè)務(wù)經(jīng)理的菜單顯示為:
1訂單管理
- 1.1未處理訂單
- 1.2已派發(fā)訂單
- 1.3已處理訂單
2系統(tǒng)設(shè)置
- 2.1密碼修改
- 2.2個人信息設(shè)置
3員工管理
- 3.1查看下級員工信息
- 3.2修改下級員工信息
業(yè)務(wù)員的菜單顯示為:
1訂單管理
- 1.4處理下派訂單
- 1.5提交已完成的下派訂單
2系統(tǒng)設(shè)置
- 2.1密碼修改
- 2.2個人信息設(shè)置
這是第一種簡單的權(quán)限設(shè)計思路。但是,如果,如果boss對系統(tǒng)的擴(kuò)展性要求較高,而非一個過渡性的系統(tǒng)。那邊就需要改變思路。重新設(shè)計系統(tǒng)了。
第二種情況,完成更加靈活且復(fù)雜的權(quán)限設(shè)計
在這種情況下就要考慮下現(xiàn)有的各種角色以及各種角色對應(yīng)的操作是否是可修改的。未來是否會變更。
比如查看報表的權(quán)限后期業(yè)務(wù)經(jīng)理業(yè)務(wù)查看?隨著業(yè)務(wù)的擴(kuò)大,業(yè)務(wù)經(jīng)理是否變成多個?boss是否能夠禁止業(yè)務(wù)經(jīng)理的派單權(quán)限?在這種情況下,各種權(quán)限其實(shí)是變成可配置的了。
這個時候就需要轉(zhuǎn)化思路了。首先將所有的功能全部抽離并羅列出來。如下就是簡略的功能列表
其中,boss角色一開始就具備所有的功能。他可以創(chuàng)建下級角色—業(yè)務(wù)經(jīng)理,創(chuàng)建的同時給業(yè)務(wù)經(jīng)理這個角色分配權(quán)限(實(shí)現(xiàn)方式可以類似技能樹0.0)。也可以創(chuàng)建一個歸屬業(yè)務(wù)經(jīng)理的業(yè)務(wù)員。這樣,權(quán)限,角色都是可進(jìn)行靈活配置,擴(kuò)展性和實(shí)用性也更強(qiáng)。
Step1:角色管理-添加角色
在這一步中進(jìn)行角色的添加并分配權(quán)限。
Step2:用戶管理-添加用戶
在這個步驟中重點(diǎn)是給添加的用戶分配角色(即權(quán)限)
這樣子就將角色,用戶,權(quán)限分離開,管理也就更加的方便和靈活了。
但是值得注意的是,這三者之間的關(guān)聯(lián)性,對某一個的刪除,修改等操作是否會對其他部分產(chǎn)生影響。這個就需要產(chǎn)品經(jīng)理在后面進(jìn)行慢慢的梳理了。
如有錯誤,歡迎指正,謝謝。
本文由 @阿拉士奇 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
或者,將角色在設(shè)計時直接固化,如業(yè)務(wù)經(jīng)理、業(yè)務(wù)員等在流程中必須有的功能點(diǎn),直接就固化了,不需要通過權(quán)限菜單去配置,后續(xù)就需要將不同的員工分配為業(yè)務(wù)經(jīng)理/業(yè)務(wù)員就可以了
在功能權(quán)限設(shè)計上,應(yīng)該結(jié)合流程節(jié)點(diǎn),對流程從開始到結(jié)束所必須經(jīng)歷的環(huán)節(jié)所涉及到功能點(diǎn),在權(quán)限設(shè)置時應(yīng)以流程導(dǎo)向的方向進(jìn)行設(shè)置,避免因角色權(quán)限設(shè)置上的遺漏,導(dǎo)到流程走不下去。比如:上述示例中,假如因?yàn)檫z漏,所有角色都沒配“分派訂單”這個功能點(diǎn)的權(quán)限,流程就走不下去了
寫的稍淺,如果有2個負(fù)責(zé)人,分管不同部門如何設(shè)置?人員有跨組織管理如何解決?這只解決了功能權(quán)限的設(shè)置,沒解決數(shù)據(jù)權(quán)限的分配設(shè)置
同意
能夠看出人群組織的奧秘
1、如果這個業(yè)務(wù)經(jīng)理也擁有了【角色設(shè)置】&【權(quán)限設(shè)置】的權(quán)限,那這個業(yè)務(wù)經(jīng)理是不是可以直接修改boss的權(quán)限,直接把boss干掉?
2、當(dāng)這個業(yè)務(wù)經(jīng)理設(shè)置了子賬號,二級業(yè)務(wù)經(jīng)理設(shè)置了權(quán)限,那后面如果業(yè)務(wù)經(jīng)理的賬號和權(quán)限被修改了,或者被拿掉了;那這個被他設(shè)置的子賬號,怎么辦
反感角色 提倡分組
謝謝,下次按分組的情況進(jìn)行考慮??纯茨姆N方式更加實(shí)用當(dāng)前項(xiàng)目,
為什么反感角色呢,個人感覺角色更靈活,對功能的拆分重組更適合,小白一枚,望解惑
角色的用法不太適應(yīng)于流程性很強(qiáng)的應(yīng)用,流程性很強(qiáng)的應(yīng)用產(chǎn)品,更適合用“身份”來設(shè)計,如電商平臺的買家身份和賣家身份,身份就決定了這兩者進(jìn)行流程分工時的責(zé)權(quán)利
身份這里希望多說一點(diǎn),沒理解
確實(shí)不錯
謝謝