起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識小團隊有大能量，聊聊背后的科學依據
與傳統印象中的人多好辦事不同，小團隊的工作效率可能比大團隊更高。原因何在？
這篇文章，作者從一個故事說起，為我們解釋了為什么會產生這種現象。一起來看看：
1882年，法國人林格曼做了一個“拉繩子”試驗：
20名學生分別以個人和集體形式拉一根5米長的繩子，繩子的一端為測力計。
2個人一起拉繩子時，每個人的平均表現是單獨拉繩子時的93%，3個人時為85%，4個人時77%，而到8個人時，平均表現則只是個人最佳表現的50%。
心理學家將這種效應稱為林格曼效應。
林格曼效應具體是指：多人合作時，個人努力的作用就會被削弱；導致個人缺乏竭盡全力的動力，個人貢獻與團隊貢獻也難以區分，因此就會有人“濫竽充數”。
一、一個小團隊的故事
前段時間，因為工作中的親身體會，我開始對小團隊和大團隊的模式感興趣。
我在網上搜到一個案例，作者說他朋友的公司做了一個教育行業的管理系統，業務復雜，決策人牽扯的多，需要對接的系統也非常多。但是他們順利完成項目的時間和人數令人吃驚：2個多月，6個人（這6個人里一個美工，一個項目經理，其他都是開發人員）。
當朋友問作者如果這個項目交由他們來做，需要做多久。作者想了想說：順利的話，半年吧。
差異如此之大，引起了作者的興趣。他就一條一條列舉出對于這個項目中的任務，如果是他們按照傳統方式做，再對比他朋友公司的實際做法，都有哪些不一樣。
具體的內容我就不一一列舉了，在文末的參考原文里，大家有興趣可以點擊看看，我這里只舉例其中提到的兩條：
開發測試階段：
朋友公司的團隊幾個開發人員從前端到后端，從開發到測試，都是他們自己做。
作者說如果他們公司來做的話，后臺開發人員不做前端（普通的前端工作在做的，只是不做復雜的前端頁面）；質量的保證是由測試人員去保證：測試把Bug提交到Bug管理工具，開發再去Bug管理工具查閱屬于自己的Bug，等開發人員修改完Bug之后，再關閉Bug，測試再來做回歸測試。
作者總結說：這些流程看起來瑣碎，確實損耗了大量的資源。
驗收上線階段：
朋友的團隊所有人都在項目現場，有問題，他們當場就解決。
作者說如果是在自己的公司，要先收集問題，讓測試工程師去驗證問題；然后由開發解決，解決之后再驗證；然后再發布版本給現場的實施工程師，由實施工程師再更新上線，給客戶驗證。
所以，最后作者總結說：問題很明顯，規模大的團隊和規模小的團隊工作方式的差異非常大，組織資源的方式也有明顯的區別。
通過這個案例，結合我搜索到的其他資料，我發現了一個有趣的現象：小團隊合作正在被越來越多的企業推崇。知名的企業像亞馬遜，谷歌、Facebook、百度都在內部推行小團隊的運作模式。
今年因為離婚事件鬧得沸沸揚揚的全球首富亞馬遜CEO杰夫·貝索斯（Jeff Bezos）就有一條關于小團隊的“兩個披薩”定律：如果兩個披薩不夠吃，那么這個團隊就過于龐大了。
兩個披薩的概念大概就是6-8個人左右吧，當兩個披薩已經不夠時，你的團隊可能需要考慮精簡人員了！
貝索斯的這一定律正是佐證了小團隊的必要性。
為什么企業會運用小團隊模式？
必然是小團隊模式產生了可見的成果，那么為什么小團隊能夠達到這樣的效果呢，它背后的設置原理是什么呢？
我們一起來看看：
二、小團隊的科學設置
我們從兩個方向來看小團隊設置的原理：
- 大腦的構造
- 人員的溝通成本
1. 大腦的構造
1956年，著名的認知心理學家喬治·米勒（George Miller）發表了一篇重要的論文：《神奇的數字：7±2》，這是在該領域被引用次數最高的論文之一。
該論文所闡述的觀點是：
雖然大腦可以將整個生命周期中的知識都儲存在其數以萬億計的連接中，但是人類在一次意識知覺中能同時主動持有的事物數量卻是有限的，平均來說這個數字為7。即我們普通人在短期的記憶中最多只能記住7樣東西，這里的東西可能是一串數字或者是其他玩具，物件等等。
但不管是什么，聯系到我們在工作中產生的記憶時，如果這7樣東西不被主動想起時，就會被儲存在大腦的別處或者是慢慢被遺忘（本來記得的就少，不溫故還容易被遺忘）。
自從他發表這一言論后，有神經科學家和心理學家開始研究工作記憶，然后證實了Miller的研究是錯誤的：普通人在短期記憶里記住的東西不是7，而是4，也有人說5。
主張4的其中一位學者是密蘇里大學的Nelson Cowan，在2001年，他開展了各種研究。盡管我們經常會看到網絡上告訴我們的一些記憶的技巧、記憶宮殿類的記憶法，或者是通過短期的高度注意力集中，讓自己記住更多的東西。然而，Cowan的研究結果卻非常清楚地表明：人們只能記住4個東西。
一個典型的例子：fbicbxibmirs。除非我們已經知道這些毫無聯系的字母中，像FBI , CBS , IBM , IRS就是某些特定的機構縮寫，否則我們通常只能記住其中的4個字母。
當然，如果你能夠將這些需要記憶的事物和你的長期記憶里的某些東西聯系起來的話，很有可能你會記住更多。
比如：通過一個故事將這些字母串起來，安排一個角色，或是代表其中的一個象征。
但人類思維中負責集中精力的那部分，也就是有意識的那個部分，往往一次只能記住大概4樣事物。
鑒于我們的大腦存在這樣的上限（我們這里只說大部分普通人，如果你要把愛因斯坦或者是某本武俠里一目十行的傳奇人物做特例的話，你贏了），我們就能聯想到一個團隊：
3個人的團隊互相之間要溝通處理的信息，與10個人的團隊彼此之間溝通處理信息差的不是一點點，而我們的大腦能處理的就這么多。大團隊和小團隊，當然是團隊越小越好，信息越少越好。
如果你還想再細一點，我們來算算：如果用N表示團隊人數，那么：
溝通渠道數量=N（N-1)/2
按照這樣計算：
- 如果你的團隊是5個人，那么溝通渠道就是10條；
- 如果你的團隊是6個人，溝通渠道就是15條；
- 如果10個人，溝通渠道就有45條。
如此多的溝通渠道，超出了我們大腦的承受能力，我們根本無法知道團隊其他成員正在做什么；當我們想要去找尋答案時，我們的工作進度卻會慢下來。
2. 人員溝通成本
說溝通成本可能有點誤導，或者也可以說是培訓人員成本。
我們知道：要招聘一個人員，從招聘到培訓到適應工作，企業是要付出成本的。
同樣地，當我們要為新項目組建一個團隊或者是因為項目延遲了，我們采取增加人選的方案。
培養新成員，讓他跟上團隊其他成員的速度，我們需要耗費一定的時間。而且，帶領一個新成員步入正軌的過程，可能也在拖累其他成員的速度。
這一點其實是說明了：延遲的項目為什么靠加人加班反而不能達到預期效果。
綜合上面兩個原因：我們看到了，小團隊設置是有著對人類大腦和人員成本的考量的。事實上，越是團隊小，工作效率反而越高。
Lawrence Putnam是軟件開發領域的一位傳奇人物，他一生都致力于研究工作時間與效率的問題。
他的研究成果表明：如果一個項目的參與者超過20個，相比于參與者只有5個或少于5個時，他們需要付出的努力就會更多，而且不是多出一星半點。
當他一次又一次看到大團隊需要花費更多時間完成任務的現象時，在20世紀90年代中期，他決定開展一項大范圍的研究，想看看一個團隊到底應該多少成員才算合適。
他從數百家公司里選取了491個中型的項目，這些項目都是需要設計出新產品或是新功能，并不是對固有的產品或者功能進行修修補補。
他根據團隊規模對這些項目進行了分類，很快就發現：
一旦團隊規模超過了8人，那么項目耗費的時間往往就會非常多。要完成同樣的工作量，3-7人的團隊所需時間只有9-20人團隊所需時間的25%左右。
這種情況在數以百計的項目中反復出現，大規模團隊完成的工作反而比較少，這確實跳脫了人們常規的思維。
三、大團隊VS小團隊
看到這里，你可能就會說：難道所有項目都適合小團隊嗎？
那也不是。
很大型的項目比如：造火箭、造水壩，這種大規模的工程，往往需要成百上千的人員。所有成員必須要遵循組織紀律，一起協作才能夠完成，甚至需要外包出去一部分業務。
于是，一系列的規章、制度、流程、KPI就被制定出來作為約束管理的手段。
每個人都是一個零部件，發揮著自己的功效。這樣的模式被更多人熟知，它很穩，它讓我們向著目標穩穩地移動。
相對于大團隊來說，小團隊則更具靈活性。我們聽過80%的用戶可能只會使用20%的功能。
同樣地，一個精簡的團隊往往能夠集中創造出更有價值的產品。小團隊非?！翱臁?，它能保證目標的快速達成，并且能使目標達成的效率更高。
小團隊案例
耐克的HTM
HTM是耐克2002年推出的設計實驗項目。它取自三位項目合作者的名字：藤原浩（Hiroshi Fujiwara）中的“H”、汀克·哈特菲爾德（Tinker Hatfield）中的“T”和耐克首席執行官兼設計師馬克·帕克（Mark Parker）中的“M”。
HTM完美詮釋了一個小團隊是如何成功的：
三位大師進入一個房間，放下日常的工作，共同努力對現有的產品設計進行重新詮釋，開發新的產品設計。
在這個只有三個人的團隊中，他們沒有身份高低、不分權力大小，沒有給定要求，只有自由創作。
因為團隊小，使得他們每個人都充分利用時間，加快創作進程，這是公司標準流程難以企及的。尤其對耐克這樣規模的企業來說，從開發到發布，若沒有三人團隊模式，恐怕難以達到如此高效的程度。
自2002年，HTM團隊和他們的單品面世，HTM就備受各界的關注。這個傳奇的團隊所設計出來的單品至今也已多達40多款，它們各有各的特點，卻總是能帶給人們意想不到之處。
當一個團隊的人數更精簡時，彼此的責任更加明晰，工作更加透明化，他們的執行力也會加強。不是像機器中的一個螺絲釘，只是按部就班，就是有什么想法可能還需要層層匯報。
這也是我們看到為什么更多的創意都是出自小團隊，小團隊有想法時，大家實現得更快，擺脫了官僚的束縛，行事更順利；即使是嘗試失敗了，也是越快失敗越好，換個方式繼續嘗試。
相對于大團隊的逐級匯報、大量文檔和審批流程，等一個創意真正做出來了，也許競爭對手已經占領市場了；或是發現不可行時，其耗費的資源也是巨大的。
所以，小團隊更有利于溝通，小團隊更加具有執行力，小團隊更有利于創新！
四、小團隊如何管理呢？
促使我寫下這篇文章的動力源于過去兩個月的真實體驗，我親眼見證了：一個3人抱團的小團隊，從過去一年的黑暗中摸索，到兩個月內通過一套簡單的指令而煥發出如今的全新面貌。
我很吃驚，3個人的團隊竟然能夠在兩個月內成功主導一次大型的活動（持續7天），并且除活動以外的日常工作也取得了明顯的績效提升。
我向來不是因一件事就崇拜，或是夸大某個元素的個性。30多年的生活經驗和見聞讓我認清：一個大的成功事件背后充滿了時間、精力、人員等等投入，還有各種偶然的因素。
所以，我開始探索，我想要尋找到一些答案，讓我的好奇心得到滿足。
當我在探尋到以上的答案時，我更加好奇的是——是什么樣的管理方式能夠讓小團隊表現得如此卓越呢？
這就要說到我看到的3個人團隊：這個團隊的人員只有3個，是一個新媒體團隊。
我曾經進入過一家培訓公司的市場部門，類似于現在的新媒體部門。當時的部門設計有三個，文案有兩個，還有推廣、部門主管、策劃加起來有10多個人員。
每當做一次線上的推廣或者是線下的活動，加班是常事，這也是當時這個市場部人員流動異常頻繁的原因之一。主管已經完全習慣了加班，每個成員平時都是在晚上21點左右下班，有活動時到23點是常事，甚至熬通宵。
現在想想，真是可怕！
因為目睹過這樣的加班現狀，身邊廣告公司的朋友也經常吐槽，所以對于這個3人團隊的變化，我感覺很神奇。
這個團隊為什么會有這樣的變化呢？
原來，在兩個月前，公司開始推行Scrum。這個對外的展示的平臺——新媒體部門，成了最先試水的小白鼠。
關于Scrum，它的創始人Jeff老師就提出：
團隊只有在維持小規模時，才會煥發出活力。
雖然他也見過小到只有3個人的團隊就能夠實現高水平的運作，但一個團隊一般是由7個人組成，可以多兩個，可以少兩個。
團隊從最初的不適應到慢慢適應，中間經歷的一些問題暴露出來，然后再慢慢調整。
當團隊看到一步步取得的成果時，他們開始領略到Scrum這樣一套簡單的指令，竟然只是通過一些會議、一些角色就能幫助團隊達到這樣的狀態。
當大家享受到Scrum帶來的變化時，他們終于體會到了小團隊的好處。
事實上，在進行的過程中，他們也在不停學習。
比如：臨時增加了額外的人員后，在估算故事點時，他們發現耗費的時長更多，站會的時間被拉長，他們終于明白：難怪團隊不能太大了，太大的團隊溝通成本也太高了，開個站會也得多耗十幾分鐘。
我們總是在實踐中成長的。
五、小結
我們已經探討了為什么要設置小團隊的模式以及小團隊能夠為我們帶來的好處。
事實上，我們看到的很多大的項目，同樣可以使用小團隊模式。實現的途徑就是將我們的大項目拆分成一個個小項目，再由一個個小團隊去完成這些小項目。
小團隊，協作效率更高。
所以，保持你的團隊小而精！
參考文章：http://blog.jobbole.com/111484/
本文由 @敏捷行動派 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
