iT邦幫忙

2021 iThome 鐵人賽

DAY 27
0
Software Development

全端工程師生存筆記系列 第 27

[職場]不放過每個細節,完成一場 0 失誤的專案 Demo!

每份專案都是團隊盡心竭力的成果,而 Demo 就是向長官及其他部門展示團隊實力的重要時刻!

但如果在 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 前的準備、細節、技巧(筆者部落格)

上一篇
[職場]拒絕做白工!讓自己的努力效益最大化
下一篇
[職場]新工程師報到,如何協助他成為有效戰力
系列文
全端工程師生存筆記30

尚未有邦友留言

立即登入留言