前言
為什么要引出這個話題呢？雖然目前只換過兩家公司,但越來越感覺到再好的技術始終是在為產(chǎn)品做業(yè)務輸出的耕肩。光有技術并不能維持一個好的產(chǎn)品。尤其看到最近關于 2020 年 4 月 2日 瑞幸咖啡因偽造收入绩郎，盤前暴跌 90%的新聞后赖瞒，認為一個好的用戶群體以及一個好的生態(tài)閉環(huán)是多么重要。瑞幸的總部在恰好在廈門录肯，萌生出的這種危機感趴腋，讓我置于居安思危的立場,愈來愈堅定了定位為產(chǎn)品經(jīng)理的想法.
職業(yè)規(guī)劃 大數(shù)據(jù)工程師 --> 數(shù)據(jù)/B端產(chǎn)品經(jīng)理
首先，產(chǎn)品經(jīng)理按照面向用戶類型的不同论咏，分為B（Busniess）商業(yè)端和 C(Consumer)用戶端 优炬。以幾個簡單的例子而言，虎牙直播厅贪，Instagram這些娛樂蠢护、工具類軟件主要是提供給大眾用戶用的，屬于C端產(chǎn)品养涮。而唯品會（供應鏈倉儲）葵硕、樂信(分期付款)主要是提供給商家用的眉抬，屬于B端產(chǎn)品。
C端的特征
優(yōu)點：直接面向廣大用戶群體懈凹，收集需求多蜀变，迭代速度快。容易推廣產(chǎn)品介评】獗保可以根據(jù)產(chǎn)品初期的用戶留存率進一步明確產(chǎn)品定位，調整流量入口
缺點：產(chǎn)品迭代速度快威沫，如果不經(jīng)常做用戶增長分析贤惯，會導致用戶流失洼专，產(chǎn)品定位和業(yè)務邊界也會不明確棒掠。相同競品存在很小的差異性，用戶容易轉移到其他平臺
B端的特征
優(yōu)點：面向企業(yè)屁商，有穩(wěn)定的資金流烟很。容易合理的設計業(yè)務流程，根據(jù)企業(yè)的需求蜡镶，定期進行匯總迭代雾袱，迭代周期長。因為面向的客戶群體已經(jīng)確定官还，不需要關心產(chǎn)品定位
缺點：初期的用戶群體很難確立芹橡，需要跟需求方進一步研討業(yè)務流程的設計，以設計兼容各個企業(yè)的業(yè)務邏輯
數(shù)據(jù)產(chǎn)品經(jīng)理
數(shù)據(jù)產(chǎn)品每天都要面對的問題會有：流量怎么暴漲（或暴跌）了望伦？新上的渠道效果怎么樣林说？用戶的ARPU或者人均PV怎么上升（降低）了？數(shù)據(jù)產(chǎn)品經(jīng)理屯伞，需要基于數(shù)據(jù)解釋產(chǎn)品或功能的某項核心指標（包括收入腿箩、DAU、ROI等等）的走勢及背后的原因劣摇，往往需要細化到多個維度（比如：時間珠移、區(qū)域、渠道等）末融【澹基于這些解釋，做事后總結或者提前預警勾习，試圖保證產(chǎn)品及功能在正確的軌道上發(fā)展浓瞪。下圖是某服務的實時PV數(shù)據(jù)，并有今日數(shù)據(jù)與昨日數(shù)據(jù)的對比语卤。數(shù)據(jù)產(chǎn)品經(jīng)理應該學會經(jīng)常閱讀和理解數(shù)據(jù)并培養(yǎng)對數(shù)據(jù)的直覺追逮，當數(shù)據(jù)出現(xiàn)異常的時候酪刀，能迅速往下深追找到真正的理由。
以上三種钮孵，以B端最難入行骂倘。在上家個人是做交易結算業(yè)務的時候，深感到后端對于業(yè)務數(shù)據(jù)流的把控多么重要
所以在未轉行產(chǎn)品之前巴席，給自己定了兩個基準
在大數(shù)據(jù)上沉淀技術功底历涝。并主動上PMtalk或者其他產(chǎn)品社區(qū)的同行多多溝通數(shù)據(jù)產(chǎn)品的概念
尋找開源項目，在其中充當PM角色漾唉，了解產(chǎn)品從0到1的建設
對于第一個基準荧库，可以利用社區(qū)平臺溝通。而第二個基準赵刑，則是最近半年有幸參與的一個開源項目 DevOps測試平臺分衫。主旨是為了解決研發(fā)側和產(chǎn)品側溝通不便的情況，幫助企業(yè)完成自動化測試能力的接入
自定義權限系統(tǒng)的設計
首先般此，我們需要有一張競品分析的需求畫布,這里我們以比較出名的DevOps平臺coding為例
接著蚪战，作為輸出競品畫布的產(chǎn)物。思維導圖要先輸出
我解釋一下為什么會這樣規(guī)劃铐懊，下面是產(chǎn)品能為企業(yè)提供的能力
簡單來說邀桑，通常我們的測試在對項目進行回歸測試的時候。會往jenkins上加上一個測試腳本,比如
jmeter -n -t test.jmx(腳本的絕對路徑) -l result.jtl(自定義的名稱) -e -o \tmp\result_report(測試報告的絕對路徑)
測試腳本的輸入?yún)?shù)被稱為測試對象科乎，輸出參數(shù)為測試結果壁畸。在我們通過調度器執(zhí)行后，會將不同的測試結果匯總生成一個相應的測試報告茅茂。 配置管理就是加上測試腳本的前置步驟捏萍，我們需要配置一些元數(shù)據(jù)以寫入腳本文件
接著由于這個項目的服務用戶是給企業(yè)用的，我們說下scurm敏捷開發(fā)中的iteration玉吁，story照弥，task，rank进副，backlog这揣，現(xiàn)在大多數(shù)項目都在做敏捷開發(fā)。自己也深有體會
iteration 就是指迭代影斑，產(chǎn)品給研發(fā)側指派任務時给赞，需要指派影響范圍為整個流程的新功能，或者新流程
-
stroy 指的是用戶故事矫户，根據(jù)李寬的B端產(chǎn)品必修課一書中所提到的需求描述片迅，切換為結構化的形式如下：
- who?用戶是誰?
- what?用戶想要什么樣的功能?
- why為什么想要這樣的功能？實現(xiàn)它的價值是什么皆辽？
task就是從stroy里面拆分出的小需求柑蛇，比如說我們上面的配置管理可以劃分為多個頁面的數(shù)據(jù)交互
rank 是指對于本次迭代里每次任務的完成度芥挣，每個人做了多少需求，產(chǎn)生了多少bug,會在各個團隊有個task的完成度排名
backlog 有點像我們每次要開的晨會耻台，每個人及時匯報工作進度空免，然后向上級匯報。一個迭代的周期開始循環(huán)
然后盆耽，我們言歸正傳蹋砚。對于目前這樣的系統(tǒng)，我們可以把每一個待執(zhí)行的測試請求看成是一個事件摄杂。對于每一個事件坝咐，用事件+可視化配置+規(guī)則攔截的方法來進行攔截。之后交給調度器模塊析恢。但是問題在于墨坚，測試的種類的是非常多的。比如單元測試氮昧，接口測試框杜，回歸測試浦楣。壓力測試袖肥，集成測試。要根據(jù)不同職位的人員約定進行測試振劳，這也是我們常說的一句話“約定大于配置”
舉一些簡單的例子
迭代較快椎组，無法進行集成測試 ：一個前后端分離的項目。前端發(fā)了历恐，后端還在回歸測試部門功能寸癌。那這個時候要測其他功能就只能灰度發(fā)布。但流程上可能阻塞了其他功能的提測弱贼，比如說結算對賬單生成功能的下一步是對賬確認處理蒸苇，此時結算對賬單由于后端在進行測試，所以在測試環(huán)境對于前端而言會產(chǎn)生臟數(shù)據(jù)吮旅。對于這種情況溪烤，發(fā)布只能由前后端的組長進行評估發(fā)布時間，決定好各自發(fā)布的順序
對服務器性能損耗庇勃，需要下班后執(zhí)行:如果我們要執(zhí)行的定時測試腳本檬嘀，需要查詢的數(shù)據(jù)量過大，又或者會mock大量數(shù)據(jù)進行壓力測試责嚷，此時就需要主管級別的人來進行評估鸳兽，給客戶造成的影響范圍
- 接口測試：已經(jīng)指定了一個測試腳本的測試對象，但是在執(zhí)行中的時候罕拂，在配置管理里面又改了測試對象的配置揍异，導致測試結果出現(xiàn)不一致全陨。這種也需要用戶提測時約定好。
總結衷掷，對于以上需求烤镐，顯然需要通過權限控制的方式來使其接入相應的測試能力，避免生產(chǎn)環(huán)境上事故的發(fā)生棍鳖。經(jīng)過調研炮叶，采用了RBAC模型+權限接入測試能力的方式設計自定義賬戶體系
登錄時序圖
對于權限模型的選擇，從ABAC模型渡处，CBAC模型镜悉，OrBAC模型，RBAC模型中選擇了RBAC模型
根據(jù)RBAC權限定義,設計如下:
系統(tǒng)的所有權限信息医瘫。權限具有上下級關系侣肄，是一個樹狀的結構。下面來看一個例子
系統(tǒng)管理
-
用戶管理
查看用戶
新增用戶
修改用戶
刪除用戶
對于上面的每個權限醇份，又存在兩種情況稼锅，一個是只是可訪問，另一種是可授權僚纷，例如對于“查看用戶”這個權限矩距，如果用戶只被授予“可訪問”，那么他就不能將他所具有的這個權限分配給其他人怖竭。
用戶
應用系統(tǒng)的具體操作者锥债，用戶可以自己擁有權限信息，可以歸屬于0～n個角色痊臭，可屬于0～n個組哮肚。他的權限集是自身具有的權限、所屬的各角色具有的權限广匙、所屬的各組具有的權限的合集允趟。它與權限、角色鸦致、組之間的關系都是n對n的關系潮剪。
角色
為了對許多擁有相似權限的用戶進行分類管理，定義了角色的概念蹋凝，例如系統(tǒng)管理員鲁纠、管理員、用戶鳍寂、訪客等角色改含。角色具有上下級關系，可以形成樹狀視圖迄汛，父級角色的權限是自身及它的所有子角色的權限的綜合捍壤。父級角色的用戶骤视、父級角色的組同理可推。
組
為了更好地管理用戶鹃觉，對用戶進行分組歸類专酗，簡稱為用戶分組。組也具有上下級關系盗扇，可以形成樹狀視圖祷肯。在實際情況中，我們知道疗隶，組也可以具有自己的角色信息佑笋、
權限信息。這讓我想到我們的QQ用戶群斑鼻，一個群可以有多個用戶蒋纬，一個用戶也可以加入多個群。每個群具有自己的權限信息坚弱。例如查看群共享蜀备。QQ群也可以具有自己的角色信息，例如普通群荒叶、高級群等碾阁。
針對如上提出的四種對象，我們可以整理得出它們之間的關系停撞，如下所示：
總體設計思路是將系統(tǒng)分為組權限管理瓷蛙、角色權限管理、用戶權限管理戈毒、組織管理和操作日志管理五部分。
其中組權限管理包括包含用戶横堡、所屬角色埋市、組權限資源和組總權限資源四部分，某個組的權限信息可用公式表示：組權限 = 所屬角色的權限合集 + 組自身的權限命贴。
角色權限管理包括包含用戶、包含組和角色權限三部分，某個角色的權限的計算公式為：角色權限 = 角色自身權限邻寿。
用戶權限管理包括所屬角色渠抹、所屬組、用戶權限葬项、用戶總權限資源和組織管理五部分泞当。某個用戶總的權限信息存在如下計算公式：用戶權限 = 所屬角色權限合集 + 所屬組權限合集 + 用戶自身權限。
組織管理即對用戶所屬的組織進行管理民珍，組織以樹形結構展示襟士，組織管理具有組織的增盗飒、刪、改陋桂、查功能逆趣。
操作日志管理用于管理本系統(tǒng)的操作日志。
ps：因為組和角色都具有上下級關系嗜历，所以下級的組或角色的權限只能在自己的直屬上級的權限中選擇宣渗，下級的組或者角色的總的權限都不能大于直屬上級的總權限。
