< 前情提要>
RACI 是專案管理中常見的工具，專門用來決定階段性任務的負責人以及如何明確分工。我以前都會覺得為什麼有些同事都一直躲避責任、不做事，後來發現其實是因為自己沒有想好對方的責任劃分範圍。所以後來安排事情的時候我都會先想清楚每個階段的負責人應該要找誰，然後 hold them accountable，確保這個階段任務如果出包的話他要負責，並且在開始執行以前發 email 給大家並 cc 他老闆說他會為這件事情負責。
⚠️ RACI 排版小技巧
在排版 RACI 的時候我會按照：
1）縱軸由上到下，安排始至終的階段性任務
2）橫軸由左到右，列出高到低的利害關係人
這樣觀察縱軸你可以知道某個部門應該負責什麼，觀察橫軸你可以知道一項重大的里程碑需要牽扯到多少部門的參與。
❌ 另外要提的一點是很多人都會覺得「老闆把事情交代給我，器重我，所以我要一肩扛起所有責任。」我覺得這是很錯誤的觀念，這樣你只會限縮自己的格局而沒辦法複製自己的成功。做自己的主人不代表你要扛所有的責任和做所有的事情，做自己的主人代表著要學會判斷什麼時候你應該負責而什麼時候應該要把事情分出去。
< 正文開始 >
【練習語言沒有捷徑】
說到 SQL 我覺得算是比較簡單的程式語言，因為你只要知道「選取什麼，從哪裡找資料，需要什麼搜尋限制。」大至上就可以架構起你想要寫的程式碼。舉例來說我們在圖書館的時候通常要找書本在哪都會先在腦海裡想著，
1）我想要找什麼類型的書，可能是行銷（找書名）
2）從哪裡找這些書，應該是商業區域（選定書櫃）
3）搜尋限制就是找行銷大師，Philip Kotler（指定作者）
換成簡單的 SQL 就會是
Select book_name
From business_book
Where author = ‘Philip_Kotler’
我那個時候每天下班後只花半小時刷題目，兩個月下來我發現是別的同事來問你哪些 table 有什麼資料而不是我再當伸手牌去要資料。
這邊想要大推 Udemy 免費課程，像這個免費課程總時數兩個多小時而已就包含了最基本的公式：
【先想好你的資料範圍】
起初我在學數字分析的時候也是很有野心，覺得反正就是愈多數據愈好，這樣才能找到我想要的 insight。後來學了 SQL 之後才知道，什麼 data 都要，也代表著什麼都不知道。就像我們在圖書館不會一次借太多本書，會從經典書籍開始再慢慢延伸到比較難的知識。在急著分析以前也一樣，要先想好自己要什麼，資料的範圍長什麼樣子。
以【客服人森 11】的表格為例，我們可以知道有些時候如果 row 不是 unique 的話，你的 data array 會等比級數的增加，對於資料清理是很大的負擔。所以現在回頭來看當初的兩個表格（完整版）
（顧客滿意度的表格）
（回報次數的表格）
會發現第一個表格的第一欄和第二個表格的第三欄有相似的點，就是都包含事件種類但是排序不同。那麼這個欄位可以作為串接兩個表格的定錨點，然後利用 join table 的方式讓兩個表格合併成一個。當兩個表格合在一起後，就可以用下面的公式找到資料。
Select *
From Table1
Left Join Table2
On Table1.Issue_Type = Table2.Issue_Type
（合併後的表格，包含顧客滿意度和回報次數）
【抓了這些資料然後呢？】
當初在學 join table 的時候邏輯上一直卡關想不通，後來看到了某張集合圖才恍然大悟，原來就是把兩個圓的交集處找出來，然後把他們的欄位重疊在一起，最後回傳那些能找到欄位中有相同集合的數字以列的方式呈現。
（實際把概念轉換成表格的示意圖）
就想像你今天在找書的時候行銷書籍放成兩個書櫃放，一個櫃子放教科書，另外一個櫃子放工具書，但是電腦除非把教科書和工具書全部放在同一個櫃子裡頭不然他不會知道 Philip Kotler 同時有出教科書也有寫工具書。
當我不再當伸手牌之後也慢慢跟淡定哥打好關係，知道他工作的習慣，去跟他要 data 的時候很快就能切入重點說明我想分析什麼資料然後大概想要什麼樣的矩陣。意外的還聊到他在下班之餘還另外兼差當 DJ，超酷！
這時候才想起來雖然說團隊建立之後是交由小帥在管理，但是不免好奇我們之前一起建立的團隊表現好不好呢？
不然自己練習如何用 SQL 撈 data 然後稍微分析一下看看好了。
以上內容純屬虛構，如有雷同純屬巧合
Comments