小團(tuán)隊(duì)管理與大團(tuán)隊(duì)管理

《小團(tuán)隊(duì)管理與大團(tuán)隊(duì)管理》由會(huì)員分享，可在線閱讀，更多相關(guān)《小團(tuán)隊(duì)管理與大團(tuán)隊(duì)管理（4頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、小團(tuán)隊(duì)管理與大團(tuán)隊(duì)管理 我們公司和大部分傳統(tǒng)軟件公司一樣， 隨著業(yè)務(wù)的發(fā)展和新領(lǐng)域的開拓， 公司的管理風(fēng)格越 來越像華為，這是不是最佳的演進(jìn)路線， 我覺得值得探討，以下是我的思考，希望跟大家討 論。 一個(gè)問題 前段時(shí)間跟一個(gè)創(chuàng)業(yè)的朋友聊天， 說起他們最近在做的一個(gè)項(xiàng)目， 這是一個(gè)教育行業(yè)的管理 系統(tǒng)， 業(yè)務(wù)非常復(fù)雜，牽涉到的決策人， 需要對(duì)接的系統(tǒng)也非常多，最后問到他們做了多久 完成這個(gè)項(xiàng)目，朋友告訴我 2 個(gè)多月， 6 個(gè)人，其中還括一個(gè)美工，一個(gè)項(xiàng)目經(jīng)理；剩下的 都是開發(fā)人員，沒有測試，沒有前端開發(fā)；朋友問我，如果這個(gè)項(xiàng)目給你們做，你們需要做 多久；我想了想說，這個(gè)項(xiàng)目如果交給我們做

2、，順利的話，至少要半年。 為什么差異這么大呢？ 我們一個(gè)一個(gè)環(huán)節(jié)來分析一下， 朋友的團(tuán)隊(duì)跟客戶溝通需求的時(shí)候， 功能性需求只用一個(gè)原 型草圖，非功能性需求就一個(gè) excel 表格；如果我們公司做的話，至少要做需求調(diào)研報(bào)告， 需求規(guī)格說明書；這個(gè)階段的負(fù)責(zé)人甚至不會(huì)畫原型，要到設(shè)計(jì)階段才有人能畫原型； 到設(shè)計(jì)階段， 朋友的團(tuán)隊(duì)幾乎沒有什么技術(shù)設(shè)計(jì)， 業(yè)務(wù)按模塊給開發(fā)人員分一下， 各人設(shè)計(jì) 好自己的數(shù)據(jù)庫模型， 匯總起來給項(xiàng)目經(jīng)理看一下， 沒問題就進(jìn)入開發(fā)階段了， 界面設(shè)計(jì)花 的時(shí)間比較久， 跟客戶反復(fù)確認(rèn)了兩三次；如果我們公司做的話， 至少要產(chǎn)出原型設(shè)計(jì) （低 保真描述功能的設(shè)計(jì)稿，高保真

3、描述界面的設(shè)計(jì)稿） ，概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)（技術(shù)設(shè)計(jì)、架 構(gòu)設(shè)計(jì)、網(wǎng)絡(luò)設(shè)計(jì)）等等，而且?guī)缀趺總€(gè)設(shè)計(jì)都要經(jīng)歷評(píng)審環(huán)節(jié)，組織評(píng)審就要協(xié)調(diào)人員， 要等大家都有時(shí)間的時(shí)候再做評(píng)審，這都是損耗； 到開發(fā)測試階段， 朋友的團(tuán)隊(duì)幾個(gè)開發(fā)人員從前端到后端， 從開發(fā)到測試， 都是這幾個(gè)人做； 如果我們公司來做的話， 后臺(tái)開發(fā)人員不做前端 （不做復(fù)雜的前端頁面， 普通的前端工作還 是要做的），質(zhì)量保證要測試人員保證，測試把 BUG 提交到 BUG 管理工具，開發(fā)再去 BUG 管理工具查閱屬于自己的 BUG，修改完成之后，再關(guān)閉 BUG,測試再做回歸測試；這些流 程看起來瑣碎，但卻損耗了大量的資源； 驗(yàn)收上線階

4、段, 朋友的團(tuán)隊(duì)所有人都鋪在項(xiàng)目現(xiàn)場,有問題, 當(dāng)場解決； 我們公司要收集問 題,讓測試工程師驗(yàn)證問題,再由開發(fā)解決, 解決之后再驗(yàn)證,再發(fā)布版本給現(xiàn)場的實(shí)施工 程師,實(shí)施工程師再更新上線,給客戶驗(yàn)證。 這個(gè)問題很明顯： 規(guī)模大的團(tuán)隊(duì)和規(guī)模小的團(tuán)隊(duì)工作方式的差異非常大, 組織資源的方式也 有明顯的區(qū)別； 我們抽象一下, 把這兩種模式稱為：大軍團(tuán)模式和小編隊(duì)模式,再看這兩種 模式的具體區(qū)別： 大軍團(tuán)模式 之前有一種理論， 要完成一項(xiàng)超大規(guī)模的工程， 往往需要成百上千人， 有組織有紀(jì)律的協(xié)作 才能完成； 這樣就需要制定一系列的規(guī)章、制度、流程、 KPI 來約束這些人， 把這些人變成一個(gè)龐大機(jī)

5、器的零部件，保證結(jié)果的達(dá)成，避免產(chǎn)生差錯(cuò)； 這是一種非常常見的大組織的運(yùn)作模式， 不但在軟件行業(yè)普遍存在（華為、惠普、 IBM）， 在造橋、修路、航天、汽車等工業(yè)領(lǐng)域也十分常見， 這種模式非?！胺€(wěn)” ，他能保證目標(biāo)的穩(wěn)定達(dá)成，并且能使目標(biāo)達(dá)成的過程清晰、可控。 小編隊(duì)模式 第三次工業(yè)革命（信息技術(shù)革命）以來，小編隊(duì)的運(yùn)作模式發(fā)展越來越好，我司 IPCC產(chǎn)品 的核心：開源語音通信軟件 FreeSwitch，核心開發(fā)者也不過 6個(gè)人；（說這個(gè)開源軟件養(yǎng)活 了半個(gè)呼叫中心行業(yè)的開發(fā)者都不足為過） ； 這種例子在軟件行業(yè)不勝枚舉，比如： git 源 碼管理系統(tǒng)、linux操作系統(tǒng)、JavaS

6、cript語言等等。 甚至有些產(chǎn)品是一個(gè)人在短時(shí)間內(nèi)完成的，這就是英雄； 有很多大規(guī)模的公司，比如谷歌、 、國內(nèi)的百度也在內(nèi)部推行小編隊(duì)的運(yùn)作模式； 這種模式非?！翱臁?，他能保證目標(biāo)的快速達(dá)成，并且能使目標(biāo)達(dá)成的效率非常高； 大軍團(tuán)的不足 效率低下 大軍團(tuán)強(qiáng)調(diào)集體的智慧， 個(gè)體想推動(dòng)一項(xiàng)事務(wù)向正確的方向推進(jìn)十分困難， 個(gè)體的決策往往會(huì)受到質(zhì)疑或排斥 諸如：流程、規(guī)范、計(jì)劃、考核、文檔、評(píng)審、調(diào)研等詞 都是為了保證目標(biāo)的穩(wěn)定達(dá)成所衍生出來的東西， 它們都是團(tuán)隊(duì)快速前進(jìn)的束縛和絆腳石！ 阻礙創(chuàng)新 大軍團(tuán)鼓勵(lì)墨守成規(guī)、照章辦事的氛圍， 大軍團(tuán)強(qiáng)調(diào)分工， 把員工看作螺絲釘， 希望員

7、工各司其職， 不是職責(zé)范圍內(nèi)的事務(wù)盡量不要 碰，因?yàn)槟悴粚I(yè)，你可能會(huì)出錯(cuò)，大軍團(tuán)最害怕出錯(cuò)； 只有這樣才能使目標(biāo)達(dá)成的過程清晰可控； 然而創(chuàng)新卻需要不拘一格的思想， 需要獨(dú)立自主的工作空間， 需要組織具備容錯(cuò)性， 這和大 軍團(tuán)的工作方式是格格不入的； 資源浪費(fèi) 為了使目標(biāo)的達(dá)成過程清晰可控； 大軍團(tuán)制定了很多流程和制度來約束個(gè)體的行為； 他把每一項(xiàng)事務(wù)都拆分成很多環(huán)節(jié)； 又給每個(gè)環(huán)節(jié)制定了很多關(guān)卡； 而且每個(gè)環(huán)節(jié)都要留下數(shù)據(jù)，使過程有跡可尋； 因?yàn)榇筌妶F(tuán)要做到每項(xiàng)事務(wù)都可以復(fù)盤，產(chǎn)生問題之后要可以追溯問題根源； 這樣確實(shí)保證了目標(biāo)達(dá)成過程的清晰可控，但卻浪費(fèi)了大量的資源；

8、小編隊(duì)的優(yōu)勢 小編隊(duì)也適合做大項(xiàng)目 有很多很龐大復(fù)雜的軟件系統(tǒng)，都是以小編隊(duì)的方式完成的； 比如操作系統(tǒng) linux ，大數(shù)據(jù)分析系統(tǒng) hadoop ，我們這個(gè)行業(yè)的 freeSwitch 等； 如果一個(gè)項(xiàng)目大到一定的規(guī)模， 需要不同角色的人參與， 那么也應(yīng)該是有更多的小編隊(duì)來做 這一塊事情； 甚至更極端的做法， 就是一個(gè)項(xiàng)目在建設(shè)之初， 就考慮到會(huì)有很多小編隊(duì)或個(gè) 人參與到項(xiàng)目建設(shè)過程中，預(yù)留了多人、多團(tuán)隊(duì)協(xié)作的支撐工具，比如說 nodejs 的 NPM ， go 語言和 rust 語言也有相應(yīng)的規(guī)劃； 小編隊(duì)有很強(qiáng)的執(zhí)行力 小編隊(duì)不會(huì)說這個(gè)事情需要做個(gè)評(píng)審； 小編隊(duì)不會(huì)說這個(gè)事

9、情安排的資源不夠，需要協(xié)調(diào)更多的資源； 小編隊(duì)會(huì)把這個(gè)事情當(dāng)成自己的事情， 不會(huì)像大軍團(tuán)一樣， 把這個(gè)事情當(dāng)成大家的事情來對(duì) 待； 我們來看個(gè)圖： （圖片遺失，暫不補(bǔ)充） 小編隊(duì)有很強(qiáng)的創(chuàng)新力 軟件行業(yè)不像建筑行業(yè)， 90%以上的優(yōu)秀軟件一開始都是個(gè)人或者小編隊(duì)創(chuàng)造出來的；很少 見一個(gè)優(yōu)秀軟件是一個(gè)大規(guī)模的組織創(chuàng)造出來的。 一個(gè)案例 張小龍?jiān)?jīng)說過一段話： 好的工具就不應(yīng)該黏人， 應(yīng)該幫助用戶非常高效率完成任務(wù)， 而不是說用完了還要拿到手里 玩一會(huì)兒、 多用一會(huì)兒， 那不是一個(gè)很高效的表現(xiàn)。但是對(duì)這樣的一些想法的話， 我特別希 望它能夠根植到大家意識(shí)里，時(shí)刻想一下什么是我們做的

10、對(duì)用戶有價(jià)值的事情； 假設(shè)你是馬化騰，你會(huì)怎么給張小龍定 KPI呢？考核微信的日活嗎？…… 無論你制定什么 KPI,都會(huì)導(dǎo)致團(tuán)隊(duì)去圍繞著那個(gè) KPI去完成任務(wù)； KPI考核準(zhǔn)則里有一項(xiàng)原則就是“可度量”，當(dāng)你提出一項(xiàng)純數(shù)據(jù)目標(biāo)的時(shí)候， 團(tuán)隊(duì)就會(huì)圍繞 著那個(gè)數(shù)字去工作。而偏離了做好產(chǎn)品的初心。 一個(gè)團(tuán)隊(duì)工作的目的不應(yīng)該是完成 KPI,工作的目的應(yīng)該是做好產(chǎn)品，完成 KPI只不過是做 好產(chǎn)品這件事情的副產(chǎn)物， 就像一個(gè)人好好工作的目的不應(yīng)該是為了賺錢， 他好好工作的副 產(chǎn)物是賺了很多錢； 所以你制定了一系列的 kpi 考核制度，只能導(dǎo)致員工工作的動(dòng)機(jī)更不純粹。 最后 一個(gè)組織只要發(fā)展良好， 總是會(huì)吸引更多的資源， 所以組織規(guī)模的擴(kuò)大是無可避免的， 但如 果一個(gè)組織規(guī)模已經(jīng)超過 500 人了，那么你應(yīng)該把他看作是 50~100 個(gè)小團(tuán)隊(duì)來對(duì)待，而不 是把他當(dāng)作一個(gè) 500 人的大團(tuán)隊(duì)來對(duì)待。