技術敏感度 — 基層技術管理者必備

一說到管理者的能力特質，咱們立刻會聯想到溝通、受權、決策等能力。然而，對於軟件開發活動中的基層技術管理者（team lead、line manager等），我想指出被極爲忽視的另外一種重要能力 — 技術敏感度。

對於基層技術管理者來講，何爲技術敏感度？技術敏感度表現爲：1）工程師解釋技術問題時，能快速理解並切中問題要害； 2）面對多個技術方案作選擇時，具有權衡能力，並能給出有建設性的意見和建議，甚至作出選擇；3）工程師提出技術想法時，能敏銳地意識到對產品和團隊的意義； 4）能根據團隊成員的個體差別和技能特色，及團隊技能總體發展的須要，合理地調配團隊成員的工做內容；5）從代碼層面瞭解項目的質量情況；6）理解軟件開發活動的複雜性本質。部份內容看似應是工程師應具有的，爲什麼卻要求基層技術管理者必備？

第一，基層技術管理者在平常工做中做爲技術團隊面向管理層的接口人，他們在各種與產品經理、項目經理的會議中表明着工程師隊伍解釋影響項目進展所面臨的技術問題。這就要求管理者適時地瞭解項目在技術方面的進展，顯然，這些進展得從工程師口中得到。平常工做中，基層技術管理者不只要能理解工程師所解釋的技術問題，還得掌握問題要害，而不能工程師解釋時瞭解，事後卻健忘。基層技術管理者如不具有這種能力，容易形成與管理層和技術團隊的溝通不順暢而影響工做效率。（注：我碰到過一些基層技術管理者，一樣的技術問題得在不一樣時間段爲他解釋。開技術會議的主要工做是讓他理解所出現的技術問題，效率之低能夠想象）

第二，基層技術管理者在平常工做中不時會面臨團隊技術方案的選擇問題。規模較大的技術方案（如系統級、子系統級）的選擇一般由架構師們完成，但團隊級別小規模的技術方案選擇不少情形下會成爲基層技術管理者的工做內容。當團隊具有一個以上技術實力至關，但在設計理念上存在明顯差別的工程師時，他們頗有可能在項目實施的過程當中主張不一樣的實現方案，若是設計方案沒法及時達成共識，勢必影響項目的順利進展。此時，基層技術管理者得參與其中，經過運用本身的技術能力與團隊共同作出設計方案的選擇。在這種狀況下，即便技術管理者不直接作決策，也得經過詢問一些問題幫助團隊作出決策。所問的問題可能有：各方案的開發成本如何？各方案所得到的長遠與短時間利益分別是什麼？長遠與短時間利益哪個更緊迫？等等。問怎樣的問題，徹底取決於基層技術管理者的技術能力和項目當時的具體情況，並無標準問題集。基層技術管理者若是不具有這種能力，很容易讓團隊在技術方向上迷失，不利於在團隊維持向上的技術氛圍。（注：我看到過一些基層技術管理者，對於團隊所出現的由於技術方案選擇而產生的爭議漠不關心，作決策時是根據各方案有多少人支持，而不是依靠本身的技術能力施加影響）

第三，工程師在工做中會提出這樣或那樣的技術想法，基層技術管理者很重要的工做內容是對這些想法進行積極的迴應，以引導團隊的技能發展。這就要求基層技術管理者對各類技術想法具有甄別能力，能敏銳地發現想法對產品與團隊的意義。對於能改善產品質量與提升團隊效能的想法，基層技術管理者應在團隊內給予及時的確定，併爲想法的實施適當地分配資源。假如基層技術管理者缺少這種能力，要讓團隊具有必定的創新能力幾乎不可能。要知道，工程師所努力的方向很大程度上與基層技術管理者的承認內容有很大的關係。（注：這一點我認爲是基層技術管理者作得很糟糕，他們彷佛只在乎項目計劃和進度）

第四，提升團隊技能是基層技術管理者的核心工做內容，這就要求基層技術管理者在工做中有意識地彌補團隊的技能「短板」，經過考量團隊成員個體的特色和技術特長合理安排工做。技術管理工做中，很懼怕的是忽視個體特色覺得每一個人只要有機會都能成爲技術專家。另外，軟件開發活動中所出現的項目延期，很容易給人的假象是「任務估計不許」，而實際上，這是團隊能力不足的表現。（注：請參見《技術管理的核心內容 - 提升團隊技能》一文）

第五，設計是軟件產品的質量之本，但再好的設計也得經過程序代碼這種「物質外殼」去表達，所以代碼質量將決定軟件產品的最終質量（引自《專業嵌入式軟件開發》）。對於基層技術管理者來講，真實瞭解軟件產品的質量情況並不是簡單地知曉發現了多少缺陷，或閱讀所謂的「質量報告」，而應從產品代碼中得到。因爲軟件開發團隊是以交付高質量軟件產品爲使命的，這就要求基層技術管理者根據代碼質量去指導技術管理工做，不然很容易浮在質量管理的表面。我認爲基層技術管理者很重要的一個工做內容是幫助團隊造成良好的編程習慣，若是對項目的質量沒有代碼級的認識，就很難就這一點在工做中引導團隊。（注：有很多基層技術管理者根本沒有閱讀過項目的代碼，而是一味地經過項目的缺陷率間接瞭解產品質量，甚至一廂情願地生活在「產品質量很高」的夢境中）

第六，軟件開發做爲一種腦力密集型的工做，基層技術管理者如何管理知識工做者一直存在很大的挑戰。在面對和克服挑戰的過程當中，必定須要基層技術管理者很好地理解軟件開發的複雜性本質（沒有「銀彈」），不然很容易生搬硬套純率的管理理論，而忽視技術因素。也只有理解軟件開發的複雜性本質，才能對工程師由於面臨技術難題而使得工做處於焦灼狀態表示理解和保持耐心，也有助於在工做中區分問題的根源是來自管理域、抑或技術域。（注：很多基層技術管理者由於忽視管理工做中的技術因素，採用管理方法去解決技術問題，其效率與效果能夠想象）

技術敏感度歸結起來就是要求基層技術管理者應具有很強的技術能力（千萬不要丟了「很強」兩個字），或者說對技術具有良好的洞察力。對於以上談到的幾點，讀者或許會想：絕大多數基層技術管理者都是技術出身的，難道就沒有技術敏感度？我消極地認爲，不少人都沒有！

不少基層技術管理者是從技術能力較強的人羣中提拔上去的，這是一個事實。然而，因爲他們中的大多數在技術道路上積累的時間都比較短（8年如下），在走上管理崗位時其實對軟件的複雜性本質並無深入的認識，更談不上擁有本身的軟件哲學思想，也沒有多少成功克服技術困難的磨礪。加之，一旦走上管理工做崗位，公司在能力培養方面總愛假設他們在技術能力上能勝任工做，而大力彌補他們的管理技能。結果是，至關數量的基層技術管理者技術能力並無達到至關的水準（管理水平也通常），談不上對技術敏感。

基於這種現狀，對於那些在技術積累尚未達到至關水準卻一心想成爲管理者的同仁，個人建議是：請不要急着去作管理，不然你會身不禁已地失去技術的成長空間。儘管早走上管理崗位能讓咱們把握先機，但操之過急的職業發展是以犧牲本身的未來而換取的。在現在浮燥的社會，不多有工程師知道，其實精進本身的技術是通向成功技術管理的最有效途徑。技術敏感度的缺少會讓咱們在未來付出不少，也會在職業發展的道路上面臨更大的困境（到時技術不精，管理也作很差，拿什麼去競爭？你如何證實你的管理能力突出？）。

之因此如此強調技術敏感度，是由於只有這樣基層技術管理者才更具軟件開發常識，而運用常識去管理複雜的軟件開發應是最爲有效的方法。現實中，正是由於基層技術管理者常識的缺少，他們在不瞭解工程師能力的狀況下卻作着績效管理（能公平嗎？），在很大程度不瞭解項目技術細節的狀況下卻作着項目計劃（能合理嗎？），在沒有讀過項目代碼的狀況下卻作着質量控制（能有效嗎？），……

強調技術敏感度並非說基層技術管理者對所管理的項目須要瞭解每個技術細節，而是強調他們應具有很好的技術積累。這裏的技術積累並非簡單地指他曾經經歷了多少項目、寫過了多少代碼（這些都是必須的），而是須要對軟件開發能有深入的認識，並擁有本身的思想，由於只有這些內容纔對不一樣的項目具備普適性。

讀到這，相信有讀者會問：管理者若是沒有技術敏感度，難道就不能經過用好技術人才而得到成功嗎？這種話某種程度上具備必定的欺騙性。在個人工做經歷中，的確碰到過一位技術敏感度缺少，但在技術管理上卻作得很好的基層技術管理者。這類人在心態上與大多數人不一樣，他們敢於認可本身技術能力的不足，且對團隊中的技術人才給予允分的尊重和信任。實際上，要作到這些很難，尤爲對於那些有很強控制慾的人來講，根本不可能。

對於基層技術管理者，最後我想說的是：你所得到的不僅是權力，更有責任 —  讓團隊成員在快樂的工做中不斷提升技能。

 

原文轉載：http://yunli.blog.51cto.com/831344/1010533