前言
為什么要引出這個話題呢？雖然目前只換過兩家公司,但越來越感覺到再好的技術始終是在為產品做業務輸出的。光有技術并不能維持一個好的產品。尤其看到最近關于 2020 年 4 月 2日 瑞幸咖啡因偽造收入，盤前暴跌 90%的新聞后，認為一個好的用戶群體以及一個好的生態閉環是多么重要。瑞幸的總部在恰好在廈門，萌生出的這種危機感，讓我置于居安思危的立場,愈來愈堅定了定位為產品經理的想法.
職業規劃 大數據工程師 --> 數據/B端產品經理
首先，產品經理按照面向用戶類型的不同，分為B（Busniess）商業端和 C(Consumer)用戶端 。以幾個簡單的例子而言，虎牙直播，Instagram這些娛樂、工具類軟件主要是提供給大眾用戶用的，屬于C端產品。而唯品會（供應鏈倉儲）、樂信(分期付款)主要是提供給商家用的，屬于B端產品。
C端的特征
優點：直接面向廣大用戶群體，收集需求多，迭代速度快。容易推廣產品。可以根據產品初期的用戶留存率進一步明確產品定位，調整流量入口
缺點：產品迭代速度快，如果不經常做用戶增長分析，會導致用戶流失，產品定位和業務邊界也會不明確。相同競品存在很小的差異性，用戶容易轉移到其他平臺
B端的特征
優點：面向企業，有穩定的資金流。容易合理的設計業務流程，根據企業的需求，定期進行匯總迭代，迭代周期長。因為面向的客戶群體已經確定，不需要關心產品定位
缺點：初期的用戶群體很難確立，需要跟需求方進一步研討業務流程的設計，以設計兼容各個企業的業務邏輯
數據產品經理
數據產品每天都要面對的問題會有：流量怎么暴漲（或暴跌）了？新上的渠道效果怎么樣？用戶的ARPU或者人均PV怎么上升（降低）了？數據產品經理，需要基于數據解釋產品或功能的某項核心指標（包括收入、DAU、ROI等等）的走勢及背后的原因，往往需要細化到多個維度（比如：時間、區域、渠道等）。基于這些解釋，做事后總結或者提前預警，試圖保證產品及功能在正確的軌道上發展。下圖是某服務的實時PV數據，并有今日數據與昨日數據的對比。數據產品經理應該學會經常閱讀和理解數據并培養對數據的直覺，當數據出現異常的時候，能迅速往下深追找到真正的理由。
以上三種，以B端最難入行。在上家個人是做交易結算業務的時候，深感到后端對于業務數據流的把控多么重要
所以在未轉行產品之前，給自己定了兩個基準
在大數據上沉淀技術功底。并主動上PMtalk或者其他產品社區的同行多多溝通數據產品的概念
尋找開源項目，在其中充當PM角色，了解產品從0到1的建設
對于第一個基準，可以利用社區平臺溝通。而第二個基準，則是最近半年有幸參與的一個開源項目 DevOps測試平臺。主旨是為了解決研發側和產品側溝通不便的情況，幫助企業完成自動化測試能力的接入
自定義權限系統的設計
首先，我們需要有一張競品分析的需求畫布,這里我們以比較出名的DevOps平臺coding為例
接著，作為輸出競品畫布的產物。思維導圖要先輸出
我解釋一下為什么會這樣規劃，下面是產品能為企業提供的能力
簡單來說，通常我們的測試在對項目進行回歸測試的時候。會往jenkins上加上一個測試腳本,比如
jmeter -n -t test.jmx(腳本的絕對路徑) -l result.jtl(自定義的名稱) -e -o \tmp\result_report(測試報告的絕對路徑)
測試腳本的輸入參數被稱為測試對象，輸出參數為測試結果。在我們通過調度器執行后，會將不同的測試結果匯總生成一個相應的測試報告。 配置管理就是加上測試腳本的前置步驟，我們需要配置一些元數據以寫入腳本文件
接著由于這個項目的服務用戶是給企業用的，我們說下scurm敏捷開發中的iteration，story，task，rank，backlog，現在大多數項目都在做敏捷開發。自己也深有體會
iteration 就是指迭代，產品給研發側指派任務時，需要指派影響范圍為整個流程的新功能，或者新流程
-
stroy 指的是用戶故事，根據李寬的B端產品必修課一書中所提到的需求描述，切換為結構化的形式如下：
- who?用戶是誰?
- what?用戶想要什么樣的功能?
- why為什么想要這樣的功能？實現它的價值是什么？
task就是從stroy里面拆分出的小需求，比如說我們上面的配置管理可以劃分為多個頁面的數據交互
rank 是指對于本次迭代里每次任務的完成度，每個人做了多少需求，產生了多少bug,會在各個團隊有個task的完成度排名
backlog 有點像我們每次要開的晨會，每個人及時匯報工作進度，然后向上級匯報。一個迭代的周期開始循環
然后，我們言歸正傳。對于目前這樣的系統，我們可以把每一個待執行的測試請求看成是一個事件。對于每一個事件，用事件+可視化配置+規則攔截的方法來進行攔截。之后交給調度器模塊。但是問題在于，測試的種類的是非常多的。比如單元測試，接口測試，回歸測試。壓力測試，集成測試。要根據不同職位的人員約定進行測試，這也是我們常說的一句話“約定大于配置”
舉一些簡單的例子
迭代較快，無法進行集成測試 ：一個前后端分離的項目。前端發了，后端還在回歸測試部門功能。那這個時候要測其他功能就只能灰度發布。但流程上可能阻塞了其他功能的提測，比如說結算對賬單生成功能的下一步是對賬確認處理，此時結算對賬單由于后端在進行測試，所以在測試環境對于前端而言會產生臟數據。對于這種情況，發布只能由前后端的組長進行評估發布時間，決定好各自發布的順序
對服務器性能損耗，需要下班后執行:如果我們要執行的定時測試腳本，需要查詢的數據量過大，又或者會mock大量數據進行壓力測試，此時就需要主管級別的人來進行評估，給客戶造成的影響范圍
- 接口測試：已經指定了一個測試腳本的測試對象，但是在執行中的時候，在配置管理里面又改了測試對象的配置，導致測試結果出現不一致。這種也需要用戶提測時約定好。
總結，對于以上需求，顯然需要通過權限控制的方式來使其接入相應的測試能力，避免生產環境上事故的發生。經過調研，采用了RBAC模型+權限接入測試能力的方式設計自定義賬戶體系
登錄時序圖
對于權限模型的選擇，從ABAC模型，CBAC模型，OrBAC模型，RBAC模型中選擇了RBAC模型
根據RBAC權限定義,設計如下:
系統的所有權限信息。權限具有上下級關系，是一個樹狀的結構。下面來看一個例子
系統管理
-
用戶管理
查看用戶
新增用戶
修改用戶
刪除用戶
對于上面的每個權限，又存在兩種情況，一個是只是可訪問，另一種是可授權，例如對于“查看用戶”這個權限，如果用戶只被授予“可訪問”，那么他就不能將他所具有的這個權限分配給其他人。
用戶
應用系統的具體操作者，用戶可以自己擁有權限信息，可以歸屬于0～n個角色，可屬于0～n個組。他的權限集是自身具有的權限、所屬的各角色具有的權限、所屬的各組具有的權限的合集。它與權限、角色、組之間的關系都是n對n的關系。
角色
為了對許多擁有相似權限的用戶進行分類管理，定義了角色的概念，例如系統管理員、管理員、用戶、訪客等角色。角色具有上下級關系，可以形成樹狀視圖，父級角色的權限是自身及它的所有子角色的權限的綜合。父級角色的用戶、父級角色的組同理可推。
組
為了更好地管理用戶，對用戶進行分組歸類，簡稱為用戶分組。組也具有上下級關系，可以形成樹狀視圖。在實際情況中，我們知道，組也可以具有自己的角色信息、
權限信息。這讓我想到我們的QQ用戶群，一個群可以有多個用戶，一個用戶也可以加入多個群。每個群具有自己的權限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高級群等。
針對如上提出的四種對象，我們可以整理得出它們之間的關系，如下所示：
總體設計思路是將系統分為組權限管理、角色權限管理、用戶權限管理、組織管理和操作日志管理五部分。
其中組權限管理包括包含用戶、所屬角色、組權限資源和組總權限資源四部分，某個組的權限信息可用公式表示：組權限 = 所屬角色的權限合集 + 組自身的權限。
角色權限管理包括包含用戶、包含組和角色權限三部分，某個角色的權限的計算公式為：角色權限 = 角色自身權限。
用戶權限管理包括所屬角色、所屬組、用戶權限、用戶總權限資源和組織管理五部分。某個用戶總的權限信息存在如下計算公式：用戶權限 = 所屬角色權限合集 + 所屬組權限合集 + 用戶自身權限。
組織管理即對用戶所屬的組織進行管理，組織以樹形結構展示，組織管理具有組織的增、刪、改、查功能。
操作日志管理用于管理本系統的操作日志。
ps：因為組和角色都具有上下級關系，所以下級的組或角色的權限只能在自己的直屬上級的權限中選擇，下級的組或者角色的總的權限都不能大于直屬上級的總權限。
