前言
2024 是個特別的一年，有幸在不同舞台完成了不同規模的分享：
- 2 場 Workshop : 使用 Pytest 進行自動化測試。 (公司內部、40 人)
- 2 場分享 : 建立 Code Review 的思維與團隊 (公司內部、30 人 & 100 人)
- DevOpsDays Taipei (社群演講，200+)
- HelloWorld Dev Conference (社群演講，100+)
前陣子意識到自己在職涯至今的每個階段，似乎都會踏上「分享」這條路，究竟是「喜歡」還是「擅長」，一時也說不上來。但開始體認到：在接下來的職涯中，這或許是個可以好好善用的「工具」。
今年在 DevOps Days 的最大收穫之一，是聽到 Ruddy 老師對於復盤的精彩分享，對於自己重視的事情，其實是需要有意識的「復盤」來精進。因此今天這篇文章，算是分享自己對於「分享」的個人復盤，紀錄自己對於「有效率且有效的分享」這個主題的理解，同時也希望能幫助到有緣人。
(如果你還不清楚復盤是什麼，歡迎你先看看我的另一篇文章 : 【 Reading with ML - 05 】復盤+ : 把經驗轉化為能力)
前期準備
關於「標題設定」與「前期宣傳」
不論是內部分享或公開的社群演講，前期宣傳都是很重要的。
以我參與過的社群演講來說，在稿件確定入選後，會有機會能調整自己的前期宣傳，也就是揭露在網站上的「標題」、「議程簡介」和「聽眾收穫」。
儘管只是寥寥數行文字，但內容品質，會極大程度的影響活動當天的聽眾數量。
(除非你已經是知名度夠高的領域大神，那我相信就算只有神秘的標題，現場還是會爆滿)
在活動當天，潛在聽眾可能是在換場的過程中，才點開議程表查看接下來議程的簡介，如果能在寥寥數行文字中，精準地闡述你想表達的內容，以及聽眾可以帶走什麼，對於吸引人潮絕對是加分的。
當然，前提是初期宣傳的內容要「貼近現實」，可不能仿照標題農場的作為，寫得五光十色、內容貧瘠無比。
(參加研討會最害怕的一件事情：「精挑細選選定一個感興趣的議程，認真聽了十分鐘後，發現原來跟標題無關，是在賣產品」。)
我自己習慣在擬定大綱、草稿後，直接與 AI 工具進行討論，請它協助我產出「吸睛」且「具專業度」的「幾個選項」，我再從這些選項中，組裝出最終版的標題及前期宣傳內容。
(DevOpsDays 的聽眾數量遠超預期，萬分感謝，看到這個畫面頓時覺得付出的心力都值得了！)
關於「投影片」
先確定 Problem Statement 與 Core Value
我在 Ted 人氣講者這樣做搶戲投影片 這本書中讀到 :
我推薦你做的第一件事是找出核心訊息，也就是你希望觀眾從這場簡報帶走哪一個最重要的概念。
你最希望觀眾記得的核心概念是什麼？
什麼是「核心概念」呢？ 我認為包含兩件事情：
Problem Statement :
是什麼原因、問題的出現，而導致了這次的分享？ (為什麼聽眾應該要聽你分享？)
Core Value :
聽眾可以從這場分享中帶走什麼？
為什麼在製作投影片前，釐清「核心概念」很重要呢？
第一個好處 : 在準備的過程中，有助於篩選素材。
過往準備投影片時，我常會採用「先發散、後收攏」的策略，先以 Brain Storming 的形式去發想自己可以講什麼，再將這些內容「塞」進一個框架中。
但後來發現一個問題：投影片容易出現「結構凌亂」的問題，因為每一個概念都想塞進投影片中，導致內容過於發散，雖然跟主題有關，但又好像沒有太多關聯。
當「核心概念」確定後，「素材」是否要被放進「投影片」就有了「篩選」的依據 ：
- 「這個概念跟 Problem Statement 有關嗎？」
- 「這頁投影片對於 Core Value 有幫助嗎？」
如果答案是「否」，那這些素材就不需要被加入投影片中。
下圖是我在準備今年 HelloWorld Dev Conference 時的大綱 :
在收集想法時，先發想並確認左半邊的「核心概念」，再逐漸向右半邊發散自己的想法，由於「核心概念」已經確立，在發想時能有「邊界」來確保自己的素材是緊扣主題的。
製作投影片前，先確定「核心概念」的第二個好處是：有助於吸引觀眾的目光。
我認為在簡報的前幾頁就明確地點出 Problem Statement 及 Core Value，能夠給聽眾傳達一種「俐落」的印象。
當聽眾在簡報剛開始的階段，就能掌握重點及能解決的問題時，才會有興趣跟著講者的腳步繼續前進。除非鋪陳階段的故事性極高，否則過長的鋪陳容易讓聽眾的注意力流失。
製作投影片的「分鏡稿」
過去在做投影片時，常有個壞習慣 : 「一頭栽進 PowerPoint 中」。
想到什麼內容，就先做一頁投影片，做到一半發現排版歪掉了，稍微調整一下。半天的時間就這樣過去了。
這種做法除了「效率不佳」外，還有個問題：
很容易在投影片完成後，出現「頭重腳輕」、「架構鬆散」（講的東西似乎沒有什麼關聯）的問題。
在 Ted 人氣講者這樣做搶戲投影片 書中建議可以用「便利貼」的方式來製作投影片的「分鏡稿」：
- 每一頁分鏡稿透過「文字」或「塗鴉」的形式，描述該頁投影面想要傳達的內容。
- 使用便利貼做為投影片的載體，能以俯瞰的視角，了解目前投影片間的關聯性。能隨時「自由挪動」，確保整份簡報的流暢度。
我非常喜歡「投影片的分鏡稿」這個概念，先以「分鏡稿」確認整份投影片的骨架和大綱後，再以簡報工具製作投影片，實際運用了兩三次後，對於投影片的製作效率和品質有了顯著的提升。
相較於實體的便利貼，我選擇採用數位工具 Excalidraw 來達到相同的目的：
- 具備「自由調整順序」的功能
- 能以文字或圖像來描繪投影片的草稿
容我透過今年 HelloWorld Dev Conference 的分鏡稿來說明：
在製作分鏡稿時，有幾個必要項目：
投影片的核心概念：
在每一張分鏡稿的旁邊，以簡短的文字描述該頁投影片想要傳達給聽眾的概念是什麼？
投影片的草稿 :
針對前一項設定的核心概念，以文字或是 Icon 的形式，大致描繪呈現方式，不需要過於精細，看得懂即可。投影片的配色、排版，等到分鏡稿完成，進入投影片製作階段再來擔心。
投影片間的轉換 :
有時候投影片完成後，單一頁看都沒有問題，但是實際在報告時，兩頁投影片之間的轉換會「卡卡的」，通常是在準備時沒有考慮到投影片間的「轉換」。因此我會在部分投影片之間加入「轉場」的說明，確定投影片之間的切換是流暢的。
透過「分鏡稿」的概念，搭配 Excalidraw 數位工具來製作投影片的大綱，對於投影片的品質和效率都有很大的提升，是我今年很大的收穫。如果你對於這部分的內容有興趣，歡迎留言或來信交流，我很願意分享更完整的做法和實例。
投影片的呈現方式
一頁投影片中，究竟要放多少文字才是好的？
有些人認為投影片要有足夠的資訊，分享完後能充當「文件」的角色，達到知識傳播的效果。但也有人認為投影片不應該喧賓奪主，過多的文字會干擾聽眾聆聽講者。
在今年的分享中，我做了一個實驗：「試著把投影片內的文字降到最低」。
讓我們來看看實際的差異，這是 2023 年我在 DevOpsDays Taipei 2023 的投影片：
而這是今年的投影片 :
相信你可以明確的感受到兩者的差異，在今年的實驗中，我放棄了繽紛的投影片模板，選擇「白底黑字」，也盡可能地以「圖像」來取代「文字」。
(如果你想看看完整差異，附上 2023 和 2024 的簡報連結)
我試著讓「投影片」成為簡報過程中的「輔助」，當文字量減少時，能不能依靠「講者」的說明，搭配「容易理解的圖像」，讓聽眾的吸收率更高？
那麼實驗的結果如何？讓我們來看看聽眾的回饋：
不論是質化或是量化的回饋，看起來都挺正向的。
然而，在實驗的過程中，我也留意到「投影片」文字下降的幾個缺點 :
分享時需要更高的專注度：
投影片中的文字，在報告時其實同時扮演「備忘稿」的角色，當文字量減少時，意味著需要花更多的心力，確保自己在報告時能精準的呈現自己原先設定的內容。
投影片的重用性降低：
降低投影片內的文字，有助於現場聽眾更專注在「講者」身上。但後續要進行傳播時，投影片所提供的資訊量是不夠的，需要搭配共筆或是其他文件。
整體來說：投影片文字越少，對於現場聽眾的專注力提升越有效。投影片資訊越多，對於跨時空的傳播越有效。如何根據自己的需求調整投影片的文字量，是個值得深思的問題。
活動當天
熟悉環境
活動前，可以先到演講場地晃晃，熟悉場地有助於緩解緊張。
同時可以確認現場的設備，今年的 DevOpsDays 抵達會場後，才發現我的場地並沒有提供講者螢幕，所以沒辦法在報告當下看到「下一頁投影片」，個人覺得對於分享的流暢度影響蠻大的。還好今年是第二天才分享，回家後還能花點時間記投影片的順序。
如果有自己攜帶簡報筆，記得提早請場控人員幫忙安裝驅動程式。
準備一點小食物
我在報告前特別容易緊張，在上台報告當天，基本上在報告前完全沒有胃口。一直都很羨慕上台前泰然自若的人，
去年第一次在 DevOpsDays 登台前，午餐沒胃口，只有狂灌咖啡，報告完直接胃痙攣，痛到整個人縮起來。
今年學乖了，隨身攜帶一個小餐包，午餐時間咬個一兩口。
如果像我一樣是個報告前容易緊張的人，可以預先做好準備，確保自己以最好的狀態登上舞台。
留意分享時間
我在分享時沒有寫備忘稿的習慣，加上投影片的文字量又縮減了，所以非常仰賴臨場發揮。
在 DevOpsDays 中表定 40 分鐘的分享，事前練習約 38 分鐘，但當天只有講 34 ~ 35 分鐘就結束了。
如果習慣不背稿、追求自然分享，要特別注意在正式分享的場合，容易因為腎上腺素帶來的興奮，讓語速變得比平常更快、或是漏掉一些原先設定的內容。在事前練習時，可以多準備一些內容，作為緩衝。
報告後的回顧
在分享完成後，終於能鬆一口氣了！
第一次面對聽眾來交流，總覺得是「回答聽眾的疑問」，但參加了幾次後，發現這也是個很棒的「雙向交流」場合！當聽眾會拋出某個問題時，代表他是在意這件事情的，很適合趁機請益對方是怎麼做的？ 是否有一些心得？
如果有提供線上共筆，可以在報告結束後，看一下現場聽眾是如何理解這場分享的，如果聽眾所列出的重點，與事先規劃的 Core Value 相同，代表此次的傳達是有效的！可以維持投影片及分享的風格。
反之，如果共筆沒有內容，或是凌亂不堪，代表這次的主題設定、核心概念或是投影片可能需要做調整。
結語
對我來說，每一次的分享都是一次挑戰，除了胃痙攣外，也曾經在上台前緊張到躲在男廁平復心情。
希望能透過這次復盤，紀錄自己今年的心得與收穫，期待未來的自己能持續精進「分享」這項工具，也希望這些經驗能為你的分享之路點亮些許光芒。
如果有任何想法或問題，歡迎留言與我交流，讓我們一起在分享的路上越走越遠！
我會定期在部落格分享不同主題的文章，目前包含：
- 職涯心得
- 個人成長
- 筆記軟體 - Obsidian 教學
- 技術相關 (
K8S,DevOps,軟體測試…)
如果你想第一時間接收到新文章，歡迎你訂閱我的電子報！
感謝你的閱讀，我們下次見！