揭秘技術 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
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...