今天不寫 code -- 聊聊那些我覺得中用的軟實力

在這篇文章中，我分享到初入工程師職場時，一些仍派得上用場的既有職場技能，而且幫助的效果是讓同事們覺得有感的程度。轉正之後，這些乍聽之下與工程師搭不上線的技能，依然發揮正向推進任務的作用。我想這值得我用一篇文章，好好分享這個經驗。

話說在前頭：這些軟實力，應該在不同領域上都派得上用場，如果你所在的職位剛好需要這些技能，歡迎酌量參考😊

簡報力

就從在面試到專案都讓主管覺得滿意的技能開始吧😆

過去，我都在數學教育領域打滾，經歷過3份工作，內容與性質不盡相同，但絕對少不了滿坑滿谷的簡報。無論是為了錄製教學影片，還是為了為現場老師辦研習會，幾乎每個月必定有數日在製作、審核、上台講簡報。

如果只是講話，而且講的都是硬邦邦的科內知識，想必會讓聽者覺得枯燥無味。因此，除了想辦法把講的內容變得比較有趣、好理解之外，另一個關鍵就是做出能與內容搭配的簡報，達到加分效果。

我從累積至目前為止的簡報經驗，歸納出了自己做簡報的心法：盡可能圖多於字，即使只有文字，也應該是為聽者整理後的重點，且每一頁的主題明確、資訊份量適中，讓讀者跟得上你的節奏。在大多數的情況，人喜歡看圖的程度，依然比看文字高，所以盡量用各種形式的圖，表達原本想將的內容，相信能一定程度地輔助聽者理解。

相對的，如何選擇合適的圖，就至關重要。以統計圖表來說，網路上就能找到很多誤用的案例，至少先避開這些地雷；其他類型的圖，可以參考以下我會用的準則：

• 圖片色調盡可能與整篇簡報的主題色調一致，至少自己看不要覺得怪
• 如果插圖（非真實照片）不是該頁簡報閱讀的重點，盡量選線條簡單的
• 盡量讓一個圖代表一個意思就好，不要多工（e.g. 在前面幾頁簡報，用某圖代表檔案，這個圖在後面就不要用來表示實體文件 or 其他不是檔案的東西）

雖然現在生成式 AI 也能幫忙做出不錯的簡報，但我建議審閱一下生成的內容，做成自己看得懂、講得順的版本，所以一些基本的簡報技能還是不能少啊！

寫作力

即使是工程師，也要處理很多自然語言的訊息，包含撰寫程式碼的途中，留下 comment 註記某段的重點； push 程式碼到 GitHub 時，需要填寫 commit message。就連向 Gen AI 問問題的 prompt，都是要好好寫下文字的工（難道你要跟 Gen AI 比誰比較會胡說八道 XD？）

在數學教育領域中最相關的任務，就屬「命題」了吧。撇除一些搭配數學關係式的慣用語句，要如何好好組織一篇完整結構的題目與問題描述，還要讓初學這些知識的學生看得懂，就讓不少現場老師傷腦筋了。我在最後一份跟數學教育相關的工作中，接觸到科普寫作，要面對的困難跟命題工作也相去不遠。

總結來說，目標就是以圈內、圈外人都看得懂的用語，寫出對大家都好讀的內容。聽起來就像「小孩子才做選擇，我全都要」的不切實際，但我認為這對寫作來說，是值得努力的方向。如果只是要應用在工作中會遇到的寫作場景，我想除了一些通則外，也可以根據讀者來調整一些細節：

• 盡可能維持「主詞+動詞+受詞」的句子結構，想像是讀者就是主詞，要跟著你的描述做動作（e.g. 與其寫「把程式碼寫好」，不如寫「寫好程式碼」）
• 在架構完整的條件下，可以用更少的文字寫出想表達的內容，就用少一點的字寫
• 寫出來的文字，如果用嘴巴讀出來也是順的，八成沒有太大的問題
• 如果無法確定讀者的預備知識多寡，就以「擁有最少預備知識量」的情形，思考用語及想要揭露的知識深度，目標是讓讀者理解＆讀完你寫的內容（e.g. 與其說「二次函數曲線」，不如說「拋物線」；如果讀者只需要知道「拋物線有最高點」，就能理解接下來的內容，就不要提到「怎麼求出拋物線的最高點」或「為什麼拋物線有最高點」）

同樣地，現在 Gen AI 已經能組織出差不多像樣的文章，但即使在 prompt 寫的需求再怎麼清楚，依然不能跳過審閱的步驟；身為提供 prompt 的人，如果連你都看不懂 Gen AI 在寫什麼毛，怎能期待你的讀者會看得懂呢？（別輕易假設讀者比你厲害😅）

溝通力

這裡提到的溝通，並不只是「說話」，而是更著重在互動的過程。「你這個人很難溝通！」經常在氣氛緊張的討論場合中出現，大部分可以歸因於討論時的互動出了狀況，當然「說話」本身也是變數之一，而且觸發者可能來自多方（包含自己）。可想而知，要解決溝通上的問題，是件非常有挑戰性的事。

我曾處理過的溝通情境，除了日常問題討論之外，還有舉辦大大小小的研發討論、評量共識等會議，規模從3-5人到20人左右的都有。雖然我在這些情境擔任的角色有點不同，但處理溝通的手段，其實有不少共通的部分，像是說清楚問題、聽懂別人的回應、彙整多方描述、釐清異同與影響、歸納共識與結論。

看起來用到的手段不少，但我覺得可以再精煉成「說清楚問題」與「聽懂別人的回應」。關於「說清楚問題」，我認為可以套用多數前面提到「寫作」的原則，而「聽懂別人的回應」，也可以透過「說清楚問題」來操作：把你理解到的內容，再說清楚給對方聽，確保彼此認知一致。關於彙整、釐清、歸納，其實也是透過不斷地「說清楚」、「聽懂」的循環建立而成，只是隨時討論推進，要說清楚什麼與聽懂什麼的目標不同而已。

至於怎樣讓「說清楚」、「聽懂」的過程流暢，可以參考我目前採取過的方式：

• 說清楚問題的同時，也要說出期望取得哪些共識與結論，避免過程太發散
• 在適當的段落，歸納目前取得哪些共識與結論，以及還有哪些沒討論到、或者尚未有共識的問題，除了提供停頓休息的空檔，也時時 align 大家的認知
• 善用工具，記下可以幫助回憶討論重點與結論的筆記，把大腦空間騰出來用在思考與理解上
• 當發覺討論脫離原本的主題，或者時間拖太久了，要嘛趕緊拉回一開始要討論的主題，要嘛先暫停休息一下，留點時間給大家＆大腦 refresh。如果是因為複雜度而卡關，不如再另約時間，但最好請大家準備好自己的想法，帶到下一次的討論

雖然我分享了許多實現的方法與原則，但我認為還有繼續摸索、學習的空間，或許未來遇到很不一樣的情境時，又會有不同的心得，也很難說不會打臉現在的自己 XD 如果那個時候真的到來，再來跟各位報告囉～

Epilogue
前陣子在忙一個大專案，趁現在客戶 UAT & 正式上線前的空檔，來更新一下這個系列。畢竟這個系列是「今天不寫 code」，忙著寫 code 的話就沒辦法更新，也是很合理的吧（？