通用工程導論/解決問題
“壞了。” 這些話出自看著講師的大一工程系學生之口。講師的眼睛閃爍著，卻一言不發。期待、興奮在空氣中醞釀，問題“為什麼”開始在空氣中無聲地飄蕩。工程生涯要開始了麼？
提到問題，大一學生就會想到解決方案。可能會引發一場競賽，看誰先解決問題。在簡報和筆記本中，問題後面緊跟著解決方案。這是一種技術人員的態度，而不是工程師的態度。工程師不修理東西。工程師解決問題。這之間存在巨大的差異。
工程師以問題為生。問題轉化為專案。工程師不會對其他工程師說“壞了”。“壞了”這句話將緊張情緒、責任和工程機會轉移給了別人。
工程師在問題的緊張氣氛中度過更多的時間。引發的工程競賽是看誰能想出儘可能多、完全不同、可能、瘋狂、古怪的解決方案……多種解決方案。不存在“修理”一說，因為通常物件還不存在。第一個解決方案可能不是最好的。問題可能沒有解決方案。問題可能從未被解決過。當前的解決問題思路可能存在問題。下面列出了說明技術人員和工程師故障排除差異的細節。
The mere formulation of a problem is far more essential than its solution … To raise new questions, new possibilities, to regard old problems from a new angle requires creative imagination .. Albert Einstein
大型問題涉及大量工程師，需要經理/專案經理/工程師協調工程師團隊。本課程的目標是透過小問題教授工程學，這可能會與技術人員的故障排除混淆。
技術人員可以透過以下解決方案進行修復：搖晃它，敲擊它，拆卸並重新組裝，插上筆，使用口香糖，纏繞一些電線，鑽孔，噴射WD40並貼上鴨嘴膠帶。技術人員的修復會導致正在執行的機器或過程偏離原始設計。工程師修復設計本身。工程師明白，經過25年的修復，同一批裝置現在已經變得獨一無二。改造這批裝置首先需要對演變後的混亂進行盤點，並再次找到最具成本效益的通用設計。
技術人員的驕傲與他們識別和解決問題的速度有關。工程師希望像品酒師一樣細細品味問題，聞而不飲。選擇靈感，而非速度。選擇優雅，而非實用。使用所有工具，而不是通常有效的那個工具。探索所有可能的解決方案，擴大範圍（硬體、軟體、期望、程式）。工程師不能受限於培訓和認證。
技術人員抱怨拆卸起來有多難，浪費了多少時間，並質疑任何需要的新工具、夾具或形式。但技術人員不必從頭開始組裝或計劃故障模式。他們不必擔心回收和/或回收利用。技術人員沒有接受過整個設計範圍的教育。技術人員不必擔心向投資者和政府監管機構推銷設計。工程師對所有事情負責。易於維修並非唯一的考慮因素。
技術人員和工程師以重疊、相似的方式進行故障排除。出於這個原因，公眾認為“工程師修理東西”。現實情況是，工程師“可以”修理東西，但你不會希望他們這麼做。他們更有可能徹底將其損壞。工程師不修理東西，因為他們沒有練習過，也沒有獲得技術人員的專業知識。如果工程師確實修理東西，他們不僅會解決你的問題，還會解決全世界各種版本的該問題……這可能需要一年時間。
例如，技術人員通常可以更換。工程師永遠不能更換。更換是技術人員的故障排除技巧。工程師不能用泡泡糖“修復”問題，因為他們正在設計尚不存在的東西。技術人員的專業知識源於變通方案。工程師挖掘這種專業知識，但永遠不能實施變通方案。工程師會怎麼做？在工程筆記本中寫下小問題。然後，他們在軟體中模擬問題。讓軟體複製問題。技術人員會怎麼做？追溯電路中的電源；用棍子按壓電路板，看看是否有任何東西松動；用手在電路板上揮動，看看是否有任何晶片異常過熱或過冷；重熔所有焊點。作為工程師，學習技術人員的故障排除方法總是有益的，但這只是工程學這頭奶牛的一個胃。
有大問題和小問題。大問題涉及其他人。影片來自俄羅斯工程師。小問題通常是一些觸發大量解決方案的小事（粘合、焊接、重新開始、一定有更好的東西可以尋找，等等）。不要選擇一個解決方案，對其進行測試，測試另一個，然後進行比較。找到最佳解決方案。列出可能的解決方案。寫下它們。寫作可能會啟發其他人。
以下是一些工程師與客戶的其他態度特徵
| 工程師 | 正常 |
|---|---|
| 堅持 | 要麼知道，要麼不知道 |
| 承擔問題 | 踢皮球 |
| 核實事實 | 做出判斷 |
| 我可以 | 我不能 |
| 工作 | 希望 |
| 尋找替代解決方案 | 草率下結論 |
| 跟蹤進度 | 不知道從哪裡開始 |
| 檢查和重新檢查 | 做出假設 |
| 每個人都值得懷疑 | 重複別人說的話 |
| 對症狀感到興奮 | 被解決方案吸引 |
| 繼續嘗試 | 壞了 |
| 必須存在 | 不存在 |
| 一直尋找直到筋疲力盡 | 找不到 |
| 涉及他人 | 放棄 |
| 更多工作！ | 藉口 |
| 惱怒，疼痛 | 否認 |
| 有明確的目標 | 生活在不知情中，迷茫 |
| 迪爾伯特 | 問題 |
“我卡住了”對工程學講師來說是美妙的音樂。一個開始工程的機會出現了！不要驚訝，如果你的工程學講師開始隨著這首歌跳舞
- 你為什麼卡住了？
- 我只是卡住了。
- 你在哪裡卡住了？
- 我無法開始。
- 你在什麼地方卡住了？
- 這個問題。
- 你希望我對此做些什麼？
- 我需要一位導師。
- 不，你不需要……如果你想成為一名工程師的話。
大多數關於創造性思維的連結都沒有正面擊中這種焦慮。有兩個問題。你對世界有什麼期望？你想成為專家嗎？到處都是挫折。任何體面的工作都會伴隨著挫折。真正的問題是你想要處理哪些挫折。工程師擁有最有趣的挫折……它們不涉及人！
大多數工程師都喜歡談論大問題，因為工程師能夠以一種重大的方式幫助世界。以下主題與大問題相關，大一新生可能不會參與其中。之所以包含這些主題，是因為每位工程師都需要同時處理大問題和小問題。大問題意味著豐厚的回報、崇高的尊重以及對世界的重大服務。大一工程師可能對能源比對世界和平更感興趣。他們可能對交通和大氣工程比對環境更感興趣。同時處理小問題和大問題！
大多數 K-12 實驗室都是封閉式的。老師們之前都做過這些實驗。有一堆說明，以及一些小方框供填寫答案。只有一個答案是不可爭議的。找到答案是最重要的事情。在這種環境下無法學習工程學。
解決問題需要突破傳統和觀點，梳理大量無關緊要的事實，並抵禦過早提出的解決方案的誘惑。這需要堅持不懈。開放式問題永遠不會“完成”。總能找到更好的螺栓、設計更好的橋樑或編寫更好的程式。範圍、規模、蝴蝶效應可能使原本良好的解決方案變成環境毒素。擁有 45 個活動部件的槍可以簡化為 17 個活動部件。生命週期可以縮短或延長。最終結果可能是火焰、永久儲存或回收。開放式問題會永遠持續下去。
必須設計支援系統。這意味著要規劃如何升級問題。問題應該升級給誰？支援系統通常具有分層的升級結構。在第一層，有人收集資訊（保修、購買日期、回電資訊），檢查簡單的解決方案並分配事件編號。如果他們無法解決問題，則將其升級給技術人員，然後是支援經理，最後是支援工程師。根據產品的獨特性，支援系統中可能只有工程師。在航天器的情況下，第一層支援可能是科學家。
許多公司每個事件收取 200 美元或更多費用，如果事件沒有被記錄（線上釋出），則會退還這筆錢。工程師（你）應該已經閱讀了文件並找到了現有的解決方案。工程師和技術人員建立知識庫或文件。
在物理世界中，必須將備件庫存戰略性地預先運送到暫存區以支援客戶。必須對人員進行培訓並將其納入保留狀態。這些物流是工程學的一部分。
支援工程師設計/發展支援系統。技術人員專注於一個領域，支援工程師負責瞭解所有領域。
無論問題是什麼，都要成為一名偵探。將事實與觀點區分開來。與熟悉問題的人交談。親自檢視問題。確認每個人所說的話。例如，假設“網路速度很慢”。
像偵探一樣，工程師不會相信任何一個人告訴他們的任何事情。“網路速度很慢”可能意味著任何事情。可能存在 100 個問題。也可能一個也沒有。可能存在一些非常小的問題，不值得修復。每個人都是嫌疑人。每個人都必須像偵探一樣接受詢問。
首先，問題定義從“網路速度很慢”修改為：一臺即時計算機沒有記錄實驗資料。
可能的解決方案
- 配置即時計算機以忽略傳入的arp請求
- 斷開未配置裝置（在本例中為彩色雷射印表機）與網路的連線
- 停止使用兩張網絡卡配置桌面。意外情況下，它們都可能被啟用，並將絕密網路和公共網路橋接。為每個網路購買單獨的計算機。
- 從集線器遷移到交換機。
在這些解決方案中，最後一個是問題的公眾面貌。其他三個解決方案會導致太多外部政治問題和內部問題。
解決問題的初始困難在於要弄清楚每個人意見的真偽。有時，最好假設什麼都不知道，並透過隔離來開始找出問題所在。這個問題與什麼無關？列出所有內容。像捕食者跟蹤獵物一樣，將問題圈出來。從物理世界開始。
維基百科有一個關於解決問題的很好的概述。
卡爾·鄧克的工作繼續激勵著人們。許多企業（如谷歌）每週都會給工程師一天的自由時間來從事他們自己的專案。為什麼？請觀看此Tedx 影片。這就是你想要成為一名工程師的原因！