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