工程文化：優先解決問題，其次探索原理

原創文章

分類：工程文化，方法論

適用人群：不熟練的工程師，對團隊協作認知不足的新人

--------------------------------

我最欣賞的當代不太知名武俠/歷史小說家冰臨神下，其創作以線索縝密，情節轉折，文辭上佳著稱。我們經常能從中讀到精彩的句段。例如被其讀者廣為推崇的「論真相與問題」。

冰臨神下曾在作品中這樣寫道：

「找出真相」與「解決問題」是截然不同的兩件事，打個比喻，有人丟了一百兩銀子，追查真相的人想知道錢到底存不存在、有沒有丟、誰是竊賊，解決問題的人則想變出一百兩讓大家都滿意，至於錢從何而來由誰提供，都是無關緊要的小事。

自從讀到這段話以後，在和一些不熟練的軟體工程師溝通「如何解決問題」時，我都喜歡重複這個比喻。

這個立論的核心在於，當人面對問題時，將採取的行動其實是針對兩個方面的。這兩個方面不僅截然不同，而且很多時候關聯不大。思維不清晰的人往往分不清兩種行動的主次，以致於浪費了許多時間卻沒有達成理想的目標。

那麼「找出真相」和「解決問題」這兩件事，哪一個更優先？

上面的疑問沒有絕對正確的答案，在不同的情況下，這兩件事的優先順序，取決於你當時的目標。對於工程師而言，或者說，在整個工程文化倡導的方法論里，大家各自貢獻知識資源，以協作的形式，向大家共同認可的目標持續推進。在這種情境下，「解決問題」應該是更優先的。

越是高效率的工程師，越是專註於優先解決問題。在軟體開發領域，無論是進行新的設計，開發新的功能，修復被發現的 BUG, 還是解決各種突發故障，都屬於解決問題的範疇。

我想說的是，無論解決上述任何一種問題，都應該以解決方案為優先，而隨後再展開對真相，原理的探索。兩件事情都是必要的，但是不要把順序反過來。不然很容易造成時間的浪費。

而且在管理學，社會學涉及的很多領域，也不難發現各種方法論對這一點的重視與強調。不同領域，不同知識背景的人，對這個世界如何保持高效有序運轉有著各自理解。而我作為一個典型的工程師，認為工程文化中的許多精神可以用來推進這個世界的方方面面。

就在前幾天，虹橋機場險些發生一起重大事故。由於調度人員的疏忽，東航的兩架飛機在機場跑道上上演驚心動魄的一幕，幾百名乘客一度距離死亡只有十幾米的距離，幾乎重演曾經的特內里費特空難。

相關報道：

東航兩飛機險相撞：就差三秒 320從330頭上飛過

在回顧這場驚險時，諸多媒體都提及東航 A330 機長的及時反應：第一時間做出正確升空判斷，如果晚 2-3 秒做出決定，後果將不堪設想。

讓我們嘗試設身處地去考慮這件事：在面對 「兩架飛機即將相撞」 這樣生死攸關的問題時，什麼更加優先？

是要找出真相，仔細分析 A320 為何會出現在跑道上？詢問機場調度為何錯誤作出了跑道就緒的指示？

還是要解決問題，想盡一切在現有條件下辦法避免事故的發生？

解決方案屬於未來，而問題屬於過去。在生死一線的情況下，專註於未來的人，才能存活下來。在那幾秒鐘之內，問題的具體原因，真相，對於 A330 的機長而言都並不重要。他需要依靠他的全部領域知識，經驗，做出解決方案，並立即執行。

留給他的思考時間可能只有短暫的幾秒。我們把這個時間拉長百倍，千萬倍，拉長到我們所在的整個團隊，產品，項目的生命周期里，再次思考這個問題時，是否應該感覺到類似 A330 機長所面對的壓力的千萬分之一？

答案是應該的。也許在另外的情境下，人要面對的不是即將到來的生死，但距離目標的失敗/無法達成的底線而言，時間終歸是有限的。

在學校里，老師和學生們做的大多數事情，都是圍繞著找出真相，探索原理，因此學生會擁有極大的時間寬裕來研究，弄懂一切，並以這種精神獲得老師的讚揚。

而在一個工作團隊里，大家更關注目標的達成。提前支付過多的時間去找出真相，探索原理，而不是設計解決方案，無論對於個人成長，還是團隊的效率，都會帶來負面影響。過多過早地研究問題原因/原理，不僅會讓他人焦慮，等待，而且也很可能會讓問題由於拖延放置變得更加嚴重。

離開學校，進入實際工作環境不久的團隊新人，一定要理解，接受，適應這種轉變。

要快速地解決問題，需要迅速定位問題，確認解決問題的目標/驗收標準，以及和相關人員及時準確地溝通；其次，是擁有必要的知識技能；當然最重要的，是時間觀念和積極主動的精神。

上面的這些能力，都有許多有效的方法來不斷提升。我以後會在其他文章里寫到。

並不是說，一味的解決問題，就完全不去找出真相和探索原理了。在工程文化里，這些只是優先順序其次的事情，而不是可以放棄不做的事情。相反，如果不去研究，探索，分析事物的原理和提升對各種知識概念的理解，個人的技能無法提升，即使再擅長解決問題，也只能解決低水平的問題。團隊也會因為缺乏內功，在技術目標和商業目標的達成上，遇到天花板。

寫這篇短文的標題時，我問團隊里的小李：對於上面說的這個理論，你有哪些過去印象稍微深刻的經歷？

小李的敘述：

例如 HTTP 請求這件事，就是這樣。

在一開始，我可能更關注於網路協議，報文，數據包，請求頭，連接 …… 這些概念，覺得必須搞懂這些概念。

但寫了一段時間的程序之後，我開始明白，為了完成大部分工作任務，完全不需要用到這些概念，而更應該注意：請求發送了什麼？響應成功還是失敗？返回信息是什麼？是否符合預期？

這就是一個不錯的總結。同理，再給不熟練的工程師們幾個 TIPs：

• 讀日誌的時候，學會找日誌關鍵點，不要試圖弄懂每一行的意思，你就當這是在玩找彆扭，而不是認真讀書。
• 如果你很有自信對程序邏輯的理解沒有問題，但程序確實又發生了原因不明的 BUG，你把某幾段程序重寫一遍，可能比找 BUG 原因還要快。
• 學習新技術的時候，把學習的過程當做是在不斷解決問題，如果沒有問題也要自己發明問題，然後不斷用剛學到的知識去解決自己發明的問題。
• 寫工作彙報的時候，看彙報的人更重視你遇到的問題，以及解決問題的嘗試，解決成功與否。而不特別關心你收穫了學到了什麼（他不是學校的老師）。
• 找人幫你解決問題也是一種解決問題的方式，可以是同事也可以是你認識的任何人。只要你保證，同樣的問題，不要反覆找人幫忙，下次自己解決，就完全過得去。
• 一個一直盯著屏幕看，很長時間沒有敲鍵盤的軟體工程師，很可能已經丟掉了解決問題的優先順序。反思一下你過去是否有時會進入這樣的狀態。

希望大家不斷進步！

--------------------------------

微信訂閱號 - 笨笨鳥公會 (benbenguild)

歡迎關注，知乎專欄同步更新

推薦閱讀：