如何提升團隊協做的效率

http://blog.csdn.net/xiaoting451292510/article/details/13022539

摘要：軟件開發是一項團隊活動，必然須要團隊成員間的交流與協做。由此，如何提升團隊協做的效率便成爲你們共同關注的話題。本期三位嘉賓將結合本身的實踐經驗與你們一塊兒探討。

金仕達衛寧軟件科技有限公司首席架構師李楓：審時度勢，及時調整

分工合理，責任明確

團隊是由我的組成的，團隊中的我的每每經歷不一樣、背景不一樣、性格有差別、水平有高低。在團隊造成後、正式開工前，首先應該進行合理分工，要結合每一個人的特色和愛好，充分發揮出每一個人的特長。由於若是工做不愉快、不順手的話，效率天然低下。分工完成後，每一個人對應的職責也就肯定了。這時應該同每一位團隊成員進行明確申明，最好以文字形式落實到我的並與平常績效考覈掛鉤，以免互相推諉、相互等待的狀況出現。

制定高效的溝通機制

分工完成後團隊即開始工做，此時必須保證信息在整個團隊內的暢通，特別是互相之間有工做關聯的同事，在發現問題時須要及時提出，以避免形成沒必要要的工時浪費。 但軟件開發自己是一種須要精力集中而且安靜的工做，屢次臨時性的打斷會形成開發思路的停滯，所以團隊負責人最好可以天天在固定的時間段內組織你們進行溝 通，並瞭解工做的進度。而固定的時間也會讓你們造成習慣，使效率獲得提高。

發現團隊瓶頸

你們每每會陷入一種誤區，認爲團隊中每一個員工效率發揮到極致的時候就是這個團隊效率最高的時候。但通過企業管理實踐不斷的論證，這種想法實際上是很是可怕的謬 論。正確的作法應該是將整個團隊當作一個總體，再去談效率問題。團隊的分工協做就比如是生產的流水線，流水線的總體生產效率不取決於流水線上效率最高的環節，而取決於效率最低、速度最慢的環節。當流水線上某一環節出現故障而停滯時，整個流水線也就停滯了。這也是常說的木桶原理。因此咱們必須時刻去發現團隊 中的短板，盡一切力量幫助它，提升它的效率。這樣，也許會犧牲局部某些我的的效率，但通過一段時間的實施後，你可能會驚奇地發現整個團隊的效率變高了。

按期檢查，及時調整

流水線的機器是死的，而程序員們是活的。所以團隊的瓶頸也許會由於調整而發生變化，這時須要團隊負責人審時度勢，及時進行調整。也許須要修正前期的分工，也 許須要改變正在使用的技術，甚至是更換沒法勝任的團隊成員。讓整個團隊的工做效率保持在一個較高的而且可以相互匹配的水平，這樣作很是重要。

總結

團隊是一個總體，不能靠每一個員工進行單打獨鬥，要始終牢記團隊的最終效用取決於團隊中效率最低的環節。進行合理分工是預防瓶頸發生的前提，而創建高效的溝通 機制則是發現瓶頸的有效方法。當瓶頸環節出現後要盡團隊最大力量去發揮其效用，而當瓶頸發生變化時需及時作出調整，才能提升團隊協做的效率。

杭州雲圖科技有限公司研發總監，資深項目管理專家塗勇：提高研發團隊協做效率的四個祕訣

要提高研發團隊的協做效率，我認爲可從目標、規則、溝通和工具四個方面入手。

目標，讓團隊成員有明確的前進方向

清晰明確的團隊目標能夠對團隊高效協做造成很強的牽引力，更重要的是，團隊目標是團隊成員我的目標制定的前提。要讓團隊高效率的協做，最好的方法就是讓團隊 全部成員每時每刻的工做都圍繞團隊目標開展。須要指出的是，將團隊的目標分解成近期目標、中期目標和遠期目標是一個值得推薦的作法。此外，少數優秀的團隊 管理者甚至可以將團隊的遠期目標上升到團隊使命感和價值觀的高度。要作到這點，管理者需具有卓越的領導力。

具體到研發管理，對項目而言，明 確項目目標並不困難，諸如產品發佈、系統上線等這些均可以做爲項目目標，而且項目經理也能夠很容易以項目計劃的形式來加以落實。但對職能部門的管理者而 言，制定好職能部門的目標就很考驗管理水平。職能部門的經理不該忽視部門目標的重要性，而這能夠與團隊成員的我的職業發展目標結合起來考慮。

規則，讓團隊成員始終保持住隊形

高效率團隊運做，必定有良好的團隊規則作保證。明確告訴團隊成員，什麼樣的行爲是團隊所不能容忍的，並將其造成制度。制度違反者都應受到相應的懲罰，並作到 及時（第一時間）、公平（一視同仁）、公開（團隊內部）。制度是團隊的高壓線，不堅定執行的制度還不如沒有制度，記住這點很重要。

若是說制度告訴團隊什麼事不能作，那麼規範就是告訴團隊成員尤爲是新進入團隊的成員應該怎樣作。文檔規範、編程規範、原理圖設計規範等開發規範，是團隊高效率協做的保證。規範不是制度，能夠容忍一時不遵照規範的狀況，但應該讓團隊在遵照規範方面作得愈來愈好。培訓、優秀案例和反面教材宣傳等都是推行規範的好實踐。 另外，規範不是高壓線，不同意對違反規範的成員進行懲罰，最好的方式是對在規範方面作得優秀的人進行公開表揚。

制度和規範都是針對的人，對事來講規則便是流程。沒有高效率的工做流程，也就沒有高效率的團隊。對於牽涉多人協做的工做，即便是一個設計不完備的流程也比沒有流程好。值得指出的是： 流程應該隨着團隊內外部的環境變化而作持續優化，在一些大公司中甚至會成立專門的流程改進小組，足見流程持續優化的重要性。

溝通，讓團隊成員凝聚成一個有機的總體

良好的溝通對一個高效率團隊有多麼重要，熟悉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鍛鍊身體。可見鍛鍊身體的重要。咱們團隊每一個人基本天天都會有專門的運動時間，跑步、游泳，或者健身房，已然成了咱們工做的一部分。