數據型產品的用戶管理相較於其他互聯網產品的來說更加複雜，本文作者分析了用戶管理的邏輯，並且總結了自身經驗，給數據型產品經理們整理了以下幾點建議。
隨着近年來大數據、人工智能、雲計算等新興技術的火熱及逐步成熟，數據的重要性再次引起了人們的重視，從底層的核心數據庫，到中間層的數據計算及數據服務，以至於頂層的數據調用，數據型產品層出不窮。
與以往IT時代相比，DT時代的產品不僅業務邏輯更多，而且數據資源的管控要求更加嚴格，數據資產的變現是每個企業都在謀求的發展之路，因此，關於數據型產品的用戶管理，往往比之前的互聯網產品更爲複雜，想要做好，實屬不易。
用戶管理類似於一個系統的基礎設施建設，重要程度雖不及其他核心功能，但卻是必不可少的其中一環，而且隨着產品內容和邏輯的增多，用戶管理髮揮的價值會日漸體現出來。
用戶管理三大模塊
由於公司有統一的域庫存儲用戶信息，包括入職離職人員的信息更新，因此我們此處的用戶管理是在已有用戶羣(並且可實時同步數據)的基礎上進行角色權限的把控。
整個模塊爲用戶管理，下分三塊分別是：
部門組織架構：所有部門人員信息的在線展示以及對應的人員列表，此處同步公司域庫數據，附加了當前在線狀態的顯示;
角色權限管理：此處分爲角色組的建立以及對應權限的把控，角色組以及所屬成員按需創建和添加，建完之後對應做權限的控制，包含功能權限、資源權限、數據權限、集成系統的訪問權限;
權限申請管理：此處是針對權限管控後，用戶對無權限資源進行的權限申請處理以及對應的權限賦予操作(權限批覆結果會自動生成消息通知，與公告消息相通)。
如何做好權限管理
上述組織架構和權限申請部分基本很容易理解，邏輯相對複雜一些的當屬角色權限管理這部分，
做好權限管理有以下幾個重點：
1. 人員組成要靈活
這部分的人員組成不一定是按照崗位角色來的，有可能是跨部門跨崗位形成的自定義角色組，因此不能直接套用之前的崗位角色，需要可以創建新的角色組，當然角色組多了還可以給角色組分大類，以便更清晰一些。
2. 權限覆蓋要全面
權限常規來說可以分爲功能權限、數據權限、資源權限，當然根據產品不同也可能有更多的權限分類。大到每個頂部導航模塊，小到頁面上每個功能按鈕，都屬於權限的範圍。與此同時資源內容的全量呈現還是部分呈現就涉及到資源權限的管控;有的數據我能訪問，你不能訪問，這種權限的區分把控在於數據權限的設置。
在上述案例中，我們的數據權限採取的是黑名單制，顧名思義就是我選擇誰不能看到哪些數據，默認情況下是所有人可以看到所有數據，這個可以根據具體情況進行正反向設計。
比如大部分都是可看的，不可看的是少數，那麼就用黑名單方便一些;如果大部分都是不公開的，只有少數是公開的，那麼白名單會更方便一些，因情況而異。
3. 權限把控要靈活
正常來說角色權限管理對於一個需要此方面把控的產品來說就像空氣一樣不可或缺，雖然我們不常注意它的存在，但是用的時候一定要確保其規範、安全、可靠。
之前我們在做的過程中有過這樣的一次經歷，一般被賦予了某個角色的人員具有把私有錶轉爲公共可見表的權限，而對應的刪除操作，當時開發則做成了誰建的表誰刪除，其餘人即使有同樣權限也不能進行刪除這樣的模式。
在一次不經意操作中我們發現共同擁有這個權限的人刪除不了別人建的公共表，我跑去告訴同事說這張表是他建的，需要他刪除，然後我就去了洗手間，但頓時感覺這樣的邏輯存在問題，假使十個人建了十張表然後都轉爲公共表了，那麼如果這十個人離職了，這些表還非這些賬號不能進行刪除操作了嗎?(不包含開發同事從數據庫刪除的情況，因爲我們設計產品的最終目的就是減少進行數據庫的操作，最大化方便使用並且邏輯合理)
因此意識到這一問題後，我們小組立即進行了討論並且及時做了更新。雖然這樣也存在不是表的主人刪除他人表的可能性，但通常來說：鄭州人流醫院
第一，這樣的情況相對較少;第二，對應的解決方案是可以通過把刪除表的功能只賦予一個最高管理員，其餘角色不能隨意操作，這樣來管控。總之要保證權限把控的靈活性，這是第一原則。
實際情況其實更復雜一點，因爲我們還涉及私有表可刪除(所有人都有的功能)、可移動到公共表(部分被賦予權限的人員具有的功能，無權限人員不顯示此操作按鈕);公有表的查看(所有人都具有的功能)、公有表的刪除(部分被賦予權限的人員具有的功能，無權限人員不顯示此操作按鈕)等，那天本來約了人，但爲了調這個並和開發講清楚，赴約都臨時取消了(捂臉)。
4. 權限申請要智能
權限申請其實和之前的權限把控是對應的，有的權限是把控之後，相應用戶看不見被屏蔽的痕跡，也沒有申請入口，而有的可以做成暫無權限的提示，同時提供申請入口。
在上述案例中，我們在部分屏蔽場景中提供了權限申請的入口，當用戶點擊申請後，會自動在後臺接收一條權限申請的消息，上面顯示申請人基本信息、申請源、申請時間以及批覆操作(通過/拒絕)，
在這塊令我比較欣慰的一點是我們的技術同事把權限開通做的相對智能化了一些，即在通過權限申請的時候，相繼會產生2條動作：
一個是在上述的角色權限模塊自動開申請用戶開通相應權限(包含功能權限、數據權限和資源權限);
另一個則是在開通流程走完之後把申請反饋通知發送到該用戶的消息賬戶，這兩個任務完成後，即權限申請“通過”，整個流程基本在1秒內完成。當然即使開放後的權限未來也有可能被收回，所以這塊的靈活性是毋庸置疑的。
總結
正如開頭所說，角色權限管理並不出衆，但屬於必不可少的基礎設施建設，從0到1的搭建也會涉及很多坑，需要耐心細緻的梳理清楚相關邏輯，每個細節方面都儘量不要遺漏，這樣才能使得出來的產品嚴謹而規範，尤其是權限方面的把控，效果和程度不容忽視。
若同一公司內很多產品都涉及這塊，其實是可以封裝成一個相對通用的產品方案，以免重複造輪子。
當然根據產品各異，繁簡程度不同，角色權限管理也是可大可小，在滿足自身需求的情況下如何做得更加靈活、擴展性更強，更加高效實用，是搭建本模塊的基本原則，希望大家在今後實際工作中能不斷精進。
一起加油!