技術團隊管理筆記(二)-帶人

聲明：所謂的技術管理筆記，是一位原大公司的碼農不甘寂寞，出來加入創業公司後的管理心得記錄。大公司到創業公司的落差是全方位的，制度，氛圍，資源，人才皆有。從最初的不適應到一路磕磕碰碰活到如今。心中充滿感恩和僥倖，以爲有必要強迫本身作下記錄和總結。遂開始於2017年11月份，截止此時我所管理的技術團隊爲50人。此背景可作參考，例子可能和您的團隊不符，可是思路可能相同，歡迎同道中人一塊兒討論切磋。

上一篇技術團隊管理筆記(一)-識人得到了你們的喜好，也和不少朋友作了交流，很是感謝你們的支持，本篇咱們開講技術團隊管理筆記(二)-帶人

首先咱們先搞清楚一個核心問題：爲何要帶人
有的同窗會說帶人是爲了讓團隊更有戰鬥力，從而能夠作好項目; 有的會說可讓本身從細節工做中慢慢解脫出來，有更多時間考慮架構的問題; 有的會說很是有成就感，看到下屬一個個成長起來這種感受喜不勝收。這些說法從結果來看，都是正確的，但彷佛和公司的總體戰略目標好像有點距離？ 在這裏，我提一個新的觀點，帶人的核心目的是：經過提高團隊的能力，爲公司贏得3到6個月的成長紅利期，且暫時不須要付出額外成本(通常6個月到1年左右會有加薪需求)。當這個紅利幫助公司拿下既定業務目標後，整個團隊就能夠享受公司成長的收益(加薪)，從而造成良性循環

這句話看上去很是市儈，恩，很像資本家無情的剝削想法:)，但這其中透露了幾個關鍵點：

1. 爲公司贏得3到6個月的成長紅利期高於一切，只有當公司得到收益後才能反哺團隊，你纔可以創建真正的威信。
2. 在帶人的時候不免會讓團隊以爲更累了，要付出更多了。但此時毫不能心軟，更不能有「萬一我在技術上對你們要求很嚴格，可是公司最後沒有給團隊加薪，那個人我的信用豈不是破產」的錯誤想法。由於沒有那3到6個月的成長紅利期，公司是不可能成功的。說句打擊士氣的話，萬一努力了，公司還沒贏得業務目標怎麼辦？哈哈，這不是你做爲技術管理者能決定的問題了，你只有往前看一條路
3. 帶人是沒有止境的，由於你須要永遠爲公司的發展創造出空間，因此一刻都不能鬆懈

電視劇漢武大帝裏有一段曾讓我印象很是深入，霍去病說本身打仗還會帶廚子專門給本身作飯，被李廣和衛青鄙視，他們說，爲將者和士兵患難與共仍是須要的。霍去病回答道：帶兵打仗，須要的毫不是行仁義。將帥的目標，只有一個，那就是贏。仗打不贏，就是每天和士兵患難與共，也是個無能之將(仗若是打贏了，將士天然論功行賞)。這正說明了，管理者爲公司贏得紅利高於一切。

明白帶人的意義後，咱們來說一下帶人的幾個心法

1. 作項目的核心目的是爲了帶人，作成是結果
   ，理解這第一點最爲關鍵和精妙，不少同窗在帶項目的時候，看上去事必躬親。天天像救火隊員同樣幫助團隊成員解決各類技術問題，也會耐心和他們講解好的技術方案，可是效果卻不盡如人意。由於你會錯意了，真正優秀的管理者是管人無論事，也是咱們常說的「無爲而治」。若是你的團隊成員夠強，項目天然是能成功的。若是你的團隊不夠強，就算你一次次靠優秀的我的能力堵上了窟窿，你的團隊也沒有成長性，更沒有將來。因此若是要作一個「四兩撥千斤」的優秀管理者，請把你的重點放在帶人上，放在關鍵的事情上，而不是在項目的雜事上。

2. 提高下屬的思惟高度高於幫助其解決問題 ，深入理解到了第一點，那這第二點就是精彩的開始。咱們來推演一個場景，假設你團隊裏的一位工程師使用了一個開源框架，由於框架自己不是很是成熟或者他的使用方式有問題，最後在某個項目的發佈中，致使程序內存溢出了。 咱們來看下以結果爲目的和以帶人爲目的的不一樣處理方式：

• 以結果爲目的：使用專業的內存分析工具，幫助工程師發現問題所在，並剖析開源框架的源代碼，告知工程師框架有何問題或之後該怎麼使用
• 以帶人爲目的：幹完以結果爲目的該乾的全部事以後，問一下工程師，你以爲使用一個第三方的開源框架，怎麼樣纔算是正確的作法？在和工程師一番討論後，你拋出本身鮮明的觀點：1 開源框架也是人寫的，可能就是有問題的 2 在使用任何開源框架前，咱們都該知其然知其因此然 3 牛逼的技術不在於你研究和使用了多少開源框架，而是你能不能永遠作出穩定的商業化系統，開源只是你的手段和工具而已。 明白二者的區別了嗎？以結果爲目的你只是看到了一棵樹，而放棄了整個森林，看似解決了此次的問題，保證了項目順利發佈，可是下一次你的工程師還會掉進開源的坑裏。而以帶人爲目的的方案，你不但解決了問題，還開始嘗試提高下屬的思惟高度，之後他再也不會掉入任何的開源坑裏，且真正明白了何爲穩定的商業化系統。在往後，就算使用公司內的其它公共服務，他都會很是當心，那是質的變化！因此，請必定要記住，提高下屬的思惟高度高於幫助其解決問題。

3. 怎麼設定好下屬的目標是個學問 ，給下屬設定目標也是很是重要的，有了目標，他們才能往那個方向去努力，才能成長嘛。不少管理文章都會提到，設定的目標通常比人的當前能力高20%到30%左右。這個確定是沒錯的，也必須按照這樣來，但這裏有一個關鍵問題：修正幅度。 你不是先知，給下屬設定的目標不必定每次都是對的，頗有可能高了或低了，這以後怎麼辦呢？切記不要一次修正幅度過大，要慢慢修正。高了或低了，就先正負修正10%左右，再觀察一下下屬的表現，若是仍是不匹配，那就再修正10%左右。這種作法有一個好處：對有上進慾望的同窗，不至於由於目標過高而讓他失去積極性，慢慢加量，幫他不斷提高。對無上進慾望的同窗，則能夠慢慢邊緣化，避免團隊震盪，由於目標每每決定了你會負責多少事。

4. 越重要越緊急的項目越要嚴格要求 ，這也是一個很關鍵的點，我看過不少技術管理者，由於ceo的業務壓力，在一些很是重要且時間緊急的項目中默認了團隊不須要作很是詳細的系統設計後再開始編碼，甚至對開發的自我測試要求也會下降（指望早點發給專業的QA去測試以節省時間）。首先從項目的成功角度來講，確定是錯的，沒有好的設計和測試，頗有多是會作失敗的。另外從帶人的角度來看，這種作法給團隊傳遞了一種極其錯誤的態度：越是重要的項目（這種項目每每進度也很急）越不須要設計和自測。這不是帶人了，簡直就是毀人啊，對團隊將來的成長帶來不可估量的阻礙。今天你給本身所謂的方便，明天必將幾倍的反噬於你，到時你再怎麼努力扭轉都無濟於事。在軍隊中有一種觀點，就算敗了，陣型也不能亂，其實說的就是這個道理。對於重要的項目不但不應放鬆，反而應該更加嚴格要求，給團隊傳遞正確的信號：越是重要的項目越要嚴格要求。

5. 先從核心人員帶起 ，還記得上篇文章技術團隊管理筆記(一)-識人裏定義的5類人嗎，在這個地方就要發揮做用了，以下處理方法：

類別	定義	帶人策略
優秀的工程師	技術優秀，認同公司目標，有很強的自驅力，喜歡發現問題，解決問題	須要你親自帶
有必定工程師思惟的潛力程序員	認同公司目標，有很強的自驅力，技術尚在快速成長期	由第1類人來帶，在須要你帶的時候再介入
有必定工程師思惟的普通程序員	認同公司目標，有很強的自驅力，技術潛力通常	由第1類人來帶
熟練的程序員	技術比較紮實，可是沒有太多工程師思惟	由第1或第2類人來帶
普通程序員	技術通常，也沒有太多工程師思惟	由第2類人來帶，你須要關注不能由於個體緣由影響到整個團隊

記住，你的帶人精力是有限的，要把精力花在最該須要的地方和人身上，才能事半功倍。

6. 細心留意真正須要你介入的時機 ，帶人的介入時機也是頗有講究的，由於帶人總免不了說教。你想一想若是你做爲一個員工，被本身的老闆指出這裏和那裏的不足，就算老闆是爲你好，你的內心老是不舒服的，由於人的本能就是抗拒本身的缺點的。若是你在向下屬指點的時候，他在本能上是抗拒的，那效果確定是很差的。那什麼時候是你介入的好時機呢？ 這裏有一個竅門：在你的下屬碰到了一些困難正手足無措須要幫助的時候，且這個困難不至於對整個項目產生致命的威脅。雪中送炭，纔是你帶人的好時機，你的下屬在這個時候更可能是感恩，能聽得進你的建議。千萬不要迷戀什麼每個月談話，看看下屬須要什麼幫助這種堂而皇之的套路，遠遠沒有雪中送炭的做用和意義大。可是度要把握好，不能等你的下屬都要被燒死了，你才進去幫忙，那真是晚了。你下屬的每一次跌倒，必定能記住痛，也是他可否成長的關鍵時刻，這個時候才須要你的出現！

帶人這篇已經表完，總的來講理解帶人的目的最爲重要。在真正理解帶人的意義以後，只要足夠耐心，採用合理的方法就能把團隊越帶越強，從而享受到產生的紅利 帶好了人後，只有用對了，才能真正發揮做用，下一章，咱們講一下技術團隊管理筆記(三)-用人

技術團隊管理筆記系列連接： 技術團隊管理筆記(一)-識人 技術管理者如何向上彙報