點擊上方藍色“程序猿DD”，選擇“設爲星標”
回覆“資源”獲取獨家整理的學習資料！
來源 | cnblogs.com/liulun/p/7159705.html
一個問題
前段時間跟一個創業的朋友聊天，說起他們最近在做的一個項目，這是一個教育行業的管理系統，業務非常複雜，牽涉到的決策人，需要對接的系統也非常多，最後問到他們做了多久完成這個項目，朋友告訴我2個多月，6個人，其中還括一個美工，一個項目經理；剩下的都是開發人員，沒有測試，沒有前端開發；朋友問我，如果這個項目給你們做，你們需要做多久；我想了想說，這個項目如果交給我們做，順利的話，至少要半年。
爲什麼差異這麼大呢？
我們一個一個環節來分析一下，朋友的團隊跟客戶溝通需求的時候，功能性需求只用一個原型草圖，非功能性需求就一個excel表格；如果我們公司做的話，至少要做需求調研報告，需求規格說明書；這個階段的負責人甚至不會畫原型，要到設計階段纔有人能畫原型；
到設計階段，朋友的團隊幾乎沒有什麼技術設計，業務按模塊給開發人員分一下，各人設計好自己的數據庫模型，彙總起來給項目經理看一下，沒問題就進入開發階段了，界面設計花的時間比較久，跟客戶反覆確認了兩三次；如果我們公司做的話，至少要產出原型設計（低保真描述功能的設計稿，高保真描述界面的設計稿），概要設計，詳細設計（技術設計、架構設計、網絡設計）等等，而且幾乎每個設計都要經歷評審環節，組織評審就要協調人員，要等大家都有時間的時候再做評審，這都是損耗；
到開發測試階段，朋友的團隊幾個開發人員從前端到後端，從開發到測試，都是這幾個人做；如果我們公司來做的話，後臺開發人員不做前端（不做複雜的前端頁面，普通的前端工作還是要做的），質量保證要測試人員保證，測試把BUG提交到BUG管理工具，開發再去BUG管理工具查閱屬於自己的BUG，修改完成之後，再關閉BUG，測試再做迴歸測試；這些流程看起來瑣碎，但卻損耗了大量的資源；
驗收上線階段，朋友的團隊所有人都鋪在項目現場，有問題，當場解決；我們公司要收集問題，讓測試工程師驗證問題，再由開發解決，解決之後再驗證，再發布版本給現場的實施工程師，實施工程師再更新上線，給客戶驗證。
這個問題很明顯：規模大的團隊和規模小的團隊工作方式的差異非常大，組織資源的方式也有明顯的區別；我們抽象一下，把這兩種模式稱爲：大軍團模式和小編隊模式，再看這兩種模式的具體區別：
大軍團模式
之前有一種理論，要完成一項超大規模的工程，往往需要成百上千人，有組織有紀律的協作才能完成；
這樣就需要制定一系列的規章、制度、流程、KPI來約束這些人，
把這些人變成一個龐大機器的零部件，保證結果的達成，避免產生差錯；
這是一種非常常見的大組織的運作模式，
不但在軟件行業普遍存在（華爲、惠普、IBM），
在造橋、修路、航天、汽車等工業領域也十分常見，
這種模式非常“穩”，他能保證目標的穩定達成，並且能使目標達成的過程清晰、可控。
小編隊模式
第三次工業革命（信息技術革命）以來，小編隊的運作模式發展越來越好，我司IPCC產品的核心：開源語音通信軟件FreeSwitch，核心開發者也不過6個人；（說這個開源軟件養活了半個呼叫中心行業的開發者都不足爲過）；這種例子在軟件行業不勝枚舉，比如：git源碼管理系統、linux操作系統、JavaScript語言等等。
甚至有些產品是一個人在短時間內完成的，這就是英雄；
有很多大規模的公司，比如谷歌、Facebook、國內的百度也在內部推行小編隊的運作模式；
這種模式非常“快”，他能保證目標的快速達成，並且能使目標達成的效率非常高；
大軍團的不足
效率低下
大軍團強調集體的智慧，
個體想推動一項事務向正確的方向推進十分困難，
個體的決策往往會受到質疑或排斥
諸如：流程、規範、計劃、考覈、文檔、評審、調研等詞
都是爲了保證目標的穩定達成所衍生出來的東西，
它們都是團隊快速前進的束縛和絆腳石！
阻礙創新
大軍團鼓勵墨守成規、照章辦事的氛圍，
大軍團強調分工，把員工看作螺絲釘，希望員工各司其職，不是職責範圍內的事務儘量不要碰，因爲你不專業，你可能會出錯，大軍團最害怕出錯；
只有這樣才能使目標達成的過程清晰可控；
然而創新卻需要不拘一格的思想，需要獨立自主的工作空間，需要組織具備容錯性，這和大軍團的工作方式是格格不入的；
資源浪費
爲了使目標的達成過程清晰可控；
大軍團制定了很多流程和制度來約束個體的行爲；
他把每一項事務都拆分成很多環節；
又給每個環節制定了很多關卡；
而且每個環節都要留下數據，使過程有跡可尋；
因爲大軍團要做到每項事務都可以覆盤，產生問題之後要可以追溯問題根源；
這樣確實保證了目標達成過程的清晰可控，但卻浪費了大量的資源；
小編隊的優勢
小編隊也適合做大項目
有很多很龐大複雜的軟件系統，都是以小編隊的方式完成的；
比如操作系統linux，大數據分析系統hadoop，我們這個行業的freeSwitch等；
如果一個項目大到一定的規模，需要不同角色的人蔘與，那麼也應該是有更多的小編隊來做這一塊事情；甚至更極端的做法，就是一個項目在建設之初，就考慮到會有很多小編隊或個人參與到項目建設過程中，預留了多人、多團隊協作的支撐工具，比如說nodejs的NPM，go語言和rust語言也有相應的規劃；
小編隊也有很強的執行力
小編隊不會說這個事情需要做個評審；
小編隊不會說這個事情安排的資源不夠，需要協調更多的資源；
小編隊會把這個事情當成自己的事情，不會像大軍團一樣，把這個事情當成大家的事情來對待；
我們來看個圖：
（圖片遺失，暫不補充）
小編隊也有很強的創新力
軟件行業不像建築行業，90%以上的優秀軟件一開始都是個人或者小編隊創造出來的；很少見一個優秀軟件是一個大規模的組織創造出來的。
一個案例
張小龍曾經說過一段話：
好的工具就不應該黏人，應該幫助用戶非常高效率完成任務，而不是說用完了還要拿到手裏玩一會兒、多用一會兒，那不是一個很高效的表現。但是對這樣的一些想法的話，我特別希望它能夠根植到大家意識裏，時刻想一下什麼是我們做的對用戶有價值的事情；
假設你是馬化騰，你會怎麼給張小龍定KPI呢？考覈微信的日活嗎？……
無論你制定什麼KPI，都會導致團隊去圍繞着那個KPI去完成任務；
KPI考覈準則裏有一項原則就是“可度量”，當你提出一項純數據目標的時候，團隊就會圍繞着那個數字去工作。而偏離了做好產品的初心。
一個團隊工作的目的不應該是完成KPI，工作的目的應該是做好產品，完成KPI只不過是做好產品這件事情的副產物，就像一個人好好工作的目的不應該是爲了賺錢，他好好工作的副產物是賺了很多錢；
所以你制定了一系列的kpi考覈制度，只能導致員工工作的動機更不純粹。
最後
一個組織只要發展良好，總是會吸引更多的資源，所以組織規模的擴大是無可避免的，但如果一個組織規模已經超過500人了，那麼你應該把他看作是50~100個小團隊來對待，而不是把他當作一個500人的大團隊來對待；
2017-07-13完成以上內容
2017-07-30增補以下內容
** 康威定律**
任何組織在設計一套系統時，所交付的設計方案，在結構上都與該組織的組織結構（溝通結構）保持一致。——梅爾.康威
這個定律說明，組織的結構對系統的性質和質量有着深刻的影響；
如果構建系統的組織更加松耦合，其構建的系統則更傾向於模塊化，因此耦合度也更低；
如果一個系統足夠重要，要求有更松的耦合，更模塊化的設計，系統也會反過來要求組織具備這樣的特性，這就是反康威定律；
我這篇文章並沒有提到大軍團的優勢，並不代表大軍團沒有優勢，
相反，有很多項目非“大軍團”根本就完不成，比如：衛星裏跑的程序，控制原子彈起爆的程序，導彈的制導程序，都需要大軍團來做！
然而這些程序畢竟是少數，而且不是我們身邊的東西，大部分時候，我們還是需要小編隊來做。
亞馬遜提出“兩個披薩團隊”的概念，就是說亞馬遜要求組織內部不應該有團隊大到兩個披薩不夠喫。
歸根結底，就算非常龐大的組織，也應該強調小團隊的協作模式。
往期推薦
給 Spring Boot 項目減減肥！18.18M 到 0.18M 是如何做到的？
全球最大同性交友網站必備的五大神器！
爲什麼 HashMap 的加載因子是0.75？
那些實用與顏值齊飛的桌面！
Spring Boot 2.x基礎教程：MyBatis的多數據源配置
歡迎加入我的知識星球，聊技術、說職場、侃社會。
頭髮很多的中年程序員DD和他的朋友們在這裏期待你的到來！
加入方式：長按下方二維碼噢
最近更新：
【技術圈】分享最近給阿里提的一個數據安全問題
【社會人】開聊這本社會百科全書《民法典》，做個合格的社會人
我的星球是否適合你？
點擊閱讀原文看看我們都聊過啥？