相信很多技術團隊的leader都是從程式設計師走過來的，從管理自己到管理團隊，這是每乙個管理者都要經歷的一道鴻溝，有人做的游刃有餘，有人覺得卻是個苦差事，的確，這世界上最難管理的應該就是人了吧。
這兩年我也陸續管理了幾個小團隊，團隊雖小，但是我覺得管理的本質都是一樣，下面就我自己的一點淺薄經驗，談下如何做好團隊管理的幾個小原則。
1. 用制度的力量而不是友情的力量
這一點是管理者在小團隊管理裡面最容易犯的問題之一，我以前也犯了這個錯誤，跟團隊裡面的人太熟悉了，私下感情也很好，工作中就容易打感情牌，即便你已經成了leader，到後面你會發現該下手的時候下不了手，該發火的時候你發不了火，最後的結果是什麼：團隊執行事情的效率極低，缺乏約束，沒有紅線。
因此好的管理應該是善於使用制度管理，打你上任的那天起，就可以在公司制度的前提下，規劃好整個團隊的行事準則，這些準則包括但不限於：**規範、產品開發流程、發布流程、獎懲制度、考核機制等等並通過大家的一致表決。在乙個好的團隊制度的基礎上，獎罰分明，責任劃分清晰，做事有依據，公平公正，團隊人員之間的各種矛盾自然下降，制度在團隊的準則就在，不用刻意強調。
2. 團隊的任務和目標必須清晰
這句話看起來確實是一句廢話，但是確實是很多剛上任的leader常犯的問題，問題的原因是只關注了近期目標和任務而
忽略了中長期的目標。
實際上技術團隊的目標一定是圍繞業務目標進行，作為管理人員一定要關注全域性，多和業務線的負責人溝通，這樣有利於制定出長期的技術規劃，讓整個團隊知道未來1年、甚至2年內的長期目標是什麼，團隊的腳步現在在**，未來要到**去，技術上要解決的問題是什麼？可以選擇性忽略一些阻礙團隊進步的細節問題。
只有這樣，整個團隊才不至於迷路，大家對未來才能有所期待，才有動力去做事情，才明白現在做的事情的價值在**。
3. 一定不能事事親力親為
作為一名程式設計師，能夠親手去解決技術問題是一件很有成就感的人。所以很多程式設計師到了管理崗後，仍然有親手解決問題的慣性思維。都說屁股決定腦袋，到了管理這個位置後，那麼更重要的是要思考人員組織，思考團隊發展，思考目標和方向的問題，如果把大量時間都用在了解決瑣碎的問題上，那麼勢必
思考這些的時間就少了，很容易只看到區域性，因此要習慣培養下屬去做事，授人以漁，慢慢放權。
這樣下面的人有一定的權利，其能力也能得到相應鍛鍊，慢慢就能成長起來成為業務骨幹。
領導謀局，員工做事，大概就是這麼個意思。
4. 技術團隊的領導依然需要有**能力
「talk is cheap show me the code」，相信大家都聽過這句話，我的感悟是技術領導一定不要只是純管理性質，那樣的話會跟乙個傳話筒沒撒子區別，在關鍵性的技術細節上不能脫離。
因為很多人做了管理以後就會覺得自己沒有必要寫**了，久而久之，是真的不會寫了。
缺少了這個能力以後，也就意味著對於系統重要細節的把控能力下降，缺少了帶兵打仗的能力，如果有一天你還得上戰場那就非常被動了。
所以**不能丟，細節不能忘，要隨時可以跟團隊一起戰鬥，對團隊成員的**能夠去review，能夠優化，提出指導意見才能讓團隊相信你的硬實力。技術人一般對於技術大神都是比較膜拜的。但是大神絕對不是嘴上說說而已。
5. 要學會向上管理
如何做好程式設計師的自己
做開發的工作已經快2年了，漸漸才發現自己在工作上花的心似乎太多了，沒錯技術進步是好事，但是在與人溝通方面似乎自己壓根就沒注意。最近和朋友聊天，才發現自己有很多方面做的確實不足。總結下有幾點 一 與同事打好關係 1 別仗著自己技術好，在同事面前表現自己，留下愛裝逼的印象 1.組裡剛來一哥們，跟別人說還...
如何做好乙個程式設計師
不知不覺做軟體已經做了十年，有成功的喜悅，也有失敗的痛苦，但總不敢稱自己是高手，因為和我心目中真正的高手們比起來，還差的太遠。世界上並沒有成為高手的捷徑，但一些基本原則是可以遵循的。1.紮實的基礎。資料結構 離散數學 編譯原理，這些是所有電腦科學的基礎，如果不掌握他們，很難寫出高水平的程式。據我的觀...
如何做好乙個程式設計師
不知不覺，已經做了3個月的程式設計師了。這三個月，稍稍有點感觸，說說關於怎樣做乙個程式設計師的感受吧 一 技術 1.首先，要熟悉一門語言。這是必須的，也是基礎。至於什麼是熟悉，我個人的理解就是常用的會寫，不常用的會查。2.實際問題的解決能力。既然是做開發，就免不了要遇到問題，這樣說其實有點太寬泛的感...