會議不是語言考試，掌握3點技巧彌補語言能力上的不足
北美科技業職場生存日記
在香港當過4-5年團隊領導，主持過的會議規模小至1:1，多至50人的客戶會議，自問對主持會議有信心，雖說不上專業，但也不算生手。
不過，在加拿大入職後第一次主持工作報告會議體驗卻很糟糕，覺得自己英語不夠好不夠流利，有時候沒聽明白別人的提問，更要對方重覆幾次或找同事幫忙回答才能勉強過關。
那次會議後我向同事感謝他們對我的體諒，表示自己會在英語上多下功夫。雖然他們口上都說我英語沒問題，但我始終感覺難受，未能在第一次報告會議為自己建立好印象。
尋求前輩的意見
在那次主持會議後，我向主管和團隊中的一位Scrum Master的1:1請教過關於我在會議中的表現，奇怪的是
他們都說我英語沒有問題
明明一時三刻想不起適用的詞彙時會卡個2-3秒。
明明有時候在開始說話前沒組建好句子，導致話說到一半要重說。
明明有時候聽不懂對方的提問，導致要對方重覆或要同事協助才能解答。
難道不是英語的問題嗎？
然而，他們指出身為會議主持，要做的不是說話流利，雕琢文字，而是有效地傳達想法及資訊。Scrum Master更以例子向我講解3個匯報技巧，親身嘗試後不止覺得內容結構清晰了，更提高了對會議的掌控度，感覺更得心應手。
以下是他提到的3個方法，亦是我會在這篇電子報向你分享的技巧：
想想與會者想從會議中得到什麼？
由淺入深
圖像比文字更快傳遞資訊
想想與會者想從會議中得到什麼？
還記得剛踏入職場，每當我要主持會議時，其中一個常犯的錯誤就是只顧
我要說什麼
很正常，試想想我們讀書時期作匯報時，都是老師先給一個主題，我們要做的就是搜集資料、分折、加入見解、寫PPT，最後在課堂上匯報。
雖然班房內有其他同學，但真正的觀眾只有一位，就是負責評分的老師，加上我們在事前已經知道評分準則，只要有針對準則發揮，表現不會差到那裏去。
相反，在職場上，會議前不一定有人會事前跟我說會議的目的是什麼，主要靠的還是經驗。其中一個方法是先參與幾次會議，大概了解模式後，輪到我主持就跟大隊以差不多的形式進行，就不會犯什麼大錯。
但想要做得更好的話，就需要學會想以下問題：
與會者有什麼人？
與會者想從會議中得到什麼？
比如說技術分享會，與會者大部分是工程師，他們想聽的是一步一步的實操方法，流程圖及程式碼是工程師的最愛。
而在有高層參與的專案進度會議，當中可能有管理層、專案經理、領導，這類會議很少提及技術細節，更著重的反而是有沒有遇到什麼難關、解決辦法，和進度是否符合預期等等。
以銷售來作比喻，會議中的主持就是銷售代表，而與會者就是客人，要成功把東西賣給客人就需要知道客人正面對著什麼難題，再解釋自己的產品能怎樣協助客人解決煩惱，才能讓客人心服口服地把錢交給自己。
由淺入深
另一個由軟體工程師主持會議的通病就是
預設所有與會者都會寫程式和知道匯報內容的背景
這是一個極大的錯誤，輕則浪費首10-15分鐘後要重新解釋會議背景，重則大家在離開會議室後都不知道整場會議聊了什麼。
軟體工程師平時就是寫程式碼、系統設計，合作的人大多都是軟體工程師，就算我只會Java，你只會Python，句法(Syntax)不相通但退一步講物件導向程式設計(Object Oriented Programming)總能溝通。
因此技術會議還好，在場都是工程師的話可以直接講程式碼、流程圖，但到跟專案經理、主管，甚至有董事的會議時，就不知道應不應該開會直接進入實施細節。
這時候就需要有一個暖身，讓在場人士在幾秒前的聊天、電郵內容、客戶電話中拉回會議。
例如會議內容的是一個座位預訂系統的數據即時更新功能，只有技術人員的話我可能會這樣說：
現時系統以Short Polling Web Request由前端發送請求到伺服器讀取座位數據
我們想研究以Long Polling、Web Socket或gRPC來減輕前後端效能上的負荷
後端則想以Caching、建立資料庫索引(Database Indexing)、減少資料庫讀取來提升後端效能
假設大家都知道現時的問題，直接指出可行的解決方案，再繼續進行討論。
有效、快捷、直接。
但假如有管理層或其他部門在場的話，他們不見得已了解來龍去脈，也未必明白那些技術用語，於是我就會加插一小段概要在前面，大概流程變這樣：
現時系統的其中一個功能 - 座位數據即時更新，主要讓用家可以即時了解餐廳座位的使用及預訂情況
但根據客戶回報及內部檢測數據顯示，現時用於即時更新座位數據的前後端請求對系統效能造成影響(能寫出確實%數據更好)
因此我們想要對此功能的系統設計進行改善，以下是分別針對前端、後端，及資料庫的改善方案…
先簡單交代主題，指出問題(Problem Statement)，提出解決方案，再深入交代方案細節。
由淺入深，就算是非技術人士，也大概會知道會議的目的，未至於渾渾噩噩漫無目的地渡過會議的2小時。
圖像比文字更快傳遞資訊
相比起文字和數字，決策者往往更喜歡圖表、流程圖，因為它們能把過於冗長、詳細的內容抽象化(Abstraction)，能在更短的時間內掌握資訊。例如：
把程式碼中的if、else、elseif、loop以流程圖表達
把並行使用者(Concurrent User)的數量跟系統效能的數據以趨勢圖表達
把系統不同部件之間的運作步驟以序列圖(Sequence Diagram)表達
把Jira上的專案進度以甘特圖(Gantt Chart)表達
把專案的工作以整合計劃圖(Integration Plan)表達
其中一個我最喜歡的是序列圖，以前的我經常要解說某個功能不同系統之間如何交換數據，純粹以文字作匯報的話，容易造成資訊散亂的感覺。
第一步我會先把文字轉換成要點(Bullet Point)，每點只寫
系統A向系統A/B做了C動作
例如前端網頁向後端API接口發送付款請求、後端付款服務把數據儲存在資料庫、後端付款服務向第三方付款服務發送API請求…
有了這些要點後，每個流程的主體、受體，及所發生的事情就一目了然。
第二步我會把要點轉換為序列圖，sequencediagram.org是一個我常用的免費工具，能夠以寫虛擬碼(Pseudo Code)來產出序列圖，虛擬碼還能上傳到Git進行程式碼管理，不用以v1、v1.1、v1.2…來管理圖表版本。
英語只是溝通工具，做好溝通的角色就夠了
掌握以上3個技巧後，我不會說自己主持會議進步了很多，但從蛛絲馬跡中可以看到大家對我匯報內容的理解比以往高：
少了很多關於會議目的、內容澄清的問題
提問變得深入
減少會議超時的次數
與此同時，以上技巧並不完全只是“門面技巧”，我需要花更多時間心力在會議的準備功夫上才能有效地套用它們，準備多了自然會提高自信，更有信心在大家面前說話。
而英語程度？能夠不影響表達就夠了。
讀書時上中文課老師要求我們讀文言文，上英文課要讀文學作品，但實際出了社會，又有多少工作需要對語言有如此高的要求？
因為由始至終，語言只是用於人與人溝通的工具，水平能達到不影響表達個人想法就足夠應付工作。
可能你會問什麼是“不影響表達個人想法”的水平，我曾經為此問題困擾過，在看了一些在YouTube上模擬IELTS對話考試的影片後，我認為5.5-6是最低標準，不算流利但足夠以英語有效地表達想法，就算用詞欠準，句子結構欠佳，對方根據對話的前文後理也能理解話語內容，在加拿大從事非服務行業感覺夠用了。
職場小挑戰
我在這篇電子報分享了3個用於匯報會議的技巧，雖然對你未必完全適用，但我覺得最具挑戰性的是第一步，亦是這次的職場小挑戰：
向一位同事或上司請教自己在主持會議時的表現
可能每個人給予你的答案都不同，但其中一定有幾點能讓你學會從他們的角度看自己。
多尋求回饋，多嘗試就是在職場上進步的關鍵。