《你的燈亮著嗎?:發現問題的真正所在》

金融區是什麼意思

《你的燈亮著嗎？：發現問題的真正所在》

日內瓦湖旁邊的群山中，有一條上山隧道，雖然隧道內的照明條件很好，但司機必須做好萬全準備，以免因為停電釀成慘劇，這在山區是很有可能發生的。於是，一條這樣的警示標誌製作出來：

注意:前方有隧道，請開啟大燈。

警示標誌懸掛在隧道入口外。看起來安全隱患算是解決了。

從隧道東端出來繼續往前行駛400米，就到了全世界景色最迷人的一處休息區。這裡從高處俯視湖區，可以將美景盡收眼底。每天，總有數百名遊客來此欣賞風景。但每天，總有至少十位遊客回到自己的車上時才發現，儘管身體和精神都得到了放鬆，車上的電池卻耗盡了，因為他們下車的時候忘記了要關掉車燈。警察總是使盡渾身解數，才能幫他們發動車，或者把車輛拖走，使得遊客們怨聲載道。

為了解決這個問題，工程師考慮了好幾種解決方案：

在隧道出口處設定一塊標誌牌，寫上「關閉車燈」，但這樣的話，人們在夜間行駛時也會把車燈關掉。無視目前情況……哦不行，情況已經出現了，而且政府認為工程師的工作很不理想。在俯瞰景觀的地方設定一處充電站，但維持充電站運轉的費用會很高昂，而且如果充電站不能正常工作的話，人們會更憤怒。授權一傢俬人公司來經營充電站，但這就意味著讓景區商業化，政府和遊客式不會接受的。在隧道出口處設一塊語言表述更明確的標誌牌。

工程師的直覺告訴他應該寫出明確精準的標誌說明，最後得到了一個帶有瑞士精準風格的作品：

如果是白天，而且車燈亮著，那就把車燈關上;

如果是晚上，而且車燈關著，那就把車燈開啟;

如果是白天，而且車燈關著，那就讓它關著;

如果是晚上，而且車燈亮著，那就讓它亮著。

不管司機是誰，等讀完這條標語，他的車早就衝出護欄，被水流帶到湖底了。最後，總工程師採用了「這是

他們的

問題」這一方法，來取代之前的種種折騰。假設司機有很強的願望解決問題，只是需要一點小小的提醒。他還假設，如果司機都通過了駕照考試，他們就不會是徹頭徹尾的傻瓜。司機們需要的只是在隧道盡頭設定一塊標誌牌，上面寫著：

你的燈亮著嗎?

如果司機們笨到連這句話都看不明白，那電池耗盡應該只是他們所碰到的問題中最簡單的一個了。

以上就是本書中最具代表性的例子，也是書名的由來。本書的作者之一是在軟體領域大名鼎鼎的傑拉爾德·溫伯格，從20世紀70年代開始，他總共撰寫了30多本書籍和數以百計的論文。

這是一本教你認知問題本質的書。需要注意的是，本書側重在提示你看待問題的角度，而不是教你解決問題的方法論（讀前我就有這樣的誤解），畢竟具體的解決方法都要視具體問題而定，並不存在一勞永逸的應對方法。

《你的燈亮著嗎？》屬於啟發性的作品，沒有那麼嚴謹的框架，總共分六章，每章都以一個事例開篇，丟擲問題讓讀者先自行思考，再點出其中極易被忽略的解決問題的關鍵點。全書大致從三個大方面闡述：

問題是什麼？問題該由誰解決？問題來自哪裡？問題真的需要解決嗎？

問題是什麼?

這一部分作者給了最大的篇幅，用了三章來闡述，這很容易理解，如果你都不知道問題是什麼，何來談解決之道。然而，很多時候，我們就是這樣，遇到一個問題就迫不及待拿出各種辦法，甚至都沒有先好好想清楚問題到底是什麼？

作者在其中舉了一個例子：哥譚市金融區的中心地帶，有一座剛落成的辦公大廈，然而還有未出租空房的情況下，大廈電梯就不夠用，造成了租戶的諸多不滿，甚至威脅退租。

面對這樣一個不算複雜的問題，很多人可能在讀完上面這段介紹之後就能給出不止一套解決方案。然而，在弄清楚問題是什麼之前，不要著急著給出解決方案。同一個問題，站在租客的角度和房東的角度，需要給出的解決方案是完全不同的（甚至相反），這樣的區別足以讓我們抑制住匆匆拿出解決方案的衝動，先問問：

誰碰到了問題?

然後針對答案中的每個群體，再問問：

問題的本質是什麼?

如果對問題下一個比較簡單的定義就是：

問題就是理想狀態和現實狀態之間的差別。

然而，很多時候需要注意的是，你可能

永遠都無法確定已經找到的問題定義是正確的

，因為當人們嘗試透過改變狀態來解決一個問題時，常常會新制造出一個或幾個新問題來，簡單說：

每一個解決方案都是下一個問題的來源

，而且這些問題常常在無意中產生。很多時候，發現這些問題本身就是最難的部分了。

在發現和定義問題時，有幾條tips可以嘗試：

跳出既有身份和視角，假想一個陌生視角來重新看待問題。去過外國旅遊時，我們都不可避免地會遇上讓人覺得彆扭的地方，同樣的，對於習以為常的生活環境，嘗試跳脫開自己的身份，想象自己是一個第一次來中國的瑞士遊客，選一個小東西（比如100元紙幣）用他的眼光看看，會不會看出一些有趣的問題呢？注意那些解決方案和其提出者不匹配的情況，極容易產生新的問題，甚至是危險。解決方案的設計者，並不受問題帶來的困擾，也難以體驗到自己的設計帶來的後果，這種錯位常常帶來不協調的解決方案，衍生出新的問題。對問題定義不斷進行修正。能一眼就看出問題本質的情況畢竟是少數的，大多數情況——哪怕表象很簡答——問題的本質都隱藏在深處。隨著接收資訊量的增加，需要對問題的定義不斷修正（越到後程越會發現問題不是你之前想象的那樣），而不要兩耳不聞地一條道走到黑。

問題該由誰解決?

找準問題最迫切的解決者，往往是那些最受問題困擾的人，如果他們有能力解決，就儘量讓他們自行解決，提供幫助但不過多插手；如果他們沒有能力解決，試著把問題引導到那些有能力解決的人身上。

軟體開發行業有一句很有名的話：

Eating your own dog food

。原本是指軟體的開發者必須得使用自己開發的軟體，這樣才能知道問題和缺陷在哪，從而準確解決。在DevOps中，也指開發人員自己做測試和運維，你自己寫的程式碼，出了問題也由你來解決。只有吃自己的狗糧，才能知道哪裡好吃，哪裡難吃。

有時，為了改變局面，也可以嘗試著把解決問題的責任歸到自己身上——哪怕只有一會兒。這可能不會真正為所與人解決問題，但也許起碼能幫助你自己擺脫問題。

問題來自哪裡?

典型的例子就是考試。如果你清晰地知道這道題考點來自教材第三章，那你解決它的可能就大大提高。同理，處理問題的時候，試著搞清楚問題來自哪裡，是哪個環節出問題帶來造成現在的局面。一旦搞清楚這點，離真正解決問題也不遠了。

問題真的需要解決嗎?

有些時候，問題和解決方法簡直就像房間裡的大象，你以為沒人注意到，沒人想到過解決方法嗎？或許你應該考慮下這種問題存在也許有它的價值——這個時候甚至不應該稱之為問題了。很多問題之所以如此明顯地存在，不是因為它本身，而是有其他外力使得它難以解決，比如道德、強權和解決它的代價和風險。所以評估下眼前這個問題真的需要解決，或者有多少人真的期待這問題被解決。如果得到的答案是否定的，那就放著隨它去吧。

以上，《你的燈亮著嗎》算是有啟發性的書，話不多，點到為止，需要你自己再歸納和發散，最後能獲得更多屬於自己的想法和見解。

著作權歸作者所有