解決問題的能力 > 10倍程式員-有解無憂

如果第二次看到我的文章，歡迎右側掃碼訂閱我喲~ ??
每周五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