【51CTO.com原創稿件】 技術管理本身是一種“軟”實力，對它的理解取決于你對于事物的理解，而對于事物的理解是伴隨著你的生活、工作閱歷的增加而變化的。

[[227600]]

本文作者以“打游戲”為例，分為如下六部分闡述技術團隊管理之道：

• 球員的安撫
• 年輕球員的優勢
• 安排嘗試多個位置
• 節約開支
• 安排合理的訓練
• 選擇合適的隊長

球員的安撫

以玩足球游戲為例，游戲中的球員，特別是一些很有個性的球員，他們很容易會出現問題。

比如說受不了自己拿錢比別人少，要求加薪的；比如說年紀小，離家遠的球員，要求被掛牌出售；比如說比賽中好久沒有使用他了，讓他感覺沒有提升了，也會要求被掛牌出售。

比如說覺得自己職業生涯前景渺茫的，主動要求培訓他掌握場上其他位置所需要具備的技能的球員。諸如此類，各種情況都有。

面對不同的情況，我們首先要做的就是安撫，而不是指責，而安撫的最佳方式是從事情的根源著手。

為什么這些球員會出現這樣的問題？我們可以捫心自問，真的完全是他們個人的問題嗎？我覺得不全是，很多時候是我們的工作沒有做到位，也就是說，我們犯錯了。

不管你的意愿如何強烈，又做出多大努力，這是不可避免的：在生命的某個時候，你會犯錯。錯誤難以消化，所以我們有時會孤注一擲或回避他們，而不是直面它們。

這時候，我們在確認事物的認知上會產生偏差，導致我們尋求著證據試圖來證明自己所堅持著的信念。

比如，被你加塞擋在后面的車的保險杠上有一個小凹痕，你顯然會認為是后車司機的錯。

這種情況心理學家稱之為認知失調，即當我們持有兩種相互沖突的想法、信念、觀點或態度時所感受到的壓力。

比如，你可能認為自己是個善良、公正的人，那么當你在開車時粗暴地加塞到其他車前面時，則會經歷這種失調。

為了應對它，你會否認自己的錯誤，堅稱那個司機本該看見你或你有先行的權力，盡管事實上并不是這樣。

《錯不在我》這本書的作者 CarolTavris 認為：“認識失調是我們在自我認知——我是聰明、善良的，我堅信這是真的——受到事實挑戰時產生的感受，顯示我們做了不聰明的、傷害其他人的事，證明我們之前的想法是錯的”。

回到技術領域。如果你知道大家正在尋找的問題的根源出在你的程序上面，那么請你主動站出來，簡要地解釋一下存在什么問題，出現問題的原因，以及你能提出的解決對策。

在專業領域，出現這種大規模討論的原因，往往是由于主導者在情況變得糟糕時得不到直接的答復。

如果能夠及時向他們提供信息，說明問題出在哪里、正在采取哪些措施以最大限度地降低問題再度發生的可能性，他們就能對問題的影響做出準確的評估了。

敢于承認錯誤，并積極地彌補錯誤所造成的損失，是一種非常可貴的精神，值得我們豎起大拇指表揚。

這讓我想起來愛迪生的一位學徒，不小心打碎了一天的勞動成果，實驗室其他人都在責備他的粗心，只有愛迪生安慰他，并讓他繼續擔任成果傳遞的工作。

這一經歷最終造就了一位科學家，而不是在這孩子還很年幼的時候就無情地打擊，希望那些持這類態度的領導能夠看到這個故事。

如果哪一個領導因為你主動承認錯誤，一股腦把責任全部推給你，那你也應該離開他了，通過這次事件看清楚這個人的品德，挺好的。

[[227601]]

年輕球員的優勢

游戲中有這種情況，當一個位置上有兩名候選球員時，如果他們的能力差不多，我會不由自主地選擇年輕球員。

因為他們的可塑能力強，說不定多比賽還能有較大程度的提升，而老球員，可能也就那樣了。這是內心真實的想法，管理一支球隊必須考慮球隊的未來發展。

回到技術管理領域。坦白說，我也會有為什么年輕人機會比我多的想法，這也確實是存在的現實問題。

畢竟，基層崗位上的老兵的性價比在很多時候比不上年輕人了，你不能深夜加班，你不愿意周末放棄與家人的陪伴時間到公司加班，等等，諸如此類的情況在老板眼中都成了很糾結的事情。

我們能做什么改變這樣的現狀嗎？有的。我們應該直面這樣的情況，多多利用自己的經驗，在有限的時間里快速學習新的知識。

如果可以，我的建議是工作上一定要跟進最新技術的發展動向，某種程度上這和炒股差不多，看好業績的話提前埋伏進場。

比如若干年前剛有安卓、iOS 的時候，很多人還在塞班上開發，但眼光好的技術人第一時間就轉行到了安卓、iOS。

因為先占了坑在最稀缺的時候搶占了先機，與比你晚兩年轉行的人相比差距可能會越來越大。當然也有可能賭輸了，例如 Windows 編程。

每一次業界的革命，都會讓一些公司落寞而讓另一些公司崛起，程序員工作也是一樣的，每一次技術換代也都會導致一些程序員沒落而讓另一些程序員崛起。

在技術換代面前，之前的工作經驗不至于一文不值，但也會大打折扣。另外，正因為技術不斷換代，學的快的才比單純年輕的有優勢。

如果技術完全停滯，干五年左右技術就不再成長，那么畢業五年后還當基層程序員的失業風險就越來越大。

這也是某通信大廠被傳聞的所謂“35 歲裁員”的寫實，聽說 35 歲主要針對的就是這些基層程序員，45 歲針對的是基層程序員和技術一線管理者。

不斷的盼望著（如果能力夠強也可以自己創造）新技術的出現，并且自己保持著不亞于年輕人的學習能力，自然就降低了高齡失業風險。

至于做管理，也是一種出路，因為在管理的經驗積累上很難有天花板的說法，十年管理經驗可能有很大一部分確實是后五年積累的。

不像寫代碼，不過也要考慮做管理和技術脫節的問題，得保證這個公司不要你了，你的管理經驗是能用在其他公司的。

只有積極地面對每一天的挑戰，你才有可能在你的職業生涯上走得更遠，否則，很危險的。

[[227602]]

安排嘗試多個位置

大多數球員都可以勝任多個位置，你可以嘗試在不同的比賽中安排他們不同的場上位置。

同一個位置上的使用不能僅觀察一場比賽，你需要給他們機會，讓他們多試幾次，也許你就會有不一樣的收獲。

我曾經使用一名叫 Lemar 的法國球員，在左邊前衛的位置上他表現得不溫不火，但是當移動到右邊鋒位置時，他連續幾場比賽均有破門，這讓我對他刮目相看，也更加豐富了我的陣容選擇。

回到技術管理領域。一位來自浙大的師弟描述自己工作 3 年，現在帶領 6 個人的團隊做后端技術開發，但是覺得自己還處在技術上升期，想去阿里這樣的公司鍛煉技術，但又有點放不下現在的職位，咨詢我的看法。

我建議他先去鍛煉技術，無論是不是去阿里（也不要太相信該廠或其他大廠，還是要以所在部門承擔的技術工作職責為優先考慮），都需要加深自己的技術深度。

倒不是說技術管理我做得來，他就不能做，其實并不是這樣的。

我的認知是技術積累是一輩子的事情，只有到了一定程度，即你可以花較少的時間學會一項新技術或者架構的時候，你才要去做技術管理的工作，因為技術管理工作會占用你一部分工作時間。

我記得有華為內部某個產品總監評價李一男，他回憶一個場景，李一男完全不懂一個產品的技術，在去 21 樓的會議室路上向他簡單介紹后，李一男就能夠在會議室無障礙地參與這次技術的討論，借此事說明李的技術很強。

我不知道這件事情是否真實，我只是覺得這是有可能的。因為技術本身是相似的。

比如分區概念，可以用在 GC 的設計上，也可以用在 HBase 的設計上，在 Oracle 里也有這個概念，而且設計思路和目標基本一樣。

那么當一個人的技術基礎很好時，他就會很容易理解你所講的技術，能夠最快時間內掌握。

這就是一個人的學習能力，有點類似于慕容復的“以彼之道還施彼身”，只有功力深厚的人才能做到。

再者，你怎么知道他沒有學過？也許私下他早就看過很多資料了，杰出的程序員都是有很強烈的主動學習動力和能力的。

什么時候成為技術管理者？這沒有恒定的標準，但我的建議是，先打好技術基礎，當你覺得每天只用 50% 時間做技術，或是比你的大多數下屬都了解技術細節的時候，你可以嘗試給自己加上技術管理的工作量。

節約開支

管理一支球隊所需要面對的問題也包括財務問題，好球員的收入很高，這時你球隊的整體財政赤字就會不斷上升。

而解決這類問題的最佳方式是賣出不再需要的球員，或者解雇已經完全沒有位置的球員，聽起來很殘酷，但是必須這么做。

回到技術管理領域。一家公司如果遇到了危機，那么它會立即進行的措施通常有兩種，一是裁員，二是業務轉型。

2008 年的金融危機影響了很多以海外業務為主的公司，特別是外包公司。有朋友曾和我分享，危機爆發后的一年，公司準備大裁員，大家陸陸續續都被勸退了。

對于那些嚴重依賴單一收入來源，技術含量又不高的 IT 公司來說，一旦出現危機，首先能做的，也可能是唯一的方式，就是裁員。

這個措施針對的可能是收入、年齡均較高的員工；可能是普通員工；也可能是高管，這要看股東制定的策略。

再來看第二種方式，業務轉型，可能是單純業務方向、產品的轉移，也可能會涉及具體技術方向，當然，兩者都需要的也很正常。

轉型沒有裁員這么直接，但是對員工的影響也不小，畢竟每一個人都有自己擅長的技能、感興趣的業務和技術方向。

如果業務出現大范圍轉型，那么意味著你需要學習新的技能，而且是快速學習、上手，不然可能會走上前一條路：被裁員。

對于學習能力、自我調節能力較差的員工來說，內心會很不愿意做這樣的轉變，甚至可能出現抵觸情緒。

也有另外一種情況，比如原來寫 Java 的，現在公司業務轉型，要求你用 Python 編程，這時候就會有一些工程師不愿意了，積累了多年的技能，不想輕易丟棄。

無論是什么原因，如果不按照管理層指定的策略轉型，最后的結果都是走人。

對于這類情況，我覺得既然從一開始就選擇了工程師職業，最好能夠做好終身學習的思想準備，并付諸實際行動。

畢竟外部環境在不斷變化，科技公司好好壞壞都用不了三十年，幾年就河東河西了。

無論是否跟著公司轉型，都需要我們具備較強的自我學習能力，不斷強化自己的綜合能力，跟上技術的變遷，為自己的轉型提前做好準備。

[[227603]]

安排合理的訓練

一名球隊的主教練，需要合理安排大家的訓練時間，這一點很重要。

因為這直接決定球員的體力，如果你安排的訓練過于頻繁，那么就會出現球員上場比賽時體力都只有 80% 的情況，這樣導致他們不能在最佳狀態下比賽了。

回到技術管理領域。做過項目的團隊管理者一般都有這樣的經歷，團隊成員正在專心處理現場問題，但卻莫名其妙被人投訴。

投訴可能來自市場部門，也可能來自技術支持，或者兄弟研發部門，也容易出現團隊成員每天被大量無用的會議煩擾，不去的話就要被投訴，這類情況在大公司司空見慣。

我們要學會保護團隊成員，讓他們免受組織中每日泛濫不絕的各種問題、爭議和“機會”的干擾。

在大一些的公司內部，官僚主義政治會通過各種文書工作來忽略或者緩沖每天的各種請求和問題。

在小一些的公司里，面對挑戰的是各種銷售驅動的機會、客戶驅動的爭議問題，以及管理驅動的想法，作為團隊領導者，你可能是他們最后或者唯一的防線。

很多團隊管理者的大部分工作內容是理解、評估、討論、協商、推遲、記錄，以及最后統一或拒絕去處理這些問題。

如果你讓你的下屬去處理這些問題，那么最終他們會淹沒在這些繁雜事情的洪流之中，會極大地降低他們的程序設計效率。

通過保護你的員工，可以讓他們避免把寶貴的時間浪費在臨時事務上。而且也能讓他們工作得更愉快。

因為某些問題可能會演變成完整的流言，讓人擔心項目變更，擔心收購、重組或裁員，這些流言會大大降低士氣，并導致各種損壞工作效率的猜測和抱怨。

另外一種你必須提供的保護是，保護你的員工免受開發之外的同事或者部門的攻擊。

這些攻擊或者抨擊往往并沒有充足的信息或事實根據，有些抨擊是出于好心的，有些則是惡意的，甚至可能包括個人攻擊。

對這種情況我的建議是保持警惕，處理之前先充分了解情況，如果確實存在無根據的抨擊，事發當時或事后私下溝通，告訴那個發出抨擊的人，指出他的行為是不恰當的，已經讓你無法容忍，讓他知道事情的嚴重性，而不是一味指責自己的員工做得不夠好。

有一個情況我想特別說明。公司內部非重要部門組織的會議，盡量不要放在周五的晚上、休息日進行。

放在這種休息時間，看起來很有效率，其實是在過度使用研發資源、過度消費員工對公司的滿意度。

周五晚上、休息日可以打擾研發人員的事情是：

• 現場問題，必須立即處理（不處理會損害公司未來利益）。
• 重要客戶提出需求，要求立即做出回復（不處理會損害公司當前利益）。
• 特別重大的突發事件（對你、對公司都很重要）。

[[227604]]

選擇合適的隊長

游戲中每場比賽都需要指定場上隊長，我記得加里內維爾在曼聯期間一直擔任著副隊長，這是因為他應該算是曼聯青訓營出來的那幫 95 黃金一代里最為勤奮的。

但是他是副隊長，這又是因為他的體格和性格在球員中都太普通了，真的遇到強悍的對手時就會有點慫了，所以需要基恩這樣的硬漢來擔任隊長。

在游戲中，我通常指定領導力、溝通力、決斷力、技術能力都較好的球員擔任隊長。

回到技術管理領域。我們在選擇隊長（Leader）之前，先來看看團隊的組成。

我們假設現有團隊全部由普通程序員（能夠完成交代的工作，但是沒有主動創造能力）組成，這時候其實團隊中沒有任何一位成員會成為合格的技術經理。

除非他們遇到特別復雜的環境，逼迫著他們做出自我改變和自我激勵，否則他們會一直保持現狀。

這種情況下，我們需要做的是招聘 1-2 位杰出的程序員，這一步要耐心，明確候選人是否是真正的杰出程序員。

因為只有招聘到真正正確的人才才能讓工作高效，如果招到的員工很差，那么你就沒有時間去處理其他的工作了（總是有各種問題不停地困擾著你）。

這就是為什么平庸的團隊需要有集技術和管理豐富經驗于一身的高手空降到團隊的原因。

但是可惜國內很多公司都不愿意這樣做，因為擔心現有團隊成員會比較排斥，也擔心空降的人能力不到位，這其實是能力評估方法論的問題。

很多團隊傾向于讓系統架構師擔任團隊負責人（隊長），但是需要注意的是，一些系統程序員/架構師往往在團隊里顯得有點格格不入，這是因為他們很多都是“獨狼”，他們可能脾氣很差，也可能技術上很有個人主義。

這也是個人成就差別最大的群體。和這類人不同，杰出的程序員能夠以一種優雅而簡潔易懂的設計來架構大型的復雜系統。

這些優秀的系統往往能讓所有其他程序員的工作都更加輕松，因此，單人就能帶來巨大的杠桿效應。

我的理解是需要讓系統程序員/架構師深入到開發工作，不要讓他們只設計、不編碼，應該把他們引導成為杰出程序員。

否則他們最終可能成為團隊的雞肋，其實真正的架構師本身就是團隊的領導者。

后記

每個人都有自己的優勢，努力在職業生涯中找到自己的優勢，最大程度發揮它、利用它，你會有收獲的，加油，諸位。

作者：周明耀

簡介：畢業于浙江大學，工學碩士。13 年軟件開發領域工作經驗，近 10 年技術管理經驗，4 年分布式軟件開發經驗，提交發明專利 17 項。目前出版《大話Java性能優化》、《深入理解JVM&G1 GC》、《技術領導力程序員如何才能帶團隊》等三本書籍。微信號 michael_tec，微信公眾號“麥克叔叔每晚10點說”。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】