小團隊管理與大團隊管理

小團隊管理與大團隊管理我們公司和大部分傳統(tǒng)軟件公司一樣， 隨著業(yè)務(wù)的發(fā)展和新領(lǐng)域的開拓， 公司的管理風(fēng)格越 來越像華為，這是不是最佳的演進(jìn)路線， 我覺得值得探討，以下是我的思考，希望跟大家討 論。一個問題前段時間跟一個創(chuàng)業(yè)的朋友聊天， 說起他們最近在做的一個項目， 這是一個教育行業(yè)的管理 系統(tǒng)， 業(yè)務(wù)非常復(fù)雜，牽涉到的決策人， 需要對接的系統(tǒng)也非常多，最后問到他們做了多久 完成這個項目，朋友告訴我 2 個多月， 6 個人，其中還括一個美工，一個項目經(jīng)理；剩下的 都是開發(fā)人員，沒有測試，沒有前端開發(fā)；朋友問我，如果這個項目給你們做，你們需要做 多久；我想了想說，這個項目如果交給我們做，順利的話，至少要半年。為什么差異這么大呢？我們一個一個環(huán)節(jié)來分析一下， 朋友的團隊跟客戶溝通需求的時候， 功能性需求只用一個原 型草圖，非功能性需求就一個 excel 表格；如果我們公司做的話，至少要做需求調(diào)研報告， 需求規(guī)格說明書；這個階段的負(fù)責(zé)人甚至不會畫原型，要到設(shè)計階段才有人能畫原型；到設(shè)計階段， 朋友的團隊幾乎沒有什么技術(shù)設(shè)計， 業(yè)務(wù)按模塊給開發(fā)人員分一下， 各人設(shè)計 好自己的數(shù)據(jù)庫模型， 匯總起來給項目經(jīng)理看一下， 沒問題就進(jìn)入開發(fā)階段了， 界面設(shè)計花 的時間比較久， 跟客戶反復(fù)確認(rèn)了兩三次；如果我們公司做的話， 至少要產(chǎn)出原型設(shè)計 （低 保真描述功能的設(shè)計稿，高保真描述界面的設(shè)計稿） ，概要設(shè)計，詳細(xì)設(shè)計（技術(shù)設(shè)計、架 構(gòu)設(shè)計、網(wǎng)絡(luò)設(shè)計）等等，而且?guī)缀趺總€設(shè)計都要經(jīng)歷評審環(huán)節(jié)，組織評審就要協(xié)調(diào)人員， 要等大家都有時間的時候再做評審，這都是損耗；到開發(fā)測試階段， 朋友的團隊幾個開發(fā)人員從前端到后端， 從開發(fā)到測試， 都是這幾個人做； 如果我們公司來做的話， 后臺開發(fā)人員不做前端 （不做復(fù)雜的前端頁面， 普通的前端工作還 是要做的），質(zhì)量保證要測試人員保證，測試把 BUG 提交到 BUG 管理工具，開發(fā)再去 BUG 管理工具查閱屬于自己的BUG，修改完成之后，再關(guān)閉 BUG,測試再做回歸測試；這些流程看起來瑣碎，但卻損耗了大量的資源；驗收上線階段, 朋友的團隊所有人都鋪在項目現(xiàn)場,有問題, 當(dāng)場解決； 我們公司要收集問 題,讓測試工程師驗證問題,再由開發(fā)解決, 解決之后再驗證,再發(fā)布版本給現(xiàn)場的實施工 程師,實施工程師再更新上線,給客戶驗證。這個問題很明顯： 規(guī)模大的團隊和規(guī)模小的團隊工作方式的差異非常大,組織資源的方式也有明顯的區(qū)別； 我們抽象一下, 把這兩種模式稱為：大軍團模式和小編隊模式,再看這兩種 模式的具體區(qū)別： 大軍團模式 之前有一種理論， 要完成一項超大規(guī)模的工程， 往往需要成百上千人， 有組織有紀(jì)律的協(xié)作 才能完成；這樣就需要制定一系列的規(guī)章、制度、流程、 KPI 來約束這些人， 把這些人變成一個龐大機器的零部件，保證結(jié)果的達(dá)成，避免產(chǎn)生差錯； 這是一種非常常見的大組織的運作模式，不但在軟件行業(yè)普遍存在（華為、惠普、IBM），在造橋、修路、航天、汽車等工業(yè)領(lǐng)域也十分常見， 這種模式非常“穩(wěn)” ，他能保證目標(biāo)的穩(wěn)定達(dá)成，并且能使目標(biāo)達(dá)成的過程清晰、可控。 小編隊模式第三次工業(yè)革命（信息技術(shù)革命）以來，小編隊的運作模式發(fā)展越來越好，我司IPCC產(chǎn)品的核心：開源語音通信軟件FreeSwitch，核心開發(fā)者也不過 6個人；（說這個開源軟件養(yǎng)活了半個呼叫中心行業(yè)的開發(fā)者都不足為過） ； 這種例子在軟件行業(yè)不勝枚舉，比如： git 源 碼管理系統(tǒng)、linux操作系統(tǒng)、JavaScript語言等等。甚至有些產(chǎn)品是一個人在短時間內(nèi)完成的，這就是英雄；有很多大規(guī)模的公司，比如谷歌、國內(nèi)的百度也在內(nèi)部推行小編隊的運作模式；這種模式非常“快” ，他能保證目標(biāo)的快速達(dá)成，并且能使目標(biāo)達(dá)成的效率非常高；大軍團的不足效率低下大軍團強調(diào)集體的智慧，個體想推動一項事務(wù)向正確的方向推進(jìn)十分困難， 個體的決策往往會受到質(zhì)疑或排斥 諸如：流程、規(guī)范、計劃、考核、文檔、評審、調(diào)研等詞 都是為了保證目標(biāo)的穩(wěn)定達(dá)成所衍生出來的東西， 它們都是團隊快速前進(jìn)的束縛和絆腳石！阻礙創(chuàng)新 大軍團鼓勵墨守成規(guī)、照章辦事的氛圍，大軍團強調(diào)分工， 把員工看作螺絲釘， 希望員工各司其職， 不是職責(zé)范圍內(nèi)的事務(wù)盡量不要 碰，因為你不專業(yè)，你可能會出錯，大軍團最害怕出錯；只有這樣才能使目標(biāo)達(dá)成的過程清晰可控；然而創(chuàng)新卻需要不拘一格的思想， 需要獨立自主的工作空間， 需要組織具備容錯性， 這和大 軍團的工作方式是格格不入的；資源浪費為了使目標(biāo)的達(dá)成過程清晰可控；大軍團制定了很多流程和制度來約束個體的行為；他把每一項事務(wù)都拆分成很多環(huán)節(jié)；又給每個環(huán)節(jié)制定了很多關(guān)卡；而且每個環(huán)節(jié)都要留下數(shù)據(jù)，使過程有跡可尋；因為大軍團要做到每項事務(wù)都可以復(fù)盤，產(chǎn)生問題之后要可以追溯問題根源； 這樣確實保證了目標(biāo)達(dá)成過程的清晰可控，但卻浪費了大量的資源； 小編隊的優(yōu)勢小編隊也適合做大項目有很多很龐大復(fù)雜的軟件系統(tǒng)，都是以小編隊的方式完成的；比如操作系統(tǒng) linux ，大數(shù)據(jù)分析系統(tǒng) hadoop ，我們這個行業(yè)的 freeSwitch 等； 如果一個項目大到一定的規(guī)模， 需要不同角色的人參與， 那么也應(yīng)該是有更多的小編隊來做這一塊事情； 甚至更極端的做法， 就是一個項目在建設(shè)之初， 就考慮到會有很多小編隊或個 人參與到項目建設(shè)過程中，預(yù)留了多人、多團隊協(xié)作的支撐工具，比如說 nodejs 的 NPM ， go 語言和 rust 語言也有相應(yīng)的規(guī)劃；小編隊有很強的執(zhí)行力小編隊不會說這個事情需要做個評審； 小編隊不會說這個事情安排的資源不夠，需要協(xié)調(diào)更多的資源；小編隊會把這個事情當(dāng)成自己的事情， 不會像大軍團一樣， 把這個事情當(dāng)成大家的事情來對 待；我們來看個圖：（圖片遺失，暫不補充）小編隊有很強的創(chuàng)新力軟件行業(yè)不像建筑行業(yè)， 90%以上的優(yōu)秀軟件一開始都是個人或者小編隊創(chuàng)造出來的；很少 見一個優(yōu)秀軟件是一個大規(guī)模的組織創(chuàng)造出來的。一個案例張小龍曾經(jīng)說過一段話：好的工具就不應(yīng)該黏人， 應(yīng)該幫助用戶非常高效率完成任務(wù)， 而不是說用完了還要拿到手里 玩一會兒、 多用一會兒， 那不是一個很高效的表現(xiàn)。但是對這樣的一些想法的話， 我特別希 望它能夠根植到大家意識里，時刻想一下什么是我們做的對用戶有價值的事情；假設(shè)你是馬化騰，你會怎么給張小龍定KPI呢？考核微信的日活嗎？無論你制定什么 KPI,都會導(dǎo)致團隊去圍繞著那個KPI去完成任務(wù)；KPI考核準(zhǔn)則里有一項原則就是“可度量”，當(dāng)你提出一項純數(shù)據(jù)目標(biāo)的時候，團隊就會圍繞著那個數(shù)字去工作。而偏離了做好產(chǎn)品的初心。一個團隊工作的目的不應(yīng)該是完成 KPI,工作的目的應(yīng)該是做好產(chǎn)品，完成 KPI只不過是做 好產(chǎn)品這件事情的副產(chǎn)物， 就像一個人好好工作的目的不應(yīng)該是為了賺錢， 他好好工作的副 產(chǎn)物是賺了很多錢；所以你制定了一系列的 kpi 考核制度，只能導(dǎo)致員工工作的動機更不純粹。最后一個組織只要發(fā)展良好， 總是會吸引更多的資源， 所以組織規(guī)模的擴大是無可避免的， 但如 果一個組織規(guī)模已經(jīng)超過 500 人了，那么你應(yīng)該把他看作是 50100 個小團隊來對待，而不 是把他當(dāng)作一個 500 人的大團隊來對待。