一說(shuō)到管理者的能力特質(zhì)，我們馬上會(huì )聯(lián)想到溝通、授權、決策等能力。然而，對于軟件開(kāi)發(fā)活動(dòng)中的基層技術(shù)管理者（team lead、line manager等），我想指出被極為忽視的另一種重要能力 — 技術(shù)敏感度。
對于基層技術(shù)管理者來(lái)說(shuō)，何為技術(shù)敏感度？技術(shù)敏感度表現為：1）工程師解釋技術(shù)問(wèn)題時(shí)，能快速理解并切中問(wèn)題要害； 2）面對多個(gè)技術(shù)方案做選擇時(shí)，具備權衡能力，并能給出有建設性的意見(jiàn)和建議，甚至做出選擇；3）工程師提出技術(shù)想法時(shí)，能敏銳地意識到對產(chǎn)品和團隊的意義； 4）能根據團隊成員的個(gè)體差異和技能特點(diǎn)，及團隊技能整體發(fā)展的需要，合理地調配團隊成員的工作內容；5）從代碼層面了解項目的質(zhì)量狀況；6）理解軟件開(kāi)發(fā)活動(dòng)的復雜性本質(zhì)。部分內容看似應是工程師應具備的，為何卻要求基層技術(shù)管理者必備？
第一，基層技術(shù)管理者在日常工作中作為技術(shù)團隊面向管理層的接口人，他們在各類(lèi)與產(chǎn)品經(jīng)理、項目經(jīng)理的會(huì )議中代表著(zhù)工程師隊伍解釋影響項目進(jìn)展所面臨的技術(shù)問(wèn)題。這就要求管理者適時(shí)地了解項目在技術(shù)方面的進(jìn)展，顯然，這些進(jìn)展得從工程師口中獲得。日常工作中，基層技術(shù)管理者不僅要能理解工程師所解釋的技術(shù)問(wèn)題，還得掌握問(wèn)題要害，而不能工程師解釋時(shí)了解，過(guò)后卻健忘?；鶎蛹夹g(shù)管理者如不具備這種能力，容易造成與管理層和技術(shù)團隊的溝通不暢而影響工作效率。（注：我碰到過(guò)一些基層技術(shù)管理者，同樣的技術(shù)問(wèn)題得在不同時(shí)間段為他解釋。開(kāi)技術(shù)會(huì )議的主要工作是讓他理解所出現的技術(shù)問(wèn)題，效率之低可以想象）
第二，基層技術(shù)管理者在日常工作中不時(shí)會(huì )面臨團隊技術(shù)方案的選擇問(wèn)題。規模較大的技術(shù)方案（如系統級、子系統級）的選擇通常由架構師們完成，但團隊級別小規模的技術(shù)方案選擇很多情形下會(huì )成為基層技術(shù)管理者的工作內容。當團隊具備一個(gè)以上技術(shù)實(shí)力相當，但在設計理念上存在明顯差異的工程師時(shí)，他們很有可能在項目實(shí)施的過(guò)程中主張不同的實(shí)現方案，如果設計方案無(wú)法及時(shí)達成共識，勢必影響項目的順利進(jìn)展。此時(shí)，基層技術(shù)管理者得參與其中，通過(guò)運用自己的技術(shù)能力與團隊共同做出設計方案的選擇。在這種情況下，即使技術(shù)管理者不直接做決策，也得通過(guò)詢(xún)問(wèn)一些問(wèn)題幫助團隊做出決策。所問(wèn)的問(wèn)題可能有：各方案的開(kāi)發(fā)成本如何？各方案所獲得的長(cháng)遠與短期利益分別是什么？長(cháng)遠與短期利益哪一個(gè)更緊迫？等等。問(wèn)怎樣的問(wèn)題，完全取決于基層技術(shù)管理者的技術(shù)能力和項目當時(shí)的具體狀況，并沒(méi)有標準問(wèn)題集?；鶎蛹夹g(shù)管理者如果不具備這種能力，很容易讓團隊在技術(shù)方向上迷失，不利于在團隊維持向上的技術(shù)氛圍。（注：我看到過(guò)一些基層技術(shù)管理者，對于團隊所出現的因為技術(shù)方案選擇而產(chǎn)生的爭議不聞不問(wèn)，做決策時(shí)是根據各方案有多少人支持，而不是依靠自己的技術(shù)能力施加影響）
第三，工程師在工作中會(huì )提出這樣或那樣的技術(shù)想法，基層技術(shù)管理者很重要的工作內容是對這些想法進(jìn)行積極的回應，以引導團隊的技能發(fā)展。這就要求基層技術(shù)管理者對各種技術(shù)想法具備甄別能力，能敏銳地發(fā)現想法對產(chǎn)品與團隊的意義。對于能改善產(chǎn)品質(zhì)量與提高團隊效能的想法，基層技術(shù)管理者應在團隊內給予及時(shí)的肯定，并為想法的實(shí)施適當地分配資源。假如基層技術(shù)管理者缺乏這種能力，要讓團隊具備一定的創(chuàng )新能力幾乎不可能。要知道，工程師所努力的方向很大程度上與基層技術(shù)管理者的認可內容有很大的關(guān)系。（注：這一點(diǎn)我認為是基層技術(shù)管理者做得很糟糕，他們似乎只在意項目計劃和進(jìn)度）
第四，提高團隊技能是基層技術(shù)管理者的核心工作內容，這就要求基層技術(shù)管理者在工作中有意識地彌補團隊的技能“短板”，通過(guò)考量團隊成員個(gè)體的特點(diǎn)和技術(shù)特長(cháng)合理安排工作。技術(shù)管理工作中，很害怕的是忽視個(gè)體特點(diǎn)以為每個(gè)人只要有機會(huì )都能成為技術(shù)專(zhuān)家。另外，軟件開(kāi)發(fā)活動(dòng)中所出現的項目延期，很容易給人的假象是“任務(wù)估計不準”，而實(shí)際上，這是團隊能力不足的表現。（注：請參見(jiàn)《技術(shù)管理的核心內容 - 提高團隊技能》一文）
第五，設計是軟件產(chǎn)品的質(zhì)量之本，但再好的設計也得通過(guò)程序代碼這種“物質(zhì)外殼”去表達，因此代碼質(zhì)量將決定軟件產(chǎn)品的最終質(zhì)量（引自《專(zhuān)業(yè)嵌入式軟件開(kāi)發(fā)》）。對于基層技術(shù)管理者來(lái)說(shuō)，真實(shí)了解軟件產(chǎn)品的質(zhì)量狀況并非簡(jiǎn)單地知曉發(fā)現了多少缺陷，或閱讀所謂的“質(zhì)量報告”，而應從產(chǎn)品代碼中獲得。由于軟件開(kāi)發(fā)團隊是以交付高質(zhì)量軟件產(chǎn)品為使命的，這就要求基層技術(shù)管理者根據代碼質(zhì)量去指導技術(shù)管理工作，否則很容易浮在質(zhì)量管理的表面。我認為基層技術(shù)管理者很重要的一個(gè)工作內容是幫助團隊形成良好的編程習慣，如果對項目的質(zhì)量沒(méi)有代碼級的認識，就很難就這一點(diǎn)在工作中引導團隊。（注：有不少基層技術(shù)管理者根本沒(méi)有閱讀過(guò)項目的代碼，而是一味地通過(guò)項目的缺陷率間接了解產(chǎn)品質(zhì)量，甚至一廂情愿地生活在“產(chǎn)品質(zhì)量很高”的夢(mèng)境中）
第六，軟件開(kāi)發(fā)作為一種腦力密集型的工作，基層技術(shù)管理者如何管理知識工作者一直存在很大的挑戰。在面對和克服挑戰的過(guò)程中，一定需要基層技術(shù)管理者很好地理解軟件開(kāi)發(fā)的復雜性本質(zhì)（沒(méi)有“銀彈”），否則很容易生搬硬套純率的管理理論，而忽視技術(shù)因素。也只有理解軟件開(kāi)發(fā)的復雜性本質(zhì)，才能對工程師因為面臨技術(shù)難題而使得工作處于焦灼狀態(tài)表示理解和保持耐心，也有助于在工作中區分問(wèn)題的根源是來(lái)自管理域、抑或技術(shù)域。（注：不少基層技術(shù)管理者因為忽視管理工作中的技術(shù)因素，采用管理方法去解決技術(shù)問(wèn)題，其效率與效果可以想象）
技術(shù)敏感度歸結起來(lái)就是要求基層技術(shù)管理者應具備很強的技術(shù)能力（千萬(wàn)不要丟了“很強”兩個(gè)字），或者說(shuō)對技術(shù)具備良好的洞察力。對于以上談到的幾點(diǎn)，讀者或許會(huì )想：絕大多數基層技術(shù)管理者都是技術(shù)出身的，難道就沒(méi)有技術(shù)敏感度？我消極地認為，很多人都沒(méi)有！
很多基層技術(shù)管理者是從技術(shù)能力較強的人群中提拔上去的，這是一個(gè)事實(shí)。然而，由于他們中的大多數在技術(shù)道路上積累的時(shí)間都比較短（8年以下），在走上管理崗位時(shí)其實(shí)對軟件的復雜性本質(zhì)并沒(méi)有深刻的認識，更談不上擁有自己的軟件哲學(xué)思想，也沒(méi)有多少成功克服技術(shù)困難的磨礪。加之，一旦走上管理工作崗位，公司在能力培養方面總愛(ài)假設他們在技術(shù)能力上能勝任工作，而大力彌補他們的管理技能。結果是，相當數量的基層技術(shù)管理者技術(shù)能力并沒(méi)有達到相當的水準（管理水平也一般），談不上對技術(shù)敏感。
基于這種現狀，對于那些在技術(shù)積累還沒(méi)有達到相當水準卻一心想成為管理者的同仁，我的建議是：請不要急著(zhù)去做管理，否則你會(huì )身不由已地失去技術(shù)的成長(cháng)空間。盡管早走上管理崗位能讓我們把握先機，但操之過(guò)急的職業(yè)發(fā)展是以犧牲自己的將來(lái)而換取的。在如今浮燥的社會(huì )，很少有工程師知道，其實(shí)精進(jìn)自己的技術(shù)是通向成功技術(shù)管理的最有效途徑。技術(shù)敏感度的缺乏會(huì )讓我們在將來(lái)付出很多，也會(huì )在職業(yè)發(fā)展的道路上面臨更大的困境（到時(shí)技術(shù)不精，管理也做不好，拿什么去競爭？你如何證明你的管理能力突出？）。
之所以如此強調技術(shù)敏感度，是因為只有這樣基層技術(shù)管理者才更具軟件開(kāi)發(fā)常識，而運用常識去管理復雜的軟件開(kāi)發(fā)應是最為有效的方法?，F實(shí)中，正是因為基層技術(shù)管理者常識的缺乏，他們在不了解工程師能力的情況下卻做著(zhù)績(jì)效管理（能公平嗎？），在很大程度不了解項目技術(shù)細節的情況下卻做著(zhù)項目計劃（能合理嗎？），在沒(méi)有讀過(guò)項目代碼的情況下卻做著(zhù)質(zhì)量控制（能有效嗎？），……
強調技術(shù)敏感度并不是說(shuō)基層技術(shù)管理者對所管理的項目需要了解每一個(gè)技術(shù)細節，而是強調他們應具備很好的技術(shù)積累。這里的技術(shù)積累并不是簡(jiǎn)單地指他曾經(jīng)經(jīng)歷了多少項目、寫(xiě)過(guò)了多少代碼（這些都是必須的），而是需要對軟件開(kāi)發(fā)能有深刻的認識，并擁有自己的思想，因為只有這些內容才對不同的項目具有普適性。
讀到這，相信有讀者會(huì )問(wèn)：管理者如果沒(méi)有技術(shù)敏感度，難道就不能通過(guò)用好技術(shù)人才而獲得成功嗎？這種話(huà)某種程度上具有一定的欺騙性。在我的工作經(jīng)歷中，的確碰到過(guò)一位技術(shù)敏感度缺乏，但在技術(shù)管理上卻做得很好的基層技術(shù)管理者。這類(lèi)人在心態(tài)上與大多數人不同，他們勇于承認自己技術(shù)能力的不足，且對團隊中的技術(shù)人才給予允分的尊重和信任。實(shí)際上，要做到這些很難，尤其對于那些有很強控制欲的人來(lái)說(shuō)，根本不可能。
對于基層技術(shù)管理者，最后我想說(shuō)的是：你所獲得的不只是權力，更有責任 — 讓團隊成員在快樂(lè )的工作中不斷提高技能。
聯(lián)系客服
