揭秘技術 Leader 必備的 7 大清奇腦迴路

来源:https://www.cnblogs.com/88223100/archive/2022/08/09/Demystifying-the-7-essential-brain-circuits-of-technology-leaders.html
-Advertisement-
Play Games

技術 Leader 是一個對綜合素質要求非常高的崗位,不僅要有解具體技術問題的架構能力,還要具備團隊管理的能力,更需要引領方向帶領團隊/平臺穿越迷茫進階到下一個境界的能力。所以通常來說技術 Leader 的技能是虛實結合的居多,繁雜的工作偏多。為此我把自己在工作中經常用到的思考技巧也做了一個整理。 ...


技術 Leader 是一個對綜合素質要求非常高的崗位,不僅要有解具體技術問題的架構能力,還要具備團隊管理的能力,更需要引領方向帶領團隊/平臺穿越迷茫進階到下一個境界的能力。所以通常來說技術 Leader 的技能是虛實結合的居多,繁雜的工作偏多。為此我把自己在工作中經常用到的思考技巧也做了一個整理。

 

                                                                                                     技術常用思考方法

一、向前思考,向後倒推

 

這個思考方法的含義是:

 

在思考一個命題時可以採取未來視角,先對未來發展做個預判,然後基於你的判斷倒推現在應該要做什麼,最後制定出關鍵里程碑和節奏。

 

這個思考模型經常用在技術規劃這個場景上,但很遺憾很多團隊的技術規劃都只是基於當前問題,有多少資源,然後採取量力而行的方法在對事項優先順序進行排序。這其實不是真正的規劃,最多算是計劃(如果做得不好,計劃都算不上,只能算是列表整理)。

 

這個思考模型有幾個關鍵的誤區:

1、不敢向前思考,擔心自己對未來的判斷不對

 

我相信很多 Leader 都有這樣的恐懼,會不會因為自己思考力不夠判斷失誤導致團隊拿不到結果。有這樣的擔心可以理解但是對事項推動無意義,因為:

 

  • 對上你的信息更細緻,對下你的信息更全面,如果你都不能對未來做出好的判斷,別人如何能夠替代你做出判斷。所以要有自信。

     

  • 只要你的判斷合理有邏輯,能夠與大家達成共識,那至少說明這個判斷不會太差,也是當下比較好的思考了,未必要追求絕對的正確,況且是不是真的正確只有變成了歷史才知道(有時候往往歷史也回答不了這個問題)。

     

  • 團隊未必是永遠要做最有把握、最正確的事,團隊力出一孔比追求哲學上的正確更重要。

 

所以需要 Leader 信息充分交換分享,有信心地對未來做出合理的判斷,並與相關角色達成共識。

 

2、只有向前思考,沒有向後倒推

 

也見過只有向前思考但沒有一點向後倒推的技術規劃,這種就是典型的飄在天上,形而上的概念一堆。但實際上這個思考模型的精髓就是在向後推的結合:

 

  • 向前某種意義上是在回答 to be (要做成什麼樣子)的問題,但向後推其實是在回答 have (當前有什麼)以及 have to do(必須做什麼)的問題。

 

  • to be 是在激發大家的想象,讓大家去共識心中的理想,這是能夠激發團隊的。

 

  • have 以及 have to do 其實是在找與 to be 之間的 GAP,尋找 GAP 就是進一步去找到解法,這是進一步的落地。

 

  • 這兩者結合起來才是既能夠理想主義找到未來,也能夠務實地超前進步。我認為這就是對仰望天空,腳踏實地的詮釋。

二、目標與路徑

這個思考方法的含義是:

 

在思考一個命題要關註什麼是目標,什麼是路徑以及目標與路徑的關係。離開路徑的目標是空談,離開目標的路徑是瞎乾,所以目標與路徑是一體兩面的,離開任何一個不談其實都不成立。

 

同樣地在技術規劃這個場合,大家可以仔細去看看,很多規劃都是只有目標的(這點其實已經做得蠻好了,因為大家的意識已經覺醒,沒有目標不往下談,所以不管目標設立好與壞但至少都是有的),但很少有規劃是把路徑講清楚。

 

雖然這個思考模型見聞知義很好理解,但同樣地這個思考模型也有一些誤區:

 

1、目標一定是要用來完成的

 

Leader 都是要背負績效壓力的,所以天然就會有一個誤區認為每一個目標都必須一絲不苟去完成。但一個低價值的 100%完成的目標 與 一個高價值的 90%完成的目標,未必一定是 100%完成就能拿高績效,關鍵還是要看對組織的價值貢獻。

 

所以 Leader 還是要辯證看這個問題,在設定目標時目標要具備很強的牽引性才行,是讓需要團隊去跳一跳的才能夠達成的,讓團隊有鬥志;自己在完成目標時也要帶著團隊努力往前沖,朝著高目標去想一切辦法拿結果,但也要隨時觀察團隊狀態,不能為了達成目標不擇手段或者把團隊乾廢了。

 

2、路徑執行時被慣性帶著走

這個思考方法的含義是:

 

在思考一個命題要關註什麼是目標,什麼是路徑以及目標與路徑的關係。離開路徑的目標是空談,離開目標的路徑是瞎乾,所以目標與路徑是一體兩面的,離開任何一個不談其實都不成立。

 

同樣地在技術規劃這個場合,大家可以仔細去看看,很多規劃都是只有目標的(這點其實已經做得蠻好了,因為大家的意識已經覺醒,沒有目標不往下談,所以不管目標設立好與壞但至少都是有的),但很少有規劃是把路徑講清楚。

 

雖然這個思考模型見聞知義很好理解,但同樣地這個思考模型也有一些誤區:

 

1、目標一定是要用來完成的

 

Leader 都是要背負績效壓力的,所以天然就會有一個誤區認為每一個目標都必須一絲不苟去完成。但一個低價值的 100%完成的目標 與 一個高價值的 90%完成的目標,未必一定是 100%完成就能拿高績效,關鍵還是要看對組織的價值貢獻。

 

所以 Leader 還是要辯證看這個問題,在設定目標時目標要具備很強的牽引性才行,是讓需要團隊去跳一跳的才能夠達成的,讓團隊有鬥志;自己在完成目標時也要帶著團隊努力往前沖,朝著高目標去想一切辦法拿結果,但也要隨時觀察團隊狀態,不能為了達成目標不擇手段或者把團隊乾廢了。

 

2、路徑執行時被慣性帶著走

 

在細化目標的執行路徑時,我們一般都會得到比較細緻的 ACTION,甚至會有專人來管理和跟蹤這些 ACTION。但比較容易出現的偏差就在於,我們做著做著就把初心忘了,把目標置於腦後了。典型的就是死命按照既定的路線走,沒有重新基於當時的情況再回頭看目標,去找是否還有更優的路徑選擇。所以時刻要反思什麼是目的,什麼是手段,不能把手段當成目的一味地執行。

 三、端到端思考

這個思考方法的含義是:

 

在思考一個命題要儘可能關註到全鏈路,而不是鐵路警察各管一端。

 

這個使用的場景是在於線上的問題治理和優化,尤其是客戶體驗問題或者是效能提升的課題上。這個思考模式也是非常簡單,但是同樣誤區也蠻多:

1、端到端從哪兒到哪兒沒搞清楚

 

想到端到端去思考和解決問題是非常好的,而且大家腦補就能理解大致想乾什麼事情。但這個思考模式最大的誤區就在於它只是存在於大家的腦子裡面,而不是白紙黑字寫下來。最典型的場景就是 B 提出端到端思考解決了自己域的問題,但 A 未加仔細辨別,一聽到端到端就想當然以為 B 也解決了 A 的問題。但實際上發現根本不是一碼事,A 就開始吐槽 B 承諾沒做到,B 就吐槽 A 瞎胡說。

 

要破解這個誤區其實也蠻簡單,就是把全流程畫出來,大家先基於客觀事實把流程達成一致,然後再在這個流程上圈定端到端是具體哪一段到哪一段。

 

2、效果沒有說清楚假定條件

 

端到端一方面是把問題看全,另外一方面最重要的就是整體交付價值。這個端到端整體交付價值也有一個非常大的誤區就是,對於假定條件沒有說清楚。以端到端提效為例,那麼提效就應該要講清楚是基於什麼業務範圍做的端到端提效,以及能夠達到什麼提效效果。比較好的辦法就是,以表格的形式把條件列清楚,然後對外給予端到端提效的明確效能結論。提效這個事其實沒有盡頭,只要做不到0投入那就一定要給予效能的確定性、相比較而言大家最怕的是效能不確定打亂原有的生產計劃,而不是非要死扣幾個人日的效能提升。

四、閉環思考

這個思考方法的含義是:

 

這其實是一個很形象的邏輯思考方法,思考一個命題要從初心出發再回到初心,以免出現重大偏差。這個模式理解起來也不複雜,但也有一些誤區:

1、形而上的假閉環

 

這其實是很多 Leader 非常容易走入的誤區,沒有實際展開命題的多個環節去做分析和探討,把這種要求一味傳遞給團隊要求做閉環的思考,即只有管理要求但缺乏技術領導力的洞察。一般來說,解題一個技術命題從開始孕育到落地有如下幾步:

 

  • 覺察/認知(感知到現有平臺/系統的問題,感覺需要做架構調優升級)

 

  • 概念/原理(挖掘到問題背後的本質,從業務原理/技術原理等底層出發抽取概念和本質)

 

  • 理解/共識(對問題本質做宣講,達成上下左右的理解與共識)

 

  • 目標/路徑(提出目標,拆解出來可實施的路徑)

 

  • 表格/指標(提出衡量的指標和具體的 ACTION,最好的就是表格來跟進)

 

  • 小勝即慶 (對於階段性目標的達成進行慶祝,當然這也是咬合業務價值的關鍵點)

 

  • 持續跟進 (小勝即慶還不能放鬆警惕,還需要持續推進到下一個任務)

 

  • 靈活應變 (根據實際情況調整優先順序,同樣是咬合業務價值而不是固守之前的任務表格)

 

  • 目標完成 (完成標準不是新平臺/系統能力建設完成,而是完成模型統一,流量遷移完成,老代碼下線等)

 

  • 下一個覺察 (開啟下一個平臺/系統的架構調優升級周期)

 

很多時候我們並沒有真正的在閉環思考和跟進問題,如漏掉某些節點,或某些節點退出過早:

 

  • 比如很多平臺建設在第 4)步做完就任其自然發生了,缺乏表格的跟蹤機制,最後效果就是拖拖拉拉、磨磨唧唧拿不到結果。

 

  • 比如很多平臺建設小勝即慶做完就交接給其他人了,持續跟進出現嚴重問題,會導致不能靈活調整進而出現嚴重的建設障礙。

 

2、缺少進階的下一環

 

閉環思維某種意義上應該說環環相扣的螺旋式上升的過程,這樣才是能夠不斷驅動開啟下一輪的進化。但很多 Leader 並沒有很好意識到這個問題。以上述的閉環 10 個步驟為例,Leader 應該是在小勝即慶時就開始思考下一個覺察,在拋物線的頂點之前開始下一輪的思考繼續才能夠確保下一個閉環能夠及時開啟,進入螺旋式的優化進程中。

五、指標量化思考

這個思考方法的含義是:

 

沒有量化就談不上優化,所以在定義和推動解決一個命題時,要儘可能地把遇到的問題用數據指標的方式進行量化思考。同樣的這個思考模式也有一些誤區:

 

1、量化的維度缺失導致缺少客觀性

 

量化的本質其實是逼迫 Leader 更全面,更客觀地理解問題。但要是更加客觀地通過數據出現一個問題,也還是需要一些技巧,否則就會陷入心中已有答案,只是通過數據去做證明的困境。尤其是大團隊越是要註意這個問題,通常來說組織這個群體是有自己的偏好,也是有動力和意願去促成組織所偏好的事情。比如做技術的就傾向於偏好引導往架構優化上去,做業務的就會傾向於引導往完成 KPI 上去,但事實上更客觀的應該是如何高效滿足客戶價值。

 

如何突破這個誤區,我得到的經驗思考就是呈現的數據維度與客觀世界的匹配度,越高的就越客觀,越客觀才越有利於解決問題。只有通過數據量化出來這個問題才有可能找到可能的解法,才有後續方案選擇時的取捨,不能本末倒置為因為選定了方案然後通過數據去論證取捨的合理性。

 

2、量化的數據斷層解讀後的欺騙性

 

數據客觀反映只是第一步,如何解讀才是決定了數據的利用價值。不怕沒看到真相,只怕看到真相的一部分,不恰當的解讀方法就會讓我們看到真相的部分從而得出錯誤的結論。比如把自己和首富的財富的平均下,給人的感覺就是全民收入都大漲。

 

常見的數據解讀方法如下:

 

  • 高值 VS 低值 VS 平均值 VS 分位數:可以看出來數據的實際分佈情況。

 

  • 同比環比:可以看到各個維度的下數據的發展趨勢。

 

  • 全局 VS 局部:當全局性指標看完以後,一定要註意去搭配著 按照多個維度的局部數據。比如看完全國的人均收入 還要 看各個省份的數據,甚至還要細分到各個行業去看數據。

 

  • 局部數據的橫向比較:可以對比做些歸類分析。

 

數據指標量化其實可以用在任何一個場景,但很多人的觸發機制不是很敏感,常常忘記這個思考模型。導致很多事情實際上是在靠感覺,靠感覺的東西不長久,有時候對有時候錯。越是比較抽象比較虛比較容易講感覺的恰好就是練習的好時機,當你下次感覺到團隊狀態不對時,你可以嘗試下如何用數據指標化的方法去做個思考,看能夠量化出來哪些維度的數據。

六、故事與形象思考

這個思考方法的含義是:

 

技術 Leader 在給大家講解自己的思考時,要註意通過故事的形象思考,儘可能將問題講得透,讓大家都能夠懂。這一點是很多技術人都不是特別重視的地方,他們往往這樣想:

 

1、技術人踏實會幹比能說會道重要得多,前者才是真正的硬核技能

 

這反映了很多技術人的潛意識想法,尤其是做底層的同學。但我們是忘記人類協作的本質就是基於共同想象,如果我們都不能把自己要做的事講清楚,如何激發大家一起幹事情。作為技術 Leader 一定要摒棄這種想法,技術能力和良好的溝通能力兩手都要硬。

 

2、專業的本來就有門檻,為啥要浪費時間和精力去講給不懂的人聽

 

持有這樣觀點的人也不少,認為專業就應該有一定的神秘感,給人一種不明覺厲的感覺。但實際上真正的專業就是大道至簡,用大白話去給別人解釋清楚複雜的事情。那種不能夠大白話講清楚的多半自己還是半灌水,還不是真正的專業。

 

而要剋服這些問題最好的方法就是講故事打比方這種形象化的思考模型,其實 PPT 就是用圖片這種形象化去表達複雜的思考邏輯。至於如何講好故事我覺得想想西游記就好了:

 

  • 確定初心和目標、以及意義。西游記就是要取經普渡天下眾生。

 

  • 一路上困難重重,但總能不忘初心剋服困難。不管是師徒四人的矛盾,還是降妖除魔都是不斷遇到和剋服的困難。

 

  • 拜見佛祖取得真經,傳播眾生。歷經劫難取得真經,然後回到東土大唐給天下人講經。

 

技術 Leader 在領導團隊建設平臺/系統時候,也可以用這樣的故事講法去激勵大家。當然要講好故事不只有這樣一個結構,但本質初心是想技術 Leader 能夠加入形象化思維,通過比方,通過故事讓大家深刻理解你要做的事,這樣才能夠更好讓大家朝著目標協同。

七、乘數效應

這個思考方法的含義是:

 

技術 Leader 在思考一個技術命題時,要充分考慮這件事的影響力,比如有些決定做下去可能是影響 10 個人,有些決定做下去可能是會間接影響 100 人,這種乘數效應必須是技術 Leader 要慎重考慮的,越大的 Leader 越要註意。

 

乘數效應可以說是雙刃劍,好的乘數效應能夠讓大團隊享受到紅利,但差的事件也會讓所有人都受到波及。因此有如下實踐:

 

1、自上而下的決策要慎審,充分考慮乘數效應

 

作為團隊 Leader 尤其是二線 TL,在做一些決策時務必要考慮乘數效應帶來的威力(有時候二線 Leader 和一線 Leader 的差異就是在管理這個乘數效應),經常有如下兩個誤區:

 

  • 執行的難度未充分估計,被乘數效應放大。很多決策看起來都挺對也很有價值,但出發點可能是基於管理需要而不是一線同學工作的必須。這帶來的問題就是遲遲無法落地,變成上有政策下有對策。

 

  • 執行結果未 CHECK,實際完全走偏。如果 Leader 太自信,未有上述閉環思考的方法去跟進具體有乘數效應的事項,到最後就會出現進退兩難的境地。因為大部分都走偏繼續朝前也不可能,但又因為有太多的沉沒成本捨不得放棄。

 

2、主動管理自下而上的乘數效應

 

為了組織蓬勃發展,我們肯定是鼓勵一線同學充分發揮乘數效應,以讓大團隊都能夠享受到紅利。但 Leader 一定要去主動識別和管理這些具有乘數效應的事項,要對可能出現的問題進行及時糾正和干預,典型的糾偏就是防止重覆建設防止內捲。但對於確實對全局有利的,要做好及時的推廣並主動幫忙解決推進過程中的障礙,讓大團隊儘可能享受到紅利。但無論如何,對於這類具有乘數效應的都必須要有管理清單,鼓勵好創新但也慎重做決策。

 小結

技術 Leader 是集架構師,管理者,領導者一身的綜合性崗位,多年實踐下來也只是窺探到了部分。所以以上只沉澱的點滴思考技巧,當然也不可能解決所有的實際問題。期望這些思考對大家做好技術 Leader 有一些幫助。

 

作者丨朱春茂(知明)

本文來自博客園,作者:古道輕風,轉載請註明原文鏈接:https://www.cnblogs.com/88223100/p/Demystifying-the-7-essential-brain-circuits-of-technology-leaders.html


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • cookie是什麼 cookie 也叫 HTTPCookie,是客戶端與伺服器端進行會話(session)使用的一個能夠在瀏覽器本地化存儲的技術。 cookie就是為了存儲 sessionID而誕生. cookie的特性,會隨著請求自動攜帶cookie的值到伺服器 cookie的作用 cookie的 ...
  • 非同步組件 在大型應用中,我們可能需要將應用分割成小一些的代碼塊 並且減少主包的體積,這時候就可以使用非同步組件 頂層 await:在setup語法糖裡面 使用方法,<script setup> 中可以使用頂層 await。結果代碼會被編譯成 async setup() 在項目進行打包後 會生成打包後的 ...
  • 一、一元運算符 註:()不能與++一起使用,因為優先順序一樣,控制台會報錯,如果寫一行,要分開寫 二、比較 1、字元與數值進行比較-->會自動轉換成number,若轉換不成功,就是NaN,結果就是false 2、只要看到NaN,就是false(NaN==NaN,結果就是false) 3、字元串和字元串 ...
  • 一、一元運算符 註:()不能與++一起使用,因為優先順序一樣,控制台會報錯,如果寫一行,要分開寫 二、比較 1、字元與數值進行比較-->會自動轉換成number,若轉換不成功,就是NaN,結果就是false 2、只要看到NaN,就是false(NaN==NaN,結果就是false) 3、字元串和字元串 ...
  • 一、誕生時間 1995年 二、JavaScript包含內容 ECMAScript:基本語法及相關對象es(包括我們瞭解的es3,es5,es6.es7...) DOM:文檔對象模型,用來操作HTML BOM:瀏覽器對象模型,用來操作瀏覽器 三、書寫方式 1、書寫在script標簽里(比較常用) 2、 ...
  • margin:auto為什麼不垂直居中 margin:auto是具有強烈計算意味的關鍵字,用來計算元素對應方向上應該獲得的剩餘空間大小。 行內元素margin:auto; 不能水平居中在一行的中央位置(行內元素不獨占一行)。 position定位屬性大家都不會陌生,添加position屬性的元素可以 ...
  • vivo 互聯網前端團隊-Yang Kun 一、背景 在團隊中,我們因業務發展,需要用到桌面端技術,如離線可用、調用桌面系統能力。什麼是桌面端開發?一句話概括就是:以 Windows 、macOS 和 Linux 為操作系統的軟體開發。對此我們做了詳細的技術調研,桌面端的開發方式主要有 Native ...
  • 蒼穹之邊,浩瀚之摯,眰恦之美; 悟心悟性,善始善終,惟善惟道! —— 朝槿《朝槿兮年說》 寫在開頭 作為一名Java Developer,我們都清楚地知道,主要從搭載Linux系統上的伺服器程式來說,使用Java編寫的是”單進程-多線程"程式,而用C++語言編寫的,可能是“單進程-多線程”程式,“多 ...
一周排行
    -Advertisement-
    Play Games
  • 在C#中使用SQL Server實現事務的ACID(原子性、一致性、隔離性、持久性)屬性和使用資料庫鎖(悲觀鎖和樂觀鎖)時,你可以通過ADO.NET的SqlConnection和SqlTransaction類來實現。下麵是一些示例和概念說明。 實現ACID事務 ACID屬性是事務處理的四個基本特征, ...
  • 我們在《SqlSugar開發框架》中,Winform界面開發部分往往也用到了自定義的用戶控制項,對應一些特殊的界面或者常用到的一些局部界面內容,我們可以使用自定義的用戶控制項來提高界面的統一性,同時也增強了使用的便利性。如我們Winform界面中用到的分頁控制項、附件顯示內容、以及一些公司、部門、菜單的下... ...
  • 在本篇教程中,我們學習瞭如何在 Taurus.MVC WebMVC 中進行數據綁定操作。我們還學習瞭如何使用 ${屬性名稱} CMS 語法來綁定頁面上的元素與 Model 中的屬性。通過這些步驟,我們成功實現了一個簡單的數據綁定示例。 ...
  • 是在MVVM中用來傳遞消息的一種方式。它是在MVVMLight框架中提供的一個實現了IMessenger介面的類,可以用來在ViewModel之間、ViewModel和View之間傳遞消息。 Send 接受一個泛型參數,表示要發送的消息內容。 Register 方法用於註冊某個對象接收消息。 pub ...
  • 概述:在WPF中,通過EventHandler可實現基礎和高級的UI更新方式。基礎用法涉及在類中定義事件,併在UI中訂閱以執行更新操作。高級用法藉助Dispatcher類,確保在非UI線程上執行操作後,通過UI線程更新界面。這兩種方法提供了靈活而可靠的UI更新機制。 在WPF(Windows Pre ...
  • 概述:本文介紹了在C#程式開發中如何利用自定義擴展方法測量代碼執行時間。通過使用簡單的Action委托,開發者可以輕鬆獲取代碼塊的執行時間,幫助優化性能、驗證演算法效率以及監控系統性能。這種通用方法提供了一種便捷而有效的方式,有助於提高開發效率和代碼質量。 在軟體開發中,瞭解代碼執行時間是優化程式性能 ...
  • 概述:Cron表達式是一種強大的定時任務調度工具,通過配置不同欄位實現靈活的時間規定。在.NET中,Quartz庫提供了簡便的方式配置Cron表達式,實現精準的定時任務調度。這種靈活性和可擴展性使得開發者能夠根據需求輕鬆地制定和管理定時任務,例如每天備份系統日誌或其他重要操作。 Cron表達式詳解 ...
  • 概述:.NET提供多種定時器,如System.Windows.Forms.Timer適用於UI,System.Web.UI.Timer用於Web,System.Diagnostics.Timer用於性能監控,System.Threading.Timer和System.Timers.Timer用於一般 ...
  • 問題背景 有同事聯繫我說,在生產環境上,訪問不了我負責的common服務,然後我去檢查common服務的health endpoint, 沒問題,然後我問了下異常,timeout導致的System.OperationCanceledException。那大概率是客戶端的問題,會不會是埠耗盡,用ne ...
  • 前言: 在本篇 Taurus.MVC WebMVC 入門開發教程的第四篇文章中, 我們將學習如何實現數據列表的綁定,通過使用 List<Model> 來展示多個數據項。 我們將繼續使用 Taurus.Mvc 命名空間,同時探討如何在視圖中綁定並顯示一個 Model 列表。 步驟1:創建 Model ...