如何做Presentation(自己的一些心得)

算是對這篇文章 我放棄了 Google 的工作，因為他們拒絕給我買聖誕禮物 的一個觀後感吧， 打算聊一聊關於如何做Presentation的事。我是典型的非典型理工男， 屬於那種一寫代碼就頭疼（雖然想演算法和推數學我不頭疼），一遇到項目結題作報告就來勁的人，為了更好地作報告，我熟練掌握PS，illustrator，premiere（視頻剪輯軟體），maya等不同的軟體工具，就為了能讓插在報告里的圖更好看一些。當然在報告界，我最佩服的還是CMU計算機系的圖形學教授Keenan Crane大神，他報告的配圖我都覺得嘆為觀止，這傢伙現在竟然還開始專門為了更好地生成數學diagram而自己寫專門的軟體了。。。。。。可惜我找不到他以前寫過的一篇關於如何做slides的課件了，不然放在這裡十分合適。

這裡之所謂如何做presentation，探討的不是在做報告時的言行舉止或者如何把自己的ppt做得多麼花巧，而是更多地關於該如何去組織自己的報告的一些注意點。

廢話少說， 直接切入正題， 工作中，學習中，或多或少的都會接觸到作報告，報告有多種不同的類型， 比如粗糙的劃分， 就有理工科的報告， 商科的報告， 社科的報告等等。這裡結合職場這一特殊語境， 我想探討的是 間於理工科的報告和商科的報告之間的一種。

所謂吾日三省吾身， 從哪來， 到哪去， 去幹啥。 任何報告， 都不外乎要解釋清楚， 解釋好這三個核心問題， 即：

動機

方案

結果

而圍繞這三個核心內容展開的，則是個更核心的觀念"批判": 批判別人, 批判自己.

我曾經開玩笑的說過SIGGRAPH論文(或者任何應用計算機科學的頂會論文)的第一頁, 不管是哪一篇, 總共可以抽象成三句話: 我們要解決的問題是一個大問題, 別人解決這個問題的方法都失敗了或者不夠好, 我們的演算法出來拯救世界了! 我的導師, 每次在和我一起構思論文的寫作時, 最和我反覆強調的就是我們該如何構造一個合適的故事來強調我們演算法的重要性, 其實這個思路, 也就是正確的, 作報告的思路.

為了達到這樣的核心的創作思路, 通常可以這樣組織報告:

首先, 交代項目的動機, 此時切忌流水賬, 但一定要包含一下幾個重要的因素(這幾點甚至是該在做項目之前就考慮的):

重要性分析, (為什麼我要解決這個問題, 它有多重要?)

應用範圍分析, (我的方案,除了所提及的問題本身,是否還可以用於其它領域?)

一些失敗的解決方案的羅列(不用多講細節, 誰關心失敗者?)

自己方案的亮相(它所達到的顯著提升的展示)

---> 到此為止, 你這個報告的motivation才剛講完, 還沒有任何技術細節的提及, 已經讓聽眾有個全面的理解了, 以結果為導向的聽眾, 到此為止, 已經對你有個極好的印象了.

舉個例子你想優化一個I/O程序, 那麼在你開始做這件事之前, 首先就得問自己這幾個問題:

I/O佔了當前作業的多大比重? --> 如果我來優化, 我能優化多少?(經濟效益考量)此時有以下幾個分支:

1. I/O佔比大, 優化空間小.
2. I/O佔比小, 優化空間大.
3. I/O佔比小, 優化空間小.
4. I/O佔比大, 優化空間大.

情況1/2/3, 這件事不做. <--被指派除外. 得找更有意義的事來做, 因為一個優秀的程序員, 應該把自己的聰明才幹花在能給企業創造更大利益的地方去.

如果是情況4, 這件事得做啊, 但是這裡問同學一個問題, 情況4 怎麼來證明這是重要的呢? 通常證明一件事重要, 有以下一些套路:

1. 這件事關乎重大, 有這這那那的應用和埠都要用到這個I/O, 它一提升, 那提升的東西可就多了.
2. 優化牽扯到的效益巨大, 此時就需要記錄數據了, 現在的IO是多久? 占整個運行時多少%? 當前這個模塊又有沒有對其他模塊造成延時? 預計優化後對於能耗, 時耗, 能有多大的節省? 這些節省對我們的業務意味著什麼? ---> 注意此處為什麼要準備這麼多數據, 因為很多事情因果間的關係不是簡簡單單線性的, 說不定這裡的一些量變, 最終能引發一些其它事情的質變, 所以這是值得探討和調研的.
3. 因為之前的做法需要被修改: 存在錯誤, 而且是會造成巨大損失的錯誤(不會造成任何損失的錯誤 不算錯誤); 基於未來的戰略布局, 新的應用需求, 當前方案跟不上了, 等等
4. 我在這個問題上構造出了一種新的演算法/硬體/結構....等, 能讓我們的東西產生質變, 造成新的技術壁壘/IP. -----> 這一條, 其實是最難做的, 因為任何企業, 都有他官僚的地方, 阻礙迭代, 所以真是這種情況, 就得自己多吃苦了, 大膽假設, 小心求證, 做好POC.
5. 1/2/3/4說了這麼多, 很可惜, 以前我們的一些解決這個問題的努力並沒有太大成效, 此時要收集好證據!! 證據!! 在舊的系統上, 把1/2/3需要的數據全都統計出來...做好記錄.
6. 亮相, 我們team完成優化後, 現在的效率, 是這樣的結果:

如果快慢難分怎麼破? 此時是否考慮一下數據的變種? 比如 Perf/Watt :

注意這個數據變種, 有時候狡猾得很, 如果你有個東西幾乎無能耗, 那麼運算慢是慢了點, 單位能耗運算量卻是無窮大呢!!!!!--->當然這只是一個純假設性的說法, 事實上人類的硅工藝發展了這麼久, 用了那麼多聰明才智才把perf/watt提上來, 豈是你異想天開能夠又想能耗少又想運算不減慢的?

總而言之, 此時的亮相, 講究一個媒體常用的原則: 我們所羅列的, 一定是事實, 但是是我們精心準備過的事實.

亮相完你的優異結果後, 別忘了, 不管是不是理工科報告, 你得讓聽眾知道你們是如何達到這一個目標的, 一般人把這個過程理解為介紹自己的方案, 而實質上, 從傳播的角度來理解, 你這是在利用更多的細節減少人們對你的結論/結果的真實性的質疑.

一個報告最佳的時間是20到25分鐘, 你開頭的介紹用去了8分鐘, 接下來, 你需要用8分鐘來介紹你的方法, 介紹方法是, 需要記住一個重要的原則::::::::!!!! 不要燒腦(但燒腦這個概念視乎聽眾不同是相對的, 是需要報告者自己去協調感知的)!!!!

而燒腦種種, 包括不限於以下一些人們常犯的錯誤:

運用花巧的, 視覺/顏色上複雜的圖表和動畫

錯誤的顏色指代--例如不要用紅色去代表低值, 藍色去代表高值

過度複雜, 需要時間理解的可視化圖形

你所要傳達的信息一定要簡明扼要, 數據的可視化十分重要, 但不要去過度可視化! 可視化的圖形/顏色等一定要直觀, 任何你看到時覺得別人需要反應一下或仔細才能理解到的可視化圖, 一定要修改到一目了然為止.比如我舉個栗子:

圖1 和圖2, 圖1 雖然很酷炫, 可能是個帶點藝術感的可視化, 但信息傳播能力很弱, 很多人第一眼的感覺是, "這什麼鬼?" 圖2, 簡明扼要, 你只需要在底下再加上任意辭彙, 人們就能本能地去估計這個圖的意思了, 比如我寫, 犯罪率, 人們就會本能地覺得, 奧, 紅色地方犯罪率高, 我說, 房價, 人們就會覺得, 奧, 紅色地方房價比較火. 這就是高傳播效率的可視化.

不要單調的, 枯燥的羅列(陳列)數學公式, 演算法過程, 視乎聽眾的知識背景, 這些會對他們燒腦的東西, 甚至可以撇去, 或者在一頁裡面全都寫下, 然後說一句, "所以, 經過所有這些數學後...." 一秒鐘跳過此頁, 並展示得到的結果.

演算法, 當然是偽代碼, 除了偽代碼外, 最好還結合每一步有示意圖, 比如人迪士尼的演算法介紹是這樣做的:

以上就是方案模塊值得注意的一些點. 總而言之, 原則是, 可能會枯燥的部分, 要把它變得有趣, 可能會燒腦的部分, 要簡潔再簡潔.

接下來是結果分析部分, 結果分析要做到的就是全面, 其實很多計劃在一開始的motivation打算的時候已經都做了, 而motivation階段僅僅是展示最高亮的結果, 所以在結果階段, 就可以展示更多更全的結果了, 但此時的關鍵詞是比較, 注意, 一定要比較比較再比較, 把之前的, 別人的, 自己的, 過程中的, 不同條件限制下的(比如開關多線程)所有的系統都跑一邊, 記錄下結果, 並一頁一頁的放上去呈現, 此時可以以量取勝, 因為傳播的角度理解, 你就相當於是再說"恆源祥, 羊羊羊" 通過一種反覆的比較過程, 給別人洗腦你們的成果從各個角度都能把不同的前者比下去或者在效率上得到不小的提升. 而這一切的數據, 都需要自己有計劃地準備好.

在結果階段, 你要假想從一個攻方角度來攻擊自己的結論, 然後來補足證據, 決不可偷懶!! 比如你做了多線程的比較, 決不能漏做單線程的比較, 有十個應用用到IO端, 就得把十個應用都跑一遍!!

你不是在憑興趣做一件事, 而是想去征服別人.

推薦閱讀：