歡迎大家關注今日頭條號「JAVA前線」檢視更多精彩分享文章，主要包括原始碼分析、實際應用、架構思維、職場分享、產品思考
1 問題分析
在知乎上看到了這個有意思的問題，首先這個問題不是為了考察建築工程學知識，因為面試者並非都具有建築工程學經驗。我認為這個問題是在考察三種分析方法：合理性分析、結構化分析、可行性分析。
2 合理性分析
在職場上是允許爭論需求和問題合理性的，拒絕掉一個不合理的需求，其實也是在節約資源和成本。例如產品經理提出業務需求，程式設計師用程式碼實現業務需求。在程式碼開發前大家會進行需求評審，首先評估需求合理性，再評估需求實現細節。如果經過充分討論後，大家覺得本次需求不合理或者無法實現，那麼本次需求會被拒絕。
回到這個問題，一頭800公斤的牛要透過承重700公斤的橋，這個需求本身合理嗎？那麼我們可以從為什麼、是否緊急、是否可替代提出三個問題：
第一個問題：牛為什麼要過橋，到底什麼事情非要過橋不可，是否具有必要性
第二個問題：如果非要過橋，那麼這個過橋需求緊急嗎？不緊急可以從長計議
第三個問題：有沒有替代方案，是否可以坐船或者繞路走
如果經過討論結果是牛可以繞路走，那麼我們就無需再考慮橋的承重問題。
3 結構化分析
如果經過討論結果是這頭牛非過橋不可，那麼我們就思考牛怎麼過橋的方案，這裡可以使用結構化思維，將大問題拆分為小維度，儘量做到不遺漏和不重複。影響過橋的因素有這幾個維度：橋的維度、牛的維度、資源維度、環境維度。
橋的維度：加固橋使承重大於800公斤
牛的維度：等待牛的體重小於700公斤
資源維度：使用一臺吊機把牛運過去
環境維度：取消環境的重力
4 可行性分析
我們從橋的維度、牛的維度、資源維度、環境維度給出了方案，那麼選擇哪個方案呢？這就需要我們進行可行性評估，因時因地在資源制約下選擇當前最合適的方案。
加固橋方案經濟成本較高，等待牛的體重小於700公斤時間成本較高，取消環境的重力技術難度較高，使用一臺吊機把牛運過去這個方案目前看來最合適。
5 結構化思維延伸
在這三種分析維度中我們著重分析結構化思維，結構化思維核心思想並不複雜：一件事情可以總結出一箇中心思想，這個中心思想可以由三至七個論點支援，每個論點可以由三至七個論據支援，基本結構圖如下：
對於結構化思維僅僅分析到這裡是不夠的，我們還應該進一步去分析結構化思維的內在結構，而內在結構可以從縱向和橫向兩個維度分析：縱向結構體現了結論先行和以上統下兩個原則，橫向結構體現了歸類分組和邏輯遞進兩個原則。
5.1 縱向結構
5.1.1 結論先行
結論先行是指開宗明義地展示中心思想，讓聽眾一開始就明白溝通主旨，而如果把中心思想隱藏在溝透過程中，聽眾可能因為走神或者溝通訊息太多而失焦，根本不知道你在說什麼。結論先行具體有以下六個方面：
先重要後次要
先框架後細節
先總體後細分
先論點後論據
先結論後原因
先結果後過程
假設一個同事程式碼釋出上線後導致系統故障，如果不使用結構化方法是這麼表述的：
我看監控發現數據庫負載升高，可能是沒有加索引導致的。我又發現頻繁收到重複訊息，是不是訊息中介軟體有什麼問題？監控還顯示建立了大量執行緒，是不是執行緒池使用不當導致的？問題排查很難短時間得到結論，我們還是先回滾程式碼至上一個版本吧
這位同事中心思想是問題原因比較難排查，應該先回滾程式碼再分析問題，但是他把最重要的觀點放在最後，不聽到最後不知道他要做什麼，而如果結論先行應該怎麼表述呢？
我們應立即當回滾程式碼，因為問題排查比較複雜，還是先恢復系統再排查問題。可能的問題分三類：第一可能是索引使用不當導致的資料庫問題，第二可能是中介軟體問題導致大量重複接收訊息，第三可能是執行緒池使用不當導致執行緒大量被建立。等到恢復正常之後我們依次排查這些問題
我們比較兩段表述不難發現，第二段表述結構清晰很多，資訊傳達效率顯著提升，這就是結論先行的優勢所在。
5.1.2 以上統下
以上統下是指任何一個層的思想必須是其下一層思想的總結概括，我們分析一個例子進行說明：小王今天需要買牛肉、雞蛋、蘿蔔、果汁、白菜、牛奶、青菜、雞肉、酸奶，但這麼多菜品他記不住，請你想辦法幫助小王。
第一步我們要對菜品自下而上進行聚合歸納，這是一個找規律的過程。第二步再以上統下進行結構化表達從而幫助記憶。
自下而上聚合我們不難發現，牛肉、雞肉、雞蛋屬於肉蛋類，白菜、青菜、蘿蔔屬於蔬菜類，牛奶、果汁、酸奶屬於飲品類，這樣聚合之後我們再以上統下進行結構化表達。
上述例項比較簡單，因為元素之間的關聯性比較容易尋找，但是真實場景是不會這麼簡單的，元素之間關聯性並不容易建立，那麼我們應該如何從中心思想展開至第二層？
金字塔原理推薦使用疑問-回答式對話，透過設問的方式向下展開結構。那麼應該問哪幾個問題從而涵蓋中心思想的要點？我們可以參考5W2H分析法，儘量做到要點不缺失：
What：是什麼、做什麼
Why：為什麼、什麼原因
Where：在哪裡、從哪開始
When：開始結束時間、里程碑
Who：誰負責、誰來做、誰驗收
How：怎麼做、什麼方法、從哪切入
How Much：做多少、各項指標是多少
在這個模型基礎上我們可以進行簡化從而減少要素數量，這樣更加有利於結構化表達和記憶。我們一般選取What、Why、How這三個核心要素組成2W1H模型。
5.2 橫向結構
5.2.1 歸類分組
(1) 歸納推理
我們一般用歸納推理和演繹推理兩種方法進行歸類分組，我們先看歸納推理。
歸納推理是指把觀察到的事實、規律歸納總結為理論。這種推理方法是不嚴謹的，因為只要觀察事實和資訊是有限的，那麼歸納推理出來的結論就不一定是正確的。這就是邏輯錯誤中常見的一種：錯誤歸因。
歐洲人看到的天鵝都是白色的，那麼他們就歸納總結說所有的天鵝都是白色的。當一隻黑天鵝出現時，這個結論就被證明是錯誤的，這就是黑天鵝事件。
當然我們不可能觀察到所有事實，收集到所有資訊，而一般是為了解決某個具體問題，我們會收集側重於某個角度的資訊，建立特定模型去分析解決問題，這也不失為一種有效方法。
金字塔原理歸納推理一般有以下四種維度：時間維度、結構維度、程度維度、經驗維度。時間維度是根據天然時間線進行歸納，結構維度根據組織結構進行歸納，程度維度是根據程度級別進行歸納，經驗維度是根據已有經驗進行歸納。我們分別來看上述四種維度的幾種常見型別：
(1) 時間維度
事前、事中、事後
短期、中期、長期
(2) 結構維度
資訊部、行政部、人力部
開發組、測試組、運維組
(3) 程度維度
高階、中級、初級
重要、次要、不要
(4) 經驗維度
市場戰略3C理論
市場決策4P理論
高擴充套件、高可用、高效能
我們選取時間維度和結構維度分析一個例項：怎樣減少程式碼上線故障。從時間維度分析：事前需要做好程式碼測試，事中需要監控關鍵指標，事後需要進行分析覆盤。
從結構維度分析：開發人員需要完備單元測試，測試人員需要做好邊界測試，運維人員需要完善監控平臺。
(2) 演繹推理
演繹推理是指根據公理、定理或者自己相信的觀念，做出推理或者判斷，得到結論。
這種方法從邏輯上來說是嚴謹的。命題A是真的，推理出命題B也是真的，那是因為命題B的真實性包含在命題A中。
需要注意在邏輯上嚴謹，不是說結論一定是正確的。例如自己相信的觀念最終被證明是錯誤的，那麼得到結論也就是錯誤的。
這是一種自上而下的推理方法，由已知的公理、定理或者觀念向下推理。使用這種方法，需要在出現問題的領域有一定的經驗和積累。
標準式演繹推理分為大前提、小前提和結論：所有鳥都會飛，這是一隻鳥，所以它會飛。
演繹推理還可以分為現象、原因和解決方案三個要素：現象是開發程式碼質量不高，原因是沒有統一程式碼規約，解決方案是制定統一程式碼規約。
5.2.2 邏輯遞進
邏輯遞進是指每種思想需要按照一定順序進行排列，時間維度按照事前、事中、事後進行排列，程度級別按照高階、中級、初級進行排列。例如時間維度我們還可以繼續使用怎樣減少程式碼上線故障案例，按照事前、事中、事後時間線進行排列，這種順序更加符合理解和記憶習慣。
6 文章總結
關於更多結構化思考內容請參看我的文章：金字塔思維怎麼指導技術系統最佳化，回答這類問題結論不是最重要的，因為本質上是考察思考方法，所以思考過程才是最重要的。
歡迎大家關注今日頭條號「JAVA前線」檢視更多精彩分享文章，主要包括原始碼分析、實際應用、架構思維、職場分享、產品思考
