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

06-05

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

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

第一，基層技術管理者在日常工作中作為技術團隊面向管理層的介面人，他們在各類與產品經理、項目經理的會議中代表著工程師隊伍解釋影響項目進展所面臨的技術問題。這就要求管理者適時地了解項目在技術方面的進展，顯然，這些進展得從工程師口中獲得。日常工作中，基層技術管理者不僅要能理解工程師所解釋的技術問題，還得掌握問題要害，而不能工程師解釋時了解，過後卻健忘。基層技術管理者如不具備這種能力，容易造成與管理層和技術團隊的溝通不暢而影響工作效率。（註：我碰到過一些基層技術管理者，同樣的技術問題得在不同時間段為他解釋。開技術會議的主要工作是讓他理解所出現的技術問題，效率之低可以想像）

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

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

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

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

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

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

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

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

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

強調技術敏感度並不是說基層技術管理者對所管理的項目需要了解每一個技術細節，而是強調他們應具備很好的技術積累。這裡的技術積累並不是簡單地指他曾經經歷了多少項目、寫過了多少代碼（這些都是必須的），而是需要對軟體開發能有深刻的認識，並擁有自己的思想，因為只有這些內容才對不同的項目具有普適性。

讀到這，相信有讀者會問：管理者如果沒有技術敏感度，難道就不能通過用好技術人才而獲得成功嗎？這種話某種程度上具有一定的欺騙性。在我的工作經歷中，的確碰到過一位技術敏感度缺乏，但在技術管理上卻做得很好的基層技術管理者。這類人在心態上與大多數人不同，他們勇於承認自己技術能力的不足，且對團隊中的技術人才給予允分的尊重和信任。實際上，要做到這些很難，尤其對於那些有很強控制欲的人來說，根本不可能。

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