前言

我是從 2014 年開始正式走上管理之路的，在那之前雖然也有帶過幾個初級程式設計師，但畢竟不是正式的管理職位。正式踏上管理崗是從做一個小主管開始的，剛開始只管理幾個人；之後擔任過一些業務線的技術負責人，管理十幾二十人；最多時管理百人團隊，負責整個研發部門。一路從技術主管，到技術經理，再到技術總監，中間也和別人合夥創業當過 CTO。有空降管理過現成的團隊，也有不止一次從 0 到 1 組建團隊的經驗。

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

我打算根據管理的三個級別來聊：技術主管、技術經理、技術總監。這裡所說的這三個級別，並不是指代具體的管理崗位名稱，可以簡單理解為技術團隊中的基層管理者、中層管理者、高層管理者，具體的再一一細說。

技術主管

如剛才所說，技術主管並不指代具體的崗位，而是指初級技術管理人員，主要負責管理某一垂直技術領域，包括管理該領域的基層技術人員。比如 Android 主管、iOS 主管、前端主管、Java 主管、Golang 主管等。有些公司也稱為技術組長，而且也不一定設定明確崗位。另外，在有些小公司，管理層級少，可能就沒有設定技術主管的崗位，而直接掛名技術經理，比如我的第一份正式管理崗，掛名就是 App 技術經理，管理 Android 和 iOS。那時候的我其實既是基層管理者，也是中層管理者。這在小公司很正常，甚至處於初創期的 CTO，還需要同時擔任高層、中層、基層所有的管理工作。

技術主管所管理的人員一般只有幾個人，多的可能十幾個。如果人員超過 20 人，最好對團隊根據細分領域做一下拆分。比如 App 人員如果超過 20 人，那就可以拆分為 Android 組和 iOS 組，每組再分別設定一個主管，而原先的 App 主管則可以升級為技術經理。

對公司部門來說，技術主管優先考慮肯定是從內部人員中提拔，條件不滿足的情況下才從外部招聘。比如，組建新團隊的時候；或當前團隊都只有些初級工程師，缺乏能夠獨當一面的人；或團隊中都是些技術宅，只想專研技術，不想做管理。這些情況下，一般就需要從外部招聘合適的人選。

能榮升技術主管的，一般工作經驗 3-5 年，專業技術能力已經非常嫻熟，可達到資深級別，還具備一定的架構能力，能夠獨當一面。學習能力、溝通能力、對業務的理解能力等，也都是比較出眾的。一般可以對標阿里的 P6 級別。

想要做好技術主管的工作，也不是那麼輕鬆的。作為一名技術主管，平時大部分時間依然還是用在了技術設計、寫程式碼、解決 Bug 等工作，這和基層的程式設計師沒多大區別。但是，技術主管除了需要做好這些程式設計師本身的工作之外，還需要花時間做開發任務的分解、分配，以及程式碼 review、技術設計評審、面試、和團隊內外的人員溝通協作等管理工作。因此，想要做好技術主管的工作，提高時間管理的能力是很有必要的。不然的話，就會把自己搞得很忙很累，最後管理工作沒做好，還影響了作為程式設計師本身的工作。也因此，有些人就會開始退縮，不願意當技術主管，覺得會佔用自己過多的時間，平時寫程式碼的時間都不夠，哪有時間做管理。想要在管理這條路上不斷往上爬，這是必須要邁過去的第一道坎。

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

關於招人選人，我有一個標準，也是我最看重的一點，那就是候選人的深度思考能力。不只是技術人員，包括產品經理、UI 設計、測試人員等，我都會考察他們的深度思考能力。深度思考能力越強的人，越能看到問題的本質，各方面的能力也會越優秀。

那麼，如何考察候選人的深度思考能力呢？其實也簡單，多問些為什麼就可以了。比如，對於應聘架構師的候選人，可以類似下面這樣層層追問下去：

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

這些相互關聯的問題，是可以不斷追問下去的，問題也並非有標準答案的，也並不是考察候選人是否知道正確答案，而是考察他是否思考過這些問題，是否有自己的一些想法。當然，候選人也不可能對所有領域的問題都能答得上來，所以儘量多方面考察，並儘量從候選人所熟悉的領域進行深入。

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

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

符合我的標準招進來的人，做事基本都是很高效的，大多都能成為團隊裡的骨幹成員，有時還能做到遠超我的預期，有著突出的表現。不過，有時候，長時間沒招到合適人選或急需用人時，我只能減低標準，這時候招進來的人，則有些參差不齊了，部分人雖然也能完成任務，但成果就是不盡如人意。

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

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

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

技術經理

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

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

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

對技術經理的工作年限一般要求 5 年以上，技術上對架構能力的要求高一些，本身至少也應該是個能夠獨當一面的架構師或技術專家，可以對標阿里的 P7 級別。不過，在具體要求上，大廠和中小廠是不一樣的。大廠對技術深度的要求會更高，小廠則比較看重技術廣度。但大廠基本很少對外招聘管理崗，同級別的高 P 技術崗反而會招得多。所以，大部分人只能在中小企業發展管理路線。另外，技術經理也不一定是從技術主管升上去的，也可以從高 P 的技術專家轉崗的。

在管理能力上，對技術主管所要求的也同樣對技術經理有要求，而且要求更高。比如，業務理解能力，技術主管更多隻是停留在對業務區域性的一些點和線方面，而技術經理應該精通業務，對業務應有全域性觀。再比如，團隊建設方面，技術主管更多隻是偏於對個人提供技術指導，而技術經理則需要制定具體的團隊建設方案，比如制定技術培訓方案，以提高團隊整體的技術水平。

技術經理還有一個核心工作就是培養技術主管。如何培養呢？最核心的一點就是要懂得授人以漁，教以方法論，而不是一旦出現問題就直接幫他解決問題。技術主管上任初期普遍會存在一些不足，比如，在任務分解方面會做得不太好，經常會分解得不徹底，會導致增加很多溝通成本甚至任務延遲；面試時也不太懂得如何抓重點，會浪費很多時間；團隊成員出現分歧時，也不太懂得如何妥善處理。這些都需要技術經理花時間、花精力去慢慢指導技術主管，要讓技術主管明白背後的方法論，而不要簡單地丟給他解決方案。

我做技術經理的時候，還擔任過公司裡某些業務線的技術負責人，統籌管理專案的技術研發進度，其實就是專案管理。有些公司，會設定專崗來做專案管理，一般稱為專案經理。但不少公司和我一樣，是由技術經理兼做專案管理的。另外，還有部分公司，會由產品經理來兼做專案管理。

其實，要做好專案管理，對業務和技術兩方面都熟悉是再好不過的。畢竟，從流程來看，專案管理包含了需求、設計、開發、測試、上線五個階段，前兩個階段是業務強相關的，後三個階段是技術強相關的。因此，最好的專案管理人員，應該是既懂業務又精於技術的，才能更好地統籌全域性。但現實情況卻是這樣的人比較稀少，所以，更多時候，一個專案的前兩個階段主要由指定的產品經理進行管理，後三個階段則由指定的技術負責人進行管理。而統籌全域性的人，則從兩人中再指定一人，或直接由上級領導來統籌。所以，確切來說，我當時所擔任的專案管理，其實只是技術層面的專案管理，統籌專案全域性的是我的上級領導。

技術層面的專案管理，我主要採用敏捷開發方法，並結合 TAPD 或 TOWER 等工具進行管理。專案管理涉及到的具體事務不少，我只挑幾個重點說一下：

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

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

技術總監

高層技術管理崗，大廠和中小廠在這個級別上對管理者的能力要求，差距非常大。比如，阿里的總監級別，職級一般得在 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 組、測試組、運維組、運營組。每個小組再分別設定一個組長，管理各職能小組的成員和相應的職能事務。主要優點就是能夠發揮各職能小組的集中優勢，人員調配上也有較大的靈活性。主要缺點就是在專案管理上，完成專案需多個小組相互配合，但專案經理缺少權力，協調難度較大，難以做到快速迭代。

專案型的組織結構，即是將團隊成員按不同專案劃分為多個專案組，每個專案組都分別有自己的產品、設計、開發、測試、運營等人員，每個專案組再分別設定一個專案經理，管理專案中的所有事務和人員。優點就是專案經理對專案可以全權負責，包括對專案成員也有全部權力，專案決策快、效率高，也可做到快速迭代。缺點則是專案組相對封閉，資源無法共享，很容易造成資源浪費，且專案之間缺乏交流，知識和經驗也難以在不同專案組之間共享，對團隊整體的提升造成阻礙。

矩陣型的組織結構，則是職能型和專案型的混合體，可對兩種結構的優缺點進行取長補短，是目前大部分網際網路公司所採用的方式。矩陣型結構，專案成員會有雙重領導，職能經理和專案經理都是他/她的上級，對員工容易產生焦慮和壓力。且如果權力劃分不明確，兩位領導容易產生衝突。

根據專案經理和職能經理權力的強弱關係，矩陣型結構還可以再細分為：弱矩陣、強矩陣、平衡矩陣。弱矩陣下，職能經理的權力更高，專案經理的角色更像個協調者。強矩陣則是專案經理有著更高權力，管理上更偏向於專案。平衡矩陣自然就是兩位經理的權力都差不多，取平衡，而平衡之道其實也是最微妙的。

我這邊主要嘗試過專案型和弱矩陣型，從效果來看，弱矩陣型的組織架構會更加合適。至於平衡矩陣型，想要達到好的效果，需要精心建立管理體系，且對協調人的能力要求較高，而身邊缺乏這樣的人。另外，還有一種方案，就是讓職能經理同時兼任專案經理，我曾任技術經理時就是這樣，但我擔任總監時，卻缺乏符合要求的人。

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

總結

技術管理的方方面面還很多，限於篇幅，暫時就先聊這麼多了。總結陳詞，我只說兩點：

“管理的本質，是激發人的善意與潛能。” 謹記這句話並時刻踐行之。技術一定不能落下，不管是主管，經理，還是總監，最最核心的還是技術。

因為我自己是做Android開發的，所以呢，對於如果是在Android技術方面不是很自信的朋友，建議可以對照以下我總結的作為一個Android高階開發人員需要掌握的技術點，來查漏補缺（還會提供一些個人整理的學習筆記參考）。

架構師築基必備技能

目前Android APP開發主流語言就是Java語言，Java語言最大的特性就是提高了軟體的互動可能性，可以說安卓手機幾乎所有應用程式都是利用Java語言來進行編寫的。

知識要點：1、深入理解Java泛型2、註解深入淺出3、併發程式設計4、資料傳輸與序列化5、Java虛擬機器原理6、高效IO

架構師築基必備技能

設計思想解讀開源框架

隨著網際網路企業的不斷髮展，產品專案中的模組越來越多，使用者體驗要求也越來越高，想實現小步快跑、快速迭代的目的越來越難，外掛化技術應用而生。如果沒有外掛化技術，美團、淘寶這些集成了大量“app”的應用，可能會有幾個g那麼大。

所以，當今的Android移動開發，不會熱修復、外掛化、元件化，80%以上的面試都過不了。

知識要點：1、熱修復設計2、外掛化框架設計3、元件化框架設計4、圖片載入框架5、網路訪問框架設計6、RXJava響應式程式設計框架設計

設計思想解讀開源框架

360°全方位效能調優

在不同層次的開發工程師手裡，因為技術水平的參差不齊，即使很多手機在跑分軟體效能非常高，開啟應用依然存在卡頓現象。

另外，隨著產品內容迭代，功能越來越複雜，UI頁面也越來越豐富，也成為流暢執行的一種阻礙。綜上所述，對APP進行效能最佳化已成為開發者該有的一種綜合素質，也是開發者能夠完成高質量應用程式作品的保證。

1、設計思想與程式碼質量最佳化

2、程式效能最佳化

啟動速度與執行效率最佳化佈局檢測與最佳化記憶體最佳化耗電最佳化網路傳輸與資料儲存最佳化APK大小最佳化

3、開發效率最佳化

分散式版本控制系統Git自動化構建系統Gradle

4、專案實戰

360°全方位效能調優

Android框架體系架構

Android框架體系架構（高階UI+FrameWork原始碼） 這塊知識是現今使用者最多的，我們稱之Android2013~2016年的技術。

Android開發者也往往因為網上Copy程式碼習慣了而導致對這塊經常“使用”的程式碼熟悉而又陌生：熟悉的是幾乎天天在和它們打交道， 天天在複製這些程式碼 ；陌生的是雖然天天和這些程式碼打交道，但是並沒有深入研究過這些程式碼的原理，程式碼深處的內涵。

本篇知識要點：1、高階UI晉升2、Android核心元件3、大型專案必備IPC4、資料持久與序列化5、Framework核心解析

Android框架體系架構

NDK模組開發（音影片系列）

NDK（Native Development Kit縮寫）一種基於原生程式介面的軟體開發工具包，可以讓您在 Android 應用中利用 C 和 C++ 程式碼的工具。透過此工具開發的程式直接在本地執行，而不是虛擬機器。

在Android中，NDK是一系列工具的集合，主要用於擴充套件Android SDK。NDK提供了一系列的工具可以幫助開發者快速的開發C或C++的動態庫，並能自動將so和Java應用一起打包成apk。

本篇知識要點：1、NDK開發之C/C++入門2、JNI模組開發3、Linux程式設計4、底層圖片處理5、音影片開發6、機器學習

NDK模組開發

Flutter學習進階

2020 年無疑是 Flutter 技術如火如荼發展的一年。

每一個移動開發者都在為 Flutter 帶來的“快速開發、富有表現力和靈活的 UI、原生效能”的特色和理念而痴狂，從超級 App 到獨立應用，從純 Flutter 到混合棧，開發者們在不同的場景下樂此不疲的探索和應用著 Flutter 技術，也在面臨著各種各樣不同的挑戰。

本篇知識要點：1、Flutter跨平臺開發概述2、Windows中Flutter開發環境搭建3、編寫你的第一個Flutter APP4、Flutter Dart語言系統入門......

Flutter學習

微信小程式開發

微信小程式作為現在比較火的程式設計開發應用場景之一，深受市場的青睞，這讓不少開發者眼饞不已。但是對於初學者來說，就完全摸不著頭腦了，不知道微信小程式開發製作需要學習那些知識，有需要的朋友可以參考本篇。

本篇知識要點：1、小程式概述及入門2、小程式UI開發3、API操作4、購物商場專案實戰

Android相關原始碼解讀只要是程式設計師，不管是Java還是Android，如果不去閱讀原始碼，只看API文件，那就只是停留於皮毛，這對我們知識體系的建立和完備以及實戰技術的提升都是不利的。

Android相關原始碼解讀

Android相關原始碼解讀部分內容