小團隊管理與大團隊管理

 

咱們公司和大部分傳統軟件公司同樣，隨着業務的發展和新領域的開拓，公司的管理風格愈來愈像華爲，這是否是最佳的演進路線，我以爲值得探討，如下是個人思考，但願跟你們討論。

一個問題

前段時間跟一個創業的朋友聊天，提及他們最近在作的一個項目，這是一個教育行業的管理系統，業務很是複雜，牽涉到的決策人，須要對接的系統也很是多，最後問到他們作了多久完成這個項目，朋友告訴我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增補如下內容

康威定律

任何組織在設計一套系統時，所交付的設計方案，在結構上都與該組織的組織結構（溝通結構）保持一致。——梅爾.康威

這個定律說明，組織的結構對系統的性質和質量有着深入的影響；

若是構建系統的組織更加鬆耦合，其構建的系統則更傾向於模塊化，所以耦合度也更低；

若是一個系統足夠重要，要求有更鬆的耦合，更模塊化的設計，系統也會反過來要求組織具有這樣的特性，這就是反康威定律；

 

我這篇文章並無提到大軍團的優點，並不表明大軍團沒有優點，

相反，有不少項目非「大軍團」根本就完不成，好比：衛星裏跑的程序，控制原子彈起爆的程序，導彈的制導程序，都須要大軍團來作！

然而這些程序畢竟是少數，並且不是咱們身邊的東西，大部分時候，咱們仍是須要小編隊來作。

亞馬遜提出「兩個披薩團隊」的概念，就是說亞馬遜要求組織內部不該該有團隊大到兩個披薩不夠吃。

歸根結底，就算很是龐大的組織，也應該強調小團隊的協做模式。