『壹』 如何做IT項目團隊 組織管理
這幾天張興心情有點煩躁。張興是一個資深的程序員，公司新委任他為研發團隊主管。他這個大蝦要帶著一群小蝦一起開發軟體。沒有想到他剛剛接手研發團隊，就深深感受到研發團隊建設的痛苦。
團隊建設的最大病症：精神離職
項目管理說到底，核心是對人的管理。在張興接手研發團隊後，遇到的第一個難題就是團隊成員常常是出人不出力。現在回憶起這些情況，張興還感到後怕。這種情況的出現往往意味著在團隊建設中隱藏著危險信號，並蒙蔽了團隊經理的眼睛。如果不引起重視，團隊建設將會前功盡棄。
讓張興非常苦惱的出人不出力，就是團隊成員的精神離職，而這在團隊中是普遍存在的。精神離職的特徵表現為：工作不在狀態，對工作不夠認真，團隊內部不願意協作，行動較為遲緩，個人能力在工作中發揮不到30％，基本上是在無所事事的狀態下結束一天的工作。
精神離職產生的原因大多是個人目標與團隊願景不一致產生的，也有工作壓力、情緒等方面原因。正所謂百姓百心，在一個團隊里大家由於心態、觀念、能力的不一致使到很多研發工作進展緩慢。項目經理也往往不知道研發人員究竟是不會做還是不願做，還是由於資源缺乏而不能做，從而很難讓員工凝成一股繩高效地完成研發目標。針對精神離職者有效方法是：多溝通，用團隊精神與團隊願景來提升工作狀態，用激勵手段提升工作熱情。具體做法可以是安排假期，讓精神離職者冷靜思考，調整狀態，然後根據實際情況考慮團隊中是否會重新接納。
工作群體與團隊的區別
隨著軟體項目分工越來越細化，個人單打獨斗的時代已經結束，團隊合作提到了管理前台。軟體開發不再是個人賽，而是團體賽，團隊的組織形態越來越引起重視。
團隊是指一種為了實現某一目標而由相互協作的個體所組成的正式群體。這一定義突出了團隊與群體不同，所有的團隊都是群體，但只有正式群體才能是團隊。否則，只是一個偽團隊或工作群體而已。
工作群體是一個小規模的人群組成，群體中每個成員不互相依賴地工作，以及不為彼此的結果而分擔責任，因而工作群體的績效是每個個體績效的簡單加總，不存在像團隊的積極協作效應，也無法像團隊那樣實現1+12的效果。
工作群體與團隊的差別之處：①關系期望。團隊對成員表現在參與、投入、合作或支持等方面的期望較高，要求也較為嚴格。而在工作群體中，彼此間只是共同和睦相處，相互支持合作比較少。②溝通結構。團隊有著更為復雜的溝通結構，對於信息交流、溝通程度要求都比較高。③運作方法。因為團隊成員間相互依賴程度高，工作必須相互配合才能完成，所以格外關心共同工作的運行方式。
因此，僅把一組成員組合起來並不能稱的上一個團隊，要使成員發展成一個有效協作的團隊，既要團隊經理努力也要全體成員共同付出努力。一個高效團隊對項目目標要有共同的清晰認識和理解，對每位成員的角色要有明確的劃分，高度合作互助以及高度信任。團隊成員不僅要完成自己的任務，還要協同其他成員共同完成研發任務。
高效團隊的基石：分工平衡
研發團隊建設雖不是一件輕松的事情，但也不象大多數人認為那樣是一件非常困難的事情。在經過痛苦的挫折後，張興明白到可以藉助一些常見的管理方法來簡化團隊建設工作。除了明確工作質量、范圍、工期、成本等目標外，高效團隊的基石在於明確各團隊成員的角色和責任分工，充分發揮團隊成員各自的作用。
分工平衡和工作匹配是團隊建設的兩個重要方面。當失去了分工平衡，團隊就會變得脆弱，團隊合作遠比個人總和重要。正如一個成功的橄欖球隊，進攻，防守，教練，替補等各種角色都不可少。因此，團隊經理需要真正做到人盡其材，每個成員都能夠真正找到適合自己的位置，這樣的成員配置才能達到一個平衡狀態。
另一方面是工作匹配，是說開發任務必須分給技能和動力都匹配的人。對軟體研發團隊來說，辨別個人技能並做到最優分配是相當困難的，而且項目經理的個人主觀意願也可能使工作分配復雜化。但如果人才不能發揮所長，對軟體研發工程師和項目經理來講都是一個雙重的打擊。
項目團隊考核指標：凝聚力建設
軟體開發是一項集體運動，項目經理必須培養一種團隊合作，而不是單純的追求個人成功的氛圍。團隊凝聚力是無形的精神力量，是將一個團隊的成員緊密地聯系在一起的看不見的紐帶。團隊的凝聚力來自於團隊成員自覺的內心動力，是團隊精神的最高體現。一般情況下，高團隊凝聚力帶來高團隊績效。團隊凝聚力在外部表現為團隊成員對團隊的榮譽感及團隊的地位，團隊凝聚力在內部表現為團隊成員之間的融合度和團隊的士氣。
在軟體開發項目管理中我們強調的團隊凝聚力主要有責任感，協作精神等方面的內容。責任感是團隊凝聚力最基本的要素，只有團隊中每個人員都有了這種責任感，能夠積極主動工作，才能夠談得上後續的溝通和相互協作，以達到團隊所共同確定的目標。很多時候研發中出現設計太粗、編碼閱讀困難、或者編碼BUG很多等問題，其實很多都不是團隊成員的水平問題，更多原因是責任感不強。
協作精神在研發中是很重要的，即使完成一個簡單的研發任務也需要團隊的需求，設計，開發和測試人員來共同協作完成。協作精神在於互相尊重，團隊內每位成員都尊重和認可其它成員所扮演的角色。如果團隊成員間沒有協作精神，主動溝通去解決問題，那研發項目質量就無法得到有力的保證。一個再優秀的成員如果沒有團隊觀念，不願意和他人協作是不適合呆在團隊中，因為可能會使整個團隊的協作精神土崩瓦解。
在實際的項目管理中，加強團隊凝聚力建設方面採取的方法主要有：
1. 項目經理定期和團隊成員進行單獨溝通，了解成員對工作和個人職業發展的一些真實想法，使團隊發展和個人發展兩者相互促進，讓團隊成員感受到在做研發過程中個人技能的提高和個人成就感的增加。
2.團隊定期組織相關的聚會和活動，加強團隊成員間相互溝通和了解，活躍團隊氣氛，並把這種輕松和活躍的氛圍傳遞到日常緊張的工作任務中，讓團隊成員更多感受到工作的樂趣。
1. 公平合理的績效考核：通過將員工的獎勵和員工績效結合起來，強化績效管理。推行項目績效管理制度，除了有效管理項目成果外，在加強團隊凝聚力、培養團隊精神都極有幫助。一個有強烈協作精神和自驅力的團隊對項目的成敗起著至關重要的作用。因此，通過績效考核激發項目成員的工作熱情是一個很好的方法。
2. 協助成員技能提升：在研發過程中要讓每個團隊成員都感覺到自我技能的提升，但前提是團隊成員有這種技能提升願望和學習的熱情。如果項目成員長期都是按部就班進行著重復的工作，那工作積極性和熱情就很難持續的保持。因此，在研發過程中應該給每位團隊成員承擔挑戰性工作的機會，充分信任團隊目成員的能力，讓團隊成員體會到完成這些挑戰後的成就感和個人能力的提高。
3. 表揚和鼓勵：項目經理要時不時的通過各種方式表揚和鼓勵團隊成員，對成員完成工作的給予最大的肯定，這是對團隊成員最好的激勵方式。例如通過郵件或電話等方式對成員的進行單獨表揚、肯定和鼓勵；通過項目例會對團隊中表現優秀人員的表揚；通過團隊聚會和活動等方式對整個團隊完成工作的祝賀和鼓舞。表揚和批評兩者並不矛盾，對於團隊成員連續犯錯誤的毛病應該給予批評，但一般採用單獨溝通或郵件的方式進行，整個團隊也應該定期展開一些自我批評，讓團隊成員感受到自己的不足和待提高地方。
4. 關注每個團隊成員的職業發展：項目經理需要關注每個成員的職業發展和職業規劃，對團隊成員的職業發展給出一些建議，並為團隊成員制定一些合乎實際的學習和成長路線。
『貳』 如何解決軟體研發團隊管理的問題
高效軟體開發團隊的特徵
高效的軟體開發團隊是建立在合理的開發流程及團隊成員密切的合作的基礎之上的，成員共同的迎接挑戰、有效的計劃、協調和管理各自的工作以至完成明確的目標，高效的開發團隊具有如下特徵：
1、 具有明確且有挑戰性的共同目標
一個具有明確的而且有挑戰性目標的團隊比目標不明確或不具有很大的挑戰性目標的團隊效率高得多，通常技術人員往往會因為完成了某個明確的任務，而且這個任務的完成具有挑戰性的意義而感到自豪，反過來團隊成員為了獲取這種自豪的感覺而更加積極的工作從而帶來團隊開發的高效率，如作為系統設計人員很清楚的知道在什麼時候要做到什麼，什麼時候開始做，什麼時候必須完成，為了完成工作必須面臨哪些挑戰，怎麼解決這些困難等為設計出一個高質量的軟體項目提供了重要保證，而模模糊糊的去設計一個系統或模模糊糊的就去編寫代碼是非常危險的，而且會為此付出高昂代價，因此高效的軟體開發團隊具有挑戰性的共同目標。
2、 團隊具有很強的凝聚力
在一個高效的軟體開發團隊中，成員們凝聚為一個整體共同進行工作，他們是相互支持、互相交流、互相尊重的，而不是相互推卸責任、保守、相互指責的，在一些散亂的開發團隊中往往存在這樣的問題，一些程序員是比較保守的，明明知道另外的模塊中需要用到一段與自己已經編寫完成但有些難度的程序代碼，他也不願拿出來給其它程序員共享，不願與系統設計人員交流，這樣給項目的進度造成了些不可度量的因素。
3、 具有融洽的交流環境
在一個開發團隊中，每個人行使自己的職責，如需求分析人員制定需求規格說明、系統設計人員做系統概要設計和詳細設計、項目經理配置項目開發環境並且制定項目計劃等，但每個人的工作不可能做到完美的，如系統概要設計的文檔可能有個別地方詞不達意，做詳細設計的時候就可能會造成誤解，項目經理制定計劃時可能忽略了某種風險的存在而造成執行者過於緊張的壓力等等情況都需要大家通過交流、反饋的手段然後協商解決的，因此高效的軟體開發團隊是具有融洽的交流環境的，而不是那種簡單的命令執行式的。
4、 具有共同的工作規范和框架
高效軟體開發團隊具有規范性及共同框架的工作，對於項目管理具有規范的項目開發計劃，對於分析設計具有規范和統一框架的文檔及審評標准，對於代碼具有程序規范條例，對於測試有規范且可推理的測試計劃及測試報告等等。並且所有成員都明白自己的職責，知道必須完成什麼計劃?由誰來完成?什麼時候開始?什麼時候結束?按什麼順序?等，總之一個高效的開發團隊無論是工作內容還是工作流程都具有不同程度的規范性和標准風格的框架。
5、 採用合理的開發過程
軟體的開發不同於一般商品的研發和生產，開發過程中會面臨著各種難以預測的風險，比如需求的變化、人員的異動、技術的瓶頸、同行的競爭等，高效的軟體開發團隊往往是採用了合理的開發過程去控制開發過程中的風險、提高軟體的質量、降低開發費用，這樣的團隊會根據自身的必要程度決定要執行哪些工作?如配置管理、資源管理、版本控制、代碼控制等，團隊還合理的分劃並定義開發過程的里程碑，決定每項活動內容的底線和審評標准，決定各項活動的先後關系或迭代的關系等。總之高效的軟體開發團隊的開發過程的原則是高效率、高質量、低成本。
『叄』 如何管理你的程序員
簡言之，這些東西都是用來最有效的發掘你的員工的全部潛能的。你有了一個領導 基於此，我們通常會有一個重要人物，他可能是一個領導，一個經理或一個總監，等等。這就有了問題：這些人有什麼樣的特徵？一個管理者和一個程序員之間的不同之處在什麼地方？他們的角色可以互換嗎？ 為了弄明白這個問題，我們需要從人的視角上去思考。換種方式來說，我需要用到人的因素這個詞。如果他錯了呢？ 首先，要想管理人，你需要去理解他們。要做到這些，我們需要有情商。這並不僅僅指只針對我們這部分人。我們做的任何事情中都存在情感，你要從個人角度去體驗它，要熟練掌握，在我們的公司管理中的合作方式上不能忘記這一點。管理並不僅僅指控制和命令，它還包括聆聽，理解，溝通和對復雜的情緒上的問題給出有效的方案，這都是至關重要的。弄清他們的感受 很多人都忽略了管理工作中的這方面問題。有時候會很戲劇化，類似於這樣：「鮑勃，從明天開始你就是一名項目經理了，因為我們的程序員太多了，需要去管理，但不用擔心，你就要去上一個Scrum大師班了」。我們都知道這樣的認證證書是什麼樣的，有什麼價值。這跟那個10天的ICC培訓課程後成為一名教練的故事非常的相似——這行不通，你要銘記！ 另一方面，Mark Foster在他的標題為《How to make your dreams come true(如何實現你的夢想)》一書中談到，實現目標有兩種方式：推(Push mode)和拉(Pull mode)。前者是使用一種工藝上的技術來完成一項任務，比如程序員編程，而後者依賴於經驗、直覺和情商，從而選擇最好的方式解決一個問題——這是管理者的視角。當使用這種管理模式時，管理者是不能和程序員進行角色互換的，反之亦然。一些大公司通常使用這種管理模式。而這種方式有時會損失一些員工的潛能，因為在多個級別的管理職位中產生的太復雜的層級關系。相互協作 為什麼？很多的小公司都使用敏捷方法論。這是一種基於合作的方法論。上面描述的模式並不能滿足他們的需求。在不同層級上的管理者和程序員之間始終存在著一個隔膜。人們會被分成「腦力勞動者」和「體力勞動者」。結果就是導致我們失去那些同樣有大腦卻從來未被使用的人。如今，所謂使用有效率的員工就意味著把所有人都當作腦力勞動者。 Evan Rose 說：命令/控制(Command-and-control)文化使人們把公司成員分成了腦力勞動者和非腦力勞動者。他們讓腦力勞動者去思考，讓其他人去執行命令。這種文化中，合作沒有基礎。更重要的，信息的流轉應該是多向性的，而不是瀑布式的從高層經過多個管理層流到一線員工。事實上，如今的每個人都有資格成為一個腦力勞動者 現在出現了一種稱作自我管理的形式，這種形式本是我們這個世界的基礎。如果我們本來是自我管理的，為什麼不更進一步呢？也許我們根本不需要管理者。37Signals 和 DHH都實現了這樣的思想，描述起來如下：我們同樣也讓我們的團隊管理自己。每周，一個員工會站出來當管理者，他制定簡單的日程計劃，審查其他人的工作，更新公司動態信息，他對於其他同事來說是一個關鍵人物。這種職務輪換每周一次。你知道我們發現了什麼嗎？當每個人都知道自己要當一周的國王時，神奇的事情發生了。對管理者強迫自己做某些事情的抱怨消失了，因為職務的輪換讓他們有機會同時清楚的了解了圍欄兩邊的景觀。如果你讓員工們這樣做，這給了他們提高和成長的機會。找到共識，一起努力 但不要想當然。這並不是適用於任何地方任何人。但就像David說的：這種方法可行性很大。如果你能理解這點，你可以在團隊或部門里試驗一下。通常在小公司里當某方面出現問題時你能相當很快的對其作出反應，這能讓你更容易的避免重大事故的發生。 簡言之，不管你的管理方式是什麼樣的，永遠要記住，在公司組織結構的深處有一種叫「人的因素」的東西，它在等待著你去照顧，它能摧毀你所有美麗的計劃。唯一你防止這種災難發生的辦法就是要認識到：你在跟人打交道，不是機器。
『肆』 應該怎麼管理程序員
我是一個非常能忍耐的人，非常能忍。事情是這樣的，去年春天，由於上一個東家戰略失誤，導致我們部門被裁（悲劇啊），只好另尋他路，恰逢舊日總監空降到現在這家公司做老總，於是我就名正言順的過來做嫡系部隊。可等俺入職後，才發現這家公司水很深啊……。溜須拍馬的人比比皆是，竭盡所能討好領導，有些話我聽著都覺得臉紅心跳，胃部翻騰。此為公司第一陣營：諂媚，技術不精，管理不強，但是嘴上功夫了得，總能討得公司一把手二把手歡心，無所不用其極，堪比現代「和珅」。這一層人比較少，金字塔尖嘛。公司第二陣營：埋頭苦幹，一心只讀「聖賢書」，兩耳不聞「窗外事」。這是一群被極度剝削的新人，新時代的農奴，工資在公司墊底，升職沒他們，加薪更別想，技術沒人帶，基本處於群龍無首狀態，每天得過且過。這一層人最多，是整個公司的金字塔底，任憑黃沙蓋臉，毫無怨言。公司第三陣營：技術「大牛」，是的，這群人一般都是個小頭頭了，管理著為數不少的第二陣營，愛好鑽研技術，溝通能力基本為0，未接受過正規化訓練，一件事情要反復說多次方能「略懂略懂」，平時對自己手下不管不問，老子研究高深演算法，你們還是自己看書學習吧。好吧，我來了之後就有了第四陣營：不服管教派。 先說說幾件小事：1.剛來的時候，安排我進了一個開發中的項目組，讓我寫一個圖片處理和加水印的模塊，圖片處理，其實就是根據用戶上傳的圖片(像素很大，不適合網頁展示)，壓縮成各種尺寸並加上網站logo水印，兩天後，我寫了一個通用的介面，傳入圖片的原始地址，水印地址並輸入要生成的尺寸就可以了，給了他們一個打好的jar包。入口參數都用「中文」注釋好了，可後面一直到一個月後，還是老是被問介面怎麼用。2.其二，因為存儲的圖片很多，很大，項目組決定用分布式存儲，選了Hadoop，這任務又被委派給我了，我一看，哥也沒搞過啊，but，難不倒哥。上官網查文檔，上google查資料，經過幾天的折騰，終於把分布式集群搞好了，那個時候公司就一個運維，只會裝系統搭路由，Linux系統安裝和配置都是俺自己搞的，系統搞好後死活上不了網，又把機器從頭到尾檢查了一遍，去問運維，說我DNS地址設錯了，試了好幾個包括他給我的都不行，我不死心，去問運維，聊天的過程中無意間知道公司上公網是用路由過濾MAC地址的，果斷讓他查路由規則，我三台伺服器的MAC地址沒有一台在允許列表當中，oh，my god。好了，下面繼續講Hadoop，搭建好環境，寫完程序介面後就把圖片遷移到集群上，跑的還算穩定，就是讀取文件的時候有點延遲。後來哥有事請假兩天，打算回來解決延遲問題，可當我打開電腦興沖沖的連接Hadoop時，timeout了,What the hell did they do?去問經理，說是我離開後伺服器出問題了，項目組又沒有人會，就把圖片遷移回Apache，Hadoop集群關閉了。這尼瑪！不是坑爹嘛！！！！公司「元老」們對我的到來表示非常的不歡迎，項目組兩個月後就把我T出來了，讓我自立門戶，領導還專門關照我組建一個項目團隊時刻准備為公司沖鋒陷陣，這尼瑪，整個團隊就我一個光桿司令。以上只是技術的，一個對互聯網一竅不通，對編程壓根不懂的副總搞了一套CMMI作為管理手段，大會小會一個周要開三天，還有N多管理上的事情，不一而足，以至於我來兩個月後就想離職走人。後來想想，就這么走了太特么懦夫了，我要組建自己的團隊。於是乎招兵買馬，從招聘、帶人，制定項目規范、代碼規范，學會了js，struts(以前做軟體，沒摸過這些，慚愧……)，從去年年中的1個人道現在的6個人，我的項目組成型了。 好了，不扯閑話了，轉入正題。我有182的身高，80kg的體重，我會一些拳擊，練了五年田徑，可是我從來不跟人拳腳相向。在生活里一直信奉「人不犯我，我不犯人，人若犯我，先讓兩個回合」的至理名言，可是今天早上上班打開郵件，我就不淡定了。 公司新推出了績效考核，特別強調要量化量化再量化，最極品的是要量化「每周」寫的代碼行數。其實呢，大家都懂的，工作上按時把工作計劃里的工作完成，保證正常上線，其實就OK了。可這位副總，不懂不說，還特別不信任員工，不捨得權力下放。不知道去進行內部團隊的構建工作，偏愛相信外面什麼培訓老師，今天早上，竟然在郵件里，赫然把外面老師考核項寫在績效模板里，還佔了20%的比重。一個根本不在公司，沒和項目組成員進行溝通交流，連我們做什麼項目都不知道的所謂「老師」，竟然要給我們績效考核的「工作能力」和計劃能力打分，真是奇葩啊！！此郵件一出，「和珅」們拍手叫好，高呼領導英明，堅定的站在公司領導這邊堅決執行新規定；「農奴」和「大牛」們依然擺出關我屁事的姿態，只是農奴看書的時候把頭埋的更低了，大牛們在寫代碼的間隙，會抬頭眺望窗外，若有所思。作為不服管教的一撮人，自然是強烈的反對，再聯想來了一年了，公司對加薪一事只有書面提過，CMMI文檔還躺在SVN里。我覺得快要達到爆發的臨界值。其實，我們程序猿都是很善良的，真的為了公司的項目可以整日加班，挑燈夜戰，只是，時間長了，付出和回報不成正比，心也就冷了。俺帶人時間不長，不過也總結了一些方法和道理，雕蟲小技，眾位莫笑。1.團隊要規范： 從項目使用工具到代碼規范，最好統一，有利於項目集成和維護。一個項目立項到結項，編碼、測試、日誌、監控、文檔……，每個環節都很重要，關系著項目質量和進度，從這些環節抓規范，建立起一套良性體系，不論是對於成員還是項目本身，都是好處多多的。在項目組不忙的時候，適時的安排一些項目組會用到的技術進行鑽研，寫成文檔並做簡短的培訓分享，對技術總結，口頭表達和書面總結能力的提升都是有益處的。2.成員管理： 對於新手，要用正確的方法積極引導，鼓勵他們多動手，不要埋頭看書，畢竟看書和實際寫代碼差別還是很大的，每次帶新人我都戰戰兢兢，一開始的習慣很可能影響到他們今後職業生涯，每每想到這點，肩上壓力倍增。對於老手，要善於發揮他們的長處，以此帶動項目組其他成員，共同進步。平時要多關心了解組員，讓他們覺得項目組就像家一樣，大家都是兄弟，在攻堅克難的時候，這種團結有愛的環境對於解決問題有奇效。在公司損害到成員利益的時候要堅決和成員站在統一戰線。3.工作流程： 編程是一件需要專注去做的事情，所以在日常工作中，在不影響項目進度的情況下，流程越簡單越好，繁雜不合理的流程會讓項目進度嚴重拖延，且打擊團隊士氣。4.對於公司： 真的希望有些對這個行業不懂的老總能看到，不要再用你的一家之見來做出錯誤的管理決定，殘害手下的員工了。這個行業和傳統行業不同，不是請幾個講師就可以把公司管理好的，那是狗屁。每年請講師花幾萬，從裡面拿出一部分獎勵給工作出色的員工，效果要好的多。而且我們這個群體非常善良，你不提加薪，我們很多時候都不好意思提，真的。可是程序員也是人，人心易冷，那些新人累死累活工作一年多，還拿著兩千露頭的工資，每天還在喊著讓他們加班趕進度，可能嗎，對了，現在加班費都沒，晚上加班連晚飯都不提供一頓，我只能呵呵？即使你把人留在辦公室，心早已不在了。今天牢騷到這里吧，只要我在公司一天，就不能讓這些不合理的東西影響到我的組員，我會戰斗到底。最後，最近研究學習Swing，得到園子里不少大牛（不加引號的哦）的幫助，俺心裡十分感激，等俺學成歸來，一定出個專輯，好好報答各位園友。 多謝各位建議，小弟俺現在待遇還不錯（算是嫡系優待吧），只是看不慣那些「和珅」黨，並試圖找出自己的管理之道作為對公司亂搬亂套管理模式的回擊，畢竟手下還有六七個人，我走了就真的沒人帶這些兄弟了，他們也不會自己爭取利益，真的是很善良的小兄弟，所以在我吃飽喝足的情況下，不能讓兄弟們挨餓受氣。
『伍』 如何做好技術團隊管理
經常看到有人問程序員適合做管理嗎，或者手底下有牛人比我技術更好怎麼辦，或者感嘆一下做管理好難啊之類的。同時，相當大的一部分程序員都夢想著走所謂專家路線--並不是因為對技術特別有興趣或者覺得自己特別適合走技術路線，真正的原因是對管理工作的恐懼，覺得自己搞不定定。做管理真的很難嗎，程序員出身到底適不適合做管理，我可以斬釘截鐵的告訴你：不難！適合！ 上面的答案顯然並不完全正確。不過我們今天我們討論的並不是管理一個國家那樣的管理 ，也不是管理一個公司或者半個公司這樣的管理--絕大部分程序員同志們短時間內都不會有這樣的機會，這樣的話題也完全超出了我的知識范疇。我們今天討論的只是基礎的簡單的管理，小到幾個人的小組大到十幾二十個人的團隊，再大的都不在討論之列，而且僅限於軟體行業。所有的爺爺都是從孫子走過來的，做管理也一樣都是從小小管理一點一點慢慢做大的。 這個問題問的很多，但是實際上管理一個團隊更容易碰到的也是更頭疼的問題是團隊里沒有牛人怎麼辦，所以用流行的話說要懷著感恩的心看待這個問題。有牛人意味著你可以在一定程度上脫離繁重的開發或者設計工作把更多的時間放在做好管理和決策等清閑的工作上，意味著你有精兵強將可以完成更有挑戰性的項目，意味著你的團隊可能創造更多的效益使你的管理工作看起來更出色，等等。這都是有牛人的好處。 但是，但凡牛人多少可能有點牛脾氣，不好管。但是這個不好管究竟多大程度上是因為牛人的問題，又有多大程度是因為管理者的問題是必須要搞清楚的。 管理牛人與管理普通員工並無太大的區別，只是要更慎重更懂得平衡和技巧。因為牛人通常在團隊里的影響力比較大，做好牛人的工作管理就已經成功大半了，以下是一些要點，其他的自己任意添加： 最重要的一點是要保持自信，既然能做到這個位置必然有自己的過人之處，找到它們並充分發揮； 倚重但不依賴牛人，並且讓牛人自己也知道這一點； 注意培養新人，只有一個牛人並且有野心才是最危險的事，自己帶起來的兵最可靠； 二、道與術 很多講人講管理喜歡扯到道與術上去，特別是半吊子的管理者更喜歡講道，似乎道總是比術高一個層次。例如很多人看到我們上一個話題的討論就會跳出來大叫，你只講到了術的層次，還要從道的層次考慮；還有人會說，這樣是玩弄權術，不行，做管理要靠心，以心換心。 講以心換心的同學未免太過天真了，在社會上混幾年的人都應該知道這一條並不總是成立的，哪怕我們寧願相信它成立。做管理當然要待人以誠、以心換心，但是這並不構成做好管理的充分條件，一個在戰略方向上總是舉棋不定的領導哪怕人再好也會導致下屬喪失安全感從而不願意追隨。 道與術的關系本質上就是一個指導思想與具體手段的關系，是心法與招式的關系，固然脫離了心法的招式容易走向混亂，但也從來沒有一種心法能夠凌駕於所有的招式之上並且脫離招式而獨立存在。所以，所謂的道並不是很高深很神秘的東西，它只是給我們的管理工作提供一個總體的方向，所有的具體工作都是圍繞著這個方向進行。我自己總結出來的管理好一個團隊必須要做好的勉強能稱之為道的幾個方面如下： 保持團隊的進步感，讓團隊成員感覺到自己每隔一段時間都能學到新的東西，值得為之付出的努力； 保證團隊成員的歸屬感和自豪感，這樣的團隊才有凝聚力。 三、無為而治是很扯淡的事 《英雄》中的始皇帝說用劍的最高境界是不殺，這句話直接導致了無名丟掉了自己的劍。有人喜歡把這話套用到管理上--管理的最高境界是不管，我想說的是千萬不要被這樣的話忽悠了，也千萬不要拿這樣的話忽悠自己。 無為而治的境界雖高，但不是我等屁民能達到的，而且它有一個前提：虛其心、實其腹，弱其智、強其骨，常使民無知無欲，一句話講就是愚民政策。而我們帶團隊不是帶著大家吃吃喝喝沒事打打球強骨弱智的，這是奧巴馬要做的事，我們要辛辛苦苦的寫代碼要辛辛苦苦的給資本家創造剩餘價值 ，所以我們還是要實實在在的做管理。 無為而治要不得，更要不得的是以無為而治為借口掩飾自己的無能。一些不合格的管理者可能害怕管、或者懶得管，心裡過意不去就拿類似這樣的借口來欺騙自己，時間久了連自己也相信起來於是就像阿Q似的飄飄然覺得自己也成了革命者。比如看到下屬上班時開小差不管，下屬犯了錯誤也不批評指正，甚至對下屬上班時間接私活爭一隻眼閉一隻眼，然後欺騙自己說大家都是打工的都不容易，想做點什麼就做點什麼好了，反正吃虧的是老闆是資本家。看起來似乎是看破了紅塵，閑雲野鶴，淡然處之，孰不知這樣的心態會直接斷送掉自己的管理生涯，對自己的下屬也沒有半點的好處，若干年後（如果團隊還沒散掉的話）自己和自己團隊既沒有什麼進步也找不到值得自豪的回憶，這才是真正的悲哀。 《技術領導之路》一書中講到一個故事：一個團隊共同處理一個技術難題，成員A積極的組織大家討論，但多次嘗試都沒有成功，成員B獨自思考並成功的解決問題，最後問團隊成員最有影響力的時候大家選擇了A。 可見，影響力並不僅僅是由技術牛不牛、能不能解決問題和能解決多少問題決定的。影響力的關鍵在影響二字，你的每一個能對其他人產生影響的行為慢慢累積起來就組成了影響力。判斷影響力也很簡單，其他人是不是願意征詢你的意見、是不是願意相信你的意見都反映這你的影響力的大小，更簡單的判斷是你在團隊中有沒有小弟，有多少個小弟。如果你團隊的成員有一半以上都是你的小弟，你想不做管理都難。 影響力的來源因素有很多，年齡、職位、技術能力、性格、學歷等等都會對你的影響力產生影響，但沒有一項是決定性的。所以可以讓你稍微寬心的是你手下的牛人未必有足夠的影響力，然而你必須要擔心的是雖然你是領導但也未必在團隊中有與你地位相稱的影響力，如果你的某個野心勃勃的手下比你的影響力還要大那你就要小心了，不及早的扭轉局勢很快你可能就會被取而代之。 啰啰嗦嗦說了這么多，其實我自己做管理的經驗非常有限，而且也僅限於比較基礎的團隊管理和項目管理工作。但是對於我這樣一個從小就被我媽數落不是當官的料、被所有認識的人都認為是特別適合做技術、性格內向又有深深自卑感的人來說，能走上管理崗位並且做的不輸於其他的同事已經充分證明了做管理並不是一件難到讓人恐懼的事，雖然不容易但也不比做技術更難。不要相信做技術的不適合做管理之類的鬼話，說這話的人要麼是怕你轉作管理搶了他的位置，要麼是公司害怕技術人員流失沒人幹活故意這么宣傳的。適不適合做管理只和你自己這個人有關系，和出身無關。
『陸』 如何做好軟體項目的團隊管理
決定項目成敗的不僅僅是范圍、成本、進度的計劃多麼完美，而是團隊是否能高效的工作。說到項目管理，很多人都會記得范圍管理、成本管理、進度管理，這些都是衡量項目成敗的要素，重視對這些要素的管理，無可厚非，但卻忘了一個根本的問題，那就是：所有的這些目標都將是團隊來完成的。計劃做的再好，沒有人去實現，或者沒有忠誠的成員去實現，那豈不是空談。
或許跟其他的項目不同，軟體項目徹底是"以人才為核心"的項目，項目的主要成本來自於人力成本、項目的進度完全由成員決定，因此，在軟體項目中，對團隊的管理不僅僅是對進度的保障，更是對項目質量、項目成本的保障。團隊管理才是軟體項目管理中的重中之重。
然而，軟體項目中的項目經理往往缺少團隊管理的意識，這可能跟他們的發展歷程有關。軟體行業中，很多項目經理都是從程序員做起來的，我們都知道，程序員的職業發展規劃路徑都是"程序員--高級程序員--項目經理"。而串起這條職業路徑的線，就是技術，這就導致了只要技術高，五六年自然都發展成為項目經理了。而軟體的技術高手在溝通方面都普遍存在很大的問題，他們不善於跟團隊成員交流、不善於人際關系、不善於鼓勵與傾聽，他們都喜歡獨立的研究技術問題，在大家的記憶里，很多電影里，軟體高手就是那種一個人可以破jie國家安全密碼的人，他們往往不可能是整個團隊的管理者。
『柒』 如何管理技術團隊
團隊管理的事情很多，尤其當團隊規模更大時，如產品研發、市場支持、業績考核、日常溝通、學習培訓、工作氛圍等，以及更多的日常瑣事，如果沒有一個好的管理思路，團隊管理者往往被弄得手忙腳亂，不知所措，成天累得要死，還得不到團隊的理解和認可，或者團隊也被折騰的很疲倦。如果整理一下，我覺得可以把技術團隊的工作歸納為三個「力」，即團隊的凝聚力、戰鬥力和成長力，重點做好這三件事，會使團隊管理工作事半功倍，得心應手。
隨著現代項目日益復雜和行業跨度越來越大，技術團隊的活動往往需要靠團隊作戰的方式，單槍匹馬的時代已逐漸遠去。擁有一個好的團隊，是工作成功的一個重要的保障，因此團隊管理和建設是團隊管理者的一個重要工作。
所謂凝聚力，可以理解為團隊成員的向心力、對團隊目標的認可和共識程度等。在任何時候，管理者都應該能確保團隊成員對團隊的戰略目標達成共識，使大家都用共同的目標；確保團隊的認識是一致的，都能自覺主動心甘情願的為目標去努力。「一切行動聽指揮」。要保證團隊有凝聚力，需要管理者能做好戰略溝通和目標溝通。
所謂戰鬥力，可以理解為團隊的執行力了。三分戰略七分執行，說明執行往往來的更重要。在技術團隊中，不缺少聰明的人才，不缺少高明的點子，也不缺少高手，但整個團隊的執行力如何，是影響整個事情的進展。團隊如果能踏踏實實的把東西做出來，按時交付出來，遠比其他都要重要，現在的「敏捷開發」提倡的也就是這種思想。另外一種團隊的戰鬥力，就是團隊具有突擊能力，比如當遇到緊急項目時，只要一聲令下，大家就能各就各位，能都夠加班加點，不怕辛苦，在預期時間把項目搞定。
所謂成長力，可以理解為團隊的學習和自我學習能力。團隊要發展，要有長足的發展，那麼團隊必須要有學習和成長，不斷吸取新知識，不斷創新，不斷改進工作中不好的地方，不斷提高工作效率，將技術最高效轉化為生產力。團隊的不斷成長，才能使團隊有能力迎接新的任務，有不斷的創造力。一個不善於學習的團隊，一個不成長的團隊，終究會因時代的進步淘汰掉，終會因項目的時間積累而把團隊拖跨。
凝聚力是思想，戰鬥力是行動，成長力是後盾力量，三者很好的結合，就能是團隊管理工作變得有序有效，團隊也將成為優秀團隊。那麼，如何提高凝聚力、戰鬥力和成長力，每個管理者、每個團隊的情況都不通，可以採用的辦法也不同。不管採用什麼方法，管理者時刻需要對這三個「力」的情況不斷檢查，不斷改善。
http://blog.jobbole.com/6997/
『捌』 如何做好一線互聯網技術團隊管理
經常看到有人問程序員適合做管理嗎，或者手底下有牛人比我技術更好怎麼辦，或者感嘆一下做管理好難啊之類的。同時，相當大的一部分程序員都夢想著走所謂專家路線--並不是因為對技術特別有興趣或者覺得自己特別適合走技術路線，真正的原因是對管理工作的恐懼，覺得自己搞不定定。做管理真的很難嗎，程序員出身到底適不適合做管理，我可以斬釘截鐵的告訴你：不難！適合！ 上面的答案顯然並不完全正確。不過我們今天我們討論的並不是管理一個國家那樣的管理 ，也不是管理一個公司或者半個公司這樣的管理--絕大部分程序員同志們短時間內都不會有這樣的機會，這樣的話題也完全超出了我的知識范疇。我們今天討論的只是基礎的簡單的管理，小到幾個人的小組大到十幾二十個人的團隊，再大的都不在討論之列，而且僅限於軟體行業。所有的爺爺都是從孫子走過來的，做管理也一樣都是從小小管理一點一點慢慢做大的。 這個問題問的很多，但是實際上管理一個團隊更容易碰到的也是更頭疼的問題是團隊里沒有牛人怎麼辦，所以用流行的話說要懷著感恩的心看待這個問題。有牛人意味著你可以在一定程度上脫離繁重的開發或者設計工作把更多的時間放在做好管理和決策等清閑的工作上，意味著你有精兵強將可以完成更有挑戰性的項目，意味著你的團隊可能創造更多的效益使你的管理工作看起來更出色，等等。這都是有牛人的好處。 但是，但凡牛人多少可能有點牛脾氣，不好管。但是這個不好管究竟多大程度上是因為牛人的問題，又有多大程度是因為管理者的問題是必須要搞清楚的。 管理牛人與管理普通員工並無太大的區別，只是要更慎重更懂得平衡和技巧。因為牛人通常在團隊里的影響力比較大，做好牛人的工作管理就已經成功大半了，以下是一些要點，其他的自己任意添加： 最重要的一點是要保持自信，既然能做到這個位置必然有自己的過人之處，找到它們並充分發揮； 倚重但不依賴牛人，並且讓牛人自己也知道這一點； 注意培養新人，只有一個牛人並且有野心才是最危險的事，自己帶起來的兵最可靠； 二、道與術 很多講人講管理喜歡扯到道與術上去，特別是半吊子的管理者更喜歡講道，似乎道總是比術高一個層次。例如很多人看到我們上一個話題的討論就會跳出來大叫，你只講到了術的層次，還要從道的層次考慮；還有人會說，這樣是玩弄權術，不行，做管理要靠心，以心換心。 講以心換心的同學未免太過天真了，在社會上混幾年的人都應該知道這一條並不總是成立的，哪怕我們寧願相信它成立。做管理當然要待人以誠、以心換心，但是這並不構成做好管理的充分條件，一個在戰略方向上總是舉棋不定的領導哪怕人再好也會導致下屬喪失安全感從而不願意追隨。 道與術的關系本質上就是一個指導思想與具體手段的關系，是心法與招式的關系，固然脫離了心法的招式容易走向混亂，但也從來沒有一種心法能夠凌駕於所有的招式之上並且脫離招式而獨立存在。所以，所謂的道並不是很高深很神秘的東西，它只是給我們的管理工作提供一個總體的方向，所有的具體工作都是圍繞著這個方向進行。我自己總結出來的管理好一個團隊必須要做好的勉強能稱之為道的幾個方面如下： 保持團隊的進步感，讓團隊成員感覺到自己每隔一段時間都能學到新的東西，值得為之付出的努力； 保證團隊成員的歸屬感和自豪感，這樣的團隊才有凝聚力。 三、無為而治是很扯淡的事 《英雄》中的始皇帝說用劍的最高境界是不殺，這句話直接導致了無名丟掉了自己的劍。有人喜歡把這話套用到管理上--管理的最高境界是不管，我想說的是千萬不要被這樣的話忽悠了，也千萬不要拿這樣的話忽悠自己。 無為而治的境界雖高，但不是我等屁民能達到的，而且它有一個前提：虛其心、實其腹，弱其智、強其骨，常使民無知無欲，一句話講就是愚民政策。而我們帶團隊不是帶著大家吃吃喝喝沒事打打球強骨弱智的，這是奧巴馬要做的事，我們要辛辛苦苦的寫代碼要辛辛苦苦的給資本家創造剩餘價值 ，所以我們還是要實實在在的做管理。 無為而治要不得，更要不得的是以無為而治為借口掩飾自己的無能。一些不合格的管理者可能害怕管、或者懶得管，心裡過意不去就拿類似這樣的借口來欺騙自己，時間久了連自己也相信起來於是就像阿Q似的飄飄然覺得自己也成了革命者。比如看到下屬上班時開小差不管，下屬犯了錯誤也不批評指正，甚至對下屬上班時間接私活爭一隻眼閉一隻眼，然後欺騙自己說大家都是打工的都不容易，想做點什麼就做點什麼好了，反正吃虧的是老闆是資本家。看起來似乎是看破了紅塵，閑雲野鶴，淡然處之，孰不知這樣的心態會直接斷送掉自己的管理生涯，對自己的下屬也沒有半點的好處，若干年後（如果團隊還沒散掉的話）自己和自己團隊既沒有什麼進步也找不到值得自豪的回憶，這才是真正的悲哀。 《技術領導之路》一書中講到一個故事：一個團隊共同處理一個技術難題，成員A積極的組織大家討論，但多次嘗試都沒有成功，成員B獨自思考並成功的解決問題，最後問團隊成員最有影響力的時候大家選擇了A。 可見，影響力並不僅僅是由技術牛不牛、能不能解決問題和能解決多少問題決定的。影響力的關鍵在影響二字，你的每一個能對其他人產生影響的行為慢慢累積起來就組成了影響力。判斷影響力也很簡單，其他人是不是願意征詢你的意見、是不是願意相信你的意見都反映這你的影響力的大小，更簡單的判斷是你在團隊中有沒有小弟，有多少個小弟。如果你團隊的成員有一半以上都是你的小弟，你想不做管理都難。 影響力的來源因素有很多，年齡、職位、技術能力、性格、學歷等等都會對你的影響力產生影響，但沒有一項是決定性的。所以可以讓你稍微寬心的是你手下的牛人未必有足夠的影響力，然而你必須要擔心的是雖然你是領導但也未必在團隊中有與你地位相稱的影響力，如果你的某個野心勃勃的手下比你的影響力還要大那你就要小心了，不及早的扭轉局勢很快你可能就會被取而代之。 啰啰嗦嗦說了這么多，其實我自己做管理的經驗非常有限，而且也僅限於比較基礎的團隊管理和項目管理工作。但是對於我這樣一個從小就被我媽數落不是當官的料、被所有認識的人都認為是特別適合做技術、性格內向又有深深自卑感的人來說，能走上管理崗位並且做的不輸於其他的同事已經充分證明了做管理並不是一件難到讓人恐懼的事，雖然不容易但也不比做技術更難。不要相信做技術的不適合做管理之類的鬼話，說這話的人要麼是怕你轉作管理搶了他的位置，要麼是公司害怕技術人員流失沒人幹活故意這么宣傳的。適不適合做管理只和你自己這個人有關系，和出身無關。
『玖』 如何管理好一個團隊 讓每一位程序員
對研發人員考核建議要過於強調結應該注重對過程關注程序員種腦力勞動類似於研發考核由於其工作性質本身要求創造性結比較難於掌握單純強調考核會打壓其本身工作積極性符合客觀規律 人覺得對們考核只要能確定們認真工作、努力工作、態度端正切圍繞目標開展了！
『拾』 怎樣管理軟體開發團隊
高效軟體開發團隊的特徵
高效的軟體開發團隊是建立在合理的開發流程及團隊成員密切的合作的基礎之上的，成員共同的迎接挑戰、有效的計劃、協調和管理各自的工作以至完成明確的目標，高效的開發團隊具有如下特徵：
1、 具有明確且有挑戰性的共同目標 一個具有明確的而且有挑戰性目標的團隊比目標不明確或不具有很大的挑戰性目標的團隊效率高得多，通常技術人員往往會因為完成了某個明確的任務，而且這個任務的完成具有挑戰性的意義而感到自豪，反過來團隊成員為了獲取這種自豪的感覺而更加積極的工作從而帶來團隊開發的高效率，如作為系統設計人員很清楚的知道在什麼時候要做到什麼，什麼時候開始做，什麼時候必須完成，為了完成工作必須面臨哪些挑戰，怎麼解決這些困難等為設計出一個高質量的軟體項目提供了重要保證，而模模糊糊的去設計一個系統或模模糊糊的就去編寫代碼是非常危險的，而且會為此付出高昂代價，因此高效的軟體開發團隊具有挑戰性的共同目標。
2、 團隊具有很強的凝聚力 在一個高效的軟體開發團隊中，成員們凝聚為一個整體共同進行工作，他們是相互支持、互相交流、互相尊重的，而不是相互推卸責任、保守、相互指責的，在一些散亂的開發團隊中往往存在這樣的問題，一些程序員是比較保守的，明明知道另外的模塊中需要用到一段與自己已經編寫完成但有些難度的程序代碼，他也不願拿出來給其它程序員共享，不願與系統設計人員交流，這樣給項目的進度造成了些不可度量的因素。
3、 具有融洽的交流環境 在一個開發團隊中，每個人行使自己的職責，如需求分析人員制定需求規格說明、系統設計人員做系統概要設計和詳細設計、項目經理配置項目開發環境並且制定項目計劃等，但每個人的工作不可能做到完美的，如系統概要設計的文檔可能有個別地方詞不達意，做詳細設計的時候就可能會造成誤解，項目經理制定計劃時可能忽略了某種風險的存在而造成執行者過於緊張的壓力等等情況都需要大家通過交流、反饋的手段然後協商解決的，因此高效的軟體開發團隊是具有融洽的交流環境的，而不是那種簡單的命令執行式的。
4、 具有共同的工作規范和框架 高效軟體開發團隊具有規范性及共同框架的工作，對於項目管理具有規范的項目開發計劃，對於分析設計具有規范和統一框架的文檔及審評標准，對於代碼具有程序規范條例，對於測試有規范且可推理的測試計劃及測試報告等等。並且所有成員都明白自己的職責，知道必須完成什麼計劃？由誰來完成？什麼時候開始？什麼時候結束？按什麼順序？等，總之一個高效的開發團隊無論是工作內容還是工作流程都具有不同程度的規范性和標准風格的框架。
5、 採用合理的開發過程 軟體的開發不同於一般商品的研發和生產，開發過程中會面臨著各種難以預測的風險，比如需求的變化、人員的異動、技術的瓶頸、同行的競爭等，高效的軟體開發團隊往往是採用了合理的開發過程去控制開發過程中的風險、提高軟體的質量、降低開發費用，這樣的團隊會根據自身的必要程度決定要執行哪些工作？如配置管理、資源管理、版本控制、代碼控制等，團隊還合理的分劃並定義開發過程的里程碑，決定每項活動內容的底線和審評標准，決定各項活動的先後關系或迭代的關系等。總之高效的軟體開發團隊的開發過程的原則是高效率、高質量、低成本。