機器學習的問與答 ── 尋找成就感
在上一篇和穎鍾的討論中，他說的一句話讓我覺得相當值得思考。
我不清楚在業界到怎樣的地步才算有成就感，之前當學生只要考高分就有成就感
工作中的成就感
一個成人希望在工作中獲取成就感，是正常不過的事。希望獲得成就感，也不代表這個人是工作狂。
一周時間總共168個小時。假設一週工作四十小時，扣掉睡覺以後，工作就是占一周時間中比重最重的。如果在工作時，每天都覺得很累很煩，那會對心理健康造成極大負面影響。所以，我常在思考，要如何讓自己能在工作時保持心情愉快。如果不快，要如何改善，至少不要產生太多負面情緒。
這一兩年，在業界的觀察中，我似乎看出了一些規律。在這篇文章中，我想將我觀察出的規律，以及目前我如何在工作中尋找成就感的方法，分享出來。
以下的觀點，是從我在作資料科學時實作的經驗，加上在和業界其他人的討論中所彙整出來。這並不能代表其他業界或工作，但我想，如果是工作內容和研發、創造、研究有關，或許都有雷同之處，可以作為參考。
挫折感的來源
我認為工作中最大的挫折感，來自於一點：覺得自己是在作沒有意義的事，有我跟沒我差不多。毫無成就感。
之前有個專案，整整三個月，讓我每天都在懷疑自己到底在做這個幹嘛。細節不談，但大致上是有人畫了一塊大餅，畫完以後我作了兩周發現行不通。但因為其他因素，這個專案必須至少作三個月…最後還是證明真的行不通。
這專案讓我開始檢討，到底是什麼原因讓我心情低落，生產力大跌。(如果去看我的部落格文章日期，大概看得出是哪幾個月，我每天回家都不想作事。) 到底是哪一環出了問題？
每天回家只想躺平耍廢
我認為問題在於產品無法「上線」。
上線，英文叫做 production ，就是產品研發到一定階段，開始交給用戶使用。也就是說，開始有研發團隊以外的人在使用作出來的產品，就叫做上線。
那個專案，現階段根本作不出實用的產品。所以無法實際進到用戶的手中。
回顧以後，我發現，當我覺得自己工作時的成果毫無價值，就會產生挫折感。而一個專案上線所需的時間長短，是決定研發類型工作讓人有成就感或是挫折感的關鍵。
成就感的來源
為什麼健身房牆上掛滿大片鏡子，淋浴間裡要擺體重計？因為鏡子給人成就感。練完以後肌肉會膨脹，重訊完的顧客照鏡子時心裡會想「喂，好像大一點了喔？」作有氧減重的顧客，沖完澡一量就會看到「好像瘦一點了喔？」
雖然肌肉並不會一兩天就變大，脂肪也沒有燃燒得那麼快，但利用鏡子和體重計，及時滿足顧客，顧客就會建立信心，養成上健身房的習慣，公司才開得下去。
不管作什麼事，成就感最大的來源都在於「可見，確實的進步」。同樣的原理，也可以應用到日常工作中。
我好棒
這個道理並不難懂。但是我發現，要將這個原理應用到工作中，還有一些基本問題尚待解決：
練身體，照鏡子，量體重，可以馬上看到結果。但如果像我一樣，被分到的是一看就覺得兩個月內實用價值是零的計畫，那該怎麼辦？沒有客戶時，上線是什麼意思？這種情況下，什麼叫作上線所需的時間長短？
專案的類型
以我接觸到的問題來說，大致上可以歸類為下列兩種：
1. 只要有1%的進步，用戶就能用
舉例來說，當公司內部的某個流程有個既定的作法：可能是客服、供應鏈、法務、生產流程等等，十幾年來都是這麼作，也賺了很多錢。但有一天，有個人突然發現：「欸，明明是每天都在作的事，怎麼我們好像從來沒有試著改進過？」接著，把這個問題丟給你的團隊，看能不能幫助他們進步。
這種情形，適合建立「曳光彈」(tracer bullet) 式的產品。也就是用最簡單的方法，先解決1%的問題。產出的結果，可能從資工或是統計學家的角度看起來很廢，但是只要能有1%的進步，就是進步。
通常目標都是把全人工的流程中的一小部分替換成自動化流程。舉例來說，如果需要人工分類或是處理的東西，像是投訴、詐騙案件之類，如果能先找到一小塊保證可以用數據自動化的項目或是分類，對方馬上就可以用。
想要在這類型的專案中獲得成就感，那就要盡早把第一批成果交給用戶。
這也是為什麼我在業界集會時常常聽到人說，機器學習其實還是線性模型—如 logistic regression—的天下。原因不是因為準確度高低還是什麼線性模型能解釋參數的問題。而是因為模型越簡單，上線的速度越快。先把最簡單的東西放進去，讓客戶能開始用，再進一步改進。
通常把第一步作出來，並且把和模型無關的工程問題都解決掉以後，會發現心情很好。因為有人在用我作出來的東西。之後不管在進一步改善時是成功還是失敗，對照之前都是進步。
(註：所謂曳光彈開發是我在 Pragmatic Programmer 讀到的作法，也是軟體工程中敏捷開發的早期想法之一，我之後會寫一篇文章討論。)
2. 擺明了就是異想天開的問題，無法預料作不作得出來
瞄了一眼就覺得至少一年之內不可能上線。但是上層想試試看。這問題如果推不掉，十之八九也做不出來。除了臉很臭埋頭幹下去以外，還能怎麼辦？
以機器學習來說，有些問題要在幾個月內達到能實用化的水準，幾乎不可能。通常類型的問題，在公司能用的資料上可能還會藏著重大缺陷(不然就不是問題了)，所以無法掌握進度，也沒辦法像情形1一樣，作一點就把產品推出去開始幫公司賺錢。
我花了一年多才理解，其實這類型的專案，所謂的「上線」並不是指把產品做出來。對公司來說，重要的是在專案中所學到的功課。
這類型的專案和曳光彈不同，是「原型」(prototype)。
建立原型的經驗，如果之後能幫別人和公司省下時間，就是創造價值。
因為沒有人作過，所以不管是誰來作，都要花很多時間摸索。為了避免其他人重蹈覆轍，要如何把自己在摸索和挫敗的過程中所學到的東西，轉換為全團隊，甚至全公司，未來在開發類似的專案或產品時，能作為參考的範本？
這種情形下所謂「可見的進步」，代表用一個公開、透明的方式，可能是一系列定時發表的內部文章、報告之類，讓其他人知道你在作什麼，有什麼事可以試，什麼作法試了是浪費時間，那些是好資料，那些是爛資料，等等。
以製造業來說，設計師的汽車原型可能是用厚紙板作的，不是實際能開的車。但是作出幾種不同的外觀，秀給其他人看，大家心裡就有底，或許什麼是好的設計，什麼不要浪費時間。在機器學習或是資料科學中也是這樣。
和學術界不一樣，在學術界的實驗中，做不出來通常代表發不了文章，所以就只能進垃圾桶。但是在業界，就算作不出來，也可以寫下來，而且別人還真的會看。
就算剪錯線，也是後人的借鏡
或許有人會說，我寫下來怎麼知道會不會有人看？用心寫一定會有人注意到。不管是高階主管還是基層員工，沒有人上班時是 100% 都在做自己那天該作的事。總是會有在公司網站或什麼地方閒逛的時候。你寫下來，別人逛到有興趣讀過，就是幫別人把工作時的零碎時間轉換成未來的價值。
一邊做一邊寫
當我開始把自己的經驗整理出來後，我發現兩件事：
-
在寫下整理的過程中有時會有新的點子冒出來。
史蒂芬金在他談寫作的書 On Writing 中說：
Writing is refined thinking. (寫作就是淬鍊過的思緒)
我覺得很有道理。如果沒寫成文字或是用圖表來考慮如何表達給其他人看，有時在研發時會變成鑽牛角尖，去解決一些不合效益的問題。一邊學一邊紀錄，根據我的經驗，反而會讓自己更有效率。
-
除了可以幫助自己進步以外，大家還會覺得你做了很多事—雖然我花在工作上的時間並沒有比別人多。人的觀感是相當奇妙的東西。
我博班時的指導老師其實常常跟我說一邊做一邊寫的重要。不過那時我對學術研究的熱情完全燃燒殆盡，所以打算把論文寫完就算了。但現在進職場發現，原理是一樣的。
「定期發表」其實是個很好的動力來源，還有一個原因：不管成功還是失敗都能作。所以就算加上了「定期」這個時間條件，和模型的準確度這類需要看天吃飯的目標不同，是一個自己能完全掌控的目標。
(註：在寫教學時，不用覺得，啊，這個網路上就有了，其他人自己可以查，我再寫一遍是不是讓人覺得很廢。其實很多時候 1. 好的作法沒那麼快查到 2. 還要過濾不同版本跟不同開發環境，相當花時間。花兩個小時好好寫一寫，一年可以省下自己和其他人至少十幾個小時，是相當划算的作法。)
當然，其他人有沒有興趣，會不會看，和定期發表不同，是我無法掌握的變因，所以不能把「有沒有人看」當成目標。當我把想法轉化成文字、表格、圖片、或是影片，第一個受益者就是自己。所以在寫的時候，可以把對象設定為一位讀者(自己)來寫。
即使是天馬行空的專案，也能在其中找到成就感。就像上健身房一樣，肌肉長大或體重下降是結果，而不是過程。過程是定時定量的訓練。把目標設定在訓練(整理、發表)，自然就會在鏡子裡看到結果(成就感)。
我目前的作法
成就感來自於看得見的進步，而何謂進步要視問題類型而定。
-
如果待解決的問題是屬於只要有任何結果，客戶都能用的類型，那就要盡早作出第一批結果上線。速度比品質重要。
先搞出一個東西，解決燃眉之急，其他之後再談。成果不一定是一個模型，可能是一個網頁秀一些圖表，可能是一封附報告來解釋數據的電子郵件。都可以。
-
如果待解決的問題是屬於異想天開類，所以需要大量摸索嘗試，那就要把學到的功課記錄下來，並且在公司內部分享出去。讓別人知道什麼值得嘗試，什麼是浪費時間。省下未來摸索的時間，就是在幫公司創造價值。
寫下的東西，可以是和專案相關的想法，可以是發現公司數據上以前其他人沒有注意到的細節和邏輯上的改變，可以是嘗試不同演算法得出的結果，可以是一篇關於某個程式模組的教學等等。只要能傳播知識都可以。
這是我尋找成就感的方法。
你是怎麼在工作中尋找成就感？歡迎一起討論。
系列文中的其他文章：