從學生開始老師就教導我們什么是問題?如何找出標準答案。然而，經過十幾年的學習，大多數人依然沒有理解問題的本質。正確定義問題是成功的開始，更是成功架構師的必要條件。

[[311825]] 

圖片來自 Pexels

今天，阿里資深技術專家張榮華從問題的本質入手，用“升層思維”解決問題，告訴我們創新的核心，給出高效工作的途徑。

問題的本質

我也在很多場合問過一個問題：什么是問題?雖然我們天天掛在嘴邊，但是沒有人能夠給出較為合理的答復。之前我也沒有想過這個問題，很多人對問題的理解還不太一樣。

一部分人認為問題就是方案中的難點，一部分認為問題是現實和目標的差距，這些解讀我覺得都還不夠精確，我在嘗試定義無果之后查詢了大量的資料，終于找到了一個比較合理的定義。

目前我認為毛主席的解釋是比較合理的：“問題就是事物的矛盾。哪里有沒有解決的矛盾，哪里就有問題。”

而主管們經常問到：

• 你要解決的問題是什么?
• 這里的問題定義是什么?

其實潛臺詞在問，這里事物間的矛盾是什么(已經發生的矛盾，將來會發生的矛盾，可能潛在會發生的矛盾)，這個矛盾如果不早點解決，可能會激化，帶來很嚴重的后果。

其他例子：

• 中國人日益增加的財富和國產商品的低劣品質就存在矛盾，這個矛盾就是個問題(已經發生的矛盾)。所以我們要提倡中國質造。
• 如何利用新技術，更快更準地幫助消費者找到其最需要的商品，提升幸福感(將來會發生的矛盾，在矛盾發生之前，我們應該將之解決)。

上面幾個問題的定義都是社會級問題，而且都是公司層面在解決的問題，在我們技術同學的手頭的工作中應該也存在各種問題。

比如說 QPS 太低，RT 太高，不穩定，研發效率低，等等，這些問題的定義稍微常見一點，基本上大家只要解決問題，而不用定義問題。

[[311826]] 

準確定義問題是成功的開始

這么多年來筆者 Review 過很多技術方案，而且也經歷混沌混亂的模塊設計，大部分糟糕的設計基本上是摸不清楚自己到底要解決什么問題，總是覺得這個問題我要解決，那個問題我也要解決，甚至不是問題的問題我也要解決。

然后設計出了一個能解決所有“問題”的方案。但是實際情況是有些問題根本不是問題，有些問題確實是問題但是卻又不是核心問題，有些問題是核心問題，但是又不是當下最核心的問題。

我相信類似的方案有很多在 Review 的時候被擋下了，但是還有很多應該已經上線了。

如何盡可能減少這方面的損失?那就是要開始階段就要準確的定義問題，這也是這么多思想家推崇問題定義的原因。

著名思想家杜威如是說道：

“A problem well-defined is a problem half solved.”

愛因斯坦如是說道：

“提出一個問題往往比解決一個問題更重要，因為解決問題也許僅能是一個數學上或實驗室上的技能而已。而提出新的問題、新的可能性，從新的角度去看舊的問題，都需要有創造性的想象力，而且標志著科學的真正進步。”

那么準確定義一個問題要考慮哪些維度呢?我粗粗地列了一個表格，只是代表我自己的理解，未必是正確或者全面的，大家批判的閱讀：

 

這里應該是一個三維的圖形，有時間維度，主次要維度，緊急不緊急維度。

對這個主要次要，緊急不緊急是不是眼熟，沒錯，在很多如何高效工作上都有類似的方法，把要做的事情分成重要緊急，重要不緊急，不重要緊急，不重要不緊急。

其實我不太認同將事情劃分成重要或者不重要，緊急或者不緊急，我建議大家將自己手頭要解決的問題劃分為重要或者不重要，緊急或者不緊急。

因為事情只是一種方案或者手段，區分問題本身的重要度和緊急度才是思考的源頭(包含問題的升層思考)。

要填滿這張表格必須結合對業務的理解，和對產品的理解，尤其是業務理解，如果沒有業務理解，很難準確地刻畫問題。

可是什么叫問題的重要度呢?我也思考了很久，終于得出了一些較為自洽的解釋。

問題的嚴重程度

問題嚴重程度的定義

當我們明確地定義問題之后，我們就要設定目標來解決這個問題，但是現狀是殘酷的，我們目標和現狀之間可能存在巨大的落差。

這個落差的程度就是問題的嚴重程度，所以說：問題的嚴重程度是希望(目標)與現實的落差!

 

有些書或者文章里這樣定義問題：問題=目標-現狀，這個定義是模糊的，因為目標-現狀和這張圖一樣，往往表示的是落差。

落差往往讓人想起差距，用差距來形容問題是含糊不清的，很難讓人一下子就明白問題的本質。

我們拿性能問題舉例，我們的目標是 RT<1 秒的請求占比大于 98%，當前的現狀是 RT<1 秒的請求占比為 80%，那么這里的差距就是 98%-80%=18%。

這 18% 就是問題嚴重的程度，但是這 18% 絕對不是問題本身，這 18% 是問題的嚴重程度。

衡量問題嚴重程度的挑戰

要區分問題的嚴重程度有兩個挑戰：

• 現狀：對現狀有準確的認知，比如該例中某系統 RT<1 秒的請求占比為 80%。
• 期待(目標)：問題解決后的狀態有個清晰的表述，比如該例中某系統 RT<1 秒的請求占比大于 98%。

對于數值型的現狀，我們要搞清楚這個數值是容易的，只要將你的目標值減去現狀的值就可以得到問題的嚴重程度了。

對于難以量化的現狀，那要摸清楚問題的嚴重程度，可能需要一些案例，需要一些數據統計。

比如說架構現在不合理是個問題，這個問題嚴重到什么程度，那可以計算一下最近半年的需求在實現的過程中，花費了多少工時，如果架構合理的情況下哪些工時是可以節省掉的。

或者現在的架構上迭代需求故障和 Bug 的情況是怎么樣的，評估一下重構之后故障和 Bug 率會降低到多少。

只要現狀和目標有一個沒清晰，那我們就很難判斷出問題的嚴重程度在哪里。

FBI warning：如果你不能確定問題的嚴重程度(現在的或者將來的)，不要貿然行動去沉迷于方案的設計。

而不定義問題，不評估問題的嚴重程度，往往是很多工程師的常見思維習慣，大家可以對號入座。

問題的分類

 

基本上看這三類問題的字面意思就可以知道這三類問題的區別了：

• 恢復原狀型：原本就應該是這樣的，但是現在不是，比如說原本輪胎就應該是充滿氣的，但是現在扎了個釘子，所以我們要讓輪胎恢復原狀，這就屬于恢復原狀型問題。
• 風險防范型：問題可能發生，也可能不會發生，但是一旦發生，帶來的危害是巨大的，所以我們不得不費大量的精力來防止這樣潛在的問題發生。在安全和可用性方面，很多工作都是屬于風險防范型。

這里的尷尬之處是做了對數字指標可能沒什么提升，但是不做可能會發生特別嚴重的事故，帶來極其負面的影響。

• 追求理想型：知道未來會發生的矛盾是什么，提前解決未來必然會發生的矛盾。

如果將這三個問題映射到架構上，那么應該是如下的描述：

①解決架構上未來會遇到的問題：已經明確預知到未來的業務問題，并且可以轉換為未來的架構問題，提前做架構準備(功能性&非功能性)。

我根據自己的理解又將其劃分成兩類：

• 目標是非常明確且可以用數字衡量的：比如性能問題是可以準確定義一個指標來衡量問題當前的具體的量化值的，RT 要降低到多少毫秒，QPS 要提高到多少，穩定性要提升到幾個九等等。

基本上非功能模塊都可以用數字來衡量，比如我們系統中出現的數據搬移的功能，都是目標明確，且可以用數字來衡量的。

• 或者比如系統的可擴展性要達到什么程度，是否滿足 95% 以上的需求下不需要進行大量重構。
• 目標是不明確的：比如將來要走哪個方向，要做什么樣的技術準備，很多的類似的場景是很難直接評估出一個度量指標的。

可能只有一個愿景和使命，根據這個愿景和使命來分解問題，然后我們才能設定通往這個理想的問題的路徑。

而探尋到這個理想的過程是相當的復雜，要考慮的因素實在太多，我只能說這個東西我的經驗真的不多，我只能嘗試用我所學的內容來進行自頂向下的推導，而以目前的功力實在很難保證結果的正確性。

②解決架構上當前已經發生的問題：架構上的問題已經發生了，要對架構當前的問題進行識別，定義，以及解決(功能性&非功能性)。

③解決當前架構合理迭代的問題：我們在架構上進行大量迭代，迭代過程中往往容易給架構挖坑埋雷，我們應該盡可能避免這樣的情況發生(功能性&非功能性)。

這三大問題正是各線任意一個粒度的架構師需要明察，并時刻提醒團隊的三大問題。如果無法定義這三大問題，那么這里可能就是最大的問題。

這里還要闡述一個問題：即使是未來的架構，我們還有分類，一類是你走在最前面，一種是你跟著別人，你跟著別人要怎么跟上去。

這里應該有個決策分支，告訴我們遇到什么場景的時候應該用什么樣的思考方法，不過這只是個人總結，每個人腦海里應該都有一套類似的方法，而且這套方法是在不斷的突破和修正的。

問題定義中的常見問題

誤把方法/手段當“問題”

接下來，我編了三個小故事，大家從故事中感受一下手段和問題的區別，以及我們如何才能避免把手段當做問題。

案例一：鯀治水著重在堵的方法上，畢生精力都在思考如何更好地堵。

老師：請問這里的問題定義是什么?

小明：這里的問題是如何堵!

老師：其他同學也說說這里的問題定義是什么?

小紅：這里的問題是洪水和生命財產的矛盾!堵只是解決這個問題的方法或手段。

老師：如果問題的定義是問題是洪水和生命財產的矛盾，堵只是方法，那么還有什么方法可以解決這個問題?

小王：還可以用疏通的方法來治水。

小白：我們還可以搬走，以避免水患。

老師：恩，這也是一個思路。

案例二：如果我問我們的客戶他們想要什么，他們會告訴我他們需要一匹更快的馬。——亨利福特

老師：請問這里的問題定義是什么?

小明：這里的問題是如何讓馬跑的更快!

老師：還有其他同學能說說這里的問題定義是什么嗎?

小紅：這里的問題定義是如何更快的到底目的地，馬只是一種手段。

老師：是的，如果馬只是一種手段，而不是問題的定義，請問還有什么什么手段可以解決我們提到的問題。

小王：根據目的地的距離的不同，我們可以選擇坐飛機，坐火車，開汽車。

小明：老師，我不知道自己不知道，我不知道有汽車，火車，飛機，我只知道馬，所以我想到的就是如何讓馬跑的更快。

老師：是的，我們的局限往往是受限于我們的認知，這種情況不可避免，唯一的方法就是不斷的學習，提升自己的認知。

案例三：如何做好資金防控?

老師：請問這里的問題定義是什么?

小明：這里的問題是如何做好資金防控，怎么防，怎么控。

老師：還有其他同學能說說這里的問題定義是什么嗎?

小紅：這里的問題定義是如何避免公司產生資金上損失，防控只是手段。

小白：資損防控解決直接問題是避免公司產生資金和名譽的損失，這個問題背后更深層次的是社會信任的問題。

老師：小白，你的名字雖然叫小白，但是你的思考一點都不小白，顯然你在思考問題定義時使用了升層思考的方法，看到了問題背后的問題。

小明：老師，為啥我每次思考的時候，都是在思考解決問題的手段，都沒有看到問題定義呢?

老師：那你可以嘗試自問自答，比如你可以問自己資損防控是手段嗎?自己給個回答，如果回答是 yes，那么再問自己：如果資損防控是手段，那么資損防控是解決什么問題的呢?通過這樣的自問自答的方式，基本上我們可以較為準確的找到問題的定義。

小白：老師，我在想資損防控解決的是社會信任的手段之一，但是解決社會信任問題的手段不止一種啊。

老師：小白，你在思考問題時使用了升層思考，在思考解決方案時使用了升維思考，給你 32 個贊。

小白：謝謝老師，此時此刻我有點開心啊。

老師：保持心態的平穩，可以看到更多的東西，謙卑的態度沒了，那自己的局限也就到了。

小白：謝謝老師提醒，我記住了。

三個故事看完了，總結一下，這三個故事的核心在于：

• 準確區分手段和我們要解決的問題本身，這種情況非常常見，我 Review 的很多技術方案之所以有問題基本都是問題定義沒有搞清楚，所以解決方案也就不符合需要了。
• 思考問題背后的問題時使用升層思考，在思考問題包含的子問題時使用升維思考。
• 當升層思考之后，之前的問題可能會變成手段/方法。比如說用堵解決生命財產問題，堵是方法。升層思考之后，生命財產問題背后的問題是民生問題，此時保護生命財產就是解決民生問題的一個手段/方法。

當然當我們無法準確的分辨問題的時候，我們還可以不斷縮短描述問題句子，比如提煉主謂賓，如果還不能清晰地描述，那么在這幾個詞里再找出最最最關鍵的詞。

尤其是主語或者賓語中的詞匯非常重要，它有可能就是重點，只是我們無情的忽略它了。

把手段或者方案當問題，或者把技術方案中的挑戰當做問題是很多同學遇到的問題。

[[311830]]

誤把挑戰當"問題" 

當我們明確定義出問題之后，我們開始解決方案的升維思考，可以從各個角度來給出解決方案，這些解決方案就是我們前面說的手段/方法。

舉例：如果快速到達目的地是目標，而馬，汽車，飛機，火車只是手段/方法，那么如何讓馬跑的更快，如何讓汽車跑的更快，如何讓飛機飛的更快，如何讓火車開的更快就成了挑戰。

此時如果你說“讓馬跑的更快也是個問題啊”，確實，廣義上也可以這么理解，但我不建議這樣做，原因是這樣我容易將問題和手段/方法攪混。

所以這里我嘗試給他們一個定義，以明確他們出現的場景：

• 問題：事物之間在某個時期存在的矛盾，在本文的語境中尤其是指企業的客戶和某種事物，趨勢之間的矛盾。
• 挑戰：解決矛盾的方案中最困難的幾個地方。

接下來我們回到上述的幾個案例中，來看看問題和挑戰：

回到用堵治水的案例上：

• 問題定義：洪水和人民生命財產安全的矛盾。
• 手段/方法：堵水。
• 挑戰：獲取息壤，以筑三仞高堤，這是手段/方法的挑戰。

回到福特的案例上：

• 問題定義：如何讓人更快的到達目的地。
• 手段/方法：造汽車來讓人們更快的到達目的地。
• 挑戰：設計出更高的扭矩，更高的功率的引擎，更平順智能的變速箱等等。

這樣我們在溝通的時候，就能明確的知道對方到底是在闡述客戶的問題定義，還是在闡述方案中的難點和挑戰。

思考問題時缺少時間維度

單個問題在時間軸上的不同時期的嚴重程度是不一樣的，比如說閉關鎖國公元后 1500 年-1700 年是看不出太大的問題的，但是，300 年后的 1800 年，閉關鎖國的弊端就開始浮現了，當然我們都是事后諸葛亮。

所以任何一個問題的嚴重程度都有一個時間軸，也許過了某個時間點之后，問題便不再是個問題。

比如外賣興起之后，如何更好的制作一包方便面以滿足用戶的口味需求就不是一個問題了。

時間維度是一個極其重要的維度，任何事情理論上都必須考慮在時間維度上的影響，所以即使在定義問題上，時間維度也是一個不能不考察的維度。

所以才需要一個 Roadmap 的路線圖，標注不同階段要解決什么樣的問題。

升層思考及升維思考

我們不能用問題發生時的同一層次思維來解決問題。

——by 愛因斯坦

愛因斯坦闡述了思維存在層次這一現象，這里我發表另外一個觀點：我們不能只局限于問題本身，還需要看到問題背后的問題，然后才能更容易的找到更多的解決方案。

我把這種方法叫做問題的升層思考，接下來我會簡稱之升層思考，我在網上搜索了一下，之前沒有人提起過這個詞，所以這個詞目前版權在我這里哈，如果你想說服誰需要用這種思考方式，不妨把我這篇文章發給他。

 

當問題升層思考之后，前面的問題會變成手段/方法，比如說洪水和人民生命財產的矛盾背后的問題是社會的穩定性問題(1 和 2 是升層思考)，而升維思考洪水和人民生命財產的矛盾的時候就會發現用疏通治水或者搬走都是方案(3 是升維思考)。

這就是升層思考問題，升維思考手段/方法。不過這張圖中每個問題到底嚴重到什么程度，還沒有給出量化。

不過我們在工作中，我們是要量化這個嚴重程度，而且要放在時間軸上來進行量化，因為有些問題當前可能并不嚴重，但是數月后可能會變成大問題。

值得注意的是這里思考的升層是依賴認知升級的，就像一個小朋友，也許也能升層思考，但是其認知的程度決定了他思考能到的層度。

所以歷史，社會科學，哲學也是我們的必修課，有助于我們認知到更高的層次的存在。當問題的層次不斷提升的時候，往往最終會歸結為社會問題和人性問題。

重要的話說三遍：

• 缺乏升層思考的升維思考是不完整的自頂向下
• 缺乏升層思考的升維思考是不完整的自頂向下
• 缺乏升層思考的升維思考是不完整的自頂向下

接下來我拿一些網上橫向思考的案例，來使用升層思考和升維思考的方式獲得相應的解決方案：

例一：游客有時會從帕臺農神廟的古老立柱上砍下一些碎片，雅典當局對此非常關心，雖然這種行為是違法的，但是這些游客仍舊把它作為紀念品帶走。當局如何才能阻止這一行動呢?

問題定義：如何給客戶提供紀念品?

升層思考：客戶需要紀念品的背后是想解決什么問題?是不是解決客戶的旅游紀念的需求。

對背后的問題升維思考：要滿足客戶的旅游紀念的需求有沒有其他方法?

• 明信片：明信片也可以做為一種紀念的方式，有了明信片做紀念，游客敲石柱的比例可能會下降。
• 現場照片：可以安排現場拍照的攝像師，選擇特別的角度為這些想要留念的客戶拍攝特別的照片，游客敲石柱的比例可能會下降。
• 帕臺農神廟模型：可以制作各種帕臺農神廟的模型，讓客戶購買，以滿足客戶紀念的需求，游客敲石柱的比例可能會下降。

對原問題升維思考：

• 在地上灑上大理石碎片：讓客戶以為這是帕臺農神廟的大理石，客戶會撿起地上的大理石碎片帶回去留念(這是網上的標準答案)。
• 進入神廟時寄存各種金屬物件：讓用戶無法用金屬去砍古老立柱，缺點是成本高，效率低，需要排隊檢測金屬物件。
• 把柱子圍起來，讓用戶只能在一米開外的距離觀看：用戶碰不到柱子，自然無法去砍柱子，成本比較低，也比較容易實現。
• 寫標語，在入口處，以及門票上明確指出破壞文物是違法行為，會受到法律的制裁，等等。

網上的標準答案是在柱子旁邊灑上大理石碎片(其他的都是我使用升層思考和升維思考瞎想出來的，你也可以想出很多)。

讓游客以為這是神廟已有的碎片。不過這種方案經不起邏輯思維的推敲，比如開放了這么多年，地上的碎石為什么還沒有被撿光?于是游客就知道這是人為灑在上面的，那么有些游客會繼續破壞石柱。

我想說的是，這里的升層思考，和不同層次的升維思考會給我們帶來很多種方案，如果集合全團隊的力量，我們甚至還可以想出更多更多的 Idea。

[[311831]] 

例二：在美國的一個城市里，地鐵里的燈泡經常被偷。竊賊常常擰下燈泡，這會導致安全問題。接手此事的工程師不能改變燈泡的位置，也沒多少預算供他使用，工程師應該怎么辦?

問題定義：如何不讓竊賊擰下燈泡?

升層思考：不讓竊賊擰下燈泡是為了解決什么問題?是為了解決預算不足的問題。

對背后的問題升維思考：解決預算不足有沒有其他方案?增加預算?募捐?防止竊賊擰下燈泡。

對原問題升維思考：不讓竊賊擰下燈泡可以從哪些維度進行考慮?

• 焊?。喝秉c是燈泡壞了之后很難更換。
• 反向螺紋(竊賊在擰下燈泡的時候其實是在擰緊)：缺點是竊賊只要使用逆向思維就能破解(反向螺紋是網上的標準答案)。
• 特別的螺紋(特別螺紋讓竊賊拿到燈泡之后也無法在其他地方使用)：缺點是需要定制，成本高。
• 攝像頭：缺點是增加了設備，需要更大量的投入。
• 把燈安裝在更高的位置：竊賊得用梯子才能去盜竊燈泡，要看線路是否支持。
• 在燈泡上印上地鐵專用標志：別人不敢買這種燈泡，竊賊無法銷贓，缺點是多一道工序，燈泡的成本變高。

在這個案例中，反向螺紋是標準答案，缺點是竊賊只要使用逆向思維就能破解。

其他都是我自己通過升層思考和升維思考想出來的，其實你也可以想出很多，這里跟邏輯無關。

我想說的是通過升層思考和升維思考，我們就會發現很多種創新答案。而不會沿著某個答案一直往下走。

這兩個例子是關于橫向思維(和升維思考類似)的例子，但是通過例子我們會發現如果加上升層思考，在每個層次上再進行升維思考，我們會得到很多創新的 Idea。

如果讓整個團隊使用這一思考方式，我們就可以得到更多更多 Idea。

[[311832]] 

是新問題還是新技術解決老問題?

我們做架構的時候，一般都會根據當前流行的技術趨勢來解決問題，這些流行的技術趨勢其實是手段的更新，并不是問題的更新。

尤其是在一些社會性問題以及人性問題上，幾千年來問題都沒有變化過，只是新的技術手段可以更好的解決這些問題而已。

比如人類有溝通需求，數百年前是通過書信，后來是電報，后來是電話(音頻)，后來是視頻等等。都是技術的革新來更好的解決已有的問題。

這就要求我們隨時關注新技術，并和當前自己手頭的工作產生一定的聯想，不同對象之間的聯想能力此刻變的無比重要。

當然在一些問題特別明確的領域，比如說數據庫領域，要解決的問題基本沒有變過，但是問題轉換成的指標的值卻在一直提升。

比如支持的數據量越來越大，插入的速度越來越快，查詢速度越來越快，比如最近就有很多通過 AI 來做自動 Tunning 和 AI 索引優化的，都屬于此列。

類似的例子還有很多，比如 Mobile 流行的時候，消息的更實時觸達是改造各種消息通道的一個契機，會產生新的產品，比如微博，微信，等等。地理位置可以獲取之后，也出現一堆新的應用，改造了老的產品。

所以我對自己提了一個要求，任何新技術，哪怕是很小的新技術，都要聯想一下可能對現在的工作，以及現在工作的產業鏈路上下游有沒有什么幫助，這種聯想可能不只是個人要做的，而是要驅動團隊展開討論的。

目前被提到的新技術有 AI，區塊鏈，IOT，5G 等等，這些也許可以跟我們的業務產生鏈接，可以組織團隊進行發散型思考。

不過這個事情我自己做的也一般，想多跟大牛們學習學習。

小結

根據上文總結了以下幾點：

• 區分手段和問題
• 明確問題定義
• 對問題背后的問題進行升層思考
• 對問題的分解進行升維思考

升層思考和升維思考有時候是創新的核心，比如鯀用堵治水，他畢生都在思考如何堵，所以他是從堵這個頂點向下思考的。

如果對堵進行升層思考之后再進行升維思考，你會發現除了堵水，還可以用疏通的方式，還可以搬走等等。所以創新的關鍵在于升層思考和升維思考。