『壹』 如何帶領好一個軟體開發團隊
我記得10年前在cisco的一個面試， 幾個問題記憶尤深：
1） How do you recognize the contribution of your team member？
2）Can you remember the name of your team member's other part？
還記得大鬍子CEO講的一句話，一個團隊重要的是公平， 我覺得追求公平這是
人的天性。 我個人經驗， 公平是目標， 平衡是手段， 溝通是工具。
軟體開發團隊的難點在於你如何評估每個人的貢獻， 不容易。 單純的代碼量是沒意義的。
一個簡單的修改後面可能是幾天， 幾星期， 甚至更長時間的辛苦工作。 我曾經聽到過抱怨，
老闆問改動了多少， 哥們回答道1行， 老闆問要這么長時間？
所以好的軟體部門經理或項目經理， 要有sense，這是行業經驗積累來的。 還有就是溝通，
全面的溝通， 超出工作范圍的溝通， 溝通是彌補行業經驗的手段。
軟體開發團隊人的因素很強， 每個人就是一部」生產機器「，很多脾氣很大， 不好溝通。作為leader重要的是從哪裡， 哪方面為他們提供幫助， 我想除了技術之外還有很多， 你可以從這方面作為出發點。比如職業規劃， 比如人際關系。
一點拙見， 希望有幫組。
『貳』 如何解決軟體研發團隊管理的問題
高效軟體開發團隊的特徵
高效的軟體開發團隊是建立在合理的開發流程及團隊成員密切的合作的基礎之上的，成員共同的迎接挑戰、有效的計劃、協調和管理各自的工作以至完成明確的目標，高效的開發團隊具有如下特徵：
1、 具有明確且有挑戰性的共同目標
一個具有明確的而且有挑戰性目標的團隊比目標不明確或不具有很大的挑戰性目標的團隊效率高得多，通常技術人員往往會因為完成了某個明確的任務，而且這個任務的完成具有挑戰性的意義而感到自豪，反過來團隊成員為了獲取這種自豪的感覺而更加積極的工作從而帶來團隊開發的高效率，如作為系統設計人員很清楚的知道在什麼時候要做到什麼，什麼時候開始做，什麼時候必須完成，為了完成工作必須面臨哪些挑戰，怎麼解決這些困難等為設計出一個高質量的軟體項目提供了重要保證，而模模糊糊的去設計一個系統或模模糊糊的就去編寫代碼是非常危險的，而且會為此付出高昂代價，因此高效的軟體開發團隊具有挑戰性的共同目標。
2、 團隊具有很強的凝聚力
在一個高效的軟體開發團隊中，成員們凝聚為一個整體共同進行工作，他們是相互支持、互相交流、互相尊重的，而不是相互推卸責任、保守、相互指責的，在一些散亂的開發團隊中往往存在這樣的問題，一些程序員是比較保守的，明明知道另外的模塊中需要用到一段與自己已經編寫完成但有些難度的程序代碼，他也不願拿出來給其它程序員共享，不願與系統設計人員交流，這樣給項目的進度造成了些不可度量的因素。
3、 具有融洽的交流環境
在一個開發團隊中，每個人行使自己的職責，如需求分析人員制定需求規格說明、系統設計人員做系統概要設計和詳細設計、項目經理配置項目開發環境並且制定項目計劃等，但每個人的工作不可能做到完美的，如系統概要設計的文檔可能有個別地方詞不達意，做詳細設計的時候就可能會造成誤解，項目經理制定計劃時可能忽略了某種風險的存在而造成執行者過於緊張的壓力等等情況都需要大家通過交流、反饋的手段然後協商解決的，因此高效的軟體開發團隊是具有融洽的交流環境的，而不是那種簡單的命令執行式的。
4、 具有共同的工作規范和框架
高效軟體開發團隊具有規范性及共同框架的工作，對於項目管理具有規范的項目開發計劃，對於分析設計具有規范和統一框架的文檔及審評標准，對於代碼具有程序規范條例，對於測試有規范且可推理的測試計劃及測試報告等等。並且所有成員都明白自己的職責，知道必須完成什麼計劃?由誰來完成?什麼時候開始?什麼時候結束?按什麼順序?等，總之一個高效的開發團隊無論是工作內容還是工作流程都具有不同程度的規范性和標准風格的框架。
5、 採用合理的開發過程
軟體的開發不同於一般商品的研發和生產，開發過程中會面臨著各種難以預測的風險，比如需求的變化、人員的異動、技術的瓶頸、同行的競爭等，高效的軟體開發團隊往往是採用了合理的開發過程去控制開發過程中的風險、提高軟體的質量、降低開發費用，這樣的團隊會根據自身的必要程度決定要執行哪些工作?如配置管理、資源管理、版本控制、代碼控制等，團隊還合理的分劃並定義開發過程的里程碑，決定每項活動內容的底線和審評標准，決定各項活動的先後關系或迭代的關系等。總之高效的軟體開發團隊的開發過程的原則是高效率、高質量、低成本。
『叄』 IT公司的項目組入職了新的程序員，如何帶好這些新員工
不少軟體開發團隊每年都有新的開發人員要加入，其中以初級程序員居多，要想讓這些初級程序員能夠快速融入開發團隊並實現價值，需要從以下三個方面入手：
第一：以開發實踐能力進行人員劃分。 新入項目組的准程序員往往有兩種情況，一種情況是剛剛走出大學校門的計算機專業畢業生，另一種情況是自主學習通過面試的非計算機專業畢業生。這兩種准程序員在進入崗位之前可以根據實踐能力進行人員劃分，實踐能力較強的可以直接安排進項目組中，而實踐能力較差的准程序員則安排到實習崗位上。按照 歷史 經驗來看，不少實踐能力較差的程序員如果直接安排到開發崗位上，往往會導致其放棄這份工作。
第二：老帶新。 按照 歷史 經驗來看，讓程序員快速成長的方式無非就是通過實際項目的鍛煉，對於學習能力較強的程序員來說，如果有專人指導的情況下會很快融入到開發團隊中，有的程序員在一個月之內就可以完成功能模塊的開發。老帶新的原則有三點，其一是軟體開發團隊所使用的技術結構要交代清楚；其二是軟體開發過程中所使用的開發工具和開發流程要交代清楚；其三是給出具體的參考案例。
第三：安排清晰的工作任務。 對於初入項目組的開發人員來說，由於其自身的專業知識積累還比較少，在項目理解力上還有待提高，所以在安排具體開發任務的時候一定要詳細，越詳細越好，同時要給出明確的功能邊界，防止出現不可控的事情發生，比如哪些數據是不能動的，哪些功能和資源是不能調用的等等。有的時候「無知」是最可怕的敵人，不少初級程序員進行的「刪庫」等操作都是在「實驗」的心態下完成的。
如果有互聯網、大數據、人工智慧等方面的問題，或者是考研方面的問題，都可以在評論區留言！
我是程序員出身，現在也管理著一個項目，手下最多的時候也有十幾號人；但是說實話，在管理方面，我還是比較欠缺的，我也一直在學習和摸索；當項目組入職了新的程序員的話，我經常會這樣做：
先溝通，大方向要保持統一
每當項目組入職了新的程序員，我會第一時間和他們溝通，主要讓對方快速地知曉項目的基本信息，並了解我們大的方向、觀點、風格，我是希望在某些地方能和組員保持一致，例如：
制定計劃
下面就要給新人制定計劃了，這一點在前期很重要，否則新人就會面臨無事可做的尷尬；
安排開發任務
通常，我們一兩周後就會給新人安排一些開發任務，當然這個過程也是從易到難：
代碼檢查
對於新人，代碼檢查一定要做；如果是工作時間段的新人，每一行代碼都檢查一遍都不為過。
最後，我會給新人一些成長方面的建議，讓他們覺得在這個項目中能學到東西；畢竟我沒有權利給他們漲工資，只能通過這種方式留住員工了。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
建議從以下幾方面考慮：
1、人員能力考查和培養。人員的能力參差不齊，需要根據崗位進行有目標的培養；
2、業務技能提升。想把工作做好，不了解業務，不理解自己做的東西，早晚要出現與預期偏差較大的情況。
3、工作態度和心態的培養。
4、盡早了解項目內容和項目團隊，將人員在項目中的定位和需要的技術提前告知，告知項目計劃和提示工作的難點。
5、組織一點團隊活動，早點融入項目。
第一：熟悉你們開發工具、開發環境、運營環境……
第二：熟悉上下開發工序對接組別和責任人……比如開發該項目的前端、後台、測試等不同組別以及其他開發外項目組外的不同部門打交道的人員。
第三：項目說明書、整體功能、進程，所負責的分割模塊……要完完全全提供出來。
每個人都是從新人成長過來的，在我工作的五年間也帶過很多新人，最近剛好有個畢業生來公司實習，領導讓我帶，這邊就分享一下我具體是怎麼操作的(開發的角度):
總而言之，帶新人還是比較累的，對大部分公司而言，技術要求並不是很高，所以新人真的比較難上手的不是技術，而是業務和表結構邏輯的不熟悉，作為新人，公司的打算就是從零開始培養，因此基礎並不是最重要的，學習的態度才是公司看重的。
以上為個人觀點，歡迎在評論中發表自己不同的觀點，喜歡的加個關注，謝謝。
以十人以下的團隊來說一下。首先是和員工相處好，其實這一點做到並不難，就是正常的相處，怎麼愉快怎麼來（當然不能壞規矩）。我做的最大尺度一次是這樣：有個畢業生干著干著就哭了，一問之後知道直接原因是程序員的工作內容和自己原來想的不一樣，主要原因是剛到北京體會到了巨大的壓力。當時我就拉著她到對面肯德基去坐會了，點了飲料和薯條，聊了一下，順便開導開導她，舒緩一下情緒，這事就這么解決了。其次，作為領導請安排劃分好工作內容，不要頻繁變更，否則影響威望值。這也是保證工作可以順利開展的基礎。安排工作時請考慮員工的能力和經驗，還要考慮員工的興趣，這點也很重要，很大程度影響積極性。
在小團隊中只要工作能順利完成了，一般問題就不會很大了。其它：可以觀察一下每個人的喜好，然後看機會適度的介紹這方面的內容。比如我就專門給一個員工培訓過數據結構，而她也很願意介紹自己認識的人來工作，雙贏的結果。員工做好的地方及時表揚，自己做錯的地方及時承擔責任，等等。總之將心比心的對待員工，小團隊還是好帶的。
教會徒弟，餓死師傅，等你教會他們，你就該退了，理由：你三十多，奔四了，負擔大，不能加班，養不起你！中國現狀，保留必要絕活，留幾招吧！為養家！
先讓他做點小項目，鍛煉一下，把以前已經完成客戶的項目拿出來給他做，練手，看看功底如何
如果功底好，則主要鍛煉他的思維能力
如果功底不好則多鍛煉他的技能
首先是能力要過關，之後就是交流要能順暢，其他的問題都不是問題，只是經驗和熟悉而已。
『肆』 如何提高軟體開發團隊的協作效率
分工合理，責任明確
團隊是由個人組成的，團隊中的個人往往經歷不同、背景不同、性格有差異、水平有高低。在團隊形成後、正式開工前，首先應該進行合理分工，要結合每個人的特點和愛好，充分發揮出每個人的特長。因為如果工作不愉快、不順手的話，效率自然低下。分工完成後，每個人對應的職責也就確定了。這時應該同每一位團隊成員進行明確申明，最好以文字形式落實到個人並與日常績效考核掛鉤，以避免互相推諉、相互等待的情況出現。
制定高效的溝通機制
分工完成後團隊即開始工作，此時必須保證信息在整個團隊內的暢通，特別是互相之間有工作關聯的同事，在發現問題時需要及時提出，以免造成不必要的工時浪費。 但軟體開發本身是一種需要精力集中並且安靜的工作，多次臨時性的打斷會造成開發思路的停滯，因此團隊負責人最好能夠每天在固定的時間段內組織大家進行溝 通，並了解工作的進度。而固定的時間也會讓大家形成習慣，使效率得到提升。
發現團隊瓶頸
大家往往會陷入一種誤區，認為團隊中每個員工效率發揮到極致的時候就是這個團隊效率最高的時候。但經過企業管理實踐不斷的論證，這種想法其實是非常可怕的謬 論。正確的做法應該是將整個團隊看成一個整體，再去談效率問題。團隊的分工協作就好比是生產的流水線，流水線的整體生產效率不取決於流水線上效率最高的環節，而取決於效率最低、速度最慢的環節。當流水線上某一環節出現故障而停滯時，整個流水線也就停滯了。這也是常說的木桶原理。所以我們必須時刻去發現團隊 中的短板，盡一切力量幫助它，提高它的效率。這樣，也許會犧牲局部某些個人的效率，但經過一段時間的實施後，你可能會驚奇地發現整個團隊的效率變高了。
定期檢查，及時調整
流水線的機器是死的，而程序員們是活的。因此團隊的瓶頸也許會因為調整而發生變化，這時需要團隊負責人審時度勢，及時進行調整。也許需要修正前期的分工，也 許需要改變正在使用的技術，甚至是更換無法勝任的團隊成員。讓整個團隊的工作效率保持在一個較高的並且能夠相互匹配的水平，這樣做非常重要。
總結
團隊是一個整體，不能靠每個員工進行單打獨斗，要始終牢記團隊的最終效用取決於團隊中效率最低的環節。進行合理分工是預防瓶頸發生的前提，而建立高效的溝通 機制則是發現瓶頸的有效方法。當瓶頸環節出現後要盡團隊最大力量去發揮其效用，而當瓶頸發生變化時需及時做出調整，才能提高團隊協作的效率。