近日在工作上遇到了一件讓我啼笑皆非的事，雖然對於在職場上已經打滾了一陣子的人來說，這可能只是司空見慣 (也有可能是身為工程師的我實在太少跟工程部門以外的人交流了)。
最近我的小組要收集數據，找出系統中哪些功能最需要進行重點的效能測試。以前在其他公司也有做過類似的系統效能測試，但大多數情況都是工程師自己指出系統有可能出現效能問題的地方，然後寫案例、開發工具 (較常用的是 Selenium 和 JMeter) 去測試。
這次有點不太一樣，我們想要從不同部門獲取意見，並儘可能跟最接近真實用戶的部門溝通，例如銷售、技術支援部門，看看會不會有些意料之外的發現。
在參與了幾場會議之後，我才發現自己忽略了一個非常根本的問題，就是原來大家對「系統效能」這四個字的理解，可以相差這麼遠。
系統效能是什麼？
當了 10 年工程師，一提到「系統效能」我就馬上聯想到這些：
反應時間 (Latency)
吞吐量 (Throughput)
資源利用率 (Resource Utilization)
可用性/系統上線時間 (Availability/Uptime)
然後就會想辦法去收集這些數據、找出瓶頸位，再從快取、演算法、SQL 語法等方向嘗試解決，再不行就直接燒銀彈升級硬體規格去提升「系統效能」。
然而當我們跟銷售部門同事開會時，他們口中的「系統效能」，跟我認知中的大相逕庭。
他們所理解的，更多的是用戶體驗 (User Experience)，任何會令用戶感覺到畫面在載入的瞬間，都可以是效能問題。
他們提到的其中 2 個現象，對我來說還挺新鮮的 (雖然現在回想當自己是系統用戶時，也有同樣的想法，無奈公司沒有餵狗糧 dogfooding 的措施，我都沒怎用公司的系統)：
第一種情況是那些明知道需要下載大量資料、需要等待的功能，例如我們玩線上遊戲時的更新、Windows 的更新、上載系統備份到雲端等，這些預期中的等待，大部份人都是接受的，而且這些功能普遍不常用，可能一天、一週、或幾個月才一次。
從銷售同事口中得知，這些情況下，用戶會在按下按鈕後，安心地離開座位泡杯咖啡、吃個早餐，過 15-30 分鐘才回來看系統跑完了沒有。這種預期中的等待，通常不會被歸類為效能問題。
(驚嚇到我的點是，他們提的例子是登入，原來當用戶的系統規模大到一定程度，登入要花 15-20 分鐘，好在他們一天只需要登入一次)
第二種情況是需要頻繁操作的日常功能，比如說 Google 搜尋、在手機看短影片、發短訊，這些差不多每分每秒都在用的功能，只要系統出現明顯的延遲，大概等個 5-10 秒，就已經無法接受了。
問題是，第二種情況很少機會是簡單改幾句 SQL 就能解決的，更多時候是需要架構重建，假如系統有一定的複雜程度，還可能不是幾週或幾個月就能完成的事，所以更具 CP 值的方法是從用戶體驗著手，例如前端改成分批載入、漸進式載入、分頁、加上資料夾分類，讓用戶不用一次看到那麼多資料。
這些手法雖然能從體感上讓用戶覺得系統「不慢」，但其實後端設計沒怎麼改動過。在不少工程師眼中 (包括我)，從來沒將它們歸類為系統效能問題，而是 UI/UX 部門需要處理的事。
熱情的銷售在會議中依然熱情
發現了這個認知差距後，我們小組屢次想要把會議的重心拉回我們認知中的工程效能上，畢竟他們提到的那些前端體驗問題，我們可以轉交給 UX 或是產品團隊。
但無奈的是，銷售部門的同事真的真的太熱情、太愛說話了。
每當我們試圖把話題帶回資源載入、系統反應過慢這些地方時，對方的兩位代表就會非常順暢地接過去，像唱雙簧一樣一唱一和，一位說完直接邀請另一位補充，然後那位同事又說要做個 Demo 讓我們更容易理解，完全沒有留給我們插話的空隙。
加上他們手頭上似乎真的沒有太多針對工程層面的系統效能意見，結果就是整個小時的會議裏，大概只有短短的 15 分鐘真的有討論到我們想聽的效能層面。
雖然我們的得著不多，但會議後我們總算把記下的 UX「效能」問題轉交給了負責的團隊，算是一次默默為大家排憂解難的跨部門互助。
會議的藝術
這次的經驗讓我留下了兩個很深的體會：
首先，如果與會者的背景差距太大，而且我們有想要達到的目的的話，會議開始時我們必須要主導會議。花個 5 分鐘講解一下會議的目的、期望，在提問的同時，最好直接先舉幾個具體的例子，對齊大家的理解。提出的問題越空泛、籠統，就越大機會在理解上出現落差，結果大家各說各的，很容易令整場會議歪掉。
與工程會議 (尤其是與同組工程師開會) 不同的是，大家背景差不多，同樣是工程師，一起做同樣的專案，對事情的理解差別不大，就不太需要花過多時間去對齊，會議前在 Slack 說一句「我們想討論 A，而 B 則在明天的會議才討論」後就能直入主題，簡單快捷。
其次就是前主管教會我的一件事，這些對齊的問題最好在開會前就解決掉，不要浪費會議的時間。他常說，任何會議開始前，都要先準備一些簡單的材料，哪怕只有幾行字都好 (例如討論系統設計時事先準備 1-2 個選項，有時間的就畫圖準備 PPT，沒有的也開個 Notepad 把個重點寫下來，並且加入到會議邀請中)，這能讓大家在討論時有個共同的根據，而不是憑空想像。
他說大部份工程師都好商量 (我覺得這視乎公司和團隊文化吧，在香港這些會議材料做得不好很容易成為其他部門批評的地方)，他們不會因為準備不足而在會議上令自己難堪，會儘量想辦法一起推進會議進程 (但私下怎樣想就不能保證了)。
職場小挑戰
當了碼農快有 10 年的時間，我覺得身為工程師最難的不是寫程式碼 (而且現在有 AI)，而是怎樣跟非工程師溝通，用另一句話說就是跳出工程師的同溫層。這次的跨部門會議雖然有點歪掉，但也逼著我們學習從真實用戶的角度去審視系統。
不論你在香港還是北美，開會都是一門技術活。在開會前處理好對齊的工作，就像工程師擅長的防禦性編程 (Defensive Programming)，在事情開始之前，先把邊界定義清楚。
這次的分享跟會議有關，所以我給你的挑戰是：
下次你發起會議時，不論規模多小，試著在發出日曆邀請的時候，在描述欄寫下：
會議的目的 (We want to achieve X)
超出討論範圍的議題 (Out of scope: Y)
開會時要根據哪一份筆記或哪個畫面來討論，最好直接附上連結，不然會後通常有人會問能把 PPT 或材料轉發給他們嗎
然後才發出，逼使自己在會議開始前，必須要有所準備。
最难的事情当然是沟通。我职涯到现在越来越像个译员而不是工程师了。