騰訊高級工程師講述如何管理技術團隊

從2001年在網易成為一名項目經理，到2011年進入騰訊，我經歷了從「領導」幾個人到幾百個人的好幾種管理崗位，名字有的叫「總監」，有的叫「經理」，還有什麼O之類的。但是在十年之後，現在的我沒有一個下屬，一般的人看來似乎有點不可理解。正常來說，人的傳統是「學而優則仕」，管人的總比做事的看起來要「高級」一點。

那麼，為什麼我要「急流勇退」呢?其實並不是我覺得做一般的管理工作力不從心，也不是因為厭倦了管人，或者想要做閑雲野鶴，而是我發現，如果要真正的管理好一個技術團隊，還是要從技術方面下手。而這些真正能對技術團隊管理有幫助的技術，不實際的去學習和實踐，是非常難以掌握和熟練的。

技術團隊有多難管，從人員流動這個事上，就能最直接的體會到。我記得我第一次參加網易的校園招聘，招聘了的幾十個應屆畢業生，這些畢業生在一年之內，有70%都離職了。他們有的是去考研、有的去留學、還有繼承家族生意和考公務員的。當然留下來的那批，也有一部分在兩年之內跳槽了。按理說網易也算是不錯的公司，尚且面臨如此之高的離職率，其他的公司可能會更加嚴重。

我在這個事情上，花了無數的精力希望打造一個「具備凝聚力」的團隊，試圖降低這種流動性。但是無論如何努力，技術團隊還是會「維持」著某個流動率，所以我意識到，如何降低人員流動對工作的衝擊，才是一個必須要做的事情。我們知道，軟體開發的交接，不是一個簡單的事情。因為軟體開發的文檔、代碼、工作關係，甚至很多工作的經驗，都是以一種智力形式存在的。這種智力產品，如何從一個人的大腦遷移到另外一個大腦，如果不藉助任何工具，無異於師徒傳授技藝，是一個效率很低，結果非常不確定的過程。所以我認為，技術知識在團隊內的共享，必須要有一些強而有力的技術工具來保障，才能成功。

技術團隊的管理除了要應付人員流動的挑戰外，如何衡量技術人員的工作量，從而預估工期和掌控開發進度，這也是一個巨大的挑戰。這方面關於「項目管理」的知識也算汗牛充棟了。在實際的工作過程中，我們也嘗試各種方法，但是不管使用什麼「項目管理」的方法，我們總會發現，在項目經理的表格，到產品里可運行的代碼之間，總有一道深深的鴻溝。

不管我們的開發進度預留多少buff，也不管我們的項目進度報告的周期，從月、周細化到日甚至小時，都無法真正的準確的回答——現在項目開發到什麼地步、將來的某個時間點，項目可能開發到什麼程度。所以我開始承認，掌控技術項目開發進度，在一些需求變更特別頻繁的領域，特別是互聯網、遊戲這類沒有明確客戶代表的領域，是一個非常模糊而且複雜的工作。我們必須拋棄工業時代對於某個「項目」的管理思路，而採用更新的思路，以及更有效的技術工具，才能真正的對項目管理提供有效的推動。

管理技術團隊，我們就必須對技術團隊的產出負責：軟體的質量和開發效率。我們既需要穩定的軟體質量，盡量少的BUG，盡量好的性能和擴展性，也需要能跟隨市場快速變化的軟體迭代速度。而我們的技術團隊總會抱怨，需求變化太快，沒有時間去重構系統，導致代碼的質量下降，開發效率也受影響等等。

如果我們僅僅是通過提高技術團隊的個人技術能力，或者刺激開發者更多的「主觀能動性」，結果還是會不盡人意的。因為個人的技術能力成長需要時間和實踐經驗，而且人員也很有可能會流動;如果主觀能動性被刺激成無休止的加班，到頭來最後還是會降低團隊的工作效率，因為疲勞的開發者只會製造更多的BUG和怨言。因此我們不能單靠傳統的工商管理的思路去解決技術團隊的產品質量問題，而應該看到軟體開發本身是一種具有鮮明特色的行業，要提高產品質量和生產效率，還需要使用更先進的軟體生產工具和生產流程。

人員流動、項目進度控制、軟體質量提升，是我在管理技術團隊中，碰到的最多也是最大的三個挑戰。在深刻的思考和做了大量的管理實踐后，我深深的認識到，作為一個技術團隊的管理者，最需要的往往不是所謂的「管理能力」，而是對軟體開發這個行業，更專業的技術能力。

這些技術能力，大體包含了所謂的「軟體工程」知識，以及大量的軟體開發工具以及最佳行業實踐的經驗。所以我認為認真的去研究、實踐、開發這些，能有效提高技術團隊開發效率、準確掌控項目進度、降低人員流動性影響的技術，是具有非常重要的意義的。我在這裡所說的這種「技術」，具體包含些什麼呢?概括一下，無非有這幾類：軟體模式知識、開發工具和實踐、需求領域知識。

軟體模式知識，主要是來自軟體工程類，包括如何寫出可讀性好的代碼，面向對象或者結構化編程的知識，設計模式、架構模式等等。其中最基礎也最重要的，就是「編寫可讀性好的代碼」，與其說這是一種知識，還不如說是一種態度。

無可否認大多數工科、理科出身的程序員，對於寫文章的訓練都比較少，所以也不難理解為何對此沒有「感覺」。其實要編寫可讀性好的代碼，最簡單的方式就是重視「命名」。顧名思義是人類最簡單的閱讀體驗，代碼中的變數、函數、類的名字如果是「有意義」的，那就會大大提高代碼的可讀性。

但是，怎樣才能定義一個有意義的名字，而不是僅僅根據技術功能實現的需求來設計名字呢?我知道我們都愛循環變數int i，但那是因為我們都熟悉它的這個含義。對於可能閱讀代碼的人來說，還有什麼是確定大家都會比較熟悉的呢?肯定就是業務領域的內容，因為要接觸這份代碼，肯定就是那些要在這個業務領域工作的人，所以使用業務領域的內容辭彙是最好的。但是，由於我們的代碼往往會有很多層的抽象和封裝，所以在某些層次也許無法找到業務領域辭彙去對應，這確實需要一些想象力和抽象能力，但是不管這種想象的是否合理，一定會比不假思索的用Controllor或者Manager這樣的名字來的「有意義」。

除了命名以外，代碼可讀性還有各種各樣的需求，而業界也對這一類要求，總結出很好的規範，他們就是各種「代碼風格規範」，最著名的有Google公司開放的規範，包含了多種編程語言的版本。更重要的是，我們還可以用類似cpplint這類的「代碼靜態檢查工具」來自動的檢查代碼是否符合這樣的規範。就連Google這樣業界知名的公司，也會要求所有程序員寫出來的代碼，都要像是一個人寫出來的那樣(出自《Google軟體測試之道》)，我們還有什麼理由去追求各種代碼編寫層面的奇技淫巧呢?

除了靜態代碼檢查工具，我們也可以組織一些代碼檢視(Code Reivew)來保障這個方面，所幸的是，市面上的大多數IDE都支持某些Code Review的插件，尋找一個好的代碼檢視工具，然後在實踐中用好這個軟體，也是一種讓人愉快的體驗。更重要的是，如果一個新入職的程序員，能發現自己的代碼是受人關注的，在編碼上的技巧和問題是有人指導的，也會加強對團隊的信任和凝聚力，從另外一個意義上看，這也是一種有效的降低團隊流動性的手段。反過來說，如果不時的參加代碼檢視或者其他代碼監管的活動，管理者也能更準確的了解成員的編碼水平，從而做到賞罰有據。

在良好的代碼可讀性基礎之上，對於代碼模塊和模塊抽象，也是需要一定的專門技術的。這裡要接觸到的就是「結構化編程」和「面向對象」兩種概念。這兩方面的書籍汗牛充棟，但是我覺得需要強調的是，「結構化編程」並不和「面向對象」是衝突的，它們之間的關係非常密切。如果你能把某個需求有邏輯性的細分下去，必須要有足夠的抽象思考和業務領域理解知識。

面向對象是一種面向名詞的思考方式，結構化的思維同樣需要用到。所以結構化編程的思維同樣是面向對象設計的基礎。這方面的專業論述有很多，但是最可惜的是，我們很多技術團隊，僅僅把這些看成是程序員的「個人修養」，而不是一個團隊的必要要求，所以我們的代碼質量往往參差不齊。其實和「代碼風格規範」一樣，代碼模塊的設計也是必須要符合一定的規範的，這個在不同的團隊和業務領域中可能不一樣，但是沒有規範或者指導思想，是最差的一種。

因為這個層面的知識，由於業務需求和領域的不同，往往很難有完全統一的業界標準，所以更加需要團隊的管理者來制訂和執行。這也是對一個技術團隊管理中最具挑戰性的部分——如何定義、抽象、管理業務模型。而這部分也是很多管理者忽視的部分，他們有太多行政工作要做，反而認為這些事情應該交由其他人代勞。在這個事情上，如果不是有業務領域經驗豐富的人去做抽象，就一定避免不了模型和需求不對應產生的修改工作量;如果不具備豐富的代碼設計能力，如設計模式的人去設計，需求變更造成的工作量可能會毀掉整個項目。

優秀的程序員——往往都成了管理者，必須要發揮自己的這些智力優勢來提高技術團隊的產出，而不是去做別的一些沒有什麼「技術要求」的工作。況且這些設計工作是那麼的有挑戰性和趣味性，工作量(從開發時間看)也不是那麼大。

如果管理者在系統的設計過程中和團隊密切的互動，解釋和宣導自己的想法，在執行過程中監督這些設計的實施，本身也是對產品質量的一種把控，不管是評價下屬的工作量，還是理解項目的進度和瓶頸，都是擁有第一手資料的。這種情況，就是我認為的技術管理工作，最後還是要落實到技術工作之中的重要理由。

當然，你可能會說，如果一個非常大型的團隊，CTO也是需要這樣去管理嗎?聽起來似乎不太可能，但實際上任何一個團隊，在某個時間點上，一定會有一些非常重點的項目，或者一些關鍵的問題要解決，CTO並不是簡單的做做規劃想想點子，而是要針對關鍵的業務問題，去做具體的解決方案的。

這裡提一點題外的例子，比如二戰時德國裝甲兵總監古德里安，除了多次打報告要求組建強大的裝甲兵集團，還自己去找了兩輛卡車裝上鐵皮，安排模擬的坦克訓練。這類高級管理者做具體工作的例子非常多，最重要的是要抓到問題的關鍵點去做。我們最常見的毛病反而是不關注難點重點，一味高屋建瓴的提要求而不找解決方案，這是管理的大忌。

如果一個團隊能關注代碼模塊的抽象，能經常的討論諸如設計模式、重構這些設計問題，那麼就能有機會在更高的抽象層次上，使用更有價值的設計理論，比如架構模式。最近幾年無論是Web service、SOA、restful，還是所謂雲(PaaS,SaaS)，這些流行的名詞，從某種意義上來說，都是一種架構上的創新：結合最新的技術和最新的業務領域。使用什麼技術，上什麼架構，是一個技術團隊管理者必須隨時學習和思考的問題，固步自封肯定會有穩定可靠的好處，但也是讓一個產品腐爛落後的原因。勇於挑戰和嘗試，才是一個積極向上的技術團隊的應有的氣氛，而這個氣氛首先要考驗的是管理者的勇氣。

先進的開發工具和實踐，一直以來都有推陳出新，從最簡單的版本管理工具(《人月神話》中寫到，由於沒有版本管理工具，作者所在的團隊花了巨大的努力，制定了各種管理規範，來解決代碼分支和覆蓋的問題，甚至要靠把源代碼列印到紙上，堆的比人還高。)，到各種高級的IDE軟體、缺陷管理系統、知識庫管理等等……但其中自動化測試技術，是最重要的一種。

我們常常把測試認為是一種「質量檢查」的工作，但實際上，測試是代碼生產的生產線。我們如果以測試驅動開發的角度來看，需求首先變成測試用例代碼，具體實現代碼的首次運行也是在測試用例代碼中，最後整體項目的運行，也是由測試代碼來啟動。

這個過程中，測試代碼就好像產品的模具，保障整個產品是設計的樣子。可惜我們常常並不願意花時間去打造模具，就好像我們直接用手工直接去做產品一樣。但問題是，如果我們的產品只是一次做出來就好，但是軟體系統往往需要大量的，不同部分的修改，沒有測試系統的保障，我們肯定會改了A地方，B功能就會出錯。

一個項目如果測試用例足夠全面，就算功能代碼全部丟失了，憑藉測試用例，也能很快的重建出功能代碼來。更重要的是，測試代碼還能保證多個層次的代碼，都維持一個穩定的「樣子」，這對於項目團隊的人員交接，是有重要意義的。

我們在項目管理的過程中，常常會苦於不知道項目進度如何，但如果你有一個完整的測試驅動開發的流程，這個問題就不會那麼棘手。首先，需求的明確工作可以看測試用例的編寫進度。在編寫測試用例的過程中，大量的模糊不清的需求，都會被落實成代碼，這也排除了很多日後延期的可能。

如果在比較複雜的系統中，代碼的抽象層次有多個，所以測試用例也許同樣會有很多組。但不管怎麼說，每一層的設計最後都落實成為測試用例的話，整個項目的需求也會因此就穩定下來。然後，如果我們是針對這些測試用例去做開發，那麼每天我們都可以統計到有多少個用例被完成，這比從或空洞或繁瑣的程序員日報里，可以獲得的信息準確的多。

最後，在產品運營的過程中，我們可以把所有發現的故障和缺陷，都補充為測試用例，這樣就可以確保項目的質量可以逐漸穩定下來，當我們真的需要重構的時候，只要有這些測試用例，就能放心大膽的去修改代碼，因為只要通過所有的測試用例，項目的質量就一定是可靠的。所以一個自動化、高覆蓋率的測試系統，是一個項目在管理上最有效的工具。

測試工作有那麼多好處，但是為啥總會覺得有很多困難無法實踐呢?關鍵點就是測試中的各種依賴很難構建，這就是一個比較專業的技術問題——Mock和Fack系統。所以我們的問題又一次回到了技術上，構建足夠專業的Mock和Fack系統。

需求領域知識，從某種方面來說，不算是「純技術」的領域，但是，對於特定開發某個業務領域的團隊，這些知識的掌握程度，往往是至關重要的，因為只有在深刻的理解了需求，才能真正的用好各種抽象、模式等軟體工程知識。

程序員們往往都會有一些誤區，認為只有技術領域才是自己應該關注的，有些人可以非常熟悉Linux內核的各種實現細節，但是確對最近的一個項目的市場情況漠不關心。很多程序員往往會認為，計算機科學中的那些知識，才是知識，而他們所接觸的其他業務領域，都應該是他們關心的。

可惜的是，大部分的程序員，也叫軟體工程師，都是需要解決計算機科學以外的業務問題的。所謂工程師，就是利用已有的工具，去解決實際的問題。所以對於實際要解決的問題領域，不進行完整細緻的學習理解是不行的。事實上，計算機科學，也是因為其他業務領域的需求而發展起來的，比如軍事、金融等等。

要深入的去學習一個業務行業領域的知識，也是需要很多時間的，這往往和程序員希望自己的技能通用化有衝突。但是我認為這個世界上沒有那麼多「通用」的知識可以用，能專心做好某一個領域已經很不錯了。所以在花時間到具體的業務領域上，去學習和實踐各種技術解決方案，會比只是空泛的「領導」一隊人做事更能發揮作用。

技術團隊的管理，如果僅僅從一般意義的「管理」上去解決問題，往往是無解的。但是彼得?德魯克說：管理本質就是創新。我的理解是，管理就是要去找解決問題的方法，如果這個方法看起來很不像一般意義上的管理，那也無所謂，因為解決問題才是目的。打破對「管理」的看法，求真務實的去尋找解決問題之道，才是真正的「管理」。技術團隊的管理問題用技術手段解決，是我切身體會的最好的解決方法。