突破技術管理,IT人中年危機變契機

2021-08-29 04:37:11 字數 3826 閱讀 8563

作為乙個老技術人,今天不聊技術,就聊點技術人員職業發展的事情:對技術管理崗位的認知,比如技術總監。

先貼一張技術人員職業發展路線圖,按照管理路線和技術路線區分。在國外管理路線和技術路線的職位會按照 it manager 和 techlead 去區分。

但在國內其實是沒有純粹的管理路線,管理崗位中一定有具體技術工作的要求。今天我說說對「技術總監」崗位職能要求的理解。

我理解技術總監的權責範疇應該包括:

技術性工作

管理性工作,分為人員管理(即團隊管理)和專案管理

在技術型工作中,我認為更多考驗的是乙個技術管理者的技術深度和廣度,而管理性工作中,更多考驗的是乙個技術管理者對於複雜人和事的協調能力。

技術性工作

對於一位優秀的技術人員而言,應該具備如下三種技術能力:

關鍵性技術能力

架構設計能力

工程管理能力

而一位技術管理者首先應該是一名優秀的技術人員,必須能在這三種技術能力之間游刃有餘。

1、關鍵性技術能力

你也可以把它理解為技術難點的攻克。我曾看到過朋友圈包括餓了麼 cto 張雪峰、釘釘 cto 一粟等,在團隊面前現場 coding 演示某些難啃骨頭的解決場景。

不要求技術管理者寫**,但是在某些風險性大的技術場景裡,技術管理者必須能親自上陣,以免團隊成員解決不了「甩鍋」的時候可以接得起來。

而且了解團隊的**情況,融入團隊的**編寫,也方便對系統架構的掌控。另外,作為示範**,能夠讓管理者在團隊中更好的立威。

2、架構設計能力

我們在說到架構設計的時候,一般會提到「技術架構」和「業務架構」,脫離業務架構的技術架構一定不會成功。這就要求技術管理者對業務有良好的理解能力。

而且架構的設計不僅僅是指能畫架構圖,能寫架構文件,能把熱門技術堆砌到圖紙上;乙個沒在工地上跑過的建築設計師一定不會造出好的大樓。

反之,乙個不做架構設計就想寫出好系統的技術人員不是天才就是傻子。架構的設計要更好的考慮執行效率、業務的可拓展性 /伸縮性,特殊場景的分模組管理等。

如果做不到這些,系統將隨業務的進展越來越冗餘,最終將為如何「解耦」操碎心,「重構」往往就在這樣的場景下被提出來,這是對系統和業務的具有傷害性的選擇。

所以作為技術總監,必須要有大的視野去組織模組和架構,避免早期的設計缺陷造成痛苦不堪的晚期「重構」。

3、工程管理能力

小團隊當中,工程管理能力往往價值體現不大,但當遇到乙個大團隊的時候,大團隊的運轉穩定性和效率就會成為突出問題。

這裡面主要包括持續性優化的能力和工具化使用的能力,並且需要較多的靠近流程管理和業務理解,有比較多的細小和瑣碎事情。

我見過很多技術管理者開發出身,但是晉公升到管理者的崗位後,不得不去了解運維之類的事情。這些都屬於工程管理能力的範疇。

管理性工作

對於一位優秀的技術管理人員而言,除了三種技術能力,還應當具備團隊管理和專案管理這兩方面的能力。

1、團隊管理

團隊管理,即人員管理。很多技術人員都很厭惡管理工作,讓乙個常年跟沒有脾氣和情緒的機器打交道的技術人員,去應付心思千萬的人員管理,聽上去確實很有挑戰。

但你要知道,管理的目標是實現組織目標,最重要的是制定管理標準、貫徹執行和校驗結果。

而這些也並非非要管理者親力親為,我們在組織的構建中強調的搭班子,就可以安排一些在這方面擅長的人以「副總監」甚至是「專案經理」「助理」的職位存在。

我覺得乙個技術總監要分出 30% - 40% 的精力在團隊的管理工作上,主要包括這些方面:

2、績效考核

關於技術人員的 kpi 一直是乙個千古難題,並且熱度不減。難就難在技術人員工作的質量難以量化,並且受不可控因素的影響太多。

我認為給技術人員的績效指標達到兩個目的即可,乙個是量化可量化的東西,乙個是鼓勵他的積極性。

所謂量化可量化的東西,通常我們會認為是指在時間進度上量化或者 bug 數量、專案數量等。

但也可以將能保證「質量」的因素模組化,分模組量化,當然這個要求比較高。

因為所謂保證質量的模組,是需要技術總監確定至少是建議性,而不是丟給技術人員自行設定,比如設定必須要完成的單元測試指標、質量監控指標等。

很多人會問需不需要在技術人員的考核指標中設定業務指標,我認為在業務相對穩定的情況下是有一定有可行性的。

業務指標可以幫助技術人員更好的理解大團隊的目標,知道在業務環節中技術價值的體現,更好的發揮主動能動性。

3、組織結構設計和人員招募

我認為組織結構設計更好的關乎團隊的效率和能力發揮,包括崗位的增刪減,扁平化結構還是梯度化結構,什麼樣的人安插在什麼樣的崗位上,這也是管理者應該懂得一門大課程。

而招聘上,我只想說,對於技術總監而言抓重點崗位,普通崗位的招聘可以由經理去進行,但不要小覷招聘,尋找團隊平均能力以上的人是乙個團隊走的遠的基礎。

4、階梯人員的培養

我比較在乎這點,就像我並不認為乙個人的成長是順其自然,我認為每個人的成長中都是受到重要的人和事的影響的。

環境對於乙個人的成長非常重要,要盡可能的去創造可持續成長的環境,包括如下三點:

code review ,我認為有必要性。

技術團隊內部技術方案的評審,最好的學習往往源於把手裡的工作做好。

外部的學習和講座,最怕坐井觀天,最後被時代拋棄,不要抱著工作不放,要想象一下未來的世界和你的位置。

5、跨部門得溝通協調

對於技術總監而言,除了處理部門內的事情,部門外的事情也需要一定的協調溝通。

但是我並不建議多花時間在外部的會議和溝通上,更多的溝通是跟隨專案走,由專案負責人去跟進和反饋即可。

你只需要協調那些別人要不來的資源,當然你能要的來,大部分原因是因為你在公司的威信,你曾給過別人的幫助。

6、專案管理

專案管理,即對事的管理。很多公司會設立有專案經理的角色,這塊就不怎麼需要技術總監來操心;但反過來講,每一位技術人員也都身兼專案經理的角色,而技術總監一定是最大的專案負責人。

有關專案的事情會比較瑣碎,但完全可以按照專案負責人分配下去,技術總監需要的是指定負責人、過問專案計畫和進度,另外就是在專案推進遇到阻力的時候,去解決問題。

主要包括這兩方面:

專案進度:專案評審,確定專案計畫;檢查進度,進度延遲預警;專案驗收和總結;

資源協調:人員協調,包括專案組人員以及編外人員的支援;it 設施協調,包括硬體、軟體系統等,公司內資源還有公司外資源。

寫在最後

有一種說法,領導就是要拿別人拿不到的資源,做別人做不了的決定,承擔別人承擔不了的責任。

但是,我想說技術管理者難度更勝一層,技術管理者要先有專業性,再來領導力,需要像醫者一樣的仁心仁術,而不是簡單粗暴的工廠管理。

我也不認同很多人認為的隨著時間的增長,技術人終將成為技術管理者,否則何來的「中年危機」,不是時間的累積就能得到質的變化。

我身邊也有很多技術管理者經常感嘆:「感覺自己做到技術總監就到頭了,未來乏力。」

只想說,從技術能力的成長,到複雜事物管理能力的成長,再到視野和決策能力的成長,這才是乙個技術人員,從程式設計師到中層管理者(技術總監)再到高層管理者(cto)的能力成長過程。

如果你覺得乏力,或許應該多出來看看,畢竟有些東西是靠鑽研出來的,有些東西是靠多行路、多交流得出來的,比如情商和視野,見聞的東西多了就知道該如何處理了。

--- end ---

突破技術管理,IT人中年危機變契機

作為乙個老技術人,今天不聊技術,就聊點技術人員職業發展的事情 對技術管理崗位的認知,比如技術總監。先貼一張技術人員職業發展路線圖,按照管理路線和技術路線區分。在國外管理路線和技術路線的職位會按照 it manager 和 techlead 去區分。但在國內其實是沒有純粹的管理路線,管理崗位中一定有具...

技術 管理和技術管理

與 老大 一起談軟體行業 和 我為什麼寫 致it同仁 軟體行業的另乙個真相 中談到,軟體設計是一門藝術,也許,很多技術在做到很高的境界時都是一門藝術,也就是說很多技術在其更高層次上都是相通的。由此看來,技術與管理在高層次上也可能存在很多共性。是哲學?乙個完備的組織架構通常存在管理與技術兩方面的內容,...

技術管理 開篇

在我們工作3 5年左右,陸續都會帶領一些小夥伴,隨著帶的人越來越多,會逐步成長為管理者。在成長為leader以後,很多的小夥伴都不適應,從原來的做好自己轉變為帶著團隊做好這個層次上的轉變。我想成為乙個怎樣的人?我想要乙個怎樣的團隊?每個人都有自己的特長和喜好,比如我喜歡與人溝通交流,我喜歡帶著團隊一...