我們公司和大部分傳統軟體公司一樣，隨著業務的發展和新領域的開拓，公司的管理風格越來越像華為，這是不是最佳的演進路線，我覺得值得探討，以下是我的思考，希望跟大家討論。
一個問題
前段時間跟一個創業的朋友聊天，說起他們最近在做的一個專案，這是一個教育行業的管理系統，業務非常複雜，牽涉到的決策人，需要對接的系統也非常多，最後問到他們做了多久完成這個專案，朋友告訴我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人的大團隊來對待；