宣告：所謂的技術管理筆記，是一位原大公司的碼農不甘寂寞，出來加入創業公司後的管理心得記錄。大公司到創業公司的落差是全方位的，制度，氛圍，資源，人才皆有。從最初的不適應到一路磕磕碰碰活到現在。心中充滿感恩和僥倖，覺得有必要強迫自己做下記錄和總結。遂開始於2017年11月份，截止此時我所管理的技術團隊為50人。此背景可做參考，例子可能和您的團隊不符，但是思路可能相同，歡迎同道中人一起討論切磋。
上一篇技術團隊管理筆記(一)-識人獲得了大家的喜愛，也和很多朋友做了交流，非常感謝大家的支援，本篇我們開講技術團隊管理筆記(二)-帶人
首先我們先搞清楚一個核心問題：為什麼要帶人
有的同學會說帶人是為了讓團隊更有戰鬥力，從而可以做好專案; 有的會說可以讓自己從細節工作中慢慢解脫出來，有更多時間考慮架構的問題; 有的會說非常有成就感，看到下屬一個個成長起來這種感覺喜不勝收。這些說法從結果來看，都是正確的，但似乎和公司的整體戰略目標好像有點距離？
在這裡，我提一個新的觀點，帶人的核心目的是：通過提升團隊的能力，為公司贏得3到6個月的成長紅利期，且暫時不需要付出額外成本(一般6個月到1年左右會有加薪需求)。當這個紅利幫助公司拿下既定業務目標後，整個團隊就可以享受公司成長的收益(加薪)，從而形成良性迴圈
這句話看上去非常市儈，恩，很像資本家無情的剝削想法:)，但這其中透露了幾個關鍵點：
- 為公司贏得3到6個月的成長紅利期高於一切，只有當公司獲得收益後才能反哺團隊，你才能夠建立真正的威信。
- 在帶人的時候難免會讓團隊覺得更累了，要付出更多了。但此時絕不能心軟，更不能有“萬一我在技術上對大家要求很嚴格，但是公司最後沒有給團隊加薪，那我的個人信用豈不是破產”的錯誤想法。因為沒有那3到6個月的成長紅利期，公司是不可能成功的。說句打擊士氣的話，萬一努力了，公司還沒贏得業務目標怎麼辦？哈哈，這不是你作為技術管理者能決定的問題了，你只有往前看一條路
- 帶人是沒有止境的，因為你需要永遠為公司的發展創造出空間，所以一刻都不能鬆懈
電視劇漢武大帝裡有一段曾讓我印象非常深刻，霍去病說自己打仗還會帶廚子專門給自己做飯，被李廣和衛青鄙視，他們說，為將者和士兵同甘共苦還是需要的。霍去病回答道：帶兵打仗，需要的絕不是行仁義。將帥的目標，只有一個，那就是贏。仗打不贏，就是天天和士兵同甘共苦，也是個無能之將(仗如果打贏了，將士自然論功行賞)。這正說明了，管理者為公司贏得紅利高於一切。
明白帶人的意義後，我們來講一下帶人的幾個心法
-
做專案的核心目的是為了帶人，做成是結果
，理解這第一點最為關鍵和精妙，很多同學在帶專案的時候，看上去事必躬親。每天像救火隊員一樣幫助團隊成員解決各種技術問題，也會耐心和他們講解好的技術方案，但是效果卻不盡如人意。因為你會錯意了，真正優秀的管理者是管人不管事，也是我們常說的“無為而治”。如果你的團隊成員夠強，專案自然是能成功的。如果你的團隊不夠強，就算你一次次靠優秀的個人能力堵上了窟窿，你的團隊也沒有成長性，更沒有未來。所以如果要做一個“四兩撥千斤”的優秀管理者，請把你的重點放在帶人上，放在關鍵的事情上，而不是在專案的瑣事上。 -
提升下屬的思維高度高於幫助其解決問題 ，深刻理解到了第一點，那這第二點就是精彩的開始。我們來推演一個場景，假設你團隊裡的一位工程師使用了一個開源框架，因為框架本身不是非常成熟或者他的使用方式有問題，最後在某個專案的釋出中，導致程式記憶體溢位了。 我們來看下以結果為目的和以帶人為目的的不同處理方式：
- 以結果為目的：使用專業的記憶體分析工具，幫助工程師發現問題所在，並剖析開源框架的原始碼，告知工程師框架有何問題或以後該怎麼使用
- 以帶人為目的：幹完以結果為目的該乾的所有事之後，問一下工程師，你覺得使用一個第三方的開源框架，怎麼樣才算是正確的做法？在和工程師一番討論後，你丟擲自己鮮明的觀點：1 開源框架也是人寫的，可能就是有問題的 2 在使用任何開源框架前，我們都該知其然知其所以然 3 牛逼的技術不在於你研究和使用了多少開源框架，而是你能不能永遠做出穩定的商業化系統，開源只是你的手段和工具而已。 明白兩者的區別了嗎？以結果為目的你只是看到了一棵樹，而放棄了整個森林，看似解決了這次的問題，保證了專案順利釋出，但是下一次你的工程師還會掉進開源的坑裡。而以帶人為目的的方案，你不但解決了問題，還開始嘗試提升下屬的思維高度，以後他不再會掉入任何的開源坑裡，且真正明白了何為穩定的商業化系統。在日後，就算使用公司內的其它公共服務，他都會非常小心，那是質的變化！所以，請一定要記住，提升下屬的思維高度高於幫助其解決問題。
-
怎麼設定好下屬的目標是個學問 ，給下屬設定目標也是非常重要的，有了目標，他們才能往那個方向去努力，才能成長嘛。很多管理文章都會提到，設定的目標一般比人的當前能力高20%到30%左右。這個肯定是沒錯的，也必須按照這樣來，但這裡有一個關鍵問題：修正幅度。 你不是先知，給下屬設定的目標不一定每次都是對的，很有可能高了或低了，這之後怎麼辦呢？切記不要一次修正幅度過大，要慢慢修正。高了或低了，就先正負修正10%左右，再觀察一下下屬的表現，如果還是不匹配，那就再修正10%左右。這種做法有一個好處：對有上進慾望的同學，不至於因為目標太高而讓他失去積極性，慢慢加量，幫他不斷提升。對無上進慾望的同學，則可以慢慢邊緣化，避免團隊震盪，因為目標往往決定了你會負責多少事。
-
越重要越緊急的專案越要嚴格要求 ，這也是一個很關鍵的點，我看過很多技術管理者，因為ceo的業務壓力，在一些非常重要且時間緊急的專案中預設了團隊不需要做非常詳細的系統設計後再開始編碼，甚至對開發的自我測試要求也會降低（期望早點發給專業的QA去測試以節省時間）。首先從專案的成功角度來說，肯定是錯的，沒有好的設計和測試，很有可能是會做失敗的。另外從帶人的角度來看，這種做法給團隊傳遞了一種極其錯誤的態度：越是重要的專案（這種專案往往進度也很急）越不需要設計和自測。這不是帶人了，簡直就是毀人啊，對團隊未來的成長帶來不可估量的阻礙。今天你給自己所謂的方便，明天必將幾倍的反噬於你，到時你再怎麼努力扭轉都無濟於事。在軍隊中有一種觀點，就算敗了，陣型也不能亂，其實說的就是這個道理。對於重要的專案不但不該放鬆，反而應該更加嚴格要求，給團隊傳遞正確的訊號：越是重要的專案越要嚴格要求。
-
先從核心人員帶起 ，還記得上篇文章技術團隊管理筆記(一)-識人裡定義的5類人嗎，在這個地方就要發揮作用了，如下處理方法：
| 類別 | 定義 | 帶人策略 |
|---|---|---|
| 優秀的工程師 | 技術優秀，認同公司目標，有很強的自驅力，喜歡發現問題，解決問題 | 需要你親自帶 |
| 有一定工程師思維的潛力程式設計師 | 認同公司目標，有很強的自驅力，技術尚在快速成長期 | 由第1類人來帶，在需要你帶的時候再介入 |
| 有一定工程師思維的普通程式設計師 | 認同公司目標，有很強的自驅力，技術潛力一般 | 由第1類人來帶 |
| 熟練的程式設計師 | 技術比較紮實，但是沒有太多工程師思維 | 由第1或第2類人來帶 |
| 普通程式設計師 | 技術一般，也沒有太多工程師思維 | 由第2類人來帶，你需要關注不能因為個體原因影響到整個團隊 |
記住，你的帶人精力是有限的，要把精力花在最該需要的地方和人身上，才能事半功倍。
- 細心留意真正需要你介入的時機 ，帶人的介入時機也是很有講究的，因為帶人總免不了說教。你想想如果你作為一個員工，被自己的老闆指出這裡和那裡的不足，就算老闆是為你好，你的心裡總是不舒服的，因為人的本能就是抗拒自己的缺點的。如果你在向下屬指點的時候，他在本能上是抗拒的，那效果肯定是不好的。那何時是你介入的好時機呢？ 這裡有一個竅門：在你的下屬碰到了一些困難正手足無措需要幫助的時候，且這個困難不至於對整個專案產生致命的威脅。雪中送炭，才是你帶人的好時機，你的下屬在這個時候更多是感恩，能聽得進你的建議。千萬不要迷戀什麼每月談話，看看下屬需要什麼幫助這種冠冕堂皇的套路，遠遠沒有雪中送炭的作用和意義大。但是度要把握好，不能等你的下屬都要被燒死了，你才進去幫忙，那真是晚了。你下屬的每一次跌倒，一定能記住痛，也是他能否成長的關鍵時刻，這個時候才需要你的出現！
帶人這篇已經表完，總的來說理解帶人的目的最為重要。在真正理解帶人的意義之後，只要足夠耐心，採用合理的方法就能把團隊越帶越強，從而享受到產生的紅利 帶好了人後，只有用對了，才能真正發揮作用，下一章，我們講一下技術團隊管理筆記(三)-用人
技術團隊管理筆記系列連結： 技術團隊管理筆記(一)-識人 技術管理者如何向上彙報