金仕達衛寧軟體科技有限公司首席架構師李楓：審時度勢，及時調整
分工合理，責任明確
團隊是由個人組成的，團隊中的個人往往經歷不同、背景不同、性格有差異、水平有高低。在團隊形成後、正式開工前，首先應該進行合理分工，要結合每個人的特點和愛好，充分發揮出每個人的特長。因為如果工作不愉快、不順手的話，效率自然低下。分工完成後，每個人對應的職責也就確定了。這時應該同每一位團隊成員進行明確申明，最好以文字形式落實到個人並與日常績效考核掛鈎，以避免互相推諉、相互等待的情況出現。
制定高效的溝通機制
分工完成後團隊即開始工作，此時必須保證信息在整個團隊內的暢通，特別是互相之間有工作關聯的同事，在發現問題時需要及時提出，以免造成不必要的工時浪費。但軟體開發本身是一種需要精力集中並且安靜的工作，多次臨時性的打斷會造成開發思路的停滯，因此團隊負責人最好能夠每天在固定的時間段內組織大家進行溝通，並了解工作的進度。而固定的時間也會讓大家形成習慣，使效率得到提升。
發現團隊瓶頸
大家往往會陷入一種誤區，認為團隊中每個員工效率發揮到極致的時候就是這個團隊效率最高的時候。但經過企業管理實踐不斷的論證，這種想法其實是非常可怕的謬論。正確的做法應該是將整個團隊看成一個整體，再去談效率問題。團隊的分工協作就好比是生產的流水線，流水線的整體生產效率不取決於流水線上效率最高的環節，而取決於效率最低、速度最慢的環節。當流水線上某一環節出現故障而停滯時，整個流水線也就停滯了。這也是常說的木桶原理。所以我們必須時刻去發現團隊中的短板，盡一切力量幫助它，提高它的效率。這樣，也許會犧牲局部某些個人的效率，但經過一段時間的實施後，你可能會驚奇地發現整個團隊的效率變高了。
定期檢查，及時調整
流水線的機器是死的，而程式設計師們是活的。因此團隊的瓶頸也許會因為調整而發生變化，這時需要團隊負責人審時度勢，及時進行調整。也許需要修正前期的分工，也許需要改變正在使用的技術，甚至是更換無法勝任的團隊成員。讓整個團隊的工作效率保持在一個較高的並且能夠相互匹配的水平，這樣做非常重要。
總結
團隊是一個整體，不能靠每個員工進行單打獨鬥，要始終牢記團隊的最終效用取決於團隊中效率最低的環節。進行合理分工是預防瓶頸發生的前提，而建立高效的溝通機制則是發現瓶頸的有效方法。當瓶頸環節出現後要盡團隊最大力量去發揮其效用，而當瓶頸發生變化時需及時做出調整，才能提高團隊協作的效率。
杭州雲圖科技有限公司研發總監，資深項目管理專家塗勇：提升研發團隊協作效率的四個秘訣
要提升研發團隊的協作效率，我認為可從目標、規則、溝通和工具四個方面入手。
目標，讓團隊成員有明確的前進方向
清晰明確的團隊目標可以對團隊高效協作形成很強的牽引力，更重要的是，團隊目標是團隊成員個人目標制定的前提。要讓團隊高效率的協作，最好的方法就是讓團隊所有成員每時每刻的工作都圍繞團隊目標開展。需要指出的是，將團隊的目標分解成近期目標、中期目標和遠期目標是一個值得推薦的做法。此外，少數優秀的團隊管理者甚至能夠將團隊的遠期目標上升到團隊使命感和價值觀的高度。要做到這點，管理者需具備卓越的領導力。
具體到研發管理，對項目而言，明確項目目標並不困難，諸如產品發布、系統上線等這些都可以作為項目目標，並且項目經理也可以很容易以項目計劃的形式來加以落實。但對職能部門的管理者而言，制定好職能部門的目標就很考驗管理水平。職能部門的經理不應忽視部門目標的重要性，而這可以與團隊成員的個人職業發展目標結合起來考慮。
規則，讓團隊成員始終保持住隊形
高效率團隊運作，一定有良好的團隊規則做保證。明確告訴團隊成員，什麼樣的行為是團隊所不能容忍的，並將其形成制度。制度違反者都應受到相應的懲罰，並做到及時（第一時間）、公平（一視同仁）、公開（團隊內部）。制度是團隊的高壓線，不堅決執行的制度還不如沒有制度，記住這點很重要。
如果說制度告訴團隊什麼事不能做，那麼規範就是告訴團隊成員尤其是新進入團隊的成員應該怎樣做。文檔規範、編程規範、原理圖設計規範等開發規範，是團隊高效率協作的保證。規範不是制度，可以容忍一時不遵守規範的情況，但應該讓團隊在遵守規範方面做得越來越好。培訓、優秀案例和反面教材宣傳等都是推行規範的好實踐。另外，規範不是高壓線，不贊成對違反規範的成員進行懲罰，最好的方式是對在規範方面做得優秀的人進行公開表揚。
制度和規範都是針對的人，對事來說規則即是流程。沒有高效率的工作流程，也就沒有高效率的團隊。對於牽涉多人協作的工作，即使是一個設計不完備的流程也比沒有流程好。值得指出的是：流程應該隨著團隊內外部的環境變化而做持續優化，在一些大公司中甚至會成立專門的流程改進小組，足見流程持續優化的重要性。
溝通，讓團隊成員凝聚成一個有機的整體
良好的溝通對一個高效率團隊有多麼重要，熟悉Scrum的朋友對此會有更深刻的體會。「坐到一起，每日站立會議，Review會議」，Scrum在團隊溝通方面推崇的最佳實踐都體現了溝通的重要性。為什麼很多公司搬入新辦公大樓後就開始走下坡路？下面的這個分析很可能就是主要原因：團隊成員在新辦公區的座位會比以前拉得更大，以前與團隊成員坐在一起的主管們搬入了獨立的辦公室，而這會導致團隊間原來形成的良好溝通氛圍消失，其後果嚴重到足以給企業帶來致命打擊！好吧，我承認這聽起來有點駭人聽聞，目的只是想藉此強調一下溝通的重要性。
通過開會來達到團隊溝通的目的是一種好的方式嗎？有人會說是，有人會說不是。其實，開會這種方式，無所謂好與不好，關鍵就兩點：是否有必要開會以及開個什麼樣的會。我的個人感觸：一人用嘴大家用耳的會應該是表彰大會；開了跟沒開一樣的會最好是批判大會；如果開會有人睡著了，大多數情況下是因為會議本身具有催眠效果。
相比開會這種溝通方式，我更喜歡現場管理和看板管理。
工具，是團隊高效率協作的倍增器
這方面最容易讓人想到的也是大多數團隊目前所採用的方法就是：引入適合團隊的協同軟體。前面介紹的明確目標、制定規範和加強溝通等方面的措施，如果能有合適的團隊協同工具支持和配合，推行起來則要順利很多。
如何選擇一款合適的協同軟體呢？引入的協同軟體貴在精而不在多，功能完備集成性好的協同軟體可以避免引入過多系統而產生的信息孤島。側重自上而下管控的IT系統只會在規範團隊方面起作用，要提升團隊協作效率，更應該選擇實現注重協作性的系統。免費的協同軟體大多不如付費的，但價格昂貴的協同軟體對多數團隊而言並不適合。
優秀的管理者的工具箱中，總是會有各種各樣的寶貝。諸如團隊績效、團隊競爭等都是激發團隊成員潛能和鬥志的好方法，實施得好的話，可以顯著提升團隊成員間的協同效率。
如果你正好在帶團隊，不妨嘗試一下上面提到的這些方法，相信你的團隊的協作效率一定會越來越高。
Pragmatic.ly 聯合創始人，Teahour.FM主播系統架構師葉玎玎：創業型開發團隊的協作心得
毫無疑問，Stephen R. Covey的《The 7 Habits of Highly Effective People》和David Allen的 《Getting Things Done: The Art of Stress-Free Productivity》是個人管理類的超級暢銷書，讓我們學會如何才能成為高效能人士。然而，即使團隊裡的所有人都是高效能人士，這個團隊也不一定是個高效能團隊。我們常說「一個和尚有水喝，兩個和尚挑水喝，三個和尚沒水喝」，正是出於這個道理。顧名思義，團隊協作是指所有團隊成員之間協同、合作，裡面會有分工、溝通、協調，甚至會有妥協，所以我們需要一些規則和工具來幫助團隊提高協作效率。本文的一些心得和實踐來自於我在小團隊（<10）的經驗，並且在團隊內部相互信任、目標一致的基礎上，所以不涉及辦公室人事管理，適合於創業型開發團隊。
目標一致
不僅要確保團隊的長期目標一致，還要確保短期目標一致。如同在足球場踢球，剛開始比賽時，大家戰術和思想都是一致的。而一旦進球後，就會出現有人想守，有人想攻的情況，這種不一致會造成局面被動並可能導致輸球。創業團隊也是如此。所以在任何時候，團隊成員都要保持一致意見：現階段的目標是什麼，什麼事情對團隊最重要，然後所有做的事情都配合這個目標來完成。
合理安排
小團隊人少，永遠有做不完的事，所以在做計劃時總是害怕資源出現閒置而添加過多任務。我們一開始也是如此。但慢慢發現，這樣不僅弄得團隊身心俱疲，不停地趕進度，而且也會因為不停地延期導致團隊很沮喪、壓力過大影響工作的心情和狀態。因此，現在每次迭代只會給大家80%~90%的工作量。有意思的是，很多時候時間都是剛剛夠。
易者優先
如果討論時遇到意見分歧，且這些不一致的意見不涉及對錯，那麼會很容易陷入各自試圖說服別人接受自己觀點的困境，純屬浪費時間。所以我們採用易者優先原則，設置了單任務最長討論時間。一旦超過討論時間又無法達成共識，就會選擇最簡單的方案，先做出來，然後大家測試，最後再做改進。
免擾模式
確定項目計劃後，我們就基本啟動了免擾模式。我們不鼓勵在工作時隨意地打斷別人，即使是一起在辦公室工作時。在我們看來，每一次粗暴的打擾（例如電話、IM）都是對效率的損害，我們更需要的是100%專注在要做的事情上。因此，我們要求每個人如果需要討論，就先想清楚整個問題，然後在Pragmatic.ly或者Hipchat裡發出來。短時間來看可能回復會有延時，但從長期來看反而能讓大家都能更深入的思考、更專注的工作。
儘量避免會議。只有一個例外是遇到困難需要頭腦風暴時，因為開會比起文字是效率更高的選擇。但只有任務涉及者才需要參與，而不需要浪費其他人的時間。
狀態同步
團隊人越多，溝通成本越高，尤其是需要知道團隊的當前狀態時，例如目前進度如何，接下來有哪些事情要做，做完的時候需不需要其他成員幫忙審查，或者有沒有卡在某些地方需要幫助。這些狀態和信息同步是非常耗時的，我們更傾向於用眼睛看代替嘴巴說，而 Pragmatic.ly就很好地滿足了這點。項目裡的所有信息和狀態都會實時地同步給整個團隊。
代碼審查
作為開發團隊，我們不一定能保證每個任務都有充足的測試覆蓋而且也不追求100%覆蓋率。但每一段代碼、每一次修改，都必須有其他人來審查，通過後才能進入主幹。代碼審查中可以發現當事者沒考慮過的設計細節和一些實現上的Bug，保證了軟體質量。通過代碼審查，每個人可以學習到其他人好的思維方式和編碼方式，也會提出做的不好的地方和改進意見，是整個團隊在代碼級別的另一種溝通和思考，促進了團隊的成長。代碼審查也能避免單點故障，萬一出了問題，即使代碼編寫者不在，仍然有其他人能立刻去修正。
過程審查
除代碼需要審查外，過程也是一個很有審查必要的事情。所以我們會不定時地一起進行一次簡單的回顧，各自對這個周期的一些工作提出意見，然後在下一個周期裡有針對性地改進。整個工作過程就是這樣不斷地在迭代式調整和改進，讓我們根據自身的情況，實踐出最適合團隊的方式。
健康工作
要想工作好，身體先練好。一個健康的成員才可能高效地工作。在Y Combinator有個理論，在產品發布前，你應該專注並只專注兩件半事情，1開發+1跟用戶聊天+0.5鍛鍊身體。而在產品發布後，你應該專注並只專注三件事情，0.5開發+1跟用戶聊天+1運營+0.5鍛鍊身體。可見鍛鍊身體的重要。我們團隊每個人基本每天都會有專門的運動時間，跑步、遊泳，或者健身房，已然成了我們工作的一部分。
本文為《程式設計師》原創文章，未經允許不得轉載，如需轉載請聯繫market#csdn.net(#換成@)