【騰訊敏捷轉型No.4 】爲何敏捷團隊不要超過15人

時間 2019-11-18

原文原文鏈接

早期，騰訊公司的架構是比較簡單的。從上至下分別是：公司——商業單元（BU）——部門——組——員工，每一個部門基本上就是負責一個大的產品，每一個組都是按照專業進行分工和管理，例如：產品組、終端組、後臺組、設計組、運維組、質量組等等。html

草擬一個項目須要在每一個小組裏面抽調人力，部門的總經理就須要和每一個小組的組長溝通，通過溝通之後，肯定了該項目須要的人力安排，而後就開始執行項目。執行項目過程當中的困難，須要決策，例如：人員安排調整，產品需求變動和是否延期發佈等等，都須要總經理和組長們開會協調或者私下溝通決定，組員們須要等待協調的結果去執行，這個過程若是須要開會，與會人數有限，而且不能把實際相關的人拉進來，還須要實際執行人員寫報告給組長，組長給總經理回報。web

在實際執行的結果中，總經理和領導們沒有徹底瞭解到實際狀況，在開會的時候還會把實際相關的人拉到會議室再確認一遍，最終會議的結果經過每一個組長的郵件或者是小組內會議進行傳達，員工這才知道執行結果。有時候由於每一個組長的理解和表達方式不同，還會在執行項目的時候暴露信息不一致的問題，這些問題還要通過向上級反饋和確認以後，調整後再次執行。算法

騰訊公司早期規模不大，人數少，每一個部門人數在100人左右，因此產品和項目數都少，上面所說的流程也不算太漫長。直到騰訊公司上市之後，每一個部門都進行了擴張，每一個部門的人數迅速擴張到200至300人，基層人數激增，領導幹部儲備不足，而且在成立BU以後，有些橫向支撐組還組成了獨立部門，這樣直接致使在執行項目的時候，要跨部門進行協調工做，慢慢出現了「決策愈來愈慢」、「流程愈來愈長」、「團隊離用戶愈來愈遠」的「大企業病」。微信

問題出現了，應該要怎麼解決呢？架構

對應以上的問題，騰訊公司決定採用敏捷Scrum作出如下的實踐：運維

決策快速化工具
流程輕量化測試
團隊自組織優化

通過一段時間Scrum的實踐，爲了讓Scrum團隊實現以上效果，須要作到一些約定：設計

團隊成員的角色是齊備的
團隊承擔的業務是閉環的
團隊成員項目期間最好坐在一塊兒
團隊規模控制在15人之內

決策快速化

實現決策快速化最大的障礙是任何協調和溝通都須要正式開會。例如，咱們每一個Scrum團隊的團隊成員都是角色齊備的，也就是每一個Scrum團隊具有本身完成業務目標的全部專業角色，包括：產品經理、終端研發人員、後臺開發人員、設計師、運維人員、測試人員等等。那麼須要做出任何決策的時候，每一個團隊中團隊能夠直接做出決策，不須要開會，不須要請示領導，人數不超過15人，既能夠找工做桌旁邊的任何空地，也能夠直接圍繞白板開會，會議記錄寫在白板上，拍下一張照片，發郵件向上彙報記錄一下就能夠了，這樣會議不會超過30分鐘，簡潔高效，並且團隊中每一個人均可以參與進來。

看到這裏，你可能會產生疑問，每一個團隊裏作出決策就執行，那領導的存在的價值在哪裏？

領導的價值在於：第1、正確規劃須要多少組Scrum團隊才能完成部門業績；第2、制定每組Scrum團隊的業務目標；第3、確保每組Scrum團隊包括所須要的角色和人員。而完成這三件事，就是部門領導存在的價值，如何平衡從中人員調配和目標劃分而且完成業績，這就須要必定的技巧和精力。

流程輕量化

實現流程輕量化的最大障礙是團隊沒有坐在一塊兒。若是團隊中的成員都坐在一塊兒，促進成員之間的溝通和協做，根本不須要系統的流程或者工具來管理，有什麼需求和問題，直接說出來就能夠了，甚至是要想知道這個成員的工做進展如何，只要走到座位旁邊看一眼就知道了。

我曾經拜訪過的一些企業裏面，我發現，若是某個企業裏面，每一個人都是在規規矩矩坐在座位上，整個辦公場所都是安安靜靜，連一根針掉在地上都能聽見，那麼這個企業團隊協做是頗有問題的，估計團隊成員之間的合做只是走流程提單的。團隊氛圍熱熱鬧鬧的，團隊成員之間親密無間的合做，互相之間沒有上下級之分地大呼小叫，這樣的團隊協做氛圍更融洽，更容易促進工做協調開展。而冷漠的團隊氛圍中，每次工做只須要提單走流程，把人與人之間的距離拉得很疏遠，即便知道對面的同事也要走流程提工做單，你不提單，別人也不知道你的工做量。

我在騰訊公司管理團隊的時候，會想盡一切辦法讓團隊成員相互熟悉起來，每一個人的個性、愛好、長處都會獲得充分的展示，這樣子團隊協做才能物盡其用、人盡其才，既然團隊成員可以順暢配合，又何須追求流程呢？

團隊自組織

實現團隊自組織是最難的。由於業務的閉環是不少企業很難作到的。也去的閉環意義在於，團隊所做所爲能當即影響業務目標，根據反饋的好壞迅速調整，最終實現業務目標。

咱們所看到騰訊公司的大產品，騰訊都會拆分某個模塊給某個敏捷團隊負責，拆分的原則就是這個產品模塊能夠獨立閉環。

舉個例子，具體產品名稱就不說了，這個產品裏面有一個「搜索框」，就是獨立的一直十幾人的團隊負責。這個團隊只負責這個搜索框以及後面的二級頁面。根據運營須要，這個搜索框會展現不一樣的Hot Key，這些Hoy Key除卻公司內部的戰略要求，其它的都是須要客戶付費纔會展現的，團隊會關注哪些Hot Key 適合展現，這個Hot Key轉化率很高，最終這個項目掙的錢最多。而若是你輸入一個泛詞在這個搜索框搜索，例如「遊戲」，每個展現出來的遊戲都須要收費，那麼如何評判什麼展現效果和演變的算法的標準，就由團隊不斷根據數據和用戶反饋進行調整和優化。當團隊的平常運做都在圍繞着本身的業務目標的時候，這就表明着他們慢慢自組織起來了。

不超15人的Scrun團隊

Scrum團隊規模爲什麼要在15人之內，有這方面的緣由。首先，根據西方的組織行爲學，裏面有一個Magic Number 「七」。當團隊規模大於七個以後，就會有團隊成員不能獲得周全的照顧了，因此Scrum本來提倡8人之內的小團隊。其次，國內的團隊最容易被你們接受的團建方式就是吃飯，而國內大部分大圓桌就是12人的，有一些大店有勉強能容納15我的的大圓桌。吃飯的時候你們都坐在一桌上，很舒服。若是是超過15人的團隊的時候，人與人之間的微妙就開始涌現。若是一個大桌子，你們沒得選，隨便坐。若是是兩個桌子，有一桌有領導，有一桌沒有領導，有人早到了，怎麼選擇？若是團隊的人都在一個桌子上，任何人說話，你們都能聽見，很好溝通，而兩桌的信息傳遞就有不平衡了。最後，要保持溝通的一致性團隊成員就不能大於15人。

敏捷強調團隊成員的共識，而隨着人數的增長，溝通成本會直線增大。晨會的時候，15我的勉強還能圍成一團，再多就沒有辦法實現了。因此綜上所述，一個完備的Scrum團隊，最好規模控制在15人之內。固然，能控制8我的的小團隊是最好的，可是考慮到全棧工程師和複合型人才太少，因此通常很難作到。

【彩蛋】

上期咱們提到一個問題：把Sprint好比一個集裝箱，當一個集裝箱裝不下一頭大象的時候，應該怎麼辦呢？不少同窗選擇了把大象砍成能夠放進去集裝箱的體積，而後互相討論砍頭仍是砍腿，仍是砍屁股呢？就像咱們平日開需求評審會同樣，你們習慣PK和對抗思惟，一點都不在乎砍完的大象被裝進集裝箱是否還有生命意義。其實正確的答案就是，裝這頭大象的兒子——小象。小象是具備生命意義的，並且若是能夠，它最終會長成大象的。一頭小象養成成本是很小的，能夠減小團隊試錯的成本，你說這樣的方法是否會好一些？