作者 |  朱春茂（知明）

上周我寫的一篇文章《??關(guān)于技術(shù)能力的思考和總結(jié)??》引起了大家的關(guān)注，好多讀者的評論“以寫代想、以想促真、以講驗真”，大家的感受很深刻，基于上次的文章，這篇文章我其實更想跟大家聊聊一些常用的思考方法，思考問題的方式對了，往往可以幫助大家少走彎路。

常用思考方法

技術(shù)常用思考方法

技術(shù)思考本質(zhì)還是結(jié)構(gòu)化思考，所以常見的結(jié)構(gòu)化思考方法也是適用的。這也是大家會看到很多技術(shù)架構(gòu)師都會用一些方法論去分析問題的原因。但這里我不是重新去論述這些常見的技巧，而是分享從技術(shù)實戰(zhàn)中得到的一些思考方法，為此我分為了技術(shù)架構(gòu)設(shè)計的方法和技術(shù)Leader的思考方法兩類。

技術(shù)架構(gòu)思考方法

0--->1

這個思考方法的含義是：

當我們在一堆迷茫和混亂中不知道如何下口時，應(yīng)該先貼近問題本身，還原客觀事實，并快速形成1個能夠拉起認知并快速討論迭代優(yōu)化的版本。大家圍繞著這樣的一個初始版本去疊加和豐富其他維度的內(nèi)容，直到方案的共識。

我舉一個實際的CASE，大家在談某平臺能力升級的方案時候會經(jīng)常喜歡用PPT畫一些模塊圖，試圖通過一些抽象的詞匯來厘定清楚邊界，核心概念。大家以為是在講本質(zhì)講原則但實際所有人聽了都是云里霧里，不知所云。因為通過概念去推導概念是無法真正回答問題的。

而比較好的應(yīng)對方法我總結(jié)為以下三個步驟：

• 【用戶視角的客觀世界還原】

用戶故事的串聯(lián)，基于交互流程和真實的數(shù)據(jù)來描繪這件事在客觀世界中用戶視角看來是怎么發(fā)生的。這就是我們找準一個大家都能夠共識的視角，讓所有人快速把客觀事實搞清楚畫出來這個1，而這個1就是后續(xù)討論的靶子 。這個1的表現(xiàn)形式我認為往往都是很簡單的，要么是交互時序圖，要么是Excel表格，而不是復(fù)雜的模塊概念圖。

• 【客觀信息的結(jié)構(gòu)化整合與提煉】

只是樹立起來1這個初始版本，還遠遠不夠。因為第一個步驟只是將模糊、混亂的東西通過一種方法信息化表達出來，這還遠遠達不到使用的程度。所以還需要將上述信息進行結(jié)構(gòu)化的整合與提煉，因為信息只有經(jīng)過結(jié)構(gòu)化才能夠變成有意義的知識，才能夠與之前的經(jīng)驗形成互動，也才能夠進行初版的設(shè)計加工。比如對數(shù)據(jù)流的處理，就會發(fā)現(xiàn)有哪些是可以合并的同類項，有哪些平衡校驗邏輯等。

• 【加入多元視角的檢驗與抽象】

通過第二步的處理把1這個版本變得更加豐滿，但是要形成完整的可實施方案還遠遠不夠。我們還需要加入更多維度的校驗和抽象，比如進一步抽象以看透其本質(zhì)，比如加入重要異常，ROI，合理性等擴展性等多方的視角去做校驗。

所以大家以后在遇到很多方案談不清楚的時候，不要去聽別人講什么原則，概念，價值等等虛頭巴腦的東西。把大家拉回來，回到最簡單的最樸素的東西來對焦，那就是一張交互序列圖 或者 一張表格。越快速從一堆迷茫中快速提煉出這個 1 ，就越容易快速拿到結(jié)果。

1--->0

這個思考方法的含義是：

當我們在做一個方案時面對無數(shù)因素無法抓住關(guān)鍵點時，我們應(yīng)該考慮刪除法(把這個1拿掉不要行不行)去尋找決定性因素，以確保我們是真正的抓到了關(guān)鍵點。

我舉一個實際的CASE，每年都會做技術(shù)規(guī)劃，相信這是很多架構(gòu)師/Leader很痛苦的事。痛苦的根源就是在腦子里面有無數(shù)需求，有無數(shù)的待優(yōu)化點，也有無數(shù)的想法在縈繞，看到每個點覺得值得在新一年做攻堅。最終多半形成的就是一個表格，把今年要做的事羅列下，最多還排個優(yōu)先級，好一點的換個形式變成xmind或者PPT，再稍微好一點的可能會搭配上業(yè)務(wù)的目標和策略打法。但透過這些表面現(xiàn)象，其本質(zhì)就是一個表格，沒有抓住重點的表格。相信大家應(yīng)該都看得蠻多的了。

如何應(yīng)對這類問題我總結(jié)為以下幾個技巧：

• 【因果判斷法】

很多時候我們都在談，要抓住事情的本質(zhì)，要具備化繁為簡的能力，其實就是在談通過表面的結(jié)果去探究真實的原因。所以在看哪些是決定性因素時，大家不妨用因果法去檢驗：這個因素到底是深層次原因還是誘導的結(jié)果。

• 【樹干樹枝法】

有時候各個因素之間并不是單純的因果關(guān)系，而是依附關(guān)系，就像是樹枝依附在樹干上一樣。而我們要找到?jīng)Q定性因素，可以嘗試這個方法去檢驗：如果把這個因素去掉會不會影響全局，是不是導致結(jié)論不成立。通過這樣多輪的分析，是可以繪制出來樹干的與樹枝的關(guān)系，這個樹干就是要找的決定性因素。

• 【支點撬動法】

有時候各個因素之間可能沒有直接或者間接關(guān)系，或者這個關(guān)聯(lián)關(guān)系太弱很難通過以上兩個手段去確定關(guān)鍵點?？梢試L試支點撬動的辦法，即尋找可以激發(fā)這一堆要素的關(guān)鍵要素。我之前給團隊舉一個例子，國家抓經(jīng)濟肯定不可能是米面糧油各種瑣碎地抓，肯定是找到幾個關(guān)鍵點起到支點撬動的作用，如房地產(chǎn)行業(yè)。抓住這個就能夠帶動上下游產(chǎn)業(yè)，進而激發(fā)各行各業(yè)。

以上是目前實踐下來的抓取關(guān)鍵點的一些方法。但這里一定也要注意一個粒度問題，千萬不要走極端。比如一提關(guān)鍵點，就去思考本質(zhì)，一提到本質(zhì)就去找根因，一找根因就挖到人性，然后得出來就是人性的原罪問題。這種都是沒有任何營養(yǎng)的做法，也不利于事情的推動解決。

1--->2

這個思考方法的含義是：

當我們思考一些抽象問題/方案時候，需要對問題進行拆分(一分為二)，通過分而治之的方法來確定每個小問題的邊界，通過對小問題的解決來降低全局的思考難度，以盡快形成解決方案。

這個應(yīng)該不需要舉例子了，大家日常都應(yīng)該有所接觸，這里只是列舉幾個比較典型的技術(shù)架構(gòu)動作：

• 【縱深拆解】

拆解是非常好的一個將問題分而治之的辦法，但要注意的是要做有機的拆解而不是物理的分解。比較典型的案例就是關(guān)于故障指標這個課題的處理，我是見過有團隊層層分解，把故障指標分解到每個同學身上，這是極其錯誤的做法，也不可能得到想要的結(jié)果。我們應(yīng)該是要做拆解，就是把要守住故障指標這個結(jié)果拆解成哪幾類關(guān)鍵動作，進而要求團隊關(guān)鍵動作做到位，而不是強行分解指標。

• 【橫向解剖】

做過實際研發(fā)的同學一定遇到一些業(yè)務(wù)需求的討論，很多時候來來回回扯不清楚，而且經(jīng)常會出現(xiàn)產(chǎn)品說這是技術(shù)架構(gòu)問題，技術(shù)架構(gòu)說這是業(yè)務(wù)需求問題，業(yè)務(wù)方說這是產(chǎn)品設(shè)計問題的現(xiàn)象。要破解這個僵局就需要把這個問題進行解剖，一層一層解剖清楚，把業(yè)務(wù)需求問題描述清楚，把產(chǎn)品設(shè)計搞清楚，把技術(shù)方案搞清楚。每一層都面向上游屏蔽下游的細節(jié)，才有可能把問題定義得清楚。一般來說，將這件事參與的角色進行解剖會更容易看得全面，更透徹。

以上是我實踐對問題拆分的一些方法技巧，凡事多看幾層終歸是能夠更加有結(jié)構(gòu)性地認知事情本事，也越有利于問題的解決。

1--->N

這個思考方法的含義是：

當我們思考一些技術(shù)方案時候，不要僅局限在當時當刻的條件約束，要適當考慮系統(tǒng)的承載從1變到N的過程中的對系統(tǒng)架構(gòu)帶來的挑戰(zhàn)。

做技術(shù)架構(gòu)師的都知道做架構(gòu)要求有前瞻性，不能被業(yè)務(wù)拖著走。但很多時候我們其實沒有仔細思考如何才能夠做到前瞻性，我總結(jié)為最關(guān)鍵的考慮的因素就是時間，把時間拉長來考慮關(guān)鍵生產(chǎn)資料可能發(fā)生什么變化，通過去架構(gòu)這種變化所得出來的方案就具備了前瞻性。一般意義上來說，我們平臺演進的生產(chǎn)資料抽象地歸納為三類：

• 業(yè)務(wù)場景：這是最原始的生存資料，更是平臺演進的源動力。典型的如市場份額變化，用戶體價值的變化，競對動態(tài)等。
• 團隊組織：是人創(chuàng)造了平臺，也是主導平臺的演進發(fā)展，這個生產(chǎn)資料如果不能得到有效利用，充分釋放能動性就會出現(xiàn)平臺無法支持業(yè)務(wù)快速發(fā)展，同時人也在平臺中內(nèi)卷。
• 技術(shù)架構(gòu)：技術(shù)架構(gòu)其實本身也是非常重要的生產(chǎn)資料，這是很多人會忽略的地方。大家想一個最簡單的例子，同一個變量分散在多個地方導致語義不清，維護成本巨大就明白了。

針對這幾個生產(chǎn)資料我抽取了幾個技巧去思考如何從 1 擴張到 N：

• 【架構(gòu)考慮所有可能性但做有限明確實施】

從業(yè)務(wù)場景的變化情況來看，的確充滿很多不確定性。也遇到過一種典型的業(yè)務(wù)與架構(gòu)的死循環(huán)的情況：前端業(yè)務(wù)面臨太多不確定性需要技術(shù)架構(gòu)給予專業(yè)意見和評估，但是技術(shù)架構(gòu)認為業(yè)務(wù)啥都想不清楚還要我評估這評估那，兩邊就開始互相死鎖。

而比較好的做法就是架構(gòu)能夠基于自己的經(jīng)驗和業(yè)務(wù)變化的理解，將可能性進行羅列考慮，然后給出來基于XX業(yè)務(wù)假設(shè)下，系統(tǒng)架構(gòu)需要XX量級的工作量做XX樣的能力迭代升級，可以做到XX的業(yè)務(wù)效果和價值，但需要進一步XX的業(yè)務(wù)輸入。這就是架構(gòu)考慮所有的可能性的含義，是需要給予業(yè)務(wù)的選擇。

但技術(shù)架構(gòu)實施卻未必是要留有太多的空白，架構(gòu)要大但是實施要小，對于值得留白的地方做好擴展設(shè)計，對于實在看不清楚的地方就要明確攔截(寧愿不做也不錯做)，將可能性留足但也不瞎埋坑。

• 【沒有靠譜的人只有靠譜的機器】

我常常去聽一些故障復(fù)盤會議，在談以后如何改進的時候很多同學都價值觀爆棚，說以后XX類變更都加簽上我來審核一道，我確認沒問題再往后走。雖然這種精神值得鼓勵但是這種做法實在是很不值得推薦，這樣沉淀出來的平臺其實是非常脆弱的，在做技術(shù)方案時一定要思考能夠交給系統(tǒng)的絕對不能用流程，能夠做到領(lǐng)域模型校驗的千萬不要靠旁路系統(tǒng)的側(cè)面印證(如不必要場景下的核對)。

• 【提前思考“幸?！钡臒馈?/li>

很多技術(shù)同學都希望做高并發(fā)大流量的系統(tǒng)，但很多時候在寫代碼的時候身體很誠實，怎么簡單怎么來。實際做的時候既不考慮大流量也不考慮高并發(fā)，對于資損風險考慮也極其少，而且基本上都很有道理：現(xiàn)在的業(yè)務(wù)量沒到不需要考慮那么多，這種事發(fā)生概率極其小一期先這樣......要對技術(shù)架構(gòu)做提前思考就必須從每行代碼做起，提前考慮高并發(fā)大流量和嚴謹性。

通常來說大家其實都比較喜歡從0到1的過程，按照互聯(lián)網(wǎng)的迭代式打法，后面的1到N的過程也會被不斷壓縮。所以提前在0到1的過程加入1到N的架構(gòu)預(yù)判非常重要，因為很多時候結(jié)構(gòu)性的問題在最開始就決定了，而且只有一次機會。

-1<--->1

這個思考方法的含義是：當我們思考一些技術(shù)方案時候，不要一條道走到黑，要前后、上下、左右、正反多個方面去思考，讓技術(shù)方案具備更多維的視角。

我把常用的技巧總結(jié)如下：

• 【正反思考法】

日常也review了很多同學產(chǎn)出的架構(gòu)方案和系分以及測分，大家對于正常業(yè)務(wù)需求功能的論述基本上都沒有啥大問題，按部就班去寫就可以。但普遍的問題都是對對問題的反面論述不多，如支付正常流程濃墨重彩，退款/拒付等逆向流程就沒那么細致，業(yè)務(wù)功能正常流轉(zhuǎn)論述很飽滿但是異常場景就寥寥幾筆。但正面與反面結(jié)合起來才是完整的一體，而且對反面的思考其實是對正面的有益補充。而且通常來說，我們在正面出現(xiàn)的概率大于反面，但是反面出現(xiàn)差錯的影響所需要付出的精力卻遠遠大于正面。

• 【極限思考法】

在review技術(shù)架構(gòu)方案風險相關(guān)的內(nèi)容時，我都會特意問一下，如果出現(xiàn)XX問題最壞的業(yè)務(wù)影響是什么。為什么是問最壞的業(yè)務(wù)影響，是因為如果談風險那肯定都是有一點點的，不利于大家去深究最關(guān)鍵的問題。通過極限設(shè)問，其實是激發(fā)大家去做最壞的打算，有了最終極的兜底手段才能夠更樂觀去做技術(shù)變更。

• 【對稱思考法】

在review代碼或者邏輯結(jié)構(gòu)時，在深挖細節(jié)和關(guān)鍵點后，我時常會拔出來看看整體的邏輯結(jié)構(gòu)是不是飽滿，是不是對稱，是不是美。最簡單的例子就是寫了if我一定要有else，不然沒對稱結(jié)構(gòu)就讓我很不舒服。因為我相信對稱的美就是一種生產(chǎn)力，因為美的東西一定是簡潔且直達本質(zhì)的。而我們寫程序要的就是邏輯清晰簡單直達業(yè)務(wù)本質(zhì)，邏輯結(jié)構(gòu)清晰的基本上沒大問題，不清晰(如變量瞎命名，方法無語義)的深挖下去多半都能發(fā)現(xiàn)大問題。根源就是邏輯清晰代碼才清晰，代碼不清晰基本上就是邏輯混亂，邏輯混亂就會產(chǎn)生BUG。

M*N--->M+N

這個思考方法的含義是：當我們思考技術(shù)問題時，可以嘗試從系統(tǒng)耦合的角度去思考，嘗試找一些突破口。

我舉一個實際的CASE，高速公路網(wǎng)的連接不是把所有目的地之間都修一條高速公路，而是會選擇修建復(fù)用的高速公路主干道 +

分支道路的方式來組織這個網(wǎng)絡(luò)。一條一條串聯(lián)的方式就是耦合在一起的，這就是M * N。通過主干道 + 分支道路的方式 就是解耦的，M + N

就能夠組建這個高速網(wǎng)絡(luò)。

在技術(shù)架構(gòu)上如何運用解耦這個技法，我有如下幾個提煉。

• 【解耦上下游關(guān)聯(lián)性】

在業(yè)務(wù)和技術(shù)架構(gòu)發(fā)展的前期，把很多東西糅雜在一起是最快解決問題的方法。但隨著業(yè)務(wù)和平臺架構(gòu)的進一步演進，勢必是要做解耦，目的就是重新去界定各個模塊的邊界，平衡新的業(yè)務(wù)發(fā)展要求下各方發(fā)展快慢的訴求差異，通過解耦互相松綁快速發(fā)展。

這種技法在服務(wù)化的分布式架構(gòu)中非常常見，基本上跨域的平臺架構(gòu)升級都有解耦的影子。

• 【解耦各個角色的依賴】

解耦上下游關(guān)聯(lián)性其實更多是在技術(shù)模型的抽象上，但在落入到技術(shù)模型范疇之前，還有就是我們在做更加抽象的解決方案探討時要注意解耦各個角色之間的依賴。上述【架構(gòu)考慮所有可能性但做有限明確實施】中提及的就是最好的案例。其實這里的本質(zhì)表達就是，技術(shù)架構(gòu)的設(shè)計應(yīng)該要與商業(yè)選擇，產(chǎn)品設(shè)計等解耦開來。

通過這一層的解耦其實能夠多個角色之間基于SLA去交互，并且能夠基于自身的專業(yè)思考給予對方更多的選項和可能性。很多時候的前瞻性和競爭力可能就是比別人多一個選擇。

解耦思考法其實很有意思，幾乎所有的大型平臺架構(gòu)升級都有這個思考法的影子，所以下次沒啥思路的時候可以從這個角度做一個審視思考，說不定是有新的收獲。

總結(jié)

以上是我在做技術(shù)架構(gòu)方案時沉淀總結(jié)的一些思考方法，這些思考方法不可能解決遇到的所有實際問題，只能算是一個思考提示，在遇到問題可以嘗試從這幾個方法去看看是否有靈感?；诜椒ㄕ摰遣痪窒抻诜椒ㄕ摬攀欠椒ㄕ撟畲蟮囊饬x和價值。

作者：知明，螞蟻金服國際事業(yè)群資深技術(shù)專家，全球資金平臺技術(shù)負責人，負責了螞蟻全球化進程中底層資金清結(jié)算、外匯等平臺能力的搭建和迭代演進。