方格精選
怎麼像工程師一樣思考？十個精華法則告訴你
更新於 發佈於 閱讀時間約 6 分鐘
工程師認為他們的專業迷人、有創造力並充滿有趣的挑戰。然而行外人卻經常認為工程學是重複性高、機械性而且讓人感到挫折。
兩種觀點都明顯為真。因為工程是門複雜的學問。工程學需要在大學課程的前兩年密集地學習數學、物理與化學。儘管聚焦在這些重要學科上，大學課程往往並沒有展現學科間的連結。
我們試圖翻轉這一點。藉由強調基本概念背後的常識、各項工程學專業主題之間的關聯、簡單的抽象概念如何從日常生活中推導出來，展現工程學背後的脈絡，相信能讓讀者一瞥工程學的林與樹。
「在每一個大問題裡，都有一個小問題等待優先解決。」—東尼．霍爾＊
＊譯註：霍爾（1934-）英國計算機科學家，圖靈獎得主，開發了霍爾邏輯、交談循序程式、快速排序演算法等。
1、 工程的核心不是計算，而是解決問題。
學校可能側重於教導計算的方法。但計算並不是工程的階段目標或最終目的，計算只是用來找到問題解決方案的許多手段之一。而藉由計算所找到的解決方案，其所提供的有效改良方法將能被客觀量測。
2、 每一個問題都蘊藏著我們熟悉的原則。
每一個問題都深深緊扣著一個我們熟悉的基本概念。這個概念可能來自靜力學 （statics）、物理學或數學。當我們遇到複雜的問題而無從下手，試著從那些問題中找出能以熟悉的原則或工具掌握的部分。我們可以直覺地、或是系統性地掌握這種拆解問題的方式，只要最終用來解決問題的方法在科學上是可靠的就行。從熟悉處開始下手，就能指出通向解決方案的途徑，或者能指向有待發展的新工具或新見解。
3、 檢查過多或過少都會產生更多錯誤。
有時，檢查會淘汰良品，或沒有準確地辨識出瑕疵品。假陽性（false positive，誤將良品辨識為瑕疵品）除了替換產品的成本外沒有太嚴重的後果。但假陰性（false negative， 誤將瑕疵品辨識為良品）則可能會有嚴重的後果，因為產品可能無法發揮應有的功用。
然而，更多的檢查不必然能解決問題。從統計學角度來說，無限的檢查將使幾乎每個產品都會被找出某些瑕疵。最理想的檢查頻率，能在不小心淘汰良品所造成的損失以及沒有測出真正瑕疵品所造成的後果間，達成平衡。
4、 不要假定解決之道。
設計者在進入到產品設計的階段時，便已對問題的根本、其導致原因、以及可行的解決方法做了許多假設。一個有智慧的設計者會用倒吃甘蔗的方式思考，先調查問題的成因，以及造成問題成因的成因，以及這些成因的成因。這可能會帶來與末端用戶期待截然不同的可能性，但這最能有效滿足真正的需求。
5、 像系統一樣思考。
系統必須被視為一個整體來分析，然而分析整體並不是分析部分的加總。部分的表現取決於它與所在系統間的關係；而系統如何表現則取決於系統內的關係網絡，以及系統與其他系統間的關係。
「系統性地思考」意味著一致而徹底地採用某種特定的思考方法。「像系統一樣思考」則意味著對系統及其相關連結進行思考―系統內的關係網絡、系統間的關係以及那個包含了所有系統的巨大系統。
6、 拓展問題的維度。
幾乎所有問題都比一開始看起來的還要龐大。把這點放在心上，並在一開始就拓展問題的維度―你不用多做什麼，因為問題的各個面向幾乎都會自動向外開展。比起從解法有限的狹小維度起頭，而後再來拓展維度，不如一開始就拓展維度，而後再來縮小範圍。
7、 所有的工程師都會計算。而好的工程師會溝通。
科學概念、分析技術與數學計算等解決工程問題的方法都已發展了數百年。在早期，工程師有一套奠基於數學、化學、物理學的共同語言，這使得世界各地的工程師能有效率地瞭解彼此工程上的突破與發展。
隨著更多工程專業領域的出現，工程師「對話」的需求也變得更迫切。現在的工程師不但需要注意領域內高度專業化的術語與概念，同樣地，工程師必須要能夠將這些專業術語轉換成能被客戶、使用者及其他工程師瞭解的日常語言。
8、 當你解決一個問題後，請再解決更多問題。
工程學是一門專業，工程師們則被要求解決各種特定問題。解決問題時，別被其他可能的問題分散注意，而忘了原本應該解決的問題。但也不要過於專注同一問題， 而讓你無法在能力之內處理更多問題。
9、 清楚說明「為什麼」，而不只是「要做什麼」。
當你將一個概念傳達給其他設計師、以繼續發展設計構想時，讓每一個決定背後的理由都能被知曉，無論是技術上的、人體工學上的、個人因素上的，或是其他。藉由闡明你的意圖，你能讓他們瞭解並保留計畫中最關鍵的目標，同時給了他們探索你未曾想過的可能性的空間。
同樣，當一個設計師請求你的幫助時，請他／她解釋先前各個決定的理由，以及他 ／她的目標。這樣就算你的回答不是對方預期的，也不會讓這場討論演變到令人失望的地步。
10、通常來說，工程學並不發明輪子，而是改良輪子。
偉大的發明，通常是在過往各項成就的逐步進展中催生的。1917 年，吉登昂‧森貝克（Gideon Sundback）發明了現代拉鍊。然而，惠康‧朱德森（Whitcomb Judson）早在森貝克發明拉鍊的十八年前就發明了「鉤子扣鎖」（clasp locker），而平縫機發明人艾利亞斯‧浩威（Elias Howe），則在桑貝克發明拉鏈四十年前就取得了「使衣物自動連續閉合」的專利。桑貝克以一顆顆「勺狀」的鍊齒，取代了過往的鉤子與鉤眼的扣鎖構造，每英吋的扣鎖密度增加，為我們提供了熟悉的開關拉鍊的滑動機制。桑貝克取得「可解開的扣鎖構造」的專利六年後，B‧F‧顧里區（B. F. Goodrich）推出了應用桑貝克扣鎖裝置的膠鞋，他以開關拉鍊發出的聲音「Zipper」稱呼拉鍊。
工程是在深刻的人類問題與日常的人類活動所串連出的連續性間進行的。那些未意識到連續性的工程師，會傾向於機械式地完成工作。而那些意識到連續性的工程師，將會更能適應時代的變遷、突來的挑戰與未知的狀況。而那些對連續性了然於心的工程師，則最有可能貢獻出創新的事物。
（本文摘錄自原點出版，John Kuprenas《工程師的思考法則：擁有科學邏輯的頭腦，像工程師一樣思考》）
為什麼會看到廣告
57會員
66內容數
留言0
查看全部
你可能也想看
Google News 追蹤
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
這篇文章探討了工程師在如何有效提升自己，強調不僅僅是多coding，而是要對程式碼有更深層的理解。隨著職涯發展，工程師需要從單純的技術執行者轉變為團隊領導者，具備解決複雜問題和與他人有效溝通的能力。
數學系的訓練，與上面閱讀原始碼的優先順序，本質上是反過來的。在數學的訓練中，是先把函數定義的非常清楚，再進一步去看函數應用在具體的數據上會發生什麼行為，然後就到此為止，不太會再有進一步的討論。但如上面西尾泰和所述，工程師看事情的角度，是先掌握全局，然後再進一步細化每一層的細節。
職場中有句話常被人提起：“先懂做人，才能做事。”這句話看似簡單，卻蘊含了深刻的智慧。今天，我們就來聊聊這個主題，並通過一個真實的故事，讓大家更深入地理解這句話的真正含義。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
專案經理與工程師在工作上面對的挑戰和需求截然不同。專案經理需具備溝通、督促、認知及行政等四種核心能力，以便成功轉型。文章中舉例以生動的故事來說明這四種能力的重要性，並強調從工程師升遷為專案經理並非易事，需要不斷學習與努力。
這篇文章主要討論了設計的主客觀問題。透過討論設計師必然面對的主客觀問題，幫助讀者更妥善地處理設計衝突及評價，使設計更趨向完整。
在《為什麼這樣工作會快、準、好》一書中，作者Charles Duhigg介紹了「工程設計流程（engineering design process）」決策法，這是一套要求人們在解決問題的過程中，需要根據以下幾個步驟：明確界定問題、蒐集資料、提出解決方案、討論選擇並透過持續的實驗找到最好答案。其實這個
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
在選大學校系，甚至是選擇職業的時候，大家通常都會關注產業前景跟工作報酬，但卻忽略了最重要的一點，你的熱情在何處？如果沒有熱情，連持續學習該領域都顯得困難，又要怎麼做到在產業中競爭呢？不是別人做的工作看上去好就是好，自己過得好與不好只有自己知道，也無須和他人比較。
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
這篇文章探討了工程師在如何有效提升自己，強調不僅僅是多coding，而是要對程式碼有更深層的理解。隨著職涯發展，工程師需要從單純的技術執行者轉變為團隊領導者，具備解決複雜問題和與他人有效溝通的能力。
數學系的訓練，與上面閱讀原始碼的優先順序，本質上是反過來的。在數學的訓練中，是先把函數定義的非常清楚，再進一步去看函數應用在具體的數據上會發生什麼行為，然後就到此為止，不太會再有進一步的討論。但如上面西尾泰和所述，工程師看事情的角度，是先掌握全局，然後再進一步細化每一層的細節。
職場中有句話常被人提起：“先懂做人，才能做事。”這句話看似簡單，卻蘊含了深刻的智慧。今天，我們就來聊聊這個主題，並通過一個真實的故事，讓大家更深入地理解這句話的真正含義。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
專案經理與工程師在工作上面對的挑戰和需求截然不同。專案經理需具備溝通、督促、認知及行政等四種核心能力，以便成功轉型。文章中舉例以生動的故事來說明這四種能力的重要性，並強調從工程師升遷為專案經理並非易事，需要不斷學習與努力。
這篇文章主要討論了設計的主客觀問題。透過討論設計師必然面對的主客觀問題，幫助讀者更妥善地處理設計衝突及評價，使設計更趨向完整。
在《為什麼這樣工作會快、準、好》一書中，作者Charles Duhigg介紹了「工程設計流程（engineering design process）」決策法，這是一套要求人們在解決問題的過程中，需要根據以下幾個步驟：明確界定問題、蒐集資料、提出解決方案、討論選擇並透過持續的實驗找到最好答案。其實這個
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
在選大學校系，甚至是選擇職業的時候，大家通常都會關注產業前景跟工作報酬，但卻忽略了最重要的一點，你的熱情在何處？如果沒有熱情，連持續學習該領域都顯得困難，又要怎麼做到在產業中競爭呢？不是別人做的工作看上去好就是好，自己過得好與不好只有自己知道，也無須和他人比較。