騰訊高級工程師自述：十年沉浮，我為什么選擇離開管理崗位？
從 2001 年在網易成為一名項目經理，到 2011 年進入騰訊，我經歷了從“領導”幾個人到幾百個人的好幾種管理崗位，名字有的叫“總監(jiān)”，有的叫“經理”，還有什么O 之類的。
但在十年之后，現在的我沒有一個下屬，一般的人看來似乎有點不可理解。正常來說，中國人的傳統(tǒng)是“學而優(yōu)則仕”，管人的總比做事的看起來要“高級”一點。
那么，為什么我要“急流勇退”呢?其實并不是我覺得做一般的管理工作力不從心，也不是因為厭倦了管人，或者想要做閑云野鶴，而是我發(fā)現，如果要真正的管理好一個技術團隊，還是要從技術方面下手。
然而這些真正能對技術團隊管理有幫助的技術，不實際地去學習和實踐，是非常難以掌握和熟練的。
管理技術團隊的三大挑戰(zhàn)
01人員流動
技術團隊有多難管，從人員流動這個事上，最能直接體會到。
記得我第一次參加網易的校園招聘，招聘了幾十個應屆畢業(yè)生，這些畢業(yè)生在一年之內，有 70% 都離職了。
有的是去考研、有的去留學，還有繼承家族生意和考公務員的。當然留下來的那批，也有一部分在兩年之內跳槽了。
按理說，網易也算是不錯的公司，尚且面臨如此之高的離職率，其他的公司可能會更加嚴重。
我在這個事情上，花了無數的精力希望打造一個“具備凝聚力”的團隊，試圖降低這種流動性。
但無論如何努力，技術團隊還是會“維持”著某個流動率，這時我意識到，如何降低人員流動對工作的沖擊，才是一個必須要做的事情。
我們知道，軟件開發(fā)的交接，不是一個簡單的事情。因為軟件開發(fā)的文檔、代碼、工作關系，甚至很多工作的經驗，都是以一種智力形式存在的。
這種智力產品，如何從一個人的大腦遷移到另外一個大腦，如果不借助任何工具，無異于師徒傳授技藝，是一個效率很低，結果非常不確定的過程。
所以我認為，技術知識在團隊內的共享，必須要有一些強而有力的技術工具來保障，才能成功。
02項目進度控制
技術團隊的管理除了要應付人員流動的挑戰(zhàn)外，如何衡量技術人員的工作量，從而預估工期和掌控開發(fā)進度，也是一個巨大的挑戰(zhàn)。
這方面關于“項目管理”的知識也算汗牛充棟了。在實際的工作過程中，我們也嘗試各種方法，但是不管使用什么“項目管理”的方法，總會發(fā)現，在項目經理的表格到產品里可運行的代碼之間，總有一道深深的鴻溝。
不管我們的開發(fā)進度預留多少 buff，也不管我們的項目進度報告的周期，從月、周細化到日甚至小時，都無法真正準確的回答——現在項目開發(fā)到什么地步、將來的某個時間點，項目可能開發(fā)到什么程度。
所以我開始承認，掌控技術項目開發(fā)進度，在一些需求變更特別頻繁的領域，特別是互聯(lián)網、游戲這類沒有明確客戶代表的領域，是一個非常模糊而且復雜的工作。
我們必須拋棄工業(yè)時代對于某個“項目”的管理思路，而采用更新的思路，以及更有效的技術工具，才能真正的對項目管理提供有效的推動。
03軟件質量提升
管理技術團隊，就必須對技術團隊的產出負責：軟件的質量和開發(fā)效率。我們既需要穩(wěn)定的軟件質量，盡量少的 Bug，盡量好的性能和擴展性，也需要能跟隨市場快速變化的軟件迭代速度。
而我們的技術團隊總會抱怨，需求變化太快，沒有時間去重構系統(tǒng)，導致代碼的質量下降，開發(fā)效率也受影響等等。
如果我們僅僅是通過提高技術團隊的個人技術能力，或者刺激開發(fā)者更多的“主觀能動性”，結果還是會不盡人意的。
因為個人的技術能力成長需要時間和實踐經驗，而且人員也很有可能會流動;如果主觀能動性被刺激成無休止的加班，到頭來最后還是會降低團隊的工作效率，因為疲勞的開發(fā)者只會制造更多的 Bug 和怨言。
因此我們不能單靠傳統(tǒng)的工商管理的思路去解決技術團隊的產品質量問題，而應該看到軟件開發(fā)本身是一種具有鮮明特色的行業(yè)，要提高產品質量和生產效率，還需要使用更先進的軟件生產工具和生產流程。
人員流動、項目進度控制、軟件質量提升，是我在管理技術團隊中，碰到的最多也是最大的三個挑戰(zhàn)。
在深刻的思考和做了大量的管理實踐后，我深深地認識到，作為一個技術團隊的管理者，最需要的往往不是所謂的“管理能力”，而是對軟件開發(fā)這個行業(yè)，更專業(yè)的技術能力。
這些技術能力，大體包含了所謂的“軟件工程”知識，以及大量的軟件開發(fā)工具以及最佳行業(yè)實踐的經驗。
所以我認為，認真地去研究、實踐、開發(fā)這些，能有效提高技術團隊開發(fā)效率、準確掌控項目進度、降低人員流動性影響的技術，是具有非常重要意義的。
技術管理者需要研究的三種“技術”
在這里我所說的這種“技術”，具體包含些什么呢?概括一下，有如下幾類：
- 軟件模式知識。
- 開發(fā)工具和實踐。
- 需求領域知識。
01軟件模式知識
軟件模式知識主要來自軟件工程類，包括如何寫出可讀性好的代碼，面向對象或者結構化編程的知識，設計模式、架構模式等等。
其中最基礎也最重要的，就是“編寫可讀性好的代碼”，與其說這是一種知識，還不如說是一種態(tài)度。無可否認大多數工科、理科出身的程序員，對于寫文章的訓練都比較少，所以也不難理解為何對此沒有“感覺”。
其實要編寫可讀性好的代碼，最簡單的方式就是重視“命名”。顧名思義是人類最簡單的閱讀體驗，代碼中的變量、函數、類的名字如果是“有意義”的，那就會大大提高代碼的可讀性。
但是，怎樣才能定義一個有意義的名字，而不是僅僅根據技術功能實現的需求來設計名字呢?我知道我們都愛循環(huán)變量 inti，但那是因為我們都熟悉它的這個含義。
對于可能閱讀代碼的人來說，還有什么是確定大家都會比較熟悉的呢?肯定就是業(yè)務領域的內容，因為要接觸這份代碼，肯定是那些要在這個業(yè)務領域工作的人，所以使用業(yè)務領域的內容詞匯是最好的。
但是，由于我們的代碼往往會有很多層的抽象和封裝，所以在某些層次也許無法找到業(yè)務領域詞匯去對應，這確實需要一些想象力和抽象能力，但是不管這種想象的是否合理，一定會比不假思索的用 Controllor 或者 Manager 這樣的名字來得“有意義”。
除了命名以外，代碼可讀性還有各種各樣的需求，而業(yè)界也對這一類要求，總結出很好的規(guī)范，他們就是各種“代碼風格規(guī)范”，最著名的有 Google 公司開放的規(guī)范，包含了多種編程語言的版本。
更重要的是，我們還可以用類似 cpplint 這類的“代碼靜態(tài)檢查工具”來自動的檢查代碼是否符合這樣的規(guī)范。
就連 Google 這樣業(yè)界知名的公司，也會要求所有程序員寫出來的代碼，都要像是一個人寫出來的那樣(出自《Google 軟件測試之道》)，我們還有什么理由去追求各種代碼編寫層面的奇技淫巧呢?
除了靜態(tài)代碼檢查工具，我們也可以組織一些代碼檢視(Code Reivew)來保障這個方面，所幸的是，市面上的大多數 IDE 都支持某些 Code Review 的插件，尋找一個好的代碼檢視工具，然后在實踐中用好這個軟件，也是一種讓人愉快的體驗。
更重要的是，如果一個新入職的程序員，能發(fā)現自己的代碼是受人關注的，在編碼上的技巧和問題是有人指導的，也會加強對團隊的信任和凝聚力，從另外一個意義上看，這也是一種有效的降低團隊流動性的手段。
反過來說，如果不時地參加代碼檢視或者其他代碼監(jiān)管的活動，管理者也能更準確地了解成員的編碼水平，從而做到賞罰有據。
在良好的代碼可讀性基礎之上，對于代碼模塊和模塊抽象，也是需要一定的專門技術的。這里要接觸到的就是“結構化編程”和“面向對象”兩種概念。
這兩方面的書籍汗牛充棟，但是我覺得需要強調的是，“結構化編程”并不和“面向對象”是沖突的，它們之間的關系非常密切。
如果你能把某個需求有邏輯性的細分下去，必須要有足夠的抽象思考和對業(yè)務領域的理解能力。
面向對象是一種面向名詞的思考方式，結構化的思維同樣需要用到。所以結構化編程的思維同樣是面向對象設計的基礎。
這方面的專業(yè)論述有很多，但是最可惜的是，我們很多技術團隊，僅僅把這些看成是程序員的“個人修養(yǎng)”，而不是一個團隊的必要要求，所以我們的代碼質量往往參差不齊。
其實和“代碼風格規(guī)范”一樣，代碼模塊的設計也是必須要符合一定規(guī)范的，這個在不同的團隊和業(yè)務領域中可能不一樣，但是沒有規(guī)范或者指導思想，是最差的一種。
因為這個層面的知識，由于業(yè)務需求和領域的不同，往往很難有完全統(tǒng)一的業(yè)界標準，所以更加需要團隊的管理者來制訂和執(zhí)行。
這也是對一個技術團隊管理中最具挑戰(zhàn)性的部分——如何定義、抽象、管理業(yè)務模型。而這部分也是很多管理者忽視的部分，他們有太多行政工作要做，反而認為這些事情應該交由其他人代勞。
在這個事情上，如果不是有業(yè)務領域經驗豐富的人去做抽象，就一定避免不了模型和需求不對應產生的修改工作量;如果不具備豐富的代碼設計能力，如設計模式的人去設計，需求變更造成的工作量可能會毀掉整個項目。
優(yōu)秀的程序員——往往都成了管理者，必須要發(fā)揮自己的這些智力優(yōu)勢來提高技術團隊的產出，而不是去做別的一些沒有什么“技術要求”的工作。
況且這些設計工作是那么的有挑戰(zhàn)性和趣味性，工作量(從開發(fā)時間看)也不是那么大。
如果管理者在系統(tǒng)的設計過程中和團隊密切的互動，解釋和宣導自己的想法，在執(zhí)行過程中監(jiān)督這些設計的實施，本身也是對產品質量的一種把控，不管是評價下屬的工作量，還是理解項目的進度和瓶頸，都是擁有第一手資料的。
這種情況，就是我認為的技術管理工作，最后還是要落實到技術工作之中的重要理由。
當然，你可能會說，如果一個非常大型的團隊，CTO 也是需要這樣去管理嗎?
聽起來似乎不太可能，但實際上任何一個團隊，在某個時間點上，一定會有一些非常重點的項目，或者一些關鍵的問題要解決，CTO 并不是簡單的做做規(guī)劃想想點子，而是要針對關鍵的業(yè)務問題，去做具體的解決方案的。
這里提一點題外的例子，比如二戰(zhàn)時德國裝甲兵總監(jiān)古德里安，除了多次打報告要求組建強大的裝甲兵集團，還自己去找了兩輛卡車裝上鐵皮，安排模擬的坦克訓練。
這類高級管理者做具體工作的例子非常多，最重要的是要抓到問題的關鍵點去做。我們最常見的毛病反而是不關注難點重點，一味高屋建瓴的提要求而不找解決方案，這是管理的大忌。
如果一個團隊能關注代碼模塊的抽象，能經常討論諸如設計模式、重構這些設計問題，那么就能有機會在更高的抽象層次上，使用更有價值的設計理論，比如架構模式。
最近幾年無論是 Web service、SOA、restful，還是所謂云(PaaS、SaaS)，這些流行的名詞，從某種意義上來說，都是一種架構上的創(chuàng)新：結合最新的技術和最新的業(yè)務領域。
使用什么技術，上什么架構，是一個技術團隊管理者必須隨時學習和思考的問題，固步自封肯定會有穩(wěn)定可靠的好處，但也是讓一個產品腐爛落后的原因。
勇于挑戰(zhàn)和嘗試，才是一個積極向上的技術團隊應有的氣氛，而這個氣氛首先要考驗的是管理者的勇氣。
02開發(fā)工具和實踐
關于先進的開發(fā)工具和實踐，一直以來都有推陳出新，從最簡單的版本管理工具，到各種高級的 IDE 軟件、缺陷管理系統(tǒng)、知識庫管理等等……其中自動化測試技術，是最重要的一種。
《人月神話》中寫到，由于沒有版本管理工具，作者所在的團隊花了巨大的努力，制定了各種管理規(guī)范，來解決代碼分支和覆蓋的問題，甚至要靠把源代碼打印到紙上，堆得比人還高。
我們常常把測試認為是一種“質量檢查”的工作，但實際上，測試是代碼生產的生產線。
我們如果以測試驅動開發(fā)的角度來看，需求首先變成測試用例代碼，具體實現代碼的首次運行也是在測試用例代碼中，最后整體項目的運行，也是由測試代碼來啟動。
這個過程中，測試代碼就好像產品的模具，保障整個產品是設計的樣子?？上覀兂３２⒉辉敢饣〞r間去打造模具，就好像我們直接用手工直接去做產品一樣。
但問題是，如果我們的產品只是一次做出來就好，但是軟件系統(tǒng)往往需要大量的，不同部分的修改，沒有測試系統(tǒng)的保障，我們肯定會改了 A 地方，B 功能就會出錯。
一個項目如果測試用例足夠全面，就算功能代碼全部丟失了，憑借測試用例，也能很快地重建出功能代碼來。
更重要的是，測試代碼還能保證多個層次的代碼，都維持一個穩(wěn)定的“樣子”，這對于項目團隊的人員交接，是有重要意義的。
我們在項目管理的過程中，常常會苦于不知道項目進度如何，但如果你有一個完整的測試驅動開發(fā)的流程，這個問題就不會那么棘手：
需求明確的工作可以看測試用例的編寫進度。在編寫測試用例的過程中，大量的模糊不清的需求，都會被落實成代碼，這也排除了很多日后延期的可能。
如果在比較復雜的系統(tǒng)中，代碼的抽象層次有多個，那么測試用例也許同樣會有很多組。
但不管怎么說，每一層的設計最后都落實成為測試用例的話，整個項目的需求也會因此穩(wěn)定下來。
如果我們是針對這些測試用例去做開發(fā)，那么每天我們都可以統(tǒng)計到有多少個用例被完成，這比從或空洞或繁瑣的程序員日報里，可以獲得的信息準確的多。
在產品運營的過程中，我們可以把所有發(fā)現的故障和缺陷，都補充為測試用例，這樣就可以確保項目的質量逐漸穩(wěn)定下來。
當我們真的需要重構的時候，只要有這些測試用例，就能放心大膽的去修改代碼，因為只要通過所有的測試用例，項目的質量就一定是可靠的。
所以一個自動化、高覆蓋率的測試系統(tǒng)，是一個項目在管理上最有效的工具。
測試工作有那么多好處，但為啥總會覺得有很多困難無法實踐呢?關鍵點就是測試中的各種依賴很難構建，這就是一個比較專業(yè)的技術問題——Mock 和 Fack 系統(tǒng)。
所以我們的問題又一次回到了技術上，構建足夠專業(yè)的 Mock 和 Fack 系統(tǒng)。
03需求領域知識
需求領域知識，從某種方面來說，不算是“純技術”的領域，但對于特定開發(fā)某個業(yè)務領域的團隊，這些知識的掌握程度，往往是至關重要的，因為只有在深刻地理解了需求，才能真正用好各種抽象、模式等軟件工程知識。
程序員們往往都會有一些誤區(qū)，認為只有技術領域才是自己應該關注的，有些人可以非常熟悉 Linux 內核的各種實現細節(jié)，但卻對最近的一個項目的市場情況漠不關心。
很多程序員往往會認為，計算機科學中的那些知識，才是知識，而他們所接觸的其他業(yè)務領域，都不是他們應該關心的。
可惜的是，大部分的程序員，也叫軟件工程師，都是需要解決計算機科學以外的業(yè)務問題的。所謂工程師，就是利用已有的工具，去解決實際的問題。
所以，對于實際要解決的問題領域，不進行完整細致的學習理解是不行的。
事實上，計算機科學，也是因為其他業(yè)務領域的需求而發(fā)展起來的，比如軍事、金融等。
要深入地去學習一個業(yè)務行業(yè)領域的知識，也是需要很多時間的，這往往和程序員希望自己的技能通用化有沖突。
但我認為這個世界上沒有那么多“通用”的知識可以用，能專心做好某一個領域已經很不錯了。
所以你花時間深入到具體的業(yè)務領域上，去學習和實踐各種技術解決方案，會比只是空泛的“領導”一隊人做事更能發(fā)揮作用。
小結
技術團隊的管理，如果僅僅從一般意義的“管理”上去解決問題，往往是無解的。但彼得·德魯克說：管理本質就是創(chuàng)新。
我的理解是：管理就是要去找解決問題的方法，如果這個方法看起來很不像一般意義上的管理，那也無所謂，因為解決問題才是目的。
打破對“管理”的看法，求真務實的去尋找解決問題之道，才是真正的“管理”。技術團隊的管理問題用技術手段解決，是我切身體會的最好的解決方法。
韓偉
騰訊科技互娛研發(fā)部架構師
曾在網易任職 8 年，擔任無線事業(yè)部產品總監(jiān)。多年來一直從事技術開發(fā)，擅長開發(fā)高性能系統(tǒng)，對于軟件架構設計也有豐富的經驗。個人的技術興趣在設計模式、軟件體系架構等提高軟件開發(fā)效率方面的知識。
