數(shù)據(jù)型產(chǎn)品的用戶管理相較于其他互聯(lián)網(wǎng)產(chǎn)品的來(lái)說(shuō)更加復(fù)雜，本文作者分析了用戶管理的邏輯，并且總結(jié)了自身經(jīng)驗(yàn)，給數(shù)據(jù)型產(chǎn)品經(jīng)理們整理了以下幾點(diǎn)建議。

隨著近年來(lái)大數(shù)據(jù)、人工智能、云計(jì)算等新興技術(shù)的火熱及逐步成熟，數(shù)據(jù)的重要性再次引起了人們的重視，從底層的核心數(shù)據(jù)庫(kù)，到中間層的數(shù)據(jù)計(jì)算及數(shù)據(jù)服務(wù)，以至于頂層的數(shù)據(jù)調(diào)用，數(shù)據(jù)型產(chǎn)品層出不窮。

與以往IT時(shí)代相比，DT時(shí)代的產(chǎn)品不僅業(yè)務(wù)邏輯更多，而且數(shù)據(jù)資源的管控要求更加嚴(yán)格，數(shù)據(jù)資產(chǎn)的變現(xiàn)是每個(gè)企業(yè)都在謀求的發(fā)展之路，因此，關(guān)于數(shù)據(jù)型產(chǎn)品的用戶管理，往往比之前的互聯(lián)網(wǎng)產(chǎn)品更為復(fù)雜，想要做好，實(shí)屬不易。

用戶管理類似于一個(gè)系統(tǒng)的基礎(chǔ)設(shè)施建設(shè)，重要程度雖不及其他核心功能，但卻是必不可少的其中一環(huán)，而且隨著產(chǎn)品內(nèi)容和邏輯的增多，用戶管理發(fā)揮的價(jià)值會(huì)日漸體現(xiàn)出來(lái)。本文以我做過(guò)的一個(gè)數(shù)據(jù)產(chǎn)品為例，淺析其中用戶管理的邏輯和踩過(guò)的坑，以供參考。

用戶管理三大模塊

由于公司有統(tǒng)一的域庫(kù)存儲(chǔ)用戶信息，包括入職離職人員的信息更新，因此我們此處的用戶管理是在已有用戶群（并且可實(shí)時(shí)同步數(shù)據(jù)）的基礎(chǔ)上進(jìn)行角色權(quán)限的把控。此模塊架構(gòu)如下：

整個(gè)模塊為用戶管理，下分三塊分別是：

1. 部門組織架構(gòu)：所有部門人員信息的在線展示以及對(duì)應(yīng)的人員列表，此處同步公司域庫(kù)數(shù)據(jù)，附加了當(dāng)前在線狀態(tài)的顯示；
2. 角色權(quán)限管理：此處分為角色組的建立以及對(duì)應(yīng)權(quán)限的把控，角色組以及所屬成員按需創(chuàng)建和添加，建完之后對(duì)應(yīng)做權(quán)限的控制，包含功能權(quán)限、資源權(quán)限、數(shù)據(jù)權(quán)限、集成系統(tǒng)的訪問(wèn)權(quán)限；
3. 權(quán)限申請(qǐng)管理：此處是針對(duì)權(quán)限管控后，用戶對(duì)無(wú)權(quán)限資源進(jìn)行的權(quán)限申請(qǐng)?zhí)幚硪约皩?duì)應(yīng)的權(quán)限賦予操作（權(quán)限批復(fù)結(jié)果會(huì)自動(dòng)生成消息通知，與公告消息相通）。

如何做好權(quán)限管理

上述組織架構(gòu)和權(quán)限申請(qǐng)部分基本很容易理解，邏輯相對(duì)復(fù)雜一些的當(dāng)屬角色權(quán)限管理這部分，先看一張關(guān)系圖：

做好權(quán)限管理有以下幾個(gè)重點(diǎn)：

1. 人員組成要靈活

這部分的人員組成不一定是按照崗位角色來(lái)的，有可能是跨部門跨崗位形成的自定義角色組，因此不能直接套用之前的崗位角色，需要可以創(chuàng)建新的角色組，當(dāng)然角色組多了還可以給角色組分大類，以便更清晰一些。

2. 權(quán)限覆蓋要全面

權(quán)限常規(guī)來(lái)說(shuō)可以分為功能權(quán)限、數(shù)據(jù)權(quán)限、資源權(quán)限，當(dāng)然根據(jù)產(chǎn)品不同也可能有更多的權(quán)限分類。大到每個(gè)頂部導(dǎo)航模塊，小到頁(yè)面上每個(gè)功能按鈕，都屬于權(quán)限的范圍。與此同時(shí)資源內(nèi)容的全量呈現(xiàn)還是部分呈現(xiàn)就涉及到資源權(quán)限的管控；有的數(shù)據(jù)我能訪問(wèn)，你不能訪問(wèn)，這種權(quán)限的區(qū)分把控在于數(shù)據(jù)權(quán)限的設(shè)置。

在上述案例中，我們的數(shù)據(jù)權(quán)限采取的是黑名單制，顧名思義就是我選擇誰(shuí)不能看到哪些數(shù)據(jù)，默認(rèn)情況下是所有人可以看到所有數(shù)據(jù)，這個(gè)可以根據(jù)具體情況進(jìn)行正反向設(shè)計(jì)。

比如大部分都是可看的，不可看的是少數(shù)，那么就用黑名單方便一些；如果大部分都是不公開(kāi)的，只有少數(shù)是公開(kāi)的，那么白名單會(huì)更方便一些，因情況而異。

3. 權(quán)限把控要靈活

正常來(lái)說(shuō)角色權(quán)限管理對(duì)于一個(gè)需要此方面把控的產(chǎn)品來(lái)說(shuō)就像空氣一樣不可或缺，雖然我們不常注意它的存在，但是用的時(shí)候一定要確保其規(guī)范、安全、可靠。

之前我們?cè)谧龅倪^(guò)程中有過(guò)這樣的一次經(jīng)歷，一般被賦予了某個(gè)角色的人員具有把私有表轉(zhuǎn)為公共可見(jiàn)表的權(quán)限，而對(duì)應(yīng)的刪除操作，當(dāng)時(shí)開(kāi)發(fā)則做成了誰(shuí)建的表誰(shuí)刪除，其余人即使有同樣權(quán)限也不能進(jìn)行刪除這樣的模式。

在一次不經(jīng)意操作中我們發(fā)現(xiàn)共同擁有這個(gè)權(quán)限的人刪除不了別人建的公共表，我跑去告訴同事說(shuō)這張表是他建的，需要他刪除，然后我就去了洗手間，但頓時(shí)感覺(jué)這樣的邏輯存在問(wèn)題，假使十個(gè)人建了十張表然后都轉(zhuǎn)為公共表了，那么如果這十個(gè)人離職了，這些表還非這些賬號(hào)不能進(jìn)行刪除操作了嗎？（不包含開(kāi)發(fā)同事從數(shù)據(jù)庫(kù)刪除的情況，因?yàn)槲覀冊(cè)O(shè)計(jì)產(chǎn)品的最終目的就是減少進(jìn)行數(shù)據(jù)庫(kù)的操作，最大化方便使用并且邏輯合理）

因此意識(shí)到這一問(wèn)題后，我們小組立即進(jìn)行了討論并且及時(shí)做了更新。雖然這樣也存在不是表的主人刪除他人表的可能性，但通常來(lái)說(shuō)：

第一，這樣的情況相對(duì)較少；第二，對(duì)應(yīng)的解決方案是可以通過(guò)把刪除表的功能只賦予一個(gè)最高管理員，其余角色不能隨意操作，這樣來(lái)管控?？傊ＷC權(quán)限把控的靈活性，這是第一原則。

實(shí)際情況其實(shí)更復(fù)雜一點(diǎn)，因?yàn)槲覀冞€涉及私有表可刪除（所有人都有的功能）、可移動(dòng)到公共表（部分被賦予權(quán)限的人員具有的功能，無(wú)權(quán)限人員不顯示此操作按鈕）；公有表的查看（所有人都具有的功能）、公有表的刪除（部分被賦予權(quán)限的人員具有的功能，無(wú)權(quán)限人員不顯示此操作按鈕）等，那天本來(lái)約了人，但為了調(diào)這個(gè)并和開(kāi)發(fā)講清楚，赴約都臨時(shí)取消了（捂臉）。

4. 權(quán)限申請(qǐng)要智能

權(quán)限申請(qǐng)其實(shí)和之前的權(quán)限把控是對(duì)應(yīng)的，有的權(quán)限是把控之后，相應(yīng)用戶看不見(jiàn)被屏蔽的痕跡，也沒(méi)有申請(qǐng)入口，而有的可以做成暫無(wú)權(quán)限的提示，同時(shí)提供申請(qǐng)入口。

在上述案例中，我們?cè)诓糠制帘螆?chǎng)景中提供了權(quán)限申請(qǐng)的入口，當(dāng)用戶點(diǎn)擊申請(qǐng)后，會(huì)自動(dòng)在后臺(tái)接收一條權(quán)限申請(qǐng)的消息，上面顯示申請(qǐng)人基本信息、申請(qǐng)?jiān)础⑸暾?qǐng)時(shí)間以及批復(fù)操作（通過(guò)/拒絕），具體的申請(qǐng)?zhí)幚砹鞒倘缦聢D：

在這塊令我比較欣慰的一點(diǎn)是我們的技術(shù)同事把權(quán)限開(kāi)通做的相對(duì)智能化了一些，即在通過(guò)權(quán)限申請(qǐng)的時(shí)候，相繼會(huì)產(chǎn)生2條動(dòng)作：

• 一個(gè)是在上述的角色權(quán)限模塊自動(dòng)開(kāi)申請(qǐng)用戶開(kāi)通相應(yīng)權(quán)限（包含功能權(quán)限、數(shù)據(jù)權(quán)限和資源權(quán)限）；
• 另一個(gè)則是在開(kāi)通流程走完之后把申請(qǐng)反饋通知發(fā)送到該用戶的消息賬戶，這兩個(gè)任務(wù)完成后，即權(quán)限申請(qǐng)“通過(guò)”，整個(gè)流程基本在1秒內(nèi)完成。當(dāng)然即使開(kāi)放后的權(quán)限未來(lái)也有可能被收回，所以這塊的靈活性是毋庸置疑的。

總結(jié)

正如開(kāi)頭所說(shuō)，角色權(quán)限管理并不出眾，但屬于必不可少的基礎(chǔ)設(shè)施建設(shè)，從0到1的搭建也會(huì)涉及很多坑，需要耐心細(xì)致的梳理清楚相關(guān)邏輯，每個(gè)細(xì)節(jié)方面都盡量不要遺漏，這樣才能使得出來(lái)的產(chǎn)品嚴(yán)謹(jǐn)而規(guī)范，尤其是權(quán)限方面的把控，效果和程度不容忽視。

若同一公司內(nèi)很多產(chǎn)品都涉及這塊，其實(shí)是可以封裝成一個(gè)相對(duì)通用的產(chǎn)品方案，以免重復(fù)造輪子。

當(dāng)然根據(jù)產(chǎn)品各異，繁簡(jiǎn)程度不同，角色權(quán)限管理也是可大可小，在滿足自身需求的情況下如何做得更加靈活、擴(kuò)展性更強(qiáng)，更加高效實(shí)用，是搭建本模塊的基本原則，希望大家在今后實(shí)際工作中能不斷精進(jìn)。

一起加油！

#專欄作家#

慕斯姑娘，微信號(hào)：musiguniang，公眾號(hào)：產(chǎn)品那些年，人人都是產(chǎn)品經(jīng)理專欄作家。關(guān)注金融科技和大數(shù)據(jù)領(lǐng)域，擅長(zhǎng)產(chǎn)品規(guī)劃和落地。

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

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