clsung is reading

人臉辨識是近年來非常流行的技術，如今幾乎已是深度學習的天下了，而這門技術的應用上，現在還是非常的火紅的話題。這次參加的 LINE DevDay，就採用人臉辨識當做報到的機制。

而在第二天，也安排了議程來說明 LINE （NAVER）是如何開發、設計與導入到 LINE DevDay 2019 會場的報到流程。

由於我們自己也有在研究人臉辨識，也有用在 check-in 上（我們叫刷臉打卡），所以在第一天報到的時候，就有特別注意一下偵測的時間，以我報到的經驗，大約花了3~4秒（兩天都是），並沒有像官方宣稱的不到一秒，但搭配一直轉圈圈的 UI ，也並不會讓我感覺到等很久。實際體驗的時候， iPad App 上的圈圈會跟著你的臉部範圍動，所以可以推測時間是花在臉部特徵擷取（Facial feature extraction）或是特徵比對上。既然講到此，我們就先由講者的第二段（Face Engine）說起。

• 

• 

人臉辨識目前的作法都是 1) 偵測人臉 2) 對齊人臉 (alignment) 3) 臉部特徵擷取 4) 人臉特徵比對 。通常步驟 1/3 是相對容易的，而 2/4 就比較難了。 2 的問題是人臉的角度通常不會剛剛好，要正確定位眼鼻口眉毛並不是像一張面膜一樣貼上去就好（為了說明方便，實際上不是去定位這個是眼睛這個是嘴巴）。而 4 的問題在於，當資料庫愈大的時候，需要比對的資料就更多，計算量也就更大，要在短時間就做完，沒有硬體（如 GPU ）的幫忙，通常就要在演算法上鑽研很深才行。所有會需要上線深度學習模型的團隊，都會想辦法去做 model size reduction/compression (without losing too much accuracy)， NAVER 團隊同樣地也花了不少時間在做深度學習模型的優化。團隊的目標就是在行動裝置（也表示不見得有 GPU ）上能達成即時的人臉辨識：Our standard is real-time in mobile CPU environment。由投影片的 16~55 頁有團隊的實驗成果，在此並不贅述。不過不像 Clova team ，並沒有看到團隊的論文發表，不太確定實際的成果為何？

回頭來講臉部辨識應用，不外乎 1:1 、 1:N 的應用場景，而即時辨識的場景對於 UX 的要求更是重要，對於刷臉報到來說，如果節省等待時間、辨識時的過場畫面（不會讓人感到不耐煩）、辨識不出的解決流程，其實這考驗主辦單位的場控能力，有 UI 呈現的地方，就會需要排演 SOP 。這次的報到入場我覺得還蠻順的，但是也可以感到 LINE 官方對於這個的重視，許多工作人員也跟在旁邊引導。

由演講可知，講者也是在第三段接著討論臉部辨識的核心實作到服務應用。這次的報到是有 App 的，配著投影片也可以看出是 Client/Server 架構的，由 Client (App) 負責做 Feature Extraction ，接著再傳到後端 Server 做比對。

由上面幾張投影片可以了解透過好的 UI/UX 設計，可以降低錯誤率，為什麼呢？因為對於臉部辨識引擎本身，它就是 API 有傳進來的臉部特徵就會去比對，如果前端的介面設計是什麼都往後面丟，那整體的效果就不會太好了，所以實務上不需要處理太多 corner case 的情況，就是把這些可能會出錯的，由前端的 UI/UX 來避免。當然，這不是說 UI/UX 就不用寫程式，像上面寫的眨眼偵測啦，或是角度，那些也是要開發程式的。以 LINE 在這次 DevDay 之前，也是做了幾次實地測試（Field Test），可以感覺出來他們是愈來愈有信心了。

照舊，放上一張圖當結尾（雖然我認為還要加上 UI/UX 才更恰當）。

近十年來（其實應該超過十年了），敏捷開發逐漸在軟體工程中佔有一席之地，這個的定義大概就是如果有人說他做軟工的，那你可能會回一句「所以你對 Agile 應該很熟吧」

在 LINE DevDay 的第二天下午，有個議程也是在分享 LINE 內部是如何進行專案管理的。講者所在的部門很特別，稱作「Effective Team and Delivery Department」，由名稱可以看出來這個部門的重心。通常接著的關鍵字就是 Project Management 、Product Management 、 Agile 或 Scrum，果然講者的背景也是如此，不過多了 Engineering ，這也是符合 LINE 的企業文化。

左邊的子部門 Delivery Management Team 中，是由一群 TPM (Technical Project Manager) 組成的。 LINE 的文化認為 Project Management 對於 Product delivery 是很重要的，但 Project Manager 這個角色並不是那麼地被需要；也就是說，LINE 的 TPM 負責的並不只是 Project Manager 這個角色任務。

上圖可以看出他們對於產品開發中，對於 Product/Project Management 與 Development 各自的角色工作定義，一般而言對於前兩者的角色也就是稱為 PM (Product Manager/Project Manager) ，而後者就包含了 Engineer / QA 。

而講者藉由 R & R 的示意圖，說明 PM/Eng 雖然工作是有各自的職責，但在實際上的產品開發合作上，卻不會那麼壁壘分明。當彼此的界限模糊的時候，就不容易有事情掉在地上沒人做的時候了，不過以我自己的經驗，我認為要達成這個目標，除了企業文化能支撐之外，團隊的成員心態也非常重要。而心態的養成，也與主管甚至高階主管的支持有非常大的關係。以這個角度看，也許 LINE 做的很成功？（因為沒有在 LINE 任職，有些內部衝突是看不到的）

談完了左邊的，接著拉到右邊的子部門 Lean & Agile Team。在這方面， LINE 的 Agile 也奉行「Be Agile, not just do Agile」，以落實 Agile 的價值與原則為主，而非一昧採用其方法論。

整個部門工作重心是以 Support 其他部門為主，這中間包括了提供訓練、協助解決問題以及建立內部跨域的社群（這點就跟目前很多的社群 meetup 是一樣的意思）。

簡介完了之後，搭配而來的就是實際例子，講者是以 LINE News 的產品開發為例，但我想組織圖應該是可以通用的。

通常一間大公司的組織也就大概長的像這樣子，這類的組織特性是有管理者們層層把關，做一個既有產品的優化是很容易的，因為管理者（或是資深的老鳥）可以靠著過去的經驗來判斷；但若是產品還在初期的階段，從這個角度看上去，就是看到層層的山頭了。

從組織圖迭代的演變，我們可以看得出來，工程師永遠是最好騙講話的（笑）。目前看起來，左方的管理群們一時之間是很難拆開的，這個我想工作個十年的人大概都可以理解是怎麼一回事吧（茶）。

接下來，講者也介紹了以前述三個核心為本的，各式各樣 LINE 提供的 Training / Workshop / Team Building / Community ，這些建議直接連到投影片去看。個人覺得這些文化養成雖然不見得能讓 LINE 變的強大，但是很有機會能讓 LINE 變的偉大的。

最後，放一張 Product Management 的 global view 為結尾（其實我不知道為什麼寫了個 Thailand 卻什麼都有啊）