[[392343]] 

圖片來自 Pexels

正式踏上管理崗是從做一個小主管開始的，剛開始只管理幾個人；之后擔任過一些業務線的技術負責人，管理十幾二十人；最多時管理百人團隊，負責整個研發部門。

一路從技術主管，到技術經理，再到技術總監，中間也和別人合伙創業當過 CTO。有空降管理過現成的團隊，也有不止一次從 0 到 1 組建團隊的經驗。

六年多的管理經驗，說多不多，但說少也不少，肯定也有自己的一些心得體會，如今就用文字來和大伙分享我的一些經驗總結。

我打算根據管理的三個級別來聊：

• 技術主管
• 技術經理
• 技術總監

這里所說的這三個級別，并不是指代具體的管理崗位名稱，可以簡單理解為技術團隊中的基層管理者、中層管理者、高層管理者，具體的再一一細說。

01技術主管

如剛才所說，技術主管并不指代具體的崗位，而是指初級技術管理人員，主要負責管理某一垂直技術領域，包括管理該領域的基層技術人員。

比如 Android 主管、iOS 主管、前端主管、Java 主管、Golang 主管等。有些公司也稱為技術組長，而且也不一定設置明確崗位。

另外，在有些小公司，管理層級少，可能就沒有設置技術主管的崗位，而直接掛名技術經理，比如我的第一份正式管理崗，掛名就是 App 技術經理，管理 Android 和 iOS。

那時候的我其實既是基層管理者，也是中層管理者。這在小公司很正常，甚至處于初創期的 CTO，還需要同時擔任高層、中層、基層所有的管理工作。

技術主管所管理的人員一般只有幾個人，多的可能十幾個。如果人員超過 20 人，最好對團隊根據細分領域做一下拆分。

比如 App 人員如果超過 20 人，那就可以拆分為 Android 組和 iOS 組，每組再分別設置一個主管，而原先的 App 主管則可以升級為技術經理。

對公司部門來說，技術主管優先考慮肯定是從內部人員中提拔，條件不滿足的情況下才從外部招聘。

比如，組建新團隊的時候;或當前團隊都只有些初級工程師，缺乏能夠獨當一面的人;或團隊中都是些技術宅，只想專研技術，不想做管理。這些情況下，一般就需要從外部招聘合適的人選。

能榮升技術主管的，一般工作經驗 3-5 年，專業技術能力已經非常嫻熟，可達到資深級別，還具備一定的架構能力，能夠獨當一面。

學習能力、溝通能力、對業務的理解能力等，也都是比較出眾的。一般可以對標阿里的 P6 級別。

想要做好技術主管的工作，也不是那么輕松的。作為一名技術主管，平時大部分時間依然還是用在了技術設計、寫代碼、解決 Bug 等工作，這和基層的程序員沒多大區別。

但是，技術主管除了需要做好這些程序員本身的工作之外，還需要花時間做開發任務的分解、分配，以及代碼 review、技術設計評審、面試、和團隊內外的人員溝通協作等管理工作。

因此，想要做好技術主管的工作，提高時間管理的能力是很有必要的。不然的話，就會把自己搞得很忙很累，最后管理工作沒做好，還影響了作為程序員本身的工作。

也因此，有些人就會開始退縮，不愿意當技術主管，覺得會占用自己過多的時間，平時寫代碼的時間都不夠，哪有時間做管理。想要在管理這條路上不斷往上爬，這是必須要邁過去的第一道坎。

從程序員升級為技術主管，最核心的轉變就是：從管理自我到管理他人。所以，我想談談關于管理他人的一點經驗，主要還是分享下在選人和用人上我自己的一些做法。

關于招人選人，我有一個標準，也是我最看重的一點，那就是候選人的深度思考能力。

不只是技術人員，包括產品經理、UI 設計、測試人員等，我都會考察他們的深度思考能力。深度思考能力越強的人，越能看到問題的本質，各方面的能力也會越優秀。

那么，如何考察候選人的深度思考能力呢?其實也簡單，多問些為什么就可以了。

比如，對于應聘架構師的候選人，可以類似下面這樣層層追問下去：

• 問：你們系統采用什么樣的架構?答：微服務架構
• 問：為什么采用微服務?答：為了快速迭代
• 問：為什么用了微服務就能實現快速迭代?答：服務間解耦，可以分小組分別獨立開發、測試和部署
• 問：分了多少個小組?每個小組多少人?為什么這么分?答：……

這些相互關聯的問題，是可以不斷追問下去的，問題也并非有標準答案的，也并不是考察候選人是否知道正確答案，而是考察他是否思考過這些問題，是否有自己的一些想法。

當然，候選人也不可能對所有領域的問題都能答得上來，所以盡量多方面考察，并盡量從候選人所熟悉的領域進行深入。

再說說用人方面，我比較崇尚于為下面每個人的自我成長而負責。

我會去了解每個人的職業規劃，為他們的職業發展路線提出建議，并在工作中不斷給他們提供成長的機會，包括分配的任務、提供的技術指導和培訓、定期的一對一溝通，等等。其實，從本質上來說，就是為了激發他們的善意和潛能。

我做基層管理時就已經開始實踐選人用人的這些方法論，而且成效還非常不錯。

符合我的標準招進來的人，做事基本都是很高效的，大多都能成為團隊里的骨干成員，有時還能做到遠超我的預期，有著突出的表現。

不過，有時候，長時間沒招到合適人選或急需用人時，我只能減低標準，這時候招進來的人，則有些參差不齊了，部分人雖然也能完成任務，但成果就是不盡如人意。

也因為我用人的方式注重于他們的成長，所以，他們也很尊重我、支持我、追隨我。我管理過的團隊，離職率也一向比較低。

作為基層管理者的技術主管，建議重點培養自己的以下能力：

• 專業技術能力：這是技術管理者的立身之本，肯定需要不斷精進，如果技不如人，是無法服眾的。
• 業務理解能力：對業務有正確的理解，甚至能理解到業務的本質需求，才能讓技術實現價值。
• 任務分解能力：技術主管承擔著開發任務分解分配的職責，如果分解不當，漏掉了一些環節，就會導致任務的延遲、質量的不可控，為項目帶來了風險。
• 時間管理能力：管理者需要在有限的時間里高效地管理多種事情，自然就需要提高時間管理能力。
• 團隊建設能力：管理者的核心價值就是打造出一支優秀的團隊。
• 向上管理能力：向上管理沒做好，會影響職業的發展，但切記，向上管理并不是拍上級的馬屁。
• 領導力：領導力不同于管理力，不能靠職權，而是靠個人魅力，建議盡早培養。需要明白一點，大部分技術人員更喜歡被“領導”，而不是被“管理”。

[[392344]] 

02技術經理

技術主管作為基層管理人員，更多時候只是個執行者，要求能夠「正確地做事」，能夠帶領一線團隊高效地執行上級所交代的任務。

技術經理，作為中層管理人員，主要職責則是根據高層管理所確定的目標，制定實現目標的具體計劃并保證實施，還要為最后的實現結果負責。

技術經理具體的工作職責，不同公司會有所不同，但主要可能包括：制定技術規范、制定工作計劃、項目整體的架構設計和架構優化、跟進項目進度、團隊建設、與其他部門的協調溝通等。

對技術經理的工作年限一般要求 5 年以上，技術上對架構能力的要求高一些，本身至少也應該是個能夠獨當一面的架構師或技術專家，可以對標阿里的 P7 級別。

不過，在具體要求上，大廠和中小廠是不一樣的。大廠對技術深度的要求會更高，小廠則比較看重技術廣度。

但大廠基本很少對外招聘管理崗，同級別的高 P 技術崗反而會招得多。所以，大部分人只能在中小企業發展管理路線。

另外，技術經理也不一定是從技術主管升上去的，也可以從高 P 的技術專家轉崗的。

在管理能力上，對技術主管所要求的也同樣對技術經理有要求，而且要求更高。

比如，業務理解能力，技術主管更多只是停留在對業務局部的一些點和線方面，而技術經理應該精通業務，對業務應有全局觀。

再比如，團隊建設方面，技術主管更多只是偏于對個人提供技術指導，而技術經理則需要制定具體的團隊建設方案，比如制定技術培訓方案，以提高團隊整體的技術水平。

技術經理還有一個核心工作就是培養技術主管。如何培養呢?最核心的一點就是要懂得授人以漁，教以方法論，而不是一旦出現問題就直接幫他解決問題。

技術主管上任初期普遍會存在一些不足，比如：

• 在任務分解方面會做得不太好，經常會分解得不徹底，會導致增加很多溝通成本甚至任務延遲。
• 面試時也不太懂得如何抓重點，會浪費很多時間。
• 團隊成員出現分歧時，也不太懂得如何妥善處理。

這些都需要技術經理花時間、花精力去慢慢指導技術主管，要讓技術主管明白背后的方法論，而不要簡單地丟給他解決方案。

我做技術經理的時候，還擔任過公司里某些業務線的技術負責人，統籌管理項目的技術研發進度，其實就是項目管理。

有些公司，會設置專崗來做項目管理，一般稱為項目經理。但不少公司和我一樣，是由技術經理兼做項目管理的。另外，還有部分公司，會由產品經理來兼做項目管理。

其實，要做好項目管理，對業務和技術兩方面都熟悉是再好不過的。畢竟，從流程來看，項目管理包含了需求、設計、開發、測試、上線五個階段，前兩個階段是業務強相關的，后三個階段是技術強相關的。

因此，最好的項目管理人員，應該是既懂業務又精于技術的，才能更好地統籌全局。

但現實情況卻是這樣的人比較稀少，所以，更多時候，一個項目的前兩個階段主要由指定的產品經理進行管理，后三個階段則由指定的技術負責人進行管理。而統籌全局的人，則從兩人中再指定一人，或直接由上級領導來統籌。

所以，確切來說，我當時所擔任的項目管理，其實只是技術層面的項目管理，統籌項目全局的是我的上級領導。

技術層面的項目管理，我主要采用敏捷開發方法，并結合 TAPD 或 TOWER 等工具進行管理。

項目管理涉及到的具體事務不少，我只挑幾個重點說一下：

• 代碼分支管理：建議用 Git，不要用 SVN。要制定適合團隊和項目情況的代碼分支管理規范，可以從簡單的 TrunkBased 模式開始，在實踐中再不斷去優化演進。
• 每日站會：站會的時間控制在 15 分鐘內，目的主要是同步項目進度，發言要簡明扼要、關注重點、禁止報流水賬，可提出問題，但切記不要在站會中討論解決問題，留待會后再去溝通解決。
• 復盤總結：每次版本迭代結束后，應該組織復盤總結會，這很重要，總結成功經驗，吸取失敗教訓，有助于提升團隊能力。
• 質量管理：這應該是項目管理中最重要但卻是最難管理的一塊了，其會貫穿整個研發流程中幾乎每一個階段。主要的管理工具包括測試驅動開發、設計評審、code review 等。

作為中層管理者，技術經理一般不會對基層員工進行直接管理，因此，想要管理好下面的整個團隊，更需要提升自己的領導力，通過領導力而不是職權來讓基層員工信服。

[[392345]] 

03技術總監

高層技術管理崗，大廠和中小廠在這個級別上對管理者的能力要求，差距非常大。比如，阿里的總監級別，職級一般得在 M4 以上，M4 對應于 P9。

阿里的職級體系有兩條線，P 系列為技術崗，M 系列為管理崗，對應關系為：

• P6 = M1，主管
• P7 = M2，經理
• P8 = M3，資深經理
• P9 = M4，總監
• P10 = M5，資深總監

再往上就不列舉了，馬云卸任前是最高級別，為 M10。而一般小公司的技術總監，跳到阿里可能只會給到 P7 級別，很優秀的可給到 P8，能達到 P9 的絕對是鳳毛麟角。

大部分技術總監難以達到 P9 或 P8，很多時候是因為技術深度達不到高 P 級別的要求。

因為小公司的技術總監，能力更偏向于“全能型”，優勢在于廣度，而深度難免會成為短板。而大廠因為分工精細化，對廣度反而沒什么要求，但對深度要求很高。

另一方面，大廠的高 P 們跳去小公司當技術總監或 CTO，很多人也會面臨廣度不足的問題，難以很好地統籌全局。因此，習慣了大公司“精細化”模式的人也未必能滿足小公司“全能型”的需求。

所以說，大廠和小廠的總監，幾乎是兩個不同的方向。而我自己也沒有大廠總監的經驗，所以我在這方面的經驗主要適用于中小廠。

我的總監級別的管理經驗，也有三年多了，具體崗位擔任過技術總監、研發總監、CTO。

管理的團隊人員最多時近百人，最少時則是從 0 搭建。當 CTO 的時候責任最大，但團隊的人員卻是最少的，最多時也就 20 多人，后來因為熊市來了，資金鏈斷裂，融資失敗，團隊最終解散。

擔任研發總監時，管理的團隊是最大的，整個研發部門有百號人，包括技術人員，也包括產品和運營人員。

作為技術總監/研發總監/CTO，最核心的能力就是能夠組建和管理整個研發部門，打造出一個高效的研發團隊。

先聊聊從 0 組建團隊的經驗，這方面我有過兩次經歷。從 0 組建團隊，最核心的還是如何才能招到合適的人選。

最優的方案就是從自己的人脈中入手，以前帶過的下屬，或熟悉的同事、朋友，覺得優秀合適的可以試著挖過來，每個崗位上的人員，最好都是能夠獨當一面，后續有能力擔任技術主管的。

我當 CTO 時組建的團隊，有好幾個核心骨干就是我以前帶過的下屬，他們之所以愿意跟隨我，部分原因還是因為認可我的領導力。

這里要補充說一下，前面我就建議從技術主管開始就重點培養領導力，因為，領導力發揮作用的時候，不只是對在職的團隊成員。

次優的方案就是靠別人推薦了，最后的方案才是進行社招。而不管是推薦還是社招，有些崗位，技術總監可能不熟悉相應的技術，就難以考察候選人的實際能力。我自己倒不存在這樣的問題，畢竟我自己是個全棧。

但大部分總監卻非如此，那么，我提供三種方案：

• 請技術專家幫忙面試，并給予相應的酬勞。
• 請技術專家出一些面試題，并提供參考答案。
• 總監自己花時間去了解相應的技術。

這三種方案，效果一般也是由高到低。花點錢請相應的技術專家幫忙面試是最好的選擇，現在普遍都是視頻面試，也比較方便。

接著，再跟大伙分享下我管理近百人的整個研發部門的一些經驗。整個團隊包括了產品經理、設計師、開發、測試、運維、運營等人員，需并行研發多個項目。

有些公司的研發部門可能不會包括產品經理、設計師、運營人員，不過沒關系，管理方法也是一樣的。

管理百人級別的研發團隊，第一個核心工作，就是采用合適的組織結構。一般有三種類型的組織結構：職能型、項目型、矩陣型。

職能型的組織結構，即是對團隊成員按不同職能劃分為多個小組，比如分為：產品組、設計組、前端組、App 組、Java 組、Golang 組、測試組、運維組、運營組。

每個小組再分別設置一個組長，管理各職能小組的成員和相應的職能事務。

主要優點就是能夠發揮各職能小組的集中優勢，人員調配上也有較大的靈活性。

主要缺點就是在項目管理上，完成項目需多個小組相互配合，但項目經理缺少權力，協調難度較大，難以做到快速迭代。

項目型的組織結構，即是將團隊成員按不同項目劃分為多個項目組，每個項目組都分別有自己的產品、設計、開發、測試、運營等人員，每個項目組再分別設置一個項目經理，管理項目中的所有事務和人員。

優點就是項目經理對項目可以全權負責，包括對項目成員也有全部權力，項目決策快、效率高，也可做到快速迭代。

缺點則是項目組相對封閉，資源無法共享，很容易造成資源浪費，且項目之間缺乏交流，知識和經驗也難以在不同項目組之間共享，對團隊整體的提升造成阻礙。

矩陣型的組織結構，則是職能型和項目型的混合體，可對兩種結構的優缺點進行取長補短，是目前大部分互聯網公司所采用的方式。

矩陣型結構，項目成員會有雙重領導，職能經理和項目經理都是他/她的上級，對員工容易產生焦慮和壓力。且如果權力劃分不明確，兩位領導容易產生沖突。

根據項目經理和職能經理權力的強弱關系，矩陣型結構還可以再細分為：弱矩陣、強矩陣、平衡矩陣。

弱矩陣下，職能經理的權力更高，項目經理的角色更像個協調者。強矩陣則是項目經理有著更高權力，管理上更偏向于項目。

平衡矩陣自然就是兩位經理的權力都差不多，取平衡，而平衡之道其實也是最微妙的。

我這邊主要嘗試過項目型和弱矩陣型，從效果來看，弱矩陣型的組織架構會更加合適。

至于平衡矩陣型，想要達到好的效果，需要精心建立管理體系，且對協調人的能力要求較高，而身邊缺乏這樣的人。

另外，還有一種方案，就是讓職能經理同時兼任項目經理，我曾任技術經理時就是這樣，但我擔任總監時，卻缺乏符合要求的人。

作為技術總監，組建起研發團隊只是第一步，想讓這個團隊變得高效，還需要做很多事情，也有很多方法，但回歸到最本質上，還是要盡一切努力去激發成員們的善意與潛能。

04總結

技術管理的方方面面還很多，限于篇幅，暫時就先聊這么多了。

總結陳詞，我只說兩點：

技術一定不能落下，不管是主管，經理，還是總監，最最核心的還是技術。

“管理的本質，是激發人的善意與潛能。” 謹記這句話并時刻踐行之。

作者：Keegan小鋼

編輯：陶家龍

出處：轉載自公眾號 Keegan 小鋼(ID：keeganlee_me)