如何做好簡報？應用 10/20/30 法則

因為工作的關係，我常常要用到簡報，無論是用於教學，或是向主管或顧客提報。簡報要採取什麼範本？要講的主題有哪些重點要提？要使用幾張投影片(slides)？投影片要採用什麼格式？字型要多大？... 都是問題。這些問題的拿捏不容易，有時候怕資料不足，就會放入過多的內容，結果往往造成反效果，要不是時間配合不當，就是聽眾的反應不佳。因此，簡報要怎麼做才會好？要做多少投影片才恰當？都是相當困擾的問題。

最近在網路上看到一篇文章《如何在2小時內完成100頁PowerPoint簡報》，宣稱可以在高鐵上 2 小時完成 100 頁的投影片，並且視為家常便飯。我自問無此能力，也對擁有這項能力的人嘖嘖稱奇。不過，反過來想想，我要這 100 頁的投影片做什麼？

以我做簡報的經驗，講述十張投影片的內容大概也要花掉一個小時左右，如果時間短一點，投影片裡的內容更須要精簡，或用圖表來代替文字。並且，實際講演時的重點不是投影片，而是與聽眾交心、互動。我必須時時留意，聽眾是否能注意聽我所講的內容，是否真的了解我所論述的東西，有時還必須視現場的氣氛，調整自己講演的語調、速度、步驟和內容。我認為上述的情況，比我是否能作出一百頁投影片來得重要許多，當然，我也沒忽略簡報的重要性，畢竟，好的簡報可以增添演說的魅力和效果。

前幾年我看到矽谷創投專家蓋 川崎(Guy Kawasaki)寫的文章《The 10/20/30 Rule of PowerPoint》(PowerPoint 10/20/30 法則)，內容主要提到他認為要符合 10/20/30 的原則，才是好的簡報。那什麼是10/20/30 法則？即是投影片只要 10 張，講演的時間不超過 20 分鐘，投影片上的字型大小要超過 30 點。川崎認為，正常人在一場會議裡最多只能領會 10 個概念，過多就是不好了。講演時掌握在 20 分鐘裡把重要的訊息傳達給聽眾，其他的時間就可以用來充分的討論。而小於 30 點的字型，代表投影片的文字過多，這會造成聽眾把注意力放在投影片的文字內容，而忽略你的講演。這是由於你的講演速度，和聽眾閱讀投影片的速度，容易產生不同步的緣故。

其次，川崎也針對 10 張投影片的內容提出建言，他認為內容應該包含下列的議題：

  1. 點出問題所在(Problem)。
  2. 解決方案(Your solution)。
  3. 提供商業模式(Business model)。
  4. 獨到的技術(Underlying magic/technology)。
  5. 行銷方式(Marketing and sales)。
  6. 競爭對手(Competition)。
  7. 團隊成員(Team)。
  8. 專案計劃和里程碑(Projections and milestones)。
  9. 情況及時程(Status and timeline)。
  10. 總結並請求行動(Summary and call to action)。
當然，我們可視實際的需要，調整上述的內容。我以為，如果是運用在商業報告上，這套方式是相當適合的。但是若運用在教學方面，可能需要大幅度的調整，不過掌握一堂課不要超過 10 個概念也是必要的。底下是川崎的演說影片，有興趣可以看看。

參考資料：

留言

宇宙大肉粽寫道…
這真是受用無窮阿！！
2009年3月2日 凌晨2:50
張貼留言

這個網誌中的熱門文章

langue ou langage

圖片
日前閱讀 David A. Black 寫的一篇文章《 The L in DSL: langue ou langage 》。這篇文章所談的內容，主要是探討「 Domain Specific Language(DSL) 」(特定領域語言)這個術語受到太多的利用，致使有不勝負荷(over-burdened)的現象。同時，他也提出如何看待這些現象，還有區分「 語言 」的內涵。文章裡，開宗明義就用了法國電影理論大師 梅茲 ( Christian Metz )於 1964 年所發表的文章標題：「 Le Cinéma: langue ou langage? 」，然後說明這段話在影片裡的意思，並以「 Thus one may say that film is langage (language-like communication), but it is not une langue (a particular language). 」作為其文章的核心論點。大意是說，有人也許會認為電影是 langage (像用來溝通的語言)，而不是 une langue (獨特的語言)。 看這篇文章，如果不能真的體認「 langue 」和「 langage 」這兩個字的差異，那就只能算是一知半解。能不能理解這兩個法國字，和 梅茲 的「 Le Cinéma: langue ou langage? 」(《電影：語言或語言體系？》)這句 法語 ，就成為你能否完全了解這篇文章的關鍵。 首先，我們先要了解「 langue 」和「 langage 」這兩個字代表什麼意義。由於本人對於法文也不是很懂，所以需要一些工具來輔助，好在網際網路盛行也提供了許多方便，我把線上可供利用的法文字典找出來，列在文章最後面的「 參考資料 」。我先利用「 ARTFL Project: French-English Dictionary Form 」來查，出來的結果很叫人失望，這兩個字的英文意思同樣為「 language 」(語言)，就因為如此，所以英譯本把 梅茲 那篇《 Le Cinéma: langue ou langage? 》翻譯為《 The Cinema: Language or Language-system? 》。我改用「 邁迪法語在線翻譯詞典 」來查，結果好一點，在 langue 方面，有「 舌、舌頭、語言、用語...
閱讀完整內容

FastReport 4.7x 中文介面的問題及解法

圖片
最近全球受到金融海嘯的影響，我也無法倖免於難，腦袋昏昏沉沉，做起事來也懶懶散散。這樣也不是辦法，突然想起不知那位先哲說的，可以拿數學來訓練腦力，所以隨手抓起一本《組合數學》的書來看，效果如何？就不言而喻了。幸運的是，病情雖沒轉好，但也沒有變差，腦袋瓜當然也沒變得更聰明。上個禮拜，有朋友來電問我用 Delphi 寫報表程式的問題，主要是 Codegear 出 Delphi 2009 這個版本，早期使用報表元件 FastReport 3.x 的版本也隨之更新，然而在 FastReport 3.x 毫無問題的中文介面，更換 FastReport 4 卻變成亂碼，因此希望我協助找出問題和解決的辦法。 有事做總是好的，所以我就爽快的答應下來。為了診斷問題，所以必須先找到所需的工具， Codegear 有 Delphi 2009 的測試版 提供下載，當然少不了要填寫資料，下載《Delphi and C++Builder 2009 Trial with ISO》的檔案約 1.9 G。至於 FastReport 4.x 也可以到 Fast Report Inc. 的網站 下載 測試版，目前最新的版本是 FastReport 4.7x，由於我前後下載了幾次，每次最後的 x 數字都不同，然而截至目前為止，我發現 FastReport 4.7x 版都未解決中文介面顯示的問題。 我把 Delphi 2009 和 FastReport 4.7x 依先後安裝完畢。在安裝過程中，FastReport 會詢問所要安裝的語言別，但安裝之後，我發現並沒有什麼作用，可能只是安裝過程用來顯示繁體中文而已。因此，為了能在 Delphi 程式執行期間顯示報表的中文介面，還必須運用 FastReport 4.7x 的 Recompile Wizard(重新編譯精靈)，把語言轉換成繁體中文。 完成這項工作之後，就可以執行 Delphi 的 IDE 環境，我隨便找個 FastReport 所提供的範例來測試(像是 PrintTable 這個專案)，並且執行。當開啟 FastReport 的預覽列印時，果然中文字不是缺字，就是呈現亂碼。結果如下圖所示： 究其原因，首先是 FastReport 4 的資源編譯器 frcc.exe 發生了問題。為什麼做此判斷？我發現經由 frcc.exe 所轉換的 Delphi 檔...
閱讀完整內容

Pattren：樣式、模式或範式

圖片
幾天前買了 侯捷 的《 重構－向範式前進(Refactoring to Patterns) 》這本中譯書，本書的原作者是 Joshua Kerievsky (約書亞．克里夫斯基)，內容就像斗大的標題一樣，即是如何運用 Refactoring (重構)的技術，逐步朝向 Design Pattern (設計樣式)的技術目標推進。其實從 Martin Fowler (馬丁．佛勒)所著的《 Refactoring：Improving The Design of Existing Code 》這本書(中譯本為《 重構--改善既有程式的設計 》；譯者為侯捷)裡面就可見端倪，而在克里夫斯基的《 Refactoring to Patterns 》裡面更把這一點發揚光大。但是，在我這篇文章裡並不談這項技術的內涵，而是要談談「 pattern 」這個英文字的翻譯。 為什麼要談「 pattern 」這個字呢？因為令我感到有趣的是這個字的術語共有三種。侯捷習慣採用「 範式 」，例如《 重構－向範式前進(Refactoring to Patterns) 》；台灣部分學者和中國大陸普遍的譯法為「 模式 」，像是 葉秉哲 的《 物件導向設計模式 》，或是 蔡學鏞 翻譯的《 深入淺出設計模式 》；至於像我個人，或是 趙光正 等人，像是 趙光正 的譯作《 UML與樣式徹底研究(Applying UML and Patterns) 》，或 林昆穎 和 吳京子 的《 敏捷軟體開發：原則、樣式及實務 》，就選擇使用「 樣式 」一詞。 換句話說，在台灣「 pattern 」這個字可以為「 模式 」、「 範式 」或「 樣式 」，而會有這種現象，主要是譯名不統一，而之所以無法統一，就在於翻譯這個字的每個人想法不同所致。由於我不想評斷每個人想法的優劣，因此，在這裡我僅就我個人的見解，來抒發一下我個人的觀點。 軟體「 Pattern 」(樣式)這個概念，最早要追溯到 1987 年，當時 Ward Cunningham 和 Kent Beck 這兩人在一起用 Smalltalk 從事設計使用者介面的作業，過程中他們發現 克里斯托佛·亞歷山大 ( Christopher Alexander )所提倡的 建築模式語言 ( Pattern Language )這個觀念也可以運用在軟體開發，因此提出了軟體樣式的概念，K...
閱讀完整內容