開發(fā)團(tuán)隊中的等級
很多公司的開發(fā)團(tuán)隊都是分為：項目經(jīng)理、開發(fā)經(jīng)理、開發(fā)組長、開發(fā)人員這么幾層。這是一種典型的等級制度。
不出意外的話，這種結(jié)構(gòu)清晰、分工明確的管理體系是優(yōu)的。但經(jīng)過無數(shù)次的實踐表明，我們在軟件開發(fā)的過程中，延誤我們工期的不是計劃中的事情、而是那些突發(fā)事件或者不明確的東西。
這種情況下，開發(fā)人員遇到了困難首先需要向組長報告，組長向經(jīng)理報告。這時候處于上層的項目經(jīng)理就不得不熟悉具體的技術(shù)細(xì)節(jié)了。
當(dāng)然，如果組長什么事情都往上報告那還要組長做什么。所以一般來說組長都會根據(jù)自己的判斷來作出處理。
這么一判斷就出問題了。怎樣才能保證我們的這位組長判斷正確，就算這判斷正確了下一定正確嗎？如果存在兩個組長、三個組長都是自己判斷，那么在這個小組遇到的問題也就不能及時傳遞到整個團(tuán)隊。
以前我所處的團(tuán)隊就是以這種等級制度來管理的。如果說上面遇到的問題并不大的話，那么下面這個問題就是管理者不得不重視的了。
組長都是由經(jīng)驗豐富的程序員擔(dān)當(dāng)，如果經(jīng)驗豐富的程序員當(dāng)上了組長，肯定會因為管理上的職責(zé)影響自己的工作效率。在我們現(xiàn)在的團(tuán)隊中，新的程序員占了大多數(shù)（這是很多公司的現(xiàn)狀），凡是影響老程序員的效率的事情都是不可接受、不可原諒的，其實也就是管理成本過高。如果還用這種等級制度來管理的話會影響到團(tuán)隊的開發(fā)效率。
后來又嘗試了扁平化的管理，這樣可以將處于組長地位的程序員從管理細(xì)節(jié)上解放出來。看似效率提升了，但由于新的程序員沒有人帶，所以他們的成長特別緩慢，甚至還會走不少彎路。
以前我們嘗試過嚴(yán)格的等級制度管理方式，發(fā)現(xiàn)管理成本超出了我們的預(yù)算；接著又采用了扁平化的管理，由于新人比較多又沒有人進(jìn)行嚴(yán)格的監(jiān)督和輔導(dǎo)導(dǎo)致代碼質(zhì)量很低，結(jié)果也不理想。這樣看來開發(fā)團(tuán)隊中用等級制還是不用確實是個問題？
我們需要等級嗎？
由于團(tuán)隊規(guī)模不大，采用等級制度的話會付出高額的管理成本，這點(diǎn)我們很難接受。同時由于軟件行業(yè)的變化性，等級制度在這種環(huán)境下弱點(diǎn)是非常明顯的。
如果完全拋棄等級制度，又會出現(xiàn)諸如監(jiān)督和培訓(xùn)不足的問題。
后采用了結(jié)對編程的方式，但這種結(jié)對不是對等的結(jié)對編程，更多時候是一個老程序員帶著一個新的程序員來做。如果這時候有一個經(jīng)驗特別豐富的人來整體把握團(tuán)隊的進(jìn)度情況會更好。
看起來，似乎就現(xiàn)狀來說，我們不需要等級的制度，需要的是的角色。不過就上面分析來看，等級制度帶來的穩(wěn)定性確是不存在了。
團(tuán)隊中的每個人在職位上是對等的關(guān)系，這時候表面上不存在高等級和低等級的區(qū)分，但人員流動造成的影響并不像想象中那么大。這是因為在這種扁平化管理中每個人的經(jīng)驗是完全分享的，就算人員流動，但知識并不會隨著人員流動而流動。如果能做到這一點(diǎn)，那么等級制度可以丟掉了。
按照現(xiàn)在的團(tuán)隊規(guī)模（不超過20人）來看，等級制度是不合適的，不知道對于幾百人、幾千人的大開發(fā)團(tuán)隊是否需要等級制度，這就不得而知了。
很多公司的開發(fā)團(tuán)隊都是分為：項目經(jīng)理、開發(fā)經(jīng)理、開發(fā)組長、開發(fā)人員這么幾層。這是一種典型的等級制度。
不出意外的話，這種結(jié)構(gòu)清晰、分工明確的管理體系是優(yōu)的。但經(jīng)過無數(shù)次的實踐表明，我們在軟件開發(fā)的過程中，延誤我們工期的不是計劃中的事情、而是那些突發(fā)事件或者不明確的東西。
這種情況下，開發(fā)人員遇到了困難首先需要向組長報告，組長向經(jīng)理報告。這時候處于上層的項目經(jīng)理就不得不熟悉具體的技術(shù)細(xì)節(jié)了。
當(dāng)然，如果組長什么事情都往上報告那還要組長做什么。所以一般來說組長都會根據(jù)自己的判斷來作出處理。
這么一判斷就出問題了。怎樣才能保證我們的這位組長判斷正確，就算這判斷正確了下一定正確嗎？如果存在兩個組長、三個組長都是自己判斷，那么在這個小組遇到的問題也就不能及時傳遞到整個團(tuán)隊。
以前我所處的團(tuán)隊就是以這種等級制度來管理的。如果說上面遇到的問題并不大的話，那么下面這個問題就是管理者不得不重視的了。
組長都是由經(jīng)驗豐富的程序員擔(dān)當(dāng)，如果經(jīng)驗豐富的程序員當(dāng)上了組長，肯定會因為管理上的職責(zé)影響自己的工作效率。在我們現(xiàn)在的團(tuán)隊中，新的程序員占了大多數(shù)（這是很多公司的現(xiàn)狀），凡是影響老程序員的效率的事情都是不可接受、不可原諒的，其實也就是管理成本過高。如果還用這種等級制度來管理的話會影響到團(tuán)隊的開發(fā)效率。
后來又嘗試了扁平化的管理，這樣可以將處于組長地位的程序員從管理細(xì)節(jié)上解放出來。看似效率提升了，但由于新的程序員沒有人帶，所以他們的成長特別緩慢，甚至還會走不少彎路。
以前我們嘗試過嚴(yán)格的等級制度管理方式，發(fā)現(xiàn)管理成本超出了我們的預(yù)算；接著又采用了扁平化的管理，由于新人比較多又沒有人進(jìn)行嚴(yán)格的監(jiān)督和輔導(dǎo)導(dǎo)致代碼質(zhì)量很低，結(jié)果也不理想。這樣看來開發(fā)團(tuán)隊中用等級制還是不用確實是個問題？
我們需要等級嗎？
由于團(tuán)隊規(guī)模不大，采用等級制度的話會付出高額的管理成本，這點(diǎn)我們很難接受。同時由于軟件行業(yè)的變化性，等級制度在這種環(huán)境下弱點(diǎn)是非常明顯的。
如果完全拋棄等級制度，又會出現(xiàn)諸如監(jiān)督和培訓(xùn)不足的問題。
后采用了結(jié)對編程的方式，但這種結(jié)對不是對等的結(jié)對編程，更多時候是一個老程序員帶著一個新的程序員來做。如果這時候有一個經(jīng)驗特別豐富的人來整體把握團(tuán)隊的進(jìn)度情況會更好。
看起來，似乎就現(xiàn)狀來說，我們不需要等級的制度，需要的是的角色。不過就上面分析來看，等級制度帶來的穩(wěn)定性確是不存在了。
團(tuán)隊中的每個人在職位上是對等的關(guān)系，這時候表面上不存在高等級和低等級的區(qū)分，但人員流動造成的影響并不像想象中那么大。這是因為在這種扁平化管理中每個人的經(jīng)驗是完全分享的，就算人員流動，但知識并不會隨著人員流動而流動。如果能做到這一點(diǎn)，那么等級制度可以丟掉了。
按照現(xiàn)在的團(tuán)隊規(guī)模（不超過20人）來看，等級制度是不合適的，不知道對于幾百人、幾千人的大開發(fā)團(tuán)隊是否需要等級制度，這就不得而知了。