但如果在 Demo 時發生意外，不但會影響發表的成效，嚴重點甚至會影響到整個團隊的考績與年終。

為了避免憾事發生，筆者將在這篇文章講解專案 Demo 時的種種細節與技巧，並分享過往遇到的問題及解決方案，希望大家日後在 Demo 時都可以展現專案最好的一面。

大綱

1. 保證現場 Demo 穩定度，不打沒把握的仗
   • 1.1 Demo 前要盡可能的測試
   • 1.2 同事間的預演
   • 1.3 只用一台電腦做 Demo
   • 1.4 穿著得體、統一
2. 邀請「對」的人，不是「多」的人
3. 選擇合適的會議室
   • 3.1 會議室的座位只能多不能少
   • 3.2 將觀看 Demo 的最佳座位安排給 Key man
   • 3.3 測試現場投影機，並確認網路環境
   • 3.4 讓每個要上台 Demo 的人在講台試講一小段
   • 3.5 預定會議室
4. 在 Demo 過程中要注意的事項
   • 4.1 記得關閉會干擾 Demo 的軟體、網頁
   • 4.2 現場燈光控制
   • 4.3 讓每段 Demo 的時間都在掌控之內
   • 4.4 記得帶筆記本上台
   • 4.5 安排中場休息時間
5. 遠端 Demo 前要確認的清單
   • 5.1 確認雙方的畫面與聲音穩定性
   • 5.2 確認自己的網速是否足夠

1. 保證現場 Demo 穩定度，不打沒把握的仗

穩定比表現的突出更重要。

1.1 Demo 前要盡可能的測試

如果在 Demo 現場專案出包，你講的內容再好都無力回天了。

• 尋找可能存在的錯誤
  就算專案已經通過測試部門的審核，我還是強烈建議正式 Demo 前要窮盡各種可能來測試專案；萬一你真的發現錯誤，就算無法及時修正，至少可以避免 Demo 時操作到這個部分。
• 只 Demo 絕對不會出錯的內容
  重點：全部都要按造 SOP，絕對不要即興發揮！
  功能越多的專案，在 Demo 時就越要謹慎；如果你每次操作的路線都不一樣，萬一你在 Demo 現場把 Bug 測出來就真的完蛋了。
  不要認為自己沒有這麼衰，筆者已經親眼見證過好幾次地獄倒霉鬼的誕生了；所以建議：「乖乖的按照 SOP 來做 Demo，並且至少跑 3 輪，確認專案在這個流程絕對不會發生意外。」

1.2 同事間的預演

有時專案 Demo 會讓同事輪流上台演示自己負責的 Feature；這邊說一下預演的重要性：

• 預估每個人 Demo 所需的時間
  Demo 都是有時間限制的，如果某個人 Demo 的時間太長，會壓縮到其他人的時間。

  在大約了解每個人 Demo 需要的時間後，也比較好制定議程。

• 知道彼此會講的內容
  預演能讓其他同事知道你 Demo 時要講的內容，如果當天不幸發生了什麼變故還能協助支援。

• 微調內容
  基本上第一次預演會發現很多問題（ex：口條不流暢、內容不連貫…），需要彼此互相提醒才能在當天有好的表現。

1.3 只用一台電腦做 Demo

如果需要輪流上台請將資料都存到一台電腦上面，下面列舉在 Demo 過程中換電腦的缺點：

• 壓縮 Demo 的時間長度
  換一次電腦在快也要 30 秒，如果有 5 個人要上台就浪費了 2 分 30 秒。
• 打斷會議流暢程度
  每換一次電腦，投影幕畫面就會跳掉一次，這容易導致台下觀眾思緒抽離。
• 未知的風險
  換電腦可能導致投影幕有色偏、斷訊、閃爍的問題，雖然這不是專案本身的問題；但也容易遭到台下觀眾質疑團隊的專業能力。

1.4 穿著得體、統一

• 第一印象很重要
  建議男生襯衫西褲、女生職業套裝；千萬不要因為邋遢的打扮讓自己的專業被扣分。

• 穿著盡量統一
  如果每個人上台的穿著差異太大，可能導致觀眾把焦點轉移到人，而非在 Demo 的專案；所以這塊請事先溝通，最常見的是黑白搭配。

• 不要有異味
  有些人的汗腺較為發達，在夏天及緊張的環境更容易出汗；筆者建議隨身攜帶香水，讓觀眾在舒服的狀態下參與專案 Demo。

  在空氣不流通的會議室，這個問題更加明顯。

2. 邀請「對」的人，不是「多」的人

事半功倍 VS 事倍功半

• 重要的長官一定要出席
  Demo 的日期以 Key man 能參與的時間為主，如果最關鍵的 Key man 無法出席，你這次的 Demo 可以說有一半以上的意義都沒有了；因為就算有代理人出席，他也只能做到轉述，而轉述的效果就跟你分享電影情節給朋友的感覺差不多。
• 不要邀請一堆無關的閒雜人等
  有些會議為了要做排場給長官看，就邀請了一堆跟專案無關的人參與；這樣的做法除了會引起他人的反感外，甚至會造成台下一堆人在滑手機、做自己的事。

3. 選擇合適的會議室

如果可以絕對要提前場勘，不然很容易死得不明不白。

3.1 會議室的座位只能多不能少

• 確認參與會議的實際人數
  確認 Key man 可以參與的日期與時間後，再邀請與專案相關的人員一起參與會議；切記會議通知並不是發出去就沒事了，在會議開始的前 2 天，你要再次確認實際參與人數。
• 到現場確認有效座位
  有些會議室的結構比較特殊，部分的位置是看不到講台的，這塊在場勘的時候要特別注意。
• 保留 20% 的座位
  除了收到會議通知的人會來參加外，有時會有不在你邀請名單的長官或是同事出席；因此建議預留 20% 的空位給臨時參與的人。

3.2 將觀看 Demo 的最佳座位安排給 Key man

• 了解哪些座位擁有黃金視角
  因為大部分的會議室都是平面的，基本上只有前幾排可以看得清楚投影幕與 Demo 成員；你需要在場勘時就掌握會議室的座位圖，並了解哪些座位擁有黃金視角。

• 在入口處有專人引導
  為了保證 Key man 是坐在觀看 Demo 的黃金視角，筆者會建議安排專人負責引導 Key man 到座位上。

  也可以放座位名牌避免同仁誤坐。

3.3 測試現場投影機，並確認網路環境

• 測試投影機注意事項
  • 一定要用當天 Demo 的電腦測試，確認是否可以順利投影，以及投影的畫面是否有模糊、字體太小、色偏…等問題。
  • 同時記得確認投影機轉接頭是 HDMI 還是 RS232，現場是否有提供轉接頭還是要自己準備。
• 網路環境注意事項

  • 是否有穩定的 Wi-Fi 或是網路線連接口，建議拿當天會用的電腦直接測速會比較安全。

    有些公司的網路只能連接內網，如果你 Demo 會用到外網也須特別注意。

  • 有些會議室的收訊不佳，建議也要測試自己手機熱點的網速是否穩定。

3.4 讓每個要上台 Demo 的人在講台試講一小段

• 確認聲音大小
  每個人說話的聲音大小不同，同一個場地有人需要麥克風有人不需要，所以可以藉由試講來確認。
  另外如果場地較大，就算你的音量足夠也建議使用麥克風，因為很多場地有回音的問題。
• 熟悉講台的視角與站位
  如果有機會，建議要先上去熟悉講台的視角，這個動作可以消除部分恐慌的情緒。
  有些 Demo 會需要多人站在講台上，這部分一定要在現場走位過，不然很容易擋到投影幕以及要 Demo 的產品。

3.5 預定會議室

這邊筆者分享一些定會議室的注意事項：

• 一定要提早訂
  這種重要會議筆者一般會提前兩個禮拜預定會議室，因為公司通常沒有太多合適的大會議室。
• 確認會議時間沒有與公司例會衝突
  如果你專案的 Demo 時間與公司例會衝突，有可能導致部分原本會來的長官缺席，所以記得把時間排開。
• 保留緩衝時間
  除了 Demo 的時間外，前後都至少要留 1 小時來做緩衝。
  • 如果會議室上一批人剛使用完，可能需要進行場復作業。
  • 提早到可以再次確認與熟悉場地環境。
  • 後面多留一小時，是因為通常專案 Demo 都會 Delay 一點；並且讓會後交流的時間更充裕。

4. 在 Demo 過程中要注意的事項

這塊 PM 需要適時的去協助

4.1 記得關閉會干擾 Demo 的軟體、網頁

如果在 Demo 過程中跳出奇怪的訊息是非常尷尬的，而且訊息不斷跳出的提示音也很吵；Demo 時千萬不要犯下如此低級的錯誤。

下面列出幾個常用的的軟體、網頁：

• 通訊軟體
  LINE、Messager、WeChat…
  只要你的好朋友剛好在這個時間點傳送奇怪的訊息，你的個人隱私就會直接顯示在大螢幕上。
• 郵件
  我發現很多人都會忘記關閉郵件，筆者之前就曾看過同事 Demo 到一半，螢幕右上角跳出信件通知，主旨是：「XXX 公司錄取通知」；當時台下還有總經理，畫面有多尷尬我就不說了。
• 社群網頁
  Facebook、LinkedIn、Twitter…
  千萬不要忘記關閉社群網頁，他們的提示音也是很吵的。

4.2 現場燈光控制

在 Demo 過程中，你可以透過燈控引導觀眾的注意力，筆者大概分成 3 種：

• 只開講台燈（舞台燈）
  需要觀眾將注意力放在講者或是產品身上的時候，通常是講者剛上台做自我介紹，或是要展示產品的時候。
• 只開最後一排的燈
  希望觀眾仔細聆聽簡報的時候，在這樣的燈光下，有需要做筆記的人還是可以記錄。
  筆者不選擇將燈全關是因為：
  • 有些人的眼睛在全暗的狀態下看發光物體會有不適感。
  • 如果講者的表達能力不佳，在全暗的環境中台下會睡成一片。
• 全亮
  簡報結束與觀眾互動的環節，這樣講者與觀眾的互動比較友善。

4.3 讓每段 Demo 的時間都在掌控之內

有些與會者會不停拋出問題或意見來打斷 Demo 的過程，如果沒有阻止，會導致 Demo 時間脫離掌控。

這邊筆者建議引導他們等 Demo 結束後再發問，比如：「不好意思，我這邊先完成專案的 Demo，讓大家對專案有一個整體的概念；也許接下來的操作就能解釋您心中的疑惑，如果沒有，在 Demo 結束後我再回答您的問題。」

4.4 記得帶筆記本上台

通常在 Demo 的過程都是使用鏡像螢幕，因此在遇到發問時，你不方便使用電腦來記錄問題。

如果你在講台上用手機來紀錄問題，畫面也不太好看；所以筆者建議帶一本筆記本上台，好處有：

• 快速筆記
  有些人一次會拋出 4、5 個問題，如果沒有筆記本輔助，容易有問題遺漏沒回答到。

• 記錄需求
  Demo 結束後通常會得到很多反饋，如果沒有筆記本，光憑記憶是很難把這些全部記下來的。

  通常會安排一個同事來做會議記錄，雙重保險。

• 忘詞提示
  如果你對今天 Demo 的內容不夠熟悉，或是擔心自己緊張忘詞，你可以在上台前將重點記錄在筆記本上。

4.5 安排中場休息時間

如果議程超過 1.5 小時，絕對要安排休息時間！

無論在精彩的 Demo，觀眾的注意力還是有限的；建議 40~50 分鐘就需要休息一下，先讓大家喝杯水，5~10 分鐘後繼續。

這樣可以讓觀眾整理大腦新接收到的資訊，而會議主辦方也能利用這個空檔討論下面的議程是否需要調整。

如果主辦方沒有安排休息時間，一口氣給他講 2 個小時；相信我，這絕對是一場失敗的專案 Demo，因為幾乎沒有人可以維持長時間的注意力，通常這麼做的後果就是觀眾後半段的記憶接近空白。

5. 遠端 Demo 前要確認的清單

如果要向國外的客戶 Demo，又或是因為疫情影響需要在家 Demo。

5.1 確認雙方的畫面與聲音穩定性

因為是遠端，所以非常吃雙方的網路速度；有時畫面及聲音的延遲會造成溝通上的問題，筆者在正式 Demo 前會用以下方法維護會議品質。

• 主講者自我介紹
  讓每位主講者先簡單自我介紹，確認聲音的大小，避免有些人超大聲有些人超小聲。
• 只有主講者開麥克風
  遠端開會時除了主講者外其他人都要靜音，不然很容易會有雜訊。
• 建議購買麥克風，不要靠電腦收音
  如果有遠端 Demo 的需求，建議購買專業的麥克風收音，這樣可以大幅降低周遭環境音（ex：咖啡廳背景音樂、小孩哭鬧聲、鄰居吵架聲…）的干擾。

5.2 確認自己的網速是否足夠

• 使用 Wi-Fi 時注意不要互搶流量
  在家中通常是連接 Wi-Fi，但如果很多人共用這個 Wi-Fi 可能會導致Demo 品質不穩定；如果可以，建議大家在 Demo 時請其他人暫停使用 Wi-Fi。
• 確認自己的頻寬能否 Demo 需要高網速的頁面
  在載入圖片、影片資源時，會消耗很多的網路流量，這很可能造成你畫面卡頓甚至靜止，因此建議你先找朋友測試看看，以保證當天勤務萬全。

筆者碎碎念

Demo 過程發生的意外，對台下的觀眾而言是一種必然，因為他們只會聽一次而已；請不要讓這些可以控管的風險毀掉團隊努力的成果，每次 Demo 前都按照這份清單檢核一次吧！

如果大家還有遇到什麼狀況想補充的，請在底下留言告訴我，你無私的分享可以減少 Demo 時悲劇的發生～

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

參考資源

1. 專案 Demo 前的準備、細節、技巧(筆者部落格)

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571