《論文教室》:如何擬出結構清晰的論文大綱?

《論文教室》:如何擬出結構清晰的論文大綱?
Photo Credit: Depositephotos

我們想讓你知道的是

不易閱讀的文章,並不一定是充滿困難詞彙的文章,也可能是無法看透結構的文章。因此,我們必須盡可能在論文的結構上下功夫,讓讀者容易瞭解。那該怎麼做呢?

作者:戶田山和久|譯者:林宗德

論文是結構化的文章

在第四章,我傳達了一個很重要的訊息:論文是具有結構的文章,而「具有結構」這一點,正是論文與其他類型文章的差異所在。論文整體包括了「摘要、正文、結論」三部分,它們各司其職,而正文可再分成「提問、主張(即結論)、論證」三個部分。

寫論文並不是把閒來無事時腦海裡浮現的事情記下來這麼簡單,而是先要把上述的結構創造出來。而這個結構,與辨別容易理解和不易理解的論文也有關係。

我從事學術工作,必須閱讀許多論文。讀多了就會發現,有容易理解令人雀躍的,也有很難理解惹人煩躁的論文。一直使用困難的詞彙的確讓人招架不住,尤其必須查辭典的外語論文,讀起來更是辛苦。我曾在文章裡看過comestibles這個詞,查了辭典說是指「食物」。實在讓人很想說,這傢伙為什麼不寫food就好?

但這還不算真正的「困難論文」。對我來說,缺乏清楚結構的論文才真的困難,那讀起來非常吃力。知名學者也會寫出這種論文。他們是故意要這樣寫的嗎?抓不到結構的文章要將我帶往何方?我現在讀到的這段,是作者的主張?是作者要批評的人的主張?還是作者正在探討各種不同的觀點呢?這邊出現的問題,跟剛才的,是一樣還是不一樣?啊!搞得我頭好痛啊!真氣人⋯⋯

不易閱讀的文章,並不一定是充滿困難詞彙的文章,也可能是無法看透結構的文章。如果你們或我是某個領域最傑出的領袖學者,那不管寫的論文多難讀,大家還是會忍耐讀下去。但那是少數人的特權。我們既然是平凡人,就必須盡可能地在論文的結構上下功夫,讓讀者容易瞭解。那該怎麼做呢?

大綱是論文的結構

(哲學大叔)——論文最重要的,是要有清楚的結構。也就是說,必須讓人利用論文的「大綱」來看透論文。

(學生)——「大綱」(outline)原意是指輪廓線對吧。所以,透過輪廓線看透,不是很奇怪嗎?說利用論文的「骨架」看透才對吧?

——骨架的英文是「skeleton」,說skeleton也可以,因為辭典說它也有「文章的概要」的意思。在現在這個脈絡,outline和skeleton意思一樣。

——咦,skeleton是骨架的意思嗎?我還以為是穿透、透明的意思。

——的確,這似乎是因為某個電腦廠商用了「skeleton body」的矛盾說法,才讓這樣的誤解廣泛流傳的。總之,說文章的骨架也可以,它甚至還更符合這本書的要旨呢。因為論文的正文就是骨架加上肌肉呀。可惜的是,一般不太用「論文的骨架」這說法,我也只好用通稱的大綱來稱呼它了。

  • 【鐵則20】論文是由大綱增胖而成。從大綱開始寫出來的論文,具有強韌的結構。寫論文要先創造大綱。

——那大綱具體來說是什麼樣子呢?

——嗯,我來舉個例子。你知道挑戰者號太空梭爆炸的事件嗎?應該是在一九八六年的時候發生的。

——好像在電視上看過特別節目。

——嗯。挑戰者號好像是第一次搭載民間人士。但它爆炸了,機組員全部罹難,是太空開發史上最嚴重的事故。假設我們出個題目,問你從這個事件得到什麼教訓,要寫成一篇論文。以下是該論文的大綱:

Challenger_explosion
由 Kennedy Space Center - http://grin.hq.nasa.gov/ABSTRACTS/GPN-2004-00012.html, 公有領域, 連結

(暫定標題)「從挑戰者號爆炸事故應當學到的教訓」

一、前言(摘要)

  • 問題設定:「為何無法防止挑戰者號爆炸事故的發生」,以及「未來該如何防止同樣的事故發生」
  • 各節的內容概要

二、挑戰者號爆炸事故的概要與背景(提問與分析)

(一)事故的概要

  • 日期與時間、發射七十三秒後火箭助推器起火,引發太空梭爆炸
  • 犧牲者的簡歷

(二)事故的原因

  • 技術因素→火箭助推器的結構缺陷→詳細的調查
  • 氣象條件→發射當天的異常低溫

(三)事故的背景

  • 美國國家航空暨太空總署(NASA)為何強行發射

三、決定發射的決策過程

(一)決定發射之前的過程

  • 相關組織的概要→NASA、希爾科(Thiokol)公司(助升火箭研發公司)分擔的任務
  • 最後決定發射的視訊會議的經過

(二)T公司(希爾科公司)當初反對發射

  • 為何工程師對發射有疑慮
  • 工程師的「揭發信件」→網路上找得到嗎?如果有的話,引用並分析

(三)發射前最後一刻的會議,T公司突然改變態度,轉為贊成發射;「T公司為何在發射前一刻改變態度,轉為支持」(問題的再格式化)

四、為何會在發射前最後一刻的會議改變決定(主張與論證)

(一)數個假說的探討

  • 根據事故調查委員會的議事錄,對假說進行驗證
  • 到此為止的結論→不論是哪個假說,都無法充分說明T公司為何突然改變態度。必須對會議中的團體決策,做社會心理學上的分析

(二)社會心理學對於團體決策遭扭曲的原因之研究

  • 簡單介紹幾個重要的先行研究
  • 尤其是詹尼斯(Irving L. Janis)的「團體迷思」(Groupthink)

(三)T公司的決策與Groupthink

  • 確認T公司的決策過程,符合Groupthink的六個特徵之中的每一個特徵
  • 尤其注意隆德(Robert Lund,T公司工程師們的頭頭)想法的改變→用議事錄來驗證
  • 到此為止的結論:T公司最後的決策符合Groupthink的特徵(主張)

五、預防事故再次發生的提議(針對第二個提問的主張與論證)

(一)由分析挑戰者號事故所得到的教訓

  • 為了防止「事故」發生,只提升技術的精密度是不夠的→已經知道有潛在的危險,但並不在決策的考慮範圍內
  • 決策機制必須改進

(二)決策機制應該是怎樣的

  • 不讓決策機制陷入Groupthink的具體方案
  • 團體決策中工程師的任務
  • 要能讓工程師發揮上述功能,應該要有什麼樣的決策體制?→嗯嗯,未來的展望?

六、總結

大綱會隨著論文成長而發生變化

(哲學大叔)——這大綱很完整呢。

(老師)——對啊,這論文至少要幾千字呢。如果是課堂作業的論文,塞不下這麼多內容,還要再精簡一下。

——「一、前言」這裡寫的是摘要嗎?

——是的,正文則是從第二點到第五點。

——提問、主張和論證在哪裡呢?

——這篇論文原本的問題是「為何無法防止挑戰者號爆炸事故的發生」,但為了回答這個問題,必須掌握直到發射之前的詳細事實經過。這是第二、三節的內容。為什麼決定發射而導致事故,其中最重要的問題是:希爾科公司發覺可能會發生事故,直到快要發射都還主張應該延期,卻在發射前的視訊會議中突然改變了態度。這可能是事故之所以無法預防的關鍵所在。在這裡,大綱的作者把原本的問題,換成了更詳細的小問題,分別解析它們。

——你是說「T公司為何在發射前一刻改變態度,轉為支持」這個地方嗎?二到三節是問題的分析和格式化對吧。

——沒錯。針對這些小問題,作者提出假說,主張原因是T公司的人員陷入了「團體迷思」,並且在第四節論證它。

——那第五節是什麼呢?

——那裡是對原本提出的另外一個問題,嗯⋯⋯就是針對「未來該如何防止同樣的事故發生」這個問題,主張作者的答案。

——嗯。寫出這麼好的大綱,只要加上內容,馬上就變一篇論文了。

——沒錯。要寫出這種程度的大綱,應該會花上寫論文總時數的三分之一。如果是我,完成了這種程度的大綱,就會覺得好像寫完了,對自己說「嗯,再加把勁就完成了」,把檔案存起來去喝一杯。


猜你喜歡


年末壓軸不容錯過!線下大型開發者聚會「AWS Enterprise Dev Day」,精進企業雲端技術競爭力就在此刻

年末壓軸不容錯過!線下大型開發者聚會「AWS Enterprise Dev Day」,精進企業雲端技術競爭力就在此刻
Photo Credit:TNL Brand Studio

我們想讓你知道的是

AWS將於今年10月7日上午10:00舉辦線下開發者聚會AWS Enterprise Dev Day,以「技術開發」為活動主旨,透工作坊、講座形式,圍繞NET & Java現代應用、雲端服務、人工智慧等數位技術進行交流,精進企業雲端技術競爭力。

現今雲端已達到隨需可用的成熟度,企業該如何備戰自身技術力,了解透過雲端發展AI/ML應用、大數據分析、優化架構,並趁著新服務或新應用的契機嘗試上雲,或是將既有應用搬遷上雲,達到未來以更低成本有效管理內部資源及強化資安,並減少資源閒置,搭配現代化的方法論及工具保持未來彈性,在技術系統上達到永續經營。

AWS首次在台灣舉辦「AWS Enterprise Dev Day」,希望與企業交流如何在AWS上快速有效地遷移和現代化,以及針對希望了解開發、部署、管理現代應用程序的.NET與Java開發者介紹適合使用的工具和服務。

AWS Enterprise Dev Day活動特色

此次活動為首次為企業舉辦線下大型開發者聚會,為所有.NET與Java開發者量身打造的技術議程,以及同時從主管與開發者角色出發的活動內容設計,如有關於企業上雲挑戰、資安、現代化、開發、訓練考照等精彩內容。歡迎企業執行長、資安長、技術主管、及開發人員團隊立即報名,幫助您利用AWS雲端的廣度和規模,與眾多技術專家交流,持續保持自身企業在未來的即戰力!此外,本次活動全程錄影,報名參與者即可獲得AWS的演講內容。

最特別的是,此次活動下午場次採多軌分場的方式進行,屆時將有多場堂精選技術議程及實作上機工作坊,包含AWS熱門服務精華、方法論、最佳實踐、實戰分享等;而後續更將開放另外報名「.NET & Java現代應用開發實作工作坊」,帶您透過專業技術團隊支援及現場技術專家一對一諮詢,搭配實作課程與團隊協作解決實際技術難題,並與開發者技術同好現場即時互動交流。

立即點此報名「AWS Enterprise Dev Day」開發者技術盛宴!

本場開發者聚會將包含以下七大主題:

  1. NET & Java現代應用開發(.NET & Java Modern Application)
  2. 搬遷上雲(Migration)
  3. 無伺服器服務(Serverless)
  4. 容器服務(Containers)
  5. AI / ML人工智慧與機器學習(AI/ML)
  6. Data Analytics資訊安全(Security)(Security)
  7. 訓練考照(Training & Certificate)
1080x1080_02
Photo Credit:AWS

無論您是企業執行長、技術長、技術主管、資安相關人員、IT人員、解決方案架構師、開發人員、工程師或系統管理員,邀請您一同現場交流,藉此掌握現代開發趨勢、AWS的熱門雲端技術、平台與服務。

AWS Enterprise Dev Day活動資訊

1200x628
Photo Credit:AWS

日期:2022年10月7日(星期五)
時間:10:00 AM~3:30 PM
地點:南港展覽館二館 7F

立即點此報名「AWS Enterprise Dev Day」開發者技術盛宴!


猜你喜歡