如果第二次看到我的文章，歡迎「文末」掃碼關注我喲~

每週五11：45 按時送達。 當然了，也會時不時加個餐～

我的第「120」篇原創敬上

大家好，我是Z哥。

今天我們聊的話題對大多數人來說應該都算是一個“痛點”，就是怎麼提高自己解決問題的能力。

我們的工作中，每天會遇到大大小小的很多問題。其中有些是之前從未遇到過的問題，這對很多人來說就會很棘手，不知道該怎麼解決，可能吭呲吭呲折騰好幾天都不一定能搞定。

但是身邊往往也一定會存在這麼一小部分人，好像無論什麼問題，到他們那就能夠順利地解決。

難道他們真的只是“看得多，懂得更多”而已嗎？

我根據我身邊所接觸的人群來看，還真不是。

根本原因我認為是他們有自己的一套成體系的思考策略。表現出來的“懂得更多”而是基於這些策略經過時間的打磨後產生的結果，而不是原因。

之前看過一個淘寶技術團隊裡的故事。

當時某個小組遇到一個問題，組內的幾位成員搞了好幾天沒搞定。沒辦法，不得不跨部門去請教多隆大神，多隆5分鐘後回覆了一個解決方案，他們試了下果真把問題解決了。

所以你看， 解決問題的能力高低可以差距那麼大，遠遠超過所謂的10倍程式設計師的概念。而這其中能不能掌握正確的思路至關重要，但是我們很多人往往是“腳踩西瓜皮”，滑到哪算哪。

很多人平時遇到問題，最習以為常的就是四連招，「開啟百度，複製，黏貼，點選搜尋」。

然後就掃一眼標題去點開覺得靠譜的網頁去看。

這樣解決問題的方式從形態上大致是下面的這樣子。

這其實是一種最理想的狀態，從「問題」直接對應到「解決方案」。但現實是，建立這個對應關係其實沒那麼容易。就像找物件，你想在忙忙人海中找到你命中註定的另一半，還不想刻意去找，TA就出現在你眼前的機率有多少？

我們的人性深處就是喜歡「低投入高收益」的事情。希望正好有人和我遇到一樣的問題，並且還解決了，同時還花時間整理成文釋出在了網上。然後，自己可以順手摘下這個果實，解決眼前的問題。
但現實往往是，

沒人和我遇到一樣的問題哎。
這個問題和我的有點像，但是又不完全一樣，沒法用。
這個人和我遇到了一樣的問題哎，但是下面沒人回覆怎麼解決的，扎心……

要擺脫這種狀態，就得培養自己解決問題的思路體系。

我們可以這樣來考慮。

把解決問題的過程想象成是一個“漏斗”，逐漸收斂，最終定位到某幾個具體的解決方案。

這個“漏斗”分為幾個階段，場景分析、定義問題、建立假設、驗證。

每個人大腦中所沉澱下來的「經驗」，其實就是將經過這個漏斗走過一遍的路線圖儲存在了你的大腦裡，然後才達到了“開箱即用”的狀態。

/01 場景分析 when where/

大家都知道，很多問題其實背後的本質是一樣的，只是換了一個外殼出現在你的面前。

比如，當你看到一個程式記憶體佔用持續上升，和從系統日誌中看到這個程式有記憶體溢位的錯誤日誌，你很容易得到它們背後的原因都是一樣的，某些物件使用完後沒有釋放資源。

但是，當你在實際解決一個問題的時候，還是不能把問題所在的場景給忽略了。因為這裡面埋藏著導致這個問題的“變數”。

這個問題是在一個什麼場景下發生的？
這個場景的完整過程是怎樣的？

只有搞清楚了所處場景，你才能順藤摸瓜找到問題的根源。否則你的系統化思維也培養不起來，而且系統化思維對於做接下去的第二點也很重要。

/02 定義問題 what/

當你透過百度搜尋一個問題的時候，輸入的內容越多，得到的結果越精確，對你價值越大，但是結果的數量卻越少。與之相反的是，輸入的內容越少，得到的結果越泛，但是數量越多。

當第一種方式不管用的情況下，想要得到更多有價值的資訊，前提條件就是要我們提煉出合理的關鍵字。

因此，能否把一個問題定義的夠清楚，觸達問題的本質顯得格外重要。

其實 世上本無“問題”，“問題”源於現狀與期望之間的「差距」。

當你覺得現狀符合你的預期的時候，哪還有什麼問題啊。比如，我們做程式設計師的小夥伴預期是什麼？永遠沒有bug！那麼只要出現了bug，就不符合預期，這就是“問題”：D。

回到這個「差距」上，要搞清楚每個問題的「差距」，你就得對這個問題的相關資訊有充分的認識，而不是以偏概全。

比如，當你看到一個程式cpu跑得很高，不能簡單將其定性為cpu資源分配太小，加大就行了。而要分析看看，對比上週、上月的同期情況如何？如果對比下來差異很大，那麼至少這個「cpu需要加大到XX」這個期望就是錯誤的。

期望錯了，問題的定義也就錯了。自然後面去解決它的道路也是錯的。

所以，這第二個環節就是「搞清楚這到底是一件什麼事？」

/03 建立假設 why/

這是一個人「解決」問題能力高低的關鍵。「想得到」才談得上「去解決」。

很多人在解決問題的時候容易停留在表面，這會導致解決問題的方式指標不治本，後續還會再反覆出現。

比如，某個程式發起的請求出現超時，發現超時時間的配置是5秒。首當其衝進入大腦的解決方案是，改長啊，改成10秒。

上面提到的「程式cpu跑得很高」的例子也是這樣。

這就是典型的還沒找到原因，就去解決問題的例子。雖然短期內，從表象上看著問題是解決了，但是根本原因並沒有找到，反而是被掩蓋掉了。
在不久的將來必定會重蹈覆轍，再次暴露問題。

怎麼辦呢？建立假設。

這個方法本質上也是 易經中的「象、數、理」概念的體現。
任何「現象」的背後一定會存在「資料」的變化，而之所以產生這個變化一定有它的「道理」。

其實簡單來說就是不斷地追問why？why？why？將當前場景中導致這個問題的“變數”儘可能多的挖掘出來。這些變數最終會是一個「樹形」的結構，因為你順帶將它們分解好了。

/04 驗證 how/

Ok，透過第三步將影響這個問題的眾多變數給提煉出來了，那麼可以開始逐步驗證了。如果這個變數……（這樣），會……（怎麼樣）。

驗證假設的時候，需要我們帶著批判性思維來質疑自己剛才提出的假設。當然這個有點難，需要練習。

有時候也可以選擇動手實踐，比如像我們做程式設計師的，可以實際去改一下程式碼試試看。只是這會比較費時間一些。

好了，思路捋清楚了，那麼具體我們可以怎麼做呢？

/01 把思考的過程寫下來，畫出來/

這其實在倒逼自己轉換成“漏斗思維”，而不是想尋求一步到位的結果。

比如，在紙上將前面提到的第一點「場景分析」透過流程圖的形式畫出來，這樣你對整個過程能有更直觀的認識，也能更準確的定義問題。（字醜，請見諒……）

像第三點的建立假設也可以在紙上畫出來。比如，畫個魚骨圖。

/02 幫助解決之後要追問/

很多人找人幫忙解決掉一個問題之後恍然大悟，哦原來是這樣子啊。然後就高高興興的回去按照對方說的去改了。

只是這樣的話，下次遇到類似的問題還是不會。對方身上解決問題的能力一丁點都沒學到。

我建議是，當別人告訴你解決方法後，不要停留在結果上。簡單多問問，

你是如何想到這裡的？
你是如何搜尋到解決方法的？
你是根據問題什麼輸入做出判斷的？

這種發問相當重要， 透過這種發問其實你是在問別人解決問題的思考方式。別人的思考方式再和你自己的一印證，再問問自己我當時為什麼沒有想到那個點上呢？我下次再遇到類似問題我應該多考慮點什麼呢？

長期以往，你的解決問題的能力會顯著超過其他人，並且會大大加強「建立假設」的能力，因為你不是一個人在“戰鬥”，知識的廣度和深度積累更快。

/03 瞭解上下游/

關於上下游的瞭解，不用多，只要上一級和下一級就夠了。比如，遇到一個資料庫的問題，可以瞭解一下，儲存或者作業系統相關的知識。遇到某個模組B的問題，可以瞭解一下它的上游模組A是做什麼的？對這個業務是怎麼處理的？下游模組C是做什麼的？對這個業務是怎麼處理的？

這間接也是在為強化漏斗第三環的能力。

/04 關鍵字也需要迭代/

其實想用好搜尋引擎，對我們大部分人來說，你不用去研究搜尋引擎的原理，提煉好關鍵字就夠了。

關鍵字的選擇一定要遮蔽個性化的內容，比如原始碼行數，你自己的方法命名等等。

其次找最有價值的關鍵字，比如異常的型別、某個系統原生方法或者系統內建變數等等。

關鍵字上再配合你出現問題的軟硬體環境，如java環境、版本號等等。

在搜尋過程中許多網頁雖然沒有明確提供解決答案，但是會提供有價值的補充關鍵字。所以，你可以藉此來迭代你搜尋時鍵入的關鍵字，以此找到更深或者更廣的內容。

其實我們平時所面對的「問題」，存在兩種型別。 一種是現實中的“異常”，也就是「我知道應該怎麼樣，但實際不是這樣」； 另一種是現實中的“痛點”，「我知道這裡不好，但是不知道該怎麼變得更好」。前者面向當下，後者面向未來，我們這裡聊的主要是第一種。

好了，我們總結一下。

這篇呢，Z哥先和你強調了解決問題的能力在不同的人之間可以拉開很大的差距，所以我們要重視培養自己解決問題的能力。

其次，列舉了一些我們解決問題能力還不強時會普遍出現的情況，讓你判斷自己當前所處的階段做參考。

然後，我 建議你透過“四層漏斗模型”「場景分析、定義問題、建立假設、驗證」來作為解決問題的思路。

最後分享了4個實踐技巧，後面有想到再補充。也歡迎大家在留言區分享你的技巧。

希望本文對你有所啟發。願大家都能成為10倍高效的問題解決者：D

解決問題的能力 > 10倍程式設計師