在蝦皮數據分析競賽中領略的專案管理技能 | ARON HACK 亞倫害的

原始文章

〈在蝦皮數據分析競賽中領略的專案管理技能〉

前情提要

我在2020年11月21號和朋友組隊參加了蝦皮(Shopee)的數據分析競賽〈 I’m the Best Coder! Challenge 2020〉，比賽會場在南港展覽館，團隊人數上限為四人。據主辦單位當天口述，總參與人數大約一千人左右，我大略估了一下座位數位，也差不多是這個數字。比賽透過Kaggle進行，官方訊息則使用Telegram傳達。

這次的比賽分為學生組和職業組，職業組的題目為預測8月份的高價值顧客，使用的資料集為2至7月的交易資料與登入資料；學生組的題目是針對物流箱做分析。由於我們是報名職業組，因此不確定學生組的詳細題目內容。

重點來了，這次的比賽時間只有兩個小時，在如此緊迫的時間壓力之下，一分一秒都不能浪費，這也是這篇文章誕生的原因。練好自己的程式技能，補足缺乏的統計與機器學習知識，這些最基本的事情接近於廢話，因此，怎麼事先做好組織規劃、工作分配與風險控管，才是我在這次比賽中最大的收獲。簡單來說，我們需要一個PM(專案經理)。

第一個難題，網路速度很慢

職業組共有五個資料集，全部放在Kaggle上，未壓縮的總容量約為1G。想想，當天會場擠了一千人，當比賽開始的時候，大家必須做的第一件事情就是下載檔案。雖然蝦皮已經設置了七個Wifi分享器，當天也Delay了大約二十分鐘做網路檢查，但網路還是大塞車，我的檔案下載時間一度飆到30分鐘左右。

由於人實在太多，即使用手機的行動網路也有降速的問題，但似乎還是比現場的Wifi還要快。針對第一個難題，我認為的最佳解法是將隊員分成分成Wifi下載組及行動網路下載組，所有人同時下載，雙管齊下。另外一個超級重點，記得帶上你的隨身碟，並事先確定仍有足夠的空間可以使用。根據排列組合原理，最佳的隨身碟數量是「團員人數-1」，不要因為檔案傳輸這種小事使得團隊空轉，也不要指望Google Drive、Drive Box等雲端空間可以派上用場。

這裡題外話兩點，這兩點都要credit給我的隊友Ken。

第一點是手機網路小常識。即使大家都一樣使用4G網路，網路方案的不同可能會影響下載速度的最大值。因此，理想狀況是將手機方案最高級的隊友編入行動網路下載組。如果你的網路不是吃到飽，或者是較便宜的方案，那你理所當然是Wifi下載組成員。

第二點是給主辦單位的建議。除非主辦單位是故意考驗參賽者的流程及風險控管能力，因此安排網路大塞車的情節發生，否則主辦單位完全可以先把資料集放進壓縮檔中，並使用強密碼進行加密，讓參賽者可以事先下載檔案，並在比賽開始之後將解壓縮密碼發佈至Telegram。即使有人蓄意破解密碼，等到強密碼被破解，人類可能也毀滅了。

組織編制

通常在數據分析競爭中，大部份的資料都已經經過清理，資料量也不至於大到太誇張，但參賽者還是必須理解資料內容，確定有沒有NA或異常值。因此，在四人團隊的編制底下，我會將團隊區分為三個角色：

• 資料手：共兩名，負責理解資料表的內容、資料處理，並將資料整理到可以丟入模型的格式。
• 游擊手：共一名，即為PM，奔走於資料手與建模手中間，必須是最了解整體流程的人，對資料處理及機器學習技法都要有一定掌握度。
• 建模手：共一名，重點工作為建立機器學習模型，並且列出建模的A、B方案。

第一階段

當團員同步開始下載資料集後，就可以依據自己的工作崗位執行任務。首先，建模手不用花時間理解資料集，只需要確認最終提交的資料內容及格式，就可以開始規劃模型及演算法方案，列出A、B，甚至是C方案。列這些方案的原因很簡單，必須要有盡善盡美的方案，也要有最壞最壞的打算，可能用一個演算法就可以提交了。尤其在比賽時間緊迫的情況下，能提交答案就算是贏了一半。因此，在列完方案後，建模手就可以開始執行最重要、最不可或缺的模型，並等待其他人完成前段任務後提供支援，實現最完美的模型方案。

同時，資料手與PM必須理解資料內容，由資料手執行資料表的合併及初步運算，PM確認資料手的產出結果能夠與模型無縫接軌。由於資料手會處理raw data，理論上他們的電腦效能不能太差，寫code的速度不能太慢，因為這是最重要的第一步，如果連前面資料都處理不好，後面根本也不用玩了，這也是我會安排兩個資料手執行，並安排PM協助的原因，先將資源押在最急迫的環節上。

而PM在與資料手討論完後，不需要親自參與資料處理，他有另一個重要的工作，以合併後的資料格式產生假資料，讓建模手在理解方案之後，有實際的檔案可以進行建模，避免用通靈的方式寫code，等資料手完成任務後，建模手只需要把資料源換掉即可。

第二階段

在第一階段的任務完成後，完成的人當然不可能閒著沒事幹，因此，必須進行組織變形，執行第二階段的任務。

理論上，PM會是第一個釋放出來的人力，因此，在準備完假資料後，PM要親自參與建模流程，一邊與建模手討論不同模型間的搭配，一邊確認資料手的工作順利進行。由於PM會在兩個組別間來回奔波(PM一直都是這樣的)，所以模型的主code會由建模手負責，他要處理整體模型的控管，甚至決定壯士斷腕，採用退而求其次的方案。

在資料手完成資料處理，且檢查無誤後，兩個資料手會有不同的第二階段任務。資料手A產生一份最終答案的假資料，並測試上傳。通常比賽會有多次上傳答案的機會，上傳到一半掛掉也是常有的事，資料手A的任務目的正是熟悉Kaggle網站的上傳流程，順便確認答案是否有任何限制條件。我們這次比賽就遇到這樣的情形，上傳的檔案必須要有58000筆資料，但我們算出來的資料筆數只有40000筆，導致檔案上傳失敗。

資料手B的第二個任務是整理資料處理的code，將兩份檔案合而為一，為了可能最終審核階段準備程式碼。值得注意的是，如果比賽時間有兩小時，完整的程式碼可能在兩個半小時內完成上傳即可，等於多了半個小時的工作時間。在這種情況下，程式碼整理的工作可能就不必急著執行，資料手B可以參與建模流程，讓資料手A測試上傳後，接手程式碼整理的工作。

第三階段

第三階段為最後的收尾階段，由建模手合併所有模型後，先將code傳給負責程式碼整理的資料手A或B，讓資料身先順過全部的程式碼，並記錄應該更動名稱的變數。建模手可以利用這段時間再次執行、檢查模型，完成之後開心上傳答案。

機會是留給準備好的人

在快節奏的比賽中，我認為最大的危機是沒有釐清每個團員的工作內容，也沒有清楚的Leader，所有事情都是即興演出，導致工作量與資源分配失衡，或是重工的情形。因此，如果你們接受了以上的組織編制，就可以在賽前推舉PM人選，也了解每個人的強項，進一步分配任務。許多組隊參加的人可能在過去沒有都共事經驗，這使得前期的準備工作顯得更為重要，包含工具的差異，可能是Python或R，可能是Tableau或Power BI。如果沒搞清楚這些，比賽當天勢必會驚喜連連。

當然，上面的組織編制只是我的個人想法，實務面上可能會有所調整，像是資料處理分成兩個人做，某種程度上是增加了任務的複雜性。如果某個隊友的能力夠強，可以一手包辦這份工作，另一個資料手就可以轉職成為建模手。

另外，我個人秉持著「上班寫的code下班也要能用」的原則，在這樣的原則下，我會將許許多多常用的小功能寫成function，並將這些function包進一個檔案中，類似於library的概念，滿多資料科學界的朋友好像都沒有這個習慣。我在這次比賽中也帶上了我的library，確實也幫上了一點小忙。使用方式可以參考我的另一篇文章〈Python – 載入自己寫的套件/模組/包/Library/Modules〉。

洋洋灑灑打了三千字，老實說，這也是我第一次參加比賽，甚至最後也沒來得及提交答案及腳本，所以後半部的流程算是沙盤推演而得(被打)。如果你發現任何錯誤，或是有任何想法都歡迎留言討論。

 

相關文章

〈在DataCamp學Python和R語言，快速入門資料科學〉