怎麼做好互聯網公司的技術團隊負責人？

01-03

如題，怎麼做好互聯網公司的技術團隊負責人。互聯網公司的技術團隊負責人應該具備怎樣的能力？

謝邀

正好寫2015年終總結，其實今年不太想寫的，但是公司層面要求有個人總結要弄，寫了個開始就情不自禁多寫了一些，談談這方面的總結吧。

公司的技術團隊負責人應該具備怎樣的能力？

或者說團隊Leader應該知曉和鍛煉什麼樣的能力？

大公司、創業公司都經歷過，從Leader或創始人那裡學到了不少東西，自己也會慢慢總結，保持學習的狀態，這裡就發表一下個人想法，也參考了曾看到的優質文章和朋友的看法。

主要從業務、團隊、技術三個層面討論，當然它並不能適用所有公司，也能可引發一些口水，而且我做的是客戶端負責人，所以僅供參考咯。

1. 業務

為業務負責就是為產品和服務負責，作為技術團隊，總要完成主要任務不是，總要把產品或服務好好的實現不是？

業務要和上級負責人統一認知，和總目標方向去保持一致，才能更好的完成產品和商業的設計與實現，否則力道有了而方向不一致，浪費體力且難以更好的輔助決策。

不同時期Leader也發揮不同的職能，初期側重從技術和項目實踐方面打通設想和打造產品，迭代和試錯，隨著業務發展，能從更合適的技術、構建、架構、業務模型等方面展開專項的工作。

目前能回顧考慮到的，關於做產品（服務），關於做事情，有這麼幾點要說：

有一個核心：設計之始或明確任務前，想好並確定一個核心或者中心目標，嚴格圍繞目標轉，最益先做！它並不能促進完成核心目標，是最好的砍掉理由，真沒有那麼多資源可以用！
功能與業務：我要求團隊個人應該對業務負責，而不是功能或代碼。如果說功能是基石，而業務才是「生命」啊！功能與體驗等「有機」組成為業務。
要理解業務：整個團隊得深刻理解業務，尤其Leader更要首當其衝，仔細評估產品原型、交互設計，我們是關鍵人物先過初稿確定技術、運營可行避免浪費集體的時間，然後所有相關人一起過。
保持節奏感：目前採用項目拆分為周目標為核心措施。個別事情以天計，少數事情比如修緊急bug以小時甚至更小單位計。
服務可用性：我們是通過預發、灰度測試、可回滾等措施來控制發布質量，保持較高的可用性。
忠實用戶群：集部分優質用戶入群，保持溝通，挺重要的，微信群雖然是當為首選但是群功能有點弱，我的開源項目主要用QQ群，也比較坑哈哈。
反饋與數據：反饋和數據都是驗證結果的最好的參考之一，追尋反饋背後的動機很重要，研究用戶路徑、功能使用等數據輔助確定下階段任務。
低成本試錯：盡量以最低的成本來試錯，避免大量浪費資源，不要過早優化和擴張，先單點或AB測試，驗證過後再鋪開。
方法與方向：很多時候方法比方向重要，好的方法可以不斷糾正方向，發布較單純的功能來驗證問題和方案，應該避免堆積功能，盲目發散方向，沒有經過驗證的方向就是假設。
創新與迭代：精益創業的MVP策略有助於大多功能性或服務性新創公司檢驗產品，而創新型產品靠產品本身和培育市場拉動需求，但都需要事實檢驗和迭代完善。
手動和自動：初期能手動解決的問題動手解決就挺好的，一開始就考慮自動化機器化可能會延誤時間，或者高成本解決了一個頻率並不高的問題。
親為和團干：沒有經過實踐驗證的事情負責人最好自己先親為，才能深切體會，形成一定感知後優化，或者交給團隊一起干。
靈感和總結：靈感稍縱即逝，總結過期不候！應該有自己的全端雲筆記，和博客。短期記筆記，長期入博客，靈感可能就在你瑣碎的一瞬間，很多東西經過三五個月一忘而光。

2. 團隊

一個公司的產品和服務，是其自身組織結構和溝通、工作方式的反映（康威定律）。

人員的架構會改變和影響產品的架構，產品一大，人分組拆開了，項目也跟著拆開了，越多人一起工作就更需要科學的流程和協作方法。所以說人和組織會決定或影響產品。

如果說初期目標是打造一個良好的產品或服務，隨著發展應該慢慢更著力於打造一個能開發良好產品的團隊。

以下幾個層面是我們去實踐的幾個點，其他沒想到的後邊再補充吧：

關於招聘：找到合適的人是關鍵，不要貪多貪大，創業公司招人較好的時機是不招就會死，注意避免青黃不接。交流技術的同時感受性格，性格不合適早點終止面試，相信直覺，年限、學校不重要，重要的是作品和能力。
明確職責：團隊應該明確關鍵人物的角色，公開規定好一個角色由誰來擔任，職責和指標是什麼，甚至可以約定任期是多久，因為角色是活的。我的主項目里有一個PM角色（協助跟蹤進度等），一個PA角色（輔助協調、構建打包等），都是主工程師兼任。
充分授權：一個完整的團隊應該有充分的決策權，角色應該有比較明確的職責，可以給建議但不要隨意干涉個人的職責或決策。
團隊協作：我的團隊就是統一IDE（idea）和構建環境，統一碼風，統一版本控制策略的。合理創建Tag、Branch，盡量規範使用協作工具。
團隊溝通：我的做法是讓隊員遇到鎖事直接和當事人溝通，重要問題反饋Leader，保持充分溝通我們每周都要有一次全體碰面會議，最好有點零食。
團隊提升：選定一個主題、此項以周為節奏，每人都要充當講師，我們客戶端團隊已經系統的學了面向對象6大原則和23種設計模式，我們android、iOS、前端一起溝通技術。
開誠布公：私下溝通為主很多時候是解決不了團隊、個人衝突的，要開誠布公的面對面談，將衝突事情一一列出，對事不對人，根據輕重緩急，綜合當前狀況給出解決方案，是公司是全局是狀況不能讓所有人滿意，而不是誰不能讓你滿意。
前途錢途：不談錢就是耍流氓，不要妄圖用成長壓制待遇，不要總想用青春換取血汗，做得好就是要好的回報，但是也要講規矩，一般能力先到位再要求待遇，當然其實還要看你的位置可替代性如何。
回報遠與近：眼前看能力，近期看薪水，遠期看期權（股份），看好公司一般略側重期權，看空則略側重薪水。心情、成長、待遇、期權組成一個人的主要回報，Leader應明白隊員想法並努力為團隊爭取合適的回報。
一些福利：公司每天會買些水果當下午茶，像蘋果、桔子、香蕉、哈密瓜、葡萄、etc，看季節的。員工慶生蛋糕、年度旅遊、節日活動等。

3. 技術

技術負責人最好是技術水準不錯，最差也要知識面廣，否則可能導致疑難無法解決，產品不穩定。

我們從以下幾個方面做了實踐：

風格統一：團隊內統一風格、規約、編譯環境，開始是idea作為IDE，年底整體遷移到AS、Gradle環境開發和管理。
鍛煉思維：集體學習6大設計原則和23種設計模式，理論結合實踐，更深刻的認知面向對象的設計理念。
技術提升：優先完成業務，此項以更長時間為周期，在項目不那麼緊張時開立個人技術項目，我們選一個方向量化形成博文或者小類庫，Leader支持並協助隊員完成，培養人才，各有所長。
關於類庫：盡量選擇穩定專註、知根知底的框架，如果沒有，那就選擇知名開源框架，仍要深刻研究其代碼。
關於業務：我們客戶端業全部的務統一構建在SDK子項目中，和View剝離，便於切到多種終端設備。
關於架構：我們核心方向其實全部使用我寫的類庫，由通用組件、網路、非同步、資料庫等組成通用的底層項目，叫做LiteSDK，任何App幾乎都可以用它，可謂用之四海，它是可拆解並獨立發展的，剛才提到的業務SDK項目是基於它的。
學習前沿：儘力去接觸新技術吧，我們今年精力放在業務上了，2016年的技術方向涉及了React Native、rxjava、代碼生成、自動構建等，雖然已不是新技術^_^。

我們第一個版本App五臟俱全，登陸、簽收等業務功能、二維碼掃描、友盟統計、圖片載入、下拉刷新等視圖開源項目，但安裝包體積只有800K，極致的小。

兩款App友盟總錯誤率目前仍在0.00%（線上App版本的錯誤列表還是有零星的bug列出，難道友盟總bug率計算有問題么）。

非常感謝團隊里的每一位同事，團隊一起完成了這些，今年要有更好的進步和成長！2016加油。

哦對了，如果你的公司也有android app端，可以考慮下我的開源類庫：http://litesuits.com?f=zh

也能做到極致的小吧，還挺穩定高效嘿。

前邊 @馬天宇和 @湯濤講得很全了，我就胡扯一點個人感受好了。

利益相關：4年創業經驗，目前帶手機遊戲前端團隊。

1. 在創業公司，最重要的是人，其次才是團隊

先就說說這個有負能量的事情。有多負能量？先看看這個：遊戲邏輯程序員的成長出路？ - 曾嶸的回答

其實本節的標題可以進一步理解成：必須要有足夠好的人，才能通過團隊負責人的努力得到一個合格的團隊。現在這個時代，不是一個人牛逼就能成事兒的。

當然，你可以自豪的說：以我的能力，一幫烏合之眾（《烏合之眾》讀書筆記）也能被我帶好了！這種豪言壯語我也說過（哦，是想過），而現在我只能呵呵一笑：兄弟，U NB,U UP！

看看上面那個負能量的例子，想一想：你幹得了所有的活兒么？你有精力解決所有的BUG么？你有能力完成所有的流程么？你的工作是讓團隊幹活，不是自己幹活。

我們團隊內部會議上，我問大家：一個程序員最重要的 feature 是什麼？有兄弟說是出活。而我認為程序員不僅要能出活，還要高效地出活，出精緻的活，不達目的誓不罷休地折騰自己，變著法兒把自己玩壞。

團隊打造出來始終是要做事的，技術團隊需要高效地完成業務部門需要的結果。高效的團隊需要流暢的合作、清晰的流程、明確的目標、嚴謹的標準，而要準確無誤地達到這些要求，就需要 足夠好的人。

每個人在團隊中都有自己的位置，如果碰到了比較弱的人，TA 就會成為團隊合作中的那個短板。我絲毫不懷疑我能把 TA 帶起來，但問題是 TA 在成長的同時，團隊中的其他人也在進步，你需要在 TA 身上花多少精力才能保證 TA 的成長速度呢？弱的人總有弱的理由，強的人自有強的原因。還是把有限的精力，投入到能更快成長的團隊成員身上吧！

所以，團隊中最重要的問題，不是你有多牛逼，而是團隊中的其他人有多牛逼。負責人需要解決的問題就是讓這群牛逼的人在一起能更牛逼。避免弱的人進入團隊的最重要的一關就是招聘。那我就來說說招聘。

2.1 不怕悶，就怕不騷

都說程序員很悶，所以才有上面 @財神說的賺夠了錢去嫁程序員的段子，畢竟話少錢多死的早的老公並不是到處都有。但優秀的程序員往往是悶騷的。當然，明騷的程序員也不是沒有，只不過TA們容易把大部分精力都花在騷上，這也不好。

悶騷的特點在面試的時候就能看出來。一個優秀的悶騷，面對TA感興趣的話題，根本不用我提醒就能滔滔不絕講下去，那是攔也攔不住的，二面分分鐘超過兩小時，而且我都插不上話！我經常用這種方法在面試的時候偷懶，既能少回去開會，也能多了解這位同學的方方方面面。

前幾天剛面了以為只悶不騷的同學，這位同學有一種逆天的技能，就是所有的句子都是短句，所有的回答都是封閉性回答，所有的談話都不展開。即使是我的開放式問題，他也能轉換成封閉式問題然後給一個短句答案。我舉兩個他回答的經典語錄：

問：你之前做頁游的時候寫了兩年多AS3，對語言算是比較熟悉了。你最深的感受是什麼？

答：加班。

我：……

問：你為什麼熱愛程序員這個很有前途的職業？

答：我能比較積極的完成工作，並能保證工作的質量，所以我熱愛程序員工作。

我：……

問：AS3、C++和Go語言你都用過，對比一下它們的特點？

答：主要是定義不同，Go語言的定義需要大寫。它們的 API 不太一樣，其他都差不多。

我：……

當然，上面說的是一些極端情況，大部分程序員還是挺本分的，中規中矩，不溫不火。作為技術團隊的負責人，在招聘中需要睜大眼睛分辨這類大多數情況，保證不漏過一個可以培養的騷人，也不能招入一個沒法培養的弱人。

在我看來，悶騷的程序員可能有下面幾個特性：

1. 自信

2. 挑你的刺兒

3. 有自己的想法

4. 不願和你妥協

5. 知道如何拒絕

上面的特點可以說是極騷，下面的是普騷：

1. 幹活快

2. 喜歡啥都接著

3. 有記錄，有安排

4. 學習快

2.2 面試的兩級

要篩選出足夠好的人，面試一定要慎重。我曾經就因為太想找到「能幹活的人」而吃了許多苦頭。我碰到過幹了一個月從不加班等到發薪水那天晚上加班到21點薪水到賬就馬上刪除代碼來要挾我們的；也碰到過受不了一點批評摔門而去的；還碰到過使用物理技能攻擊公司 boss 然後威脅 format d: /P 的……一些事情到現在想起來還會呼吸急促，大腦缺氧。

上面這些人中，有從360公司回來的北漂，有十幾年的程序員，甚至有公司的創始員工……

所以，在面試層面多花點功夫是值得的。面試至少要有兩面。下面是我的老大給的關於面試的要求：

一面：
著重考察技術能力，不必涉及文化、性格、價值觀和軟技巧。但一面面試官可反饋這方面對候選人的主觀印象。
二面：

事業心。是否積極主動追求事業（技術）上的成功，有什麼樣的事例（或者成績）可以證明？是否有家庭、情感方面的困擾阻礙候選人全身心地投入工作？能否接受合理的超時間工作和學習（無論是在公司，或者在家利用業餘時間學習或者工作）？

與人溝通交流和合作情況。可以問問他如何評價前領導、同事，有什麼業餘愛好，參加什麼集體活動，在集體活動中做什麼。

職業生涯規劃。對Junior員工可以接受他沒有清晰的規劃。考察他留在武漢的意願，從事遊戲行業的意願，工作穩定性。

住址。除特別優秀外，不建議招上下班太遠的人。

我們招的人，一定要有優秀、過人之處，有較強的學習能力並能在我們的環境下持續成長，而不僅僅是能應付眼前的工作。有三年工作經歷的人，就一定要有三年或者三年以上的工作經驗和能力。請大家謹記。在面試時，一定要帶著這個問題：這個候選人如何融入到我們現有的環境，如何成長，如何適應未來的變化？

其實就算是嚴格執行上面的建議，也很難杜絕所有的問題。曾經有一個十年經驗的程序員，經過了兩輪面試，表現都很好。但工作起來和面試感受完全不同。沒過多久他主動提出了離職，給出的原因讓人匪夷所思，就是覺得工作上很「彆扭」。HR 無法接受這樣的離職原因，我們也嘗試了各種方式努力挽留（包括解決他目前的工作問題，承諾即將到來的適合他的工作任務等等），依然無法得知他離職的真正原因。不過，上了二十年小學的柯南同學說過，如果排除所有不可能的情況，那麼無論如何不可相信，真相就是真相。

十年的工作經驗，不一定就是真是十年。有些人是做了十年不一樣的事，有些人則只是把第一年的事情做了十年。對於上面的這個情況，我覺得在我當時的能力下無可避免，可亡羊補牢，猶未晚矣。現在我至少找到了兩個解決辦法：

1. 充分求證

對簡歷進行充分求證。了解每個項目的始終，並通過其能提供的原同事信息進行求證。《注意！有人在盯著你》一書中提到了一些關於背景調查的問題，也可以問一下。多花點時間總比最後承擔後果要好很多。

2. 相信直覺

比較糟糕的員工，在我第一次和他們見面的時候，我的直覺總會告訴我哪裡有些不對。但之後，我的理智又告訴我現在是急需用人的時刻，這人經驗豐富，能把項目向前快速帶動……此時直覺就被理智給壓制了。最後出事的時候，往往發現給項目帶來的影響比之前還要大許多。

人的直覺往往非常准，但也經常被理智所否定。大腦總會認為理智比較靠譜而直覺比較玄乎，而事實似乎正好相反。直覺是在你的感官觀察到這個人的第一印象的時候做出的，其實在用大腦思考這個人的時候，你的感官已經對這個人的一些細節做出評價了，一旦有不符合常理的地方，你的直覺就會報警，而此時你的大腦還沒有開始視覺分析呢！

下一次碰到不知道該不該錄用一個人的時候，嘗試一下相信自己的直覺吧！當然是在充分求證之後！

3. 興趣分類

除非是超人或者有別的重要目的，否則大多數人都只願意做自己感興趣的事。程序員則更是如此。因為悶騷的特性，TA們的興趣點大多比較集中，或者說在一段時間內比較集中。這樣，要TA們能高效的出活，就要找對路子。這個路子就是抓住TA們的興趣點。

我會保持每季度都能和團隊所有成員一對一溝通一次。平時大家的能力，特點都已經在日常工作中了解得八九不離十，但內心的想法大家並不會全告訴你。而且一對一溝通中，我可以全面了解團隊成員內心中的想法，一些平時忽略掉的細節也會在這種溝通中被放大，同時一些平時工作中不方便說的事情，也可以在這次溝通中進行全面交流。

這種溝通是非常重要的。我在溝通中了解到了大量平時無法觀察到的問題，甚至是可能得到對一個人完全相反的印象。我更願意把自己的職責歸結為如何幫助團隊成員成長，所以在溝通中我說的最多的就是：「我能幫助你做什麼？」

下面這次溝通匯總是我擔任 Leader 之後三個月不到時進行的。這次談話過程中，我制定了一些特定的技能點問題，談話結束後，再整理大家的回答，對每個技能點進行打分。下面是這次溝通的結果：

根據這個結果做出下面三張圖表：

興趣點分布

這個圖表代表了每個人關注的興趣點，數量越多則代表這個人越有發展的可能。需要注意的是「無趣」和「Lua」這兩個點。

「無趣」代表其認為目前的工作無法給其帶來快感。這種感覺比較普遍，集中在3年以上工作年限，以及對技術有理解和追求的程序員身上。

「Lua」則代表多數人願意往 Lua 腳本化方面轉換。這也符合目前 C++ 為主的技術特點。

重點指示

大部分的人的主動性是不錯的，少部分人有很強的自我推動力。C++底層是老本行自然分數高，Lua 也在情理之中。但有趣的是伺服器技術和 3D 技術的關注度。另外少數人有難得的產品思維和管理思維，值得培養。

潛力

該表能在一定程度上指出個人潛力，但由於數值的廣泛性缺失，並沒有決定意義。

做產品久了，程序員的眼光會局限在某一塊，糾結於產品邏輯，少有技術創新。為了維持團隊穩定，保持推動力，我根據團隊成員的興趣點制定了興趣組計劃，把整個團隊按興趣方向分成了3D、HTML、Lua幾個興趣組，並著手申請現有項目的HTML5移植和腳本化。

這次溝通的結果就是促成了興趣組的建立。興趣組對團隊成員是一個重要的推動，同時也是對客戶端開發培訓工作的方向性指導。

到了年底，我讓大家寫2016計劃之後，又針對TA們的個人計划進行了一次統計：

興趣點的人員分布

人員的興趣點分布

可以看出，由於是計劃，大家放得比較開，各種不同的想法和各種零碎的細節都出現在計劃中，下一步，就是把這些碎碎念都能融入到興趣組計劃中。興趣組已經不再局限於技術，寫作、讀書、健身都可以是興趣的一部分，這類有生活氣息的興趣組與基於技術的強連接興趣組相輔相成，更能加強團隊成員之間的聯繫交流，保持團隊活力。

4. 讓團隊成員信任你（2016-01-19更新）

都說文人相輕，其實程序員相輕地更厲害。作為一個「空降」的 Leader，用什麼方法讓你的團隊成員信任你，從而提高工作效率？

很多空降的傢伙們喜歡直接推翻前任的設計重來一次。我不否認這是一種不錯的方式。同樣的，這還是一種最偷懶的方式，一種最輕鬆的方式，一種最高效的方式。

可惜我不能這麼做。我們團隊負責的4個項目，每個項目都在線上跑。每個項目都抽不出人手來調整現有架構。何況，4個項目的架構還都不太一樣。對這樣的架構動大手術，稍稍不注意就會造成大的問題，影響收入。而我初來乍到，還沒有得到團隊成員的認可就進行大的改動，大家心裡也不會認同。如果得不到全力的配合，就會事倍功半，把好事辦砸。

我採用的方法是，找到一個痛點集中精力解決掉。這個痛點應該讓大家都感到棘手（凸顯你的能力），使用非常頻繁（大家會記住你），很難修改，比較複雜，但修改它（或者重寫它）不能對現有的項目有太大的影響（安全），不用動用太多人力就能搞定（最好是你自己搞定）。

這個痛點就是項目的打包工具。舊的打包工具是一個設計得相當複雜的系統（其實就是沒有設計），該系統由多人（5+）完成，多人（10+）對其進行了具體的實現和修改，最後的情況就是沒有人知道這個系統的完整設計是怎樣的。系統大部分由 bash 寫成，在 windows 上依賴 cygwin，體量如下：

我閱讀了所有代碼，繪製出了系統的架構圖：

這套架構違反了許多設計原則，但正因為其複雜，最後沒有人願意改它。

打包的同學每接入一個 SDK，就需要寫幾百行 bash 腳本，這些腳本從別的 setup.sh 文件複製過來，再進行修改。這導致如果有了更好的實現，也只可能在最新的腳本中才可以用上，沒人敢跑回去改老的腳本。

這樣一個系統整合符合我的選擇。我花了一些時間詢問所有和打包系統相關的人，弄清楚了整套系統的結構，用 Python 寫了一套全新的打包工具，這套工具不必再依賴 cygwin 。新的打包系統設計了一套繼承和覆蓋流程，讓負責發布的同學可以不用寫腳本，直接通過配置文件就能支持新的 SDK。新的配置文件基於 ini 格式，測試同學可以更易懂地進行配置。由於有完整的設計文檔和使用文檔，再加上使用了配置文件模版，無論是修改還是擴展都很方便。

項目中很快用上了這套工具，事實證明打包效率的提高是非常明顯的。我在每個項目中找了一位同學負責該工具的後續維護，我就全身而退了。

後面的事情證明，這套工具不但帶動了大家主動學習 Python 的熱情，還增強了大家對文檔的認識，同時我的設計思路和執行方法也得到了大家的認同，後面對工具、框架、方法的推動就比較容易了。

5. 培訓計劃（2016-01-19更新）
在和團隊成員溝通的過程中，我發現許多人並不是不夠努力，而是不知道往哪個方向努力。或者說，不知道應該如何努力，才能更快地成長。有些人認為已經掌握的技能足夠解決目前的問題，就開始懈怠，或者開始焦慮。大家不知道自己處於技能樹的那個級別，也不知道下一步應該爬往哪個方向。

於是，培訓，尤其是系統的培訓計劃就相當重要。我根據手機遊戲客戶端技術的特點編寫了一個技能樹：

然後，根據這個技能樹，我設計了一套完善的方法支持技能樹的實施。

5.1 質量控制系統?

要保證每個開發者對技能點的理解都達到相同的高度，必須嚴格確保技能點的實施質量，以及培訓的質量。設計中有這樣幾個級別來控制質量：

5.1.1 守門員(Gatekeeper)?

守門員是培訓質量和代碼質量的最終把關者，整個技能樹的實施質量取決於守門員的能力。整個系統設置 1~3 個守門員。

5.1.2 合作者(Collaborator)?

在技能樹繁茂的枝葉（知識領域）中，不是所有的人都能對整個體系完整深入地進行了解。在團隊的所有的程序員中，總有人對某些枝葉特別熟悉，這些人就是合作者。

合作者是某個領域的專家，他們需要根據技能樹中的枝葉制定這個領域的培訓計劃，需要審核具體領域實施過程的代碼，並保證代碼的質量，保證培訓計劃的完整深入。

5.1.3 執行者(Executor)?

執行者可以是合作者，也可以由合作者來指定。執行者負責具體的代碼編寫和培訓授課。合作者負責執行者的培訓計劃的質量。合作者是執行者的導師，執行者是合作者的接班人。

在技能樹的實施過程中，執行者負責具體的培訓授課，以及具體技能點的質量監控，是整個技能樹實施中的 最大受益者 ，是整個技能樹實施過程中 成長最快的人 。

5.1.4 學習者(Student)?

在一個技能點的實施過程中，學習者需要面對培訓做出反饋，將培訓中學習到的知識用於工作中。學習者是整個技能樹實施的 最直接的受益者 。

學習者的身份不是絕對的。在某個知識領域的學習者，可能是另一個知識領域的執行者、合作者，甚至守門員。這取決於學習者的成長鏈。

5.2 培訓和執行?

技能掌握和 Level 提升需要完善的培訓計劃和強大的執行力。培訓計劃的制定流程如下：

守門員確定合作者的知識領域；
合作者基於現有項目選擇開始點；
合作者選擇執行者，共同制定詳細的培訓文案和計劃；
在執行開始之前，使用培訓來統一執行標準，由執行者進行培訓；
在執行階段，執行者、合作者需要通過 Code review 和其他方式確保執行效果；
合作者確定該領域培訓成功，總結會議；
進入該知識領域中的下一個技能點，繼續上述流程。

對於技能點的知識領域的選擇，必須遵循以下三個原則：

盡量在現有正在進行的項目中選擇培訓內容，確定計划起始點。現有項目的框架、功能、公用庫、流程等等都可以起始點；
若1不滿足，則應考慮現有項目的開發方向，基於現有項目的升級版本確定計劃的起始點；
若2不滿足，則起始點選擇必須基於可實際操作的項目，不允許空中樓閣，不允許只談方法沒有實戰；不允許試驗性的無意義項目；所有選擇的項目必須有實際意義；選擇的項目，要麼可以直接作為一個新項目的起點，要麼可以作為舊項目升級的方向。

5.3 培訓類型?

技能樹的培訓分為三類：

5.3.1 所有開發者都需要掌握的?

例如 markdown 和 sphinx 這類培訓。這類技能非常簡單和容易掌握，而且在今後的工作甚至生活中，可以為每個開發者帶來好處。這類培訓會安排詳細的練習；

5.3.2 所有人都需要了解，但不需要完全掌握的?

程序員分為兩種，一種喜歡偷懶，偏愛使用各種工具或者自己開發工具偷懶，另一種則喜歡實現功能，按部就班地開發。

cmake 這類培訓就是能讓這兩種程序員都達到自己目的的培訓。

對於第一種程序員，聽完課程之後就會自行去搜索更深的信息，進行了解；而對於第二種程序員，培訓需要達到的效果是他在下次看到 CMakeLists.txt 的時候不發怵，碰到 CMake 錯誤的時候能知道怎麼找到相關信息解決即可。這類培訓不會安排練習，或者安排不強制的練習。

5.3.3 所有開發者都要嚴格熟悉的?

這就是和項目的開發流程、開發框架相關的內容。對於這些內容，許多開發者並不熟悉，由於沒有統一的培訓，程序員們完全是按照自己的本能在開發，這導致了代碼風格不統一，代碼質量不一致，重複早輪子等許多問題。這部分的培訓，是和 入職培訓 類似的內容，目的就在於解決上面提到的問題。

lerna 框架的系列培訓，就屬於這類培訓。這類培訓會嚴格安排聯繫並檢查，保證學習者對這些內容的完全掌握。

5.4 層層遞進的培訓進程?

當學習者的水平並不在同一個層級的時候，技能樹培訓系統只能進行「淺嘗即止」
的培訓。只有將所有學習者的水平都拉高到平均值之後，才可能進行更深入的內容培訓。到那個時候，培訓不應該是「大鍋飯」
式的，而是可能多個主題同時開講。到那個時候，每個學習者也都會了解了自己的特點，確定了自己的成長鏈，並安排好了自己的成長方向。

上面這部分內容是客戶端技能樹一文的摘錄。

所有的培訓內容、文檔、PPT 和源碼都是通過 git 管理的。主要文檔使用 Sphinx 寫成，所有團隊成員一起維護，所有的培訓都有記錄。絕大部分培訓都有練習。每個人都可以是合作者、執行者和學習者。

採用這種方式，我可以直接在技能樹培訓的過程中，順便把入職培訓的內容也做了。後面進入團隊的新人，可以直接 無縫接入 這套培訓系統。

因為培訓的內容都在內網，這裡給出兩張截圖：

6. 拉動其他團隊（2016-01-25更新）

在遊戲公司里，前端團隊是非常特殊的存在。前端是產品從設計到成果的最終一環，玩家能直接體驗到前端團隊的成果。一個優秀的產品，必須是由一個優秀的前端團隊打造出來的。

我一直認為一個優秀的手機遊戲前端程序員必須做到以下幾點：

能指導美術團隊按照客戶端的優化需求切圖；
能給UI/UX團隊提出靠譜的修改建議；
能根據技術特點與商務團隊溝通的SDK接入策略；
能根據各OS平台特點和運營團隊討論推廣策略；
能根據客服團隊需求設計更方便的反饋模塊；
能制訂通信編碼協議（必須是客戶端制訂）；
能與服務端團隊討論性能和優化策略；
……

做到這些並不容易。前端程序員不但要熟悉美術工具，對各種媒體格式了如指掌，還必須了解UI和UX的基本知識，並將其運用到最終產品中；程序員要了解商務和運營的各種術語，要學會查看各種運營報表，從中分析出產品在前端方面的問題；程序員還要熟悉各種網路通信協議，要了解服務端開發的特點，要熟悉資料庫、伺服器性能，熟悉移動網路的特點，才能做到和服務端團隊協同配合提升遊戲的網路體驗。

可是，大多數客戶端程序員都不擅長做上面的工作。然後我可以反其道而行之，讓其他團隊了解一些客戶端的工作。

我發現其他團隊在制訂操作方案的時候，並沒有過多地考慮手機遊戲的特點。這並非是由於他們不想做到更好，而是不知道我們前端團隊能做到哪一步。和前端團隊一樣，其他團隊也是對自己團隊的工作範圍熟悉，對其他團隊的工作不熟悉。如果我們可以讓大家互相多了解一些，那麼在涉及到多個團隊協作的部分，效率就會更高。

例如界面切圖工作。美術同學切圖可能不會考慮共享資源的重用，以及scale9等技巧，由於不了解界面在遊戲中如何分割，圖像文件的分類也不一定合理。而由於客戶端程序員對PS等工具並不熟悉，也無法提出合理的修改意見。最終導致的結果就是美術素材浪費了內存和增大了最終包體積，或者客戶端團隊需要對美術資源進行二次修改才能使用。

要提高這部分工作效率，我採用的方式是讓了解美術的前端程序員和美術團隊一起工作，了解具體的切圖流程，在切圖過程中確定一些常用的規則，並讓美術團隊了解這樣做的目的。一來二去，美術團隊對客戶端的需求會越來越了解，資源返工的可能性就越來越小了。

再比如，商務團隊在和渠道談SDK接入的時候，會涉及到一些技術問題，而渠道方負責合作的人員往往並不是技術人員，此時和我們客戶端團隊對接就會出現問題。如果商務團隊了解一些接入的基本規則和技術術語，在和渠道方合作的時候，就能夠更加得心應手地處理溝通問題，為客戶端團隊節省了大量的溝通時間。

7. 團隊文化（2016-01-25更新）

文化有非常濃厚的個人烙印。一個公司的文化，一定有濃厚的創始人風格。而一個團隊的文化，則反映著Leader的特點。

在創業時，我從無到有完整地打造了公司行政、人事流程和公司文化。而現在，我更希望按照公司特點打造一個高效的客戶端團隊。

文化是對共同價值觀的認同。沒有共同的價值觀，也就沒有共同的文化。我希望的團隊文化必須是輕鬆的，有趣的，發展的，共贏的。

團隊文化的建設即是實實在在的，又是潛移默化的。我們可以從日常的團建工作中找到突破口。所有這類工作，必須讓所有人一起參與。比如我們團隊上一次團建的內容這就是這麼定下來的：

這是我發的第一封開腦洞郵件：

Hi all:
我們客戶端團隊要搞一次團建活動，請大家開一下腦洞。
唱歌就不必了，一群爺們木有妹子。
吃飯啥的有點 low，做備選方案吧
內容要有趣，大家都想參與
比如攀岩啥的，大家沒搞過的在預算內的都可以搞搞
客戶端共xx人，公司預算每人xxx，我再出xxx，大家按這個來計算。若再超過，大家 AA 多出的部分。
今天下班前，每人必須回復。
沒想法的請回復：「沒想法」，然後 AA 的時候出2倍。

期間，給一些合適的引導：

Hi game client:
LHJ製作人JY同學組織了一群烏合之眾試圖與我們在網吧一爭高下，請大家準備好，給他們點 color 瞧瞧，讓他們知道遊戲是用鍵盤敲出來 DI ！！！！
@JX，是不是可以設計點彩頭哇……

經過了十幾輪郵件轟炸之後，結果變成了這樣：

Hi all:
投票結果已經出來了，見附件。
可以看出，69%的同學選擇網吧遊戲，46%的同學選擇吃飯。那麼我們這次就搞網吧遊戲+吃飯的團建吧！運動也有不少同學選擇，我們在下次團建考慮。
時間上，由於必須在 12月31日前完成，我選了3個時間點。54%的同學選擇了聖誕節當天，那麼我們就定這個時間。

團建本來是輕鬆的事情。但開放式討論必須有人收尾。就像我初中時團支書說的那樣：既要民主，也要集中。按大家的興趣點把時間地點人物確定，整件事兒基本上就可以愉快地開始了！這次團建大家都是蠻Happy的：客戶端團隊聖誕團建回顧--我們的快樂與大家分享！

團建僅僅是團隊文化建設的一部分。更多的文化建設是潛移默化進行的。例如在上面提到的培訓過程中，合作者與執行者的交流，每次授課之前的小範圍試講；再例如根據每個程序員的特點安排不同的工作，安排不同項目之間的經驗交流；還有讓團隊中每一個成員都了解自己的位置和發展方向，都知道碰到某些問題的時候應該找哪位成員詢問等等。這些看似平常，但都是文化建設的重點。

團隊文化建設的前提，就是Leader要充分了解團隊成員，知道每個人的喜好和特點，還要保持鮮明的個人風格，並把自己的風格與團隊成員特點，公司風格融合起來。這樣建立起來的團隊文化，才是經得起考驗的，才是能幫助團隊成長的，才是能和公司一同進步的。

8. 積累（2016-01-27更新）

想要做一個稱職的 Leader，積累是至關重要的。

在技術經驗上，你的積累能夠幫助你的團隊快速解決棘手的問題。當然，這是技術 Leader 的基本功。我說一點技術之外的積累。

8.1 談話

一對一談話是了解團隊成員想法的重要手段。上面談到的對團隊成員興趣的了解，大多數都是通過一對一談話來完成的。談話的內容要實時做好記錄，並做好對每次談話的結果分析。

下面是我做的一個典型談話分析。包括談話內容，對於普遍情況的總結，以及對於特殊情況的描述，最後包括解決這些問題的可選方案。

只有記錄了每一次談話的內容，才能在下次談話的時候根據原來的記錄做出合理的比較，看看哪些人進步了，哪些人的方向變化了，然後繼續尋找更合適的方法。

8.2 人事

人才和面試，是團隊成長和建設的重中之重。上面我專門用了兩個獨立的章節來講。

我對所有經手的面試和離職都會做好記錄。在有員工離職時，我可以通過對比分析其他員工的離職原因，看看到底是因為幹得不爽還是錢沒給夠。每個優秀員工的離職，對團隊都會有一定的影響，對我的工作也是一個考驗。如果能夠在離職之前發現問題所在，有針對性的進行工作的調整和團隊建設，無論對團隊來講還是對離職員工來講，都是件好事。

所有的面試資料中都包含簡歷資料，在一個新員工入職後，我可以通過 TA 的表現，慢慢去印證當時的面試有哪些偏差，是否出現了判斷錯誤，把一個優秀的求職者放棄了？還是看走了眼，招入了一個平庸的人？

8.3 GTD

大多數公司都會使用郵件來管理和發布工作。但郵件並不是進行工作管理的好工具。為了方便分析和整理，我會把每天的工作記錄下來。這些工作包括一些重要的郵件，討論和會議，還有一些就是日常的雜事。

有了每日工作記錄，就很容易寫出周報和月報並作出總結。一些比較獨立的事件，並不放在日報中，而是將它們進行單獨記錄，再以鏈接的形式將其加入到每日工作記錄中。每月結束的時候，回顧一下這些記錄，對下個月的工作安排有極大的指導意義。

9. 結語

本來準備隨便寫寫的，一不小心就寫成了工作彙報。談不上經驗，就是胡扯而已。就像我在遊戲邏輯程序員的成長出路？ - 曾嶸的回答裡面說的那樣：

如果你所處的是有 HR 有網管有安全部門有運維部門有掃地大媽的公司。就當我放屁好了。

我現在就在有 HR 有網管有安全部門有運維部門有掃地大媽的公司。

所以你們就當我放屁好了。

2016-10-13更新：

評論區裡面 @於宏慶提到的書，我已經寫了讀書筆記：【讀書筆記】聘誰，有興趣可以討論。

===== 下面絕對是廣告 ======

曾嶸胡扯的地方

http://weixin.qq.com/r/lENpcUXEbhgRrQES9xaG (二維碼自動識別)

黑斑馬團隊

http://weixin.qq.com/r/LTkQCPjEraXSrbxr92w- (二維碼自動識別)

對這個問題有些興趣，不請自來。

先審個題：怎麼做好互聯網公司的技術團隊負責人？

首先技術團隊負責人這個表述可以有多種理解，我將其分為兩種：一線Tech Leader與其他。Tech Leader往上可以有一些層級，直至CTO, 取決於公司扁平程度與規模，不同的角色其實需要思考解決的問題是不一樣的。

其次題主特意提到了互聯網公司，我在傳統軟體行業與互聯網行業各自摸爬滾打過幾年，跟過不同風格的「老大」，見過不少優秀的Leader, 自己也在不同行業有過帶技術團隊的經歷。以我個人的感受來說，互聯網與否，對技術團隊負責人的要求並沒有太多區別，區別來自於公司或團隊文化，來自於技術對於公司而言的重要程度。

僅就如何做好一線Tech Leader談一下我自己的看法，很多地方自己還做得不夠，與大家共勉。

馬天宇的回答很好，其劃分是比較合理的，基本上做好業務、團隊、技術三個方面就很不錯了，我換個角度補充幾點：

業務

1. 要充分理解業務，不僅理解自己的產品，也要關心競品，業內趨勢，如果能對趨勢有自己的判斷最好不過了，沒錯就是要把自己當半個PM。

2. 積极參与業務目標的擬訂形成過程，比如每個季度或每個月的大體規劃，在充分理解業務的基礎上，你就可以更有底氣地發表自己的看法，確保在大的業務方向上，團隊不至於走太多彎路。

3. 一旦目標擬訂，就要盡量與之保持一致，唯有整個團隊形成合力才能最大化戰鬥力。

4. 在具體執行層面，比如細化到每個迭代的具體任務時，要思考如何利用現有資源合理安排，還是以業務目標為優先，計劃做的這個feature是不是與目標一致？對關鍵目標的達成有多大幫助？就是考驗你何時Say Yes，何時Say No。然而這並不是要你拍腦袋，而是要根據自己的專業素養，綜合考量權衡事情的重要程度與開發成本。尤其是要敢於Say No, 很多時候不做某件事，比瞎折騰一頓要更加重要，別總怕大家沒活干，除了做feature, 有意義的事情還有很多，微信就是一個典型的例子，不難想像他們肯定拒絕過非常之多的花哨feature。

5. 業務數據的跟蹤與透明。產品的激活，留存率、活躍，評分，crash rate，各種feature的轉化率等等，這些產品的關鍵指標，作為Tech Leader也要關心，不僅如此，還需要共享給團隊全員，大家每天不停地做著一個又一個feature, 做完上線之後一個一個石沉大海，貌似跟我沒關係，這種氛圍很糟糕，自己做的東西受大家歡迎，成就感是很棒的。產品各項關鍵數據飆升，大家會跟打了雞血一樣。我聽說一些團隊直接把產品的關鍵指標放到電子屏幕牆上，掛在公司顯要位置。然而因為一些你懂的原因，很多公司產品的關鍵數據是嚴格保密的，但我們仍然應該在可行範圍內做到儘可能的公開透明。

團隊

1. 首先我覺得最重要的，是在條件允許的範圍內，保證團隊成員的質量，雖然常說一手爛牌也要能打好，但誰都想要兩個王四個二吧。現實情況是，在大部分情況下團隊成員都是已經決定好的，給我們選擇的機會不多，但在補員的時候，還是有機會調整的，其實就是在說招聘，關於如何做好招聘話題很大，一個關鍵原則就是新來的不能在團隊中位線以下，否則團隊質量會逐漸下滑至失控，後面想要再做提升調整，耗費的精力會大得多。關於招聘我有個回答大家可以看看：

面試時，問哪些問題能試出一個 Android 應用開發者真正的水平？ - 湯濤的回答

2. 團隊成員一旦確定，團隊建設的重點要放在如何提升大家的水平上，這不僅是每個人所期望的，也是一個Tech Leader的職責與擔當，不能幫助大家提高姿勢水平，也就是失職的Leader。如何做好這點，有幾點建議：

1）首先要充分了解每個組員，包括大家的專業技能水平與性格特點。

2）針對每個人，要定期的1對1談話，了解大家對自身、對團隊的期望。

3）根據每個人自身的期望，以及你自己對他的了解，結合現有業務，給大家制定合理的目標，目標不宜太大或太小，跳起來剛好夠得著的那種。目標的制定過程也是要與他單獨溝通確定，尊重對方的想法，可以在定期績效考評的時候做這些事情。

4）每隔一段時間的1對1談話中，與之回顧之前目標的達成情況，對他的工作進行評價，提出表揚或改進建議。

3. 除了給每個人專門擬訂的計劃外，團隊還應該有一些整體的方案用以提升水平，比如培訓、技術分享、集體的代碼評審會議。尤其是技術分享氛圍的建設，應該是要重點關心的。

4. 其他的關於明確職責，充分授權，團隊溝通，團隊協作，Team Building之類，@馬天宇已經提到過，我也不再贅述。我個人的觀點是：團隊里的每一個人，都應該同時具備很強的單兵作戰與團隊合作的能力，只要把人的姿勢水平提升上去了，大家合作起來就會愉快很多，經過一定程度的磨合，很多團隊管理過程中的問題，也就不是問題了。

技術

相信如果有機會成為Tech Leader, 在團隊內部而言，技術水平應該是沒問題的。關於技術可以再補充幾點：

1. 你的水平也許只是在團隊內部還不錯，在行業內如何呢？世界範圍內呢？如果對技術還有追求，不要停下追求技術進步的腳步。

2. 作為一線Leader, 不僅僅要做好團隊管理工作，代碼還是要堅持寫，時間安排上，至少要做到對半開，不然失去了對技術細節的了解，很多工作也就不好開展。

3. 時刻牢記團隊的輸出最大化才是最終目標，而並非事事親力親為，總擔心別人做不好，容易陷入微管理的困局，這是很多新晉Leader常犯的錯誤，要相信大家能做好，及時review工作，必要時給予幫助就好。

4. 思考如何提升開發團隊的工作效率，積極引入業內領先的技術方案或開發工具，保持團隊技術水平不要落後於時代。

5. 關鍵的技術問題或技術決策上，要積極發揮作用，面對技術債務，也不要退縮保守，鼓勵大家積極改進代碼質量，要有擔當。

最後想說，關於這個問題，大家心裡其實早就有一個簡單的答案：

能為大家爭取利益（有錢途），跟著你能成長、能做成事（有前途）。

最近運營了一個微信公眾號 Android程序員，主要關注Android最佳實踐，也會分享一些個人經驗在上面，如果大家有興趣的話，可以通過搜索微信公眾號AndroidTrending或者掃碼關注。

首先我們明確技術團隊是指做技術的團隊，而不是僅限於技術小組。這樣的話，技術團隊可大可小，比如說，我帶過6個人的技術小組，現在帶將近40人的研測團隊，我的老大負責整個九游（現在逼格高了，叫做「阿里遊戲」）的技術團隊，人員規模是幾百號人，大點公司的CTO，技術團隊可能是上千上萬人。

不同規模的團隊，負責人的做法差別很大，以下回答部分是參考我的經歷，部分是我自己推測的，如果大家在實際應用中應用這些技巧遇到問題，別打我哈：）

【5 ~ 10人團隊】

這就是最小的技術團隊，一般來說就是負責某個大業務系統裡面的一個子業務，或者某個大平台下的子系統。

這個問題 @馬天宇@湯濤的回答我個人覺得基本上已經很全面了，細節可以看他們的回答，我這裡特彆強調幾點：

1）負責人一定要技術強，業務熟悉，不求組內最強，但至少也要是前三的。

有的人看到這個說法後可能不以為然：「不是說要招聘最牛的人然後授權么」？

這句話本身沒錯，但用在這個團隊規模就是錯誤的，原因是什麼呢？

首先，大部分公司都有人力資源控制的，本來團隊人員就不夠，你還要區分一個做管理的，一個技術核心，浪費錢啊

其次，就算你招聘到了，這個規模的團隊大部分事務都是具體的技術和業務細節，如果團隊負責人只是負責轉發郵件、組織會議、有問題就說「你們找XXX吧」、對外不參與業務討論、也不參與方案討論，嘿嘿，你當組內人員是傻瓜呀，你當核心人員是傻瓜呀，沒有團隊成員的信任，哪裡來的領導力？

第三，就算大家表面上服你的領導（層級在那裡，不得不服），但如果有一天核心走了怎麼辦？要知道招聘一個牛逼的人，可能半年1年都招不到，核心對你不爽，一走了之，你啥都不懂，其他人也一般，這個團隊就陷入無序甚至癱瘓了。

有的朋友可能會說，那我招聘2個牛逼的人呀！聽起來很美好，招聘過的人就知道這很難，面試了幾十上百個，遇到想要的牛人就那麼一兩個，結果因為要價太高，公司還給不起：（

還有一個現實的問題，技術負責人自己技術不強，怎麼能夠找到牛逼的技術核心人員？

2）最重要的是培養下屬

@馬天宇@湯濤都提到了業務，團隊，但以我的實際經驗來看，當團隊處於這個規模的時候，團隊負責人對業務的控制力是比較弱的，更多的時候業務是由外部驅動的，比如說由產品人員主要負責業務規劃方向，或者由大業務決定子業務，技術負責人最多建議，不太可能把控；

團隊方面也是一樣，技術負責人應該去爭取團隊利益，但能否爭取得到，更多的時候看再上一層如何決策和平衡。

所以這個級別的技術負責人的主要職責是帶領團隊將安排的業務做好，並且手裡並沒有太多資源，這種情況下，組內人員能夠從負責人那裡得到什麼利益呢？我覺得最主要的利益就是跟著負責人學到了東西，得到了成長。這其實又回到了我說的第一點，技術負責人自己要強，否則別人怎麼從你這裡學東西呢？

分享我之前的老大給我們傳授的一個經驗：30%做管理，70%做技術，按照這個標準來衡量自己或者你的leader，管理投入太多可能成了項目經理角色，管理投入太少可能整個團隊就運轉不暢。

【10 ~ 50人技術團隊】

10 ~ 50人的技術團隊，基本上就不是單個子系統或者子業務了，更多是一組相關業務，甚至就是一個完整的業務了，要知道大部分創業公司技術人員可能也就20 ~ 30人而已。

這個規模的團隊的技術負責人，做法和10人以下團隊負責人的做法就差異很大了，為什麼呢？

主要原因是因為：整個團隊分成多個小組。一般一個小組大約就是10人以內（貝索斯推崇的理想團隊符合「2個披薩原理」，即一個團隊吃兩個披薩應該能夠吃飽，否則團隊就太大了）。

分成多個小組對技術負責人管理上的要求有和變化呢？

首先，你不可能關注每個人了。舉個最簡單的例子：季度溝通的時候，假設每個人30分鐘，如果你每個人都溝通一下，50人的團隊就要25小時，這意味著你基本上一周啥都不幹就只能溝通了。

其次，你不可能參與每個系統的開發了。這個顯而易見吧，50人的團隊，各種系統少說7、8個，多的十幾個都是正常的，你怎麼可能去參與具體版本的開發呢？

第三，小組間的衝突協調現在需要你來處理了。比如說，A組說我們要這樣做，B組說A組這樣不行，那最後怎麼辦？就只能靠你來協調了。

第四，需要關注整體的情況。單個小組的質量和效率或者士氣等情況對你來說已經不是最關鍵的，整個團隊整體的情況才是你關注的重點。

第五，業務好多，你不可能每個都熟悉。每個小組負責1 ~2 個子業務，整體團隊的子業務少則7/8個，多則10多個，你全部熟悉所有業務，這幾乎是不可能的。

以上這些情況的變化，技術負責人的管理方式也需要採取不同的手段。

1）劃分合理的組織結構

將團隊分為多少個小組，每個小組負責什麼業務，看起來無關痛癢，實際上是整個團隊運作的關鍵。有一個著名的康威定律（不是電視機），大意就是：產品就是組織結構的體現。

具體如何劃分，和公司的文化、傳統、規範等相關，難以給出一個統一的標準。前面提到的貝索斯的2個披薩理論可以用於指導團隊規模，我推薦團隊規模符合著名的7+-2原則，即5 ~ 9個人，因為一個小組負責人關注的人數就是這個規模，太多了關注不過來，太少了團隊做不了什麼事情。

2）培養小組的技術負責人

包括技術培養、做事方式培養、管理能力培養等，具體怎麼培養呢？你做小組技術負責人時怎麼做的就怎麼培養吧。

通過培養小組的技術負責人，然後由他們來管理和領導具體的每個人。

3）制定整體的流程和規範

整個團隊的流程、規範（代碼規範、發布規範、評審規範、測試規範、部署規範、灰度規範等）需要明確下來，各小組按照統一的規範和流程操作，盡量避免分歧和爭議。通過規範和流程的約束，讓整個團隊運轉更加順暢。

4）把控團隊技術發展和提升方向

這個時候技術負責人已經有一定的資源和權力，能夠主導一些事情了，技術發展方向和提升方向就是最重要的需要技術負責人把控的。為何這個事情不能由小組技術負責人完成呢？一是因為小組的業務開發壓力都是比較重的，沒有太多時間來考慮和實施；二是因為小組技術負責人視野和信息畢竟有限，不一定能夠識別出來。

舉個我現在做的事情為例：整個系統的結構已經很不合理，但各個小組技術負責人都不知道該怎麼做，如何協調資源，我接手後跟老大溝通，跟產品溝通，跟運營溝通，然後推動系統架構解耦的事情。

這個時候技術負責人能夠掌握薪酬激勵等資源么？看公司情況而定，我了解是大部分情況下還不會掌握這些資源，但是有一定的權力去在團隊範圍內分配資源。

【50 ~ 500 ~ 5000 ~ 50000技術團隊】

這種情況我還沒有經歷，一般到了這個級別，都是總監、總裁、CTO級別了。我覺得之前的做法也都不適應了，我想了一下，這個級別的技術負責人，可能主要是負責如下幾個事情了：

1）技術文化建立

文化看起來是個虛無縹緲的東西，但其實大部分人都能夠明顯的感覺到。例如：

你是要高薪招聘牛逼的人才，還是低薪招聘廉價人員？

你是要決定讓技術人員完不成任務就加班，還是要決定我們要少加班，盡量做有價值的事情？

你是要鼓勵大家技術提升，還是就當技術人員是苦力，女人當男人用，男人當牲口用？

當業務與技術衝突的時候，你是鼓勵技術為業務讓步，還是堅持技術底線？

你是準備培養開放自主的氛圍，還是培養等級森嚴的制度？

。。。。。。。。。。。。。。。。。。。。。。

這些其實都是文化的一部分，而且為何到了這個時候技術負責人可以做這些事情了呢？簡單來說就是技術負責人已經掌握了相關的資源和權力了。

2）公司技術平台的建立

當公司發展壯大後，業務肯定是越來越多，但這些業務所需要的很多技術都是通用的，例如：運維平台、資料庫容災系統、網路跨機房建設等，這些事情跨多個部門和業務線，除非級別夠高，一般人都無法推動這樣的事情落地。具體的案例可以參考阿里和騰訊的中間件或者平台系統。

怎麼建？其實互聯網技術發展到現在已經基本上形成比較固定的模式了，照貓畫虎，依樣畫葫蘆就差不多了，有興趣的可以看看我的專欄：專欄：BAT解密：互聯網技術發展之路

最後，細心的朋友可能看到我一直都沒有提到技術負責人要精通業務這個點。這可能也是大家有爭議的地方，有的人會認為技術負責人最後都要懂業務，甚至把握業務發展方向。以我的理解和經歷來看，技術負責人在業務這部分的積累本來就少，術業有專攻，技術負責人的業務能力超越產品和運營，幾乎是不太可能的事情，術業有專攻。當然，凡事都有例外，我之前的老大就是通才，而且每個都做的很好。但我相信大部分人資質和水平應該是達不到這樣的程度的。

我做過四年互聯網創業公司的技術團隊負責人，不敢說自己做得多好，只是分享一些體會。

這裡說的，是特定於創業階段的技術團隊，對於成熟的超級大公司技術負責人，有些是相通的，但是我相信不同多於相同之處。

互聯網公司的技術團隊負責人應該具備怎樣的能力？

嗯，可以扯很多很多，但是你應該也沒什麼興趣聽太多廢話，所以讓我說出最重要最有用的。要我說，最重要的能力，就是——自知之明。

這不是開玩笑，我見過很多創業公司的技術負責人都栽在這上面，太自以為是，以為自己牛逼哄哄，以為自己的技術團隊牛逼哄哄，結果所謂牛逼也只是自嗨，沒有滿足一個公司的本質需要。

我們現在說的是「互聯網公司」的技術團隊對吧，既然是公司的組織，一定要搞清楚公司是怎麼運作的。有這樣一個問題：一個公司，最少要幾個人？答案是：一個CEO，一個銷售，一個出納，一個會計。CEO就不用說了，銷售要把公司的產品或者服務推銷出去，公司才有營收，出納和會計必須是兩個人，不然財務就有大漏洞。

看清楚了吧，公司的最小配置里，並沒有工程師的位置，當然，對於互聯網公司，往往還是需要工程師的，但是，我也聽說某巨型互聯網公司最初的軟體開發是外包出去的，呵呵。

所以，作為技術負責人，最重要的是知道自己在公司的定位，技術負責人的主要職責是支持公司的業務，所有的工作都應該是圍繞這個目的來做的。

公司里不同職位的人有不同的思維方式和專長，技術負責人要做的，就是技術團隊和其他團隊能夠順暢溝通，提供高效的開發和支持。

當你能夠能有有一顆謙虛的心態來支持公司各個部門的團隊，很多糾結的事情都不存在。

把注意力放在如何deliver上面就不會有太大問題，最好的方式是服務好自己的下屬，他們才能高效地服務你和團隊目標。如果兩者有衝突，仍然以deliver-ability為先。

架構師形式：能寫代碼能測試，能承壓力有責任，帶領團隊打硬仗，最終上線

技術總監式：思考團隊管理，鼓舞團隊，提升效率，優化配置，兼顧部分業務

CTO的形式：對外企業交流宣傳，打造技術文化，指引技術方向，參與業務

這個文章裡面的答案都寫得很好，但是更多偏向於創業/小型企業，我就厚著臉皮拋磚引玉一下。

我說的負責人，一個團隊的負責人，我猜應該比Lead要高，這個是前提，那麼他應該做的事情其實是

1）Manage up，團隊大了，micro manage或者向下管理，基本上不可行。Manage up是首要重點，跟上頭把Vision，Mission這些基本點達成一致，同時管理他們的期望, 為團隊爭取更多的資源和發展空間。

2）Manage across, 除了跟上級索取資源之外，還需要跟其他職能部門的負責人了解好大家的期望，痛點，派好優先順序，避免資源的衝突等，一步一步齊心協力把Mission完成。

3）Manage yourself, 端正自己的心態，做負責人，簡單點說就是要把屎吃掉, 讓下面的人少吃屎，才能夠安心幹活出成績。

當然了，作為一個技術負責人，除了上面三樣，你還要持續的學習吸收新的技術和方法，讓自己在日新月異的技術環境下不落伍，然後超前，這也是一個基本點。

用互聯網思維來提升自己的技術和團隊管理能力，有錯就改，無錯加強，通過不斷迭代、試錯和總結來實現從小白到大牛的版本升級。

管好2種人，小弟和老闆，後者尤其重要

管好小弟容易理解，各種領導力、激勵的書也能裝一筐，學點理論、和有經驗的人交流、再反覆實踐

但是管好老闆就難了，別以為帶著小弟加班加點把事情搞定就行了，你要知道老闆想什麼，期望什麼，你的團隊在老闆心中的位置，你在老闆心中的位置，否則吃力不討好，得不到認可，小弟也會認為你無能

看公司情況這種問題其實沒辦法統一的回答

我先說下我的感受吧

我先後在兩家公司做所謂的CTO 為什麼要加所謂的CTO呢慢慢解釋

第一家公司國內數一數二的教育企業。注意是教育企業~我從一個底層碼農爬到CTO 這個過程就不說了。但是我總結了幾點

團隊的代碼寫的好壞真的不重要。重要的能快速出來尤其是你的直屬領導不懂技術。比如我當初直接管理我的副總裁，老頭以前是做保險的。洗腦有一套，但是對互聯網不很熟悉，更別說代碼。關鍵就看他喜歡不喜歡你了。要喜歡你~需要擴招你報名額就可以。需要給團隊成員漲薪只要報給他就行。所以團隊很好帶也很聽我的話。

還是那句話真正放手讓你去做並且相信你的老闆太重要了 ~尤其是CTO 這個角色。雖然有的時候我很反感他的想法比如不需要什麼XXX技術我直接人工解決。其實這些想法我以前理解不了現在覺得他是對的

很多公司等不得你潛心去把代碼寫好。而要的只是一個BUG 滿身的版本慢慢改進 ~要是不盈利也許等不到BUG改完就已經斷氣了。而程序員寫代碼的時間遠不如使用人海戰術成本低或者說即使從長遠來看代碼可以解決效率的問題短期來說人工更容易

另外一點在大公司做中層。PPT EXCEL WORD 這3個技能太重要了。尤其是面對不懂行的人 ~你要是能把這3個做的高端、大氣、上檔次那恭喜你沒問題了

-------------------------2016.1.14-------------------------

今天有時間了更新下

可能跟職業生涯的關係吧 ~工作8年來前後去過互聯網企業、傳統企業、教育企業、不管去哪個企業一個好的且信任你的上司真的灰常重要。

在教育公司3年里。說實話技術提升沒有多少第一年得了一個優秀員工。這基本上是加班加出來的而且還是不計報酬的加班。3年來一次都沒捨得休年假老婆生孩子就請了2天假~ 結婚也沒捨得休婚假就請了2天去老家辦了下事就繼續上班。當然在這裡說這些並不是想表達我自己如何如何了不起。

我想要表達的是遇到好的上司你就該付出十倍的努力。

公司越大尤其是你的老大不是最大的老闆。那你做很多的事情的時候就要考慮前後的因素對上很多表面工作一定要做好做實。你代碼可以寫的爛些但是你的想法你的PPT 一定要和你直屬上司溝通好溝通透。才能跟大老闆彙報。在教育企業的3年我其實見總裁的次數十個手指頭都能數的過來。但是去彙報一次少則準備1月多則準備3月~從數據分析到產品成本節約等等都要詳細描述清楚。文檔太長不行總裁沒空聽你啰嗦。每次準備10分鐘彙報就夠了 ~要說到要點。再加上你的上司給總裁吹吹風基本的資源支持就有了。

說實話在這種企業里很多東西真的沒辦法。

技術是為業務服務的，但是對於技術是第一生產力和廉價驅動力

沒有與公司共存亡的決心，一切都是扯淡。

「不要用戰術上的勤奮掩蓋戰略上的懶惰」

作為工作兩年半的職場小白，大廠測試工程師一枚，站在員工角度匿名強答一波。

大概見過五六個開發團隊技術負責人，有整個團隊快走完的，有團隊越來越壯大的，有負責人走的。

老大的技術視野是一方面，能讓團隊有事做，做的事情能夠更快成長，個人覺得對於畢業生這兩點最重要，掌握自身技能最重要，當然見過技術很牛項目很不錯但由於不會管理團隊的把一個團隊成員快逼走完的。所以其次是個人情商或者魅力，一表現在平時管理團隊時適當鼓勵員工，促使其保持積極性，畫適當的餅，誇合適的贊。再者是團隊的凝聚力，經常帶員工出去吃吃喝喝玩玩樂樂，運動項目也不錯，俗話說吃人嘴短拿人手軟嘛，其實這些付出得到的回報會更多，假設吃吃喝喝花了一萬塊這些成員的積極性可能會幫你賺十萬塊。對於創業型公司，比如每年帶員工出國游，逼格多高，員工工作辛苦，平時最好要有下午茶。最後我認為一個技術負責人家庭幸福愛家人會給員工傳遞很好的正能量。

當然在招人的時候需要好好把關，招最合適的人做最合適的事。

無它，看人准。一個人接觸幾下，就能看出此人的各方面本質，然後能理性根據這個判斷正確姿態接觸這個人。

團隊技術信息流建設這是我們團隊技術建設的流程，包括技術新聞，技術博客，技術分享等

歡迎關注我們團隊技術專欄，每周都有高質量文章發布。

保證團隊成員的質量，雖然常說一手爛牌也要能打好，但誰都想要兩個王四個二吧。現實情況是，在大部分情況下團隊成員都是已經決定好的，給我們選擇的機會不多，但在補員的時候，還是有機會調整的，其實就是在說招聘，關於如何做好招聘話題很大，一個關鍵原則就是新來的不能在團隊中位線以下，否則團隊質量會逐漸下滑至失控，後面想要再做提升調整，耗費的精力會大得多

跟老闆搞好關係。找合適的人。把握技術方向。獎罰分明。言出必行。