在京東成為優秀的技術leader，需要做到這三點

我認為需要關注如下三點：

穩定，高效，創新。

我認為作為一名技術 leader，作為系統架構的負責人，系統穩定是首位的。更毫不誇張的說，系統穩定是研發團隊的脊梁骨。其次，研發效率是研發的天職，不高效的團隊是沒有競爭力的。而技術創新是進步的主要生產力。

實現系統穩定，重要做到兩點：

所以，總結出了問題，怎麼辦？

不要猜，更不要慌，通過報警點去找日誌。

當然，大多數系統出了問題，都是事後諸葛亮，所以，事前保障，嚴格評審，是唯一有效的手段。

落地如果你想在團隊裡實踐評審制度，我的建議是，不要一下子把三個會一股腦都引入到團隊，這會對團隊產生一定的不適應感，而且，如果沒有細化會議的內容和規則，最終會流於形式。

節奏應該是小步快跑，以點到面。

第一，技術架構評審、**評審和發布計畫評審，我先引入團隊的是發布計畫評審。之後技術架構評審和**評審一起引入。

原因很簡單，**評審和技術架構評審相輔相成，否則只有**評審往往只能評審出規範性的錯誤，業務邏輯的問題，需要對細節的把握，這往往又是非一線研發一時半會看不出來的。而只有技術架構評審則無法保證技術架構設計的實際落地。

這個過程大約乙個月內逐步實施為妙，而且要不斷的進行反饋和調整，才能找到乙個合適團隊節奏和方法。

第二，採用問題式的會議形式，涉及到10人日以上的專案和涉及到**流程的專案必須評審，要求專案干係人及t7+以上研發必須參與評審。

注意，採用的是會議，而非討論。雖然會議是很重的一種形式，但也具有很重的儀式感，這會讓團隊重視這件事。

採用問題式的方式，而非漫無目的的討論，這樣的形式可以保障會議的高效性。通過規則選出評審專案和參會人員，控制了相關範圍，而不是一幫烏央烏央的人，對每個細枝末節的需求都討論來討論去，造成極大的時間和成本的浪費。

那發布計畫評審的問題有哪些，我列舉一些必答的問題如下：

那技術架構評審要評什麼？我認為至少要弄清如下三件事：

然後，列舉的解決方案從以下幾點進行比較分析：

還有**評審怎麼做？我認為重點關注如下事情：

為什麼不進行編碼規範的評審，因為這個完全可以自己裝個不管是阿里、還是 sonar 掃瞄，一些潛在的空指標等，都可以掃瞄出來。就不要在會上去浪費時間了。

還有幾點，在執行中需要注意：

最後，評審會的內容一定是一致的且確定的，是為上線服務的，不為上線進行的評審是沒有意義的。注意，一定不要有太多的會議。

為了能讓上述的各項決議落地，必須讓團隊具備高效的執行力。而實現的方法，我認為只有乙個，確定每個事情的 dead line。假如要進行某專案的評審，那就明確確定下來在什麼時間點進行，並以郵件 meeting 的方式傳送給團隊。

同時，保證會議的高效，控制時間20~30分鐘。

就像《在 alibaba 成為優秀的技術主管，需要做到這三點》在文末所說，我真實的在實際工作中有過這樣的經歷，某個時間段突然一些線上故障頻發，各種技術債、業務債被業務方窮追猛打要求還債，團隊在失控的邊緣。

那最終是靠什麼熬過來的，就是重視系統質量，保障線上穩定，做需求慢一點沒關係，但絕不能再出任何乙個線上問題，因為連60分都做不到，怎麼能做到80+分？後面在系統逐步穩定的基礎上，進行團隊提效，技術創新等。當然，真正實現了系統穩定，真的是償還了大量的技術債和業務債。

摘抄《在 alibaba 成為優秀的技術主管，需要做到這三點》的一句話作為總結：

乙個技術主管的 60% ～ 70% 的時間可能花在了開發任務分解分配、開發實踐、技術架構評審、**審核和風險識別上，而餘下的 30% ～ 40% 的時間則花在為了保障系統按時交付所需的各種計畫、協作、溝通、管理上。