這是我開始學 Data Science 後做的第一個專案，也是我第一次負責完整的分析流程：從了解資料、釐清問題，到團隊合作、打造可持續的解決方案。收下了 Best Data Science 的殊榮後，我們的旅途才正要開始。
如果說這一年我在 SLO 過著類似夢境的生活，站在 Oracle 演講廳展示成果的那一刻，大概是我最不想醒來的時候吧。畢竟連我自己都很難相信，去年八月還在學 Introduction to R 的我，能和隊友在三個月內完成一個有模有樣的解決方案，並獲得評審青睞，受邀到 Oracle 總部吃吃喝喝。過程中，出於對思考和美感的堅持，我學會了很多以前沒學過也懶得學的工具，也領悟了很多過去沒想過的事，這都對我未來職涯很有幫助。
在這篇文章中，我想談我們小組如何摸索資料分析的故事線、設計和溝通，並且考慮到保密性以及對同伴們的尊重，我不會談任何細節，還請各位讀者見諒，不過希望剩下的內容一樣有幫助。
This article is mainly about the team dynamics experience and design thinking I had during the project. Complying with the Code of Conduct at Cal Poly MSBA program, I do not talk about any specific detail, demonstrate the end results, or supply business insights in any way.
課程安排和準備
冬季學期的安排是兩門課程和兩個專案，分別是：
- Advanced Econometrics II：時間序列分析
- Data Analytics and Mining：SAS 建模
- Oracle Analytics Challenge
- Dignity Health Big Data Challenge
雖然比起秋季學期少了一門課，但由於兩個專案完全就是時間的無底洞，加上教授們營造的分組競爭，以及我個人反覆無常的得失心，冬季學期的課業遠比一開始看起來重得多。針對兩個專案所做的培訓包括小組討論、進度安排等等，技術上則以之前學的內容（請參見 Cal Poly 標籤）和該學期的 Data Analytics and Mining 為基礎。
由於這些內容跟實際的解決問題、調和小組進度、建模和資料視覺化還是有段距離，我感覺大概有 80% 的內容是在死線驅使下自己摸索出來的。況且在接下來的內容和 Data Analytics and Mining 的分享裡，我也會提到工具和模型的使用本身並不難，注意使用情況和解讀也只是其次，最難也最重要的還是圍繞著模型、構築而成的解決方案。比方說，針對資料建了模型或做了圖表以後，我們會問的問題包括：
這個結果正確嗎？
這是最基本、最常也最該被問的問題。Data Manipulation 本質上是一個取捨資料特性的過程，不管是取平均、加總還是創造 dummy variable 都會微調資料所傳遞的訊息。這時，在整個分析過程中不斷問「我在追逐什麼」、「資料背後有哪些假設」很重要。正確的話，這個結果代表什麼？
這和第一點是類似的思考，只不過涉及更多 domain knowledge。為了瞭解問題是什麼、問題的輕重和改進空間，就得下工夫理解資料提供者的觀點。當然，讀者可能會問「可是我又不是醫生、工程師⋯⋯，怎樣才算做足功課？」我會說可以先以了解結果意義為目標。如何改善這個結果？
一樣，這和第二點是類似的問題，不過換成了由研究者構思可行的解決方案。雖然一個疑慮是「如果連他們都解決不了，我能解決什麼」，但我認為研究者的價值在於不同能力和觀點，以及所採取的不同方法，所以根據分析而得的「曲線拯救」方案，往往就是價值所在。
這三個問題，就像國中課文裡的三個篩子三條高速公路一樣載運生硬的分析結果，並成為觸及整個解決方案的主軸。有玩過 SimCity 或 Cities Skyline 的讀者，應該理解在大學、體育館附近多蓋幾條高路公路的重要性吧？我相信理想上的解決方案，也應該給人遊覽一座城市的感覺。
三個月，五組贏家
言歸正傳，在 Oracle Analytics Challenge 裡我們班被分為五個小組，目標是為 Oracle 分析產品推廣。說到 Oracle 的產品，有點概念的讀者應該知道 Oracle 的產品線真的是五花八門。要在這麼龐大的資料裡尋找商機，確實不是很容易的事，不過久而久之也能觀察到各組採取的不同方法。有些擅長 due diligence 的同學，花了一兩週就對產品的功能和定位暸若指掌；有些擅長建模的同學，則馬上著手測試各種模型；幾位外號叫「大食客」的同學則以開會之名行品酒之實。三個月下來，我相信大家對自己在小組中的定位都有更深的了解，因此不論成果如何，這三個月內全班五組都收穫頗豐。
最後我們組 Team 5 和 Team 4 共同受邀到 Oracle 發表。從成果來看，我們採取的分析角度不同，側重的面向也不同。在我這個光說不練科技宅的影響下，我們組做的方向比較偏為 Oracle 打造可持續的分析工具，「一套任何人都可以接手繼續研究的資訊平台」，相較之下在具體建議方面就比較薄弱；另一組比較強調具體建議，所以雖然分析上沒有用什麼太瘋狂的分析方法，但提出了很多別出心裁的建議。由於兩組做的方向不太一樣，而且都做得很好，最後 Oracle 就選 Team 4 為 Best Recommendation 的冠軍組，我們則是 Best Data Science 的代表。
老實說，現在想想以資料分析和得出 insights 為目標的話，Team 4 做的內容才是比較切題的。一位在場的業界人士和我分享，如果這是一場 Hackathon 的話，五組裡面只有我們符合資格；但換句話說，如果這是一場嚴格以建議和預測為目的的競賽，我們也是最接近失格的一組。對此真的很感謝 Oracle 破格肯定我們的成果，不過會採取這樣的切入點，也和我們一連串的評估和設計思考有關。
在打造火箭的路上
考慮到資料分析能力和研究的最大價值，我們從一開始（有點反常地）就不以模型和建議為主要目的。由於 Oracle 是全球第二大的軟體公司，我們不難想像它們已經有很成熟的資料分析體系，也相信不管是能力或規模，憑我們這群學生的能力都很難正面交鋒，所以當我們坐下來思考怎樣的分析才能對 Oracle 產生最大效益時，我是這麼說服組員的：
We’re not going to build a rocket in eight weeks,
but we should pass on our end results and help them build the rocket.
由於組員們背景也以商業為主，我們同意這是我們能做好、也對 Oracle 比較有益的定位。在我們達成共識後，衍生出來的設計思考包括（ㄧ）可處理新資料的分析架構、（二）淺顯易懂的資料準備過程、（三）完整的 tutorial 和 documentation，當然開源和可持續性也成了必備條件。說到這裡，的確已經和打造工具有幾分相似了。雖然我們並沒有忽視資料分析過程中重要的 insights，但在這些前提下，我們所提的建議難免給人一種「這是用來示範如何使用這套系統」的感覺，這也是我們跟 Team 4 比較大的差異。
不過在看過 Team 4 的發表之後，我看到了就算能力和規模無法匹敵，學生們還是能提出 Oracle 意想不到的建議，也反省了自己先前採取的定位，是否迴避了一些責任。就成果而言，因為採取以上的定位而使得成果更加豐富，算是一件好事，Team 5 也很榮幸能為 MBSA 的歷史記上一筆「打造分析工具」的紀錄。我只是想提醒讀者，建議和方法並不是完全分離的兩件事情，以上的設計思考不僅適用於打造工具，開源、合理和可持續同時也是提出好建議的重要基礎，所以可別抱著「我不提建議，只打造工具」的心態去踢館。永遠要以客戶所需為目標。
決定好方向以後，我們的研究包括「定性或定量」、「提出或驗證假設」兩個主軸。平常組員們會用 Tableau 等工具視覺化資料，我也會試著建立簡單的模型，回報比較重要的變量。這樣的工作大概持續了三週，一面思考產品們的定位，一面挖掘潛在商機。直到第五週的中期發表前，我才開始思考如何整合前面提到的三個設計思考。
在下一篇分享裡，我會談在期中發表前針對以上想法和假設，我如何構思工作流程和設計 Dashboard。由於 Oracle Analytics Challenge 的分享滿長，考慮到閱讀體驗和我的寫作時間，我決定將這篇文章和以後比較長的分享拆成幾篇連載。對習慣一整篇讀完的讀者真是不好意思，希望長期而言這能幫助各位更好消化內容。
走走拍拍：Oracle Corporation 500、小王子徐任宏的城市