在很多軟件項(xiàng)目開發(fā)團(tuán)隊(duì)中，項(xiàng)目經(jīng)理和部門經(jīng)理負(fù)責(zé)項(xiàng)目管理和控制。為了控制軟件開發(fā)的進(jìn)度，效率和風(fēng)險(xiǎn)，經(jīng)理們往往要求團(tuán)隊(duì)成員提交和更新各種各樣的表格，例如日?qǐng)?bào)、周報(bào)、代碼量報(bào)告、缺陷報(bào)告等等，通過各種計(jì)劃、報(bào)告、表格來管理團(tuán)隊(duì)。但是這種方法有很多固有的弊病。

　　首先，數(shù)據(jù)不準(zhǔn)確。例如在日?qǐng)?bào)中，一般要求提交任務(wù)完成百分比。這個(gè)數(shù)字很多時(shí)候是團(tuán)隊(duì)成員拍腦袋想出來的。任務(wù)完成90%后，剩下的10%需要更多的時(shí)間完成的情況在很多團(tuán)隊(duì)中也屢見不鮮。

　　其次，數(shù)據(jù)不及時(shí)。除了項(xiàng)目文件，經(jīng)理們沒有辦法了解項(xiàng)目的具體運(yùn)行狀況，進(jìn)度，只有通過日?qǐng)?bào)或者周報(bào)。任務(wù)分配也不及時(shí)，團(tuán)隊(duì)內(nèi)部工作量也不均衡。

　　再次，衡量標(biāo)準(zhǔn)不恰當(dāng)。用代碼量作為衡量Dev生產(chǎn)率的標(biāo)準(zhǔn)本來就是不恰當(dāng)?shù)摹＿@使團(tuán)隊(duì)成員單純追求代碼量而不停的復(fù)制拷貝，不關(guān)心優(yōu)秀系統(tǒng)架構(gòu)所要求的代碼簡(jiǎn)潔，架構(gòu)清晰。

　　用缺陷作為衡量Dev工作效率的標(biāo)準(zhǔn)也是不恰當(dāng)?shù)摹＼浖_發(fā)并不僅僅是編寫代碼，更重要的是溝通問題。絕大多數(shù)缺陷其實(shí)是由需求不明確或者是溝通的不充分和不準(zhǔn)確導(dǎo)致的。用缺陷率作為標(biāo)準(zhǔn)會(huì)導(dǎo)致團(tuán)員成員之間的矛盾，互相指責(zé)，推卸責(zé)任。

　　另外，信息不透明，不直觀。報(bào)告往往不是團(tuán)隊(duì)成員直接可見的，需要登錄到網(wǎng)站，或者訪問Source Control或者共享文件夾的某個(gè)文件(往往是有權(quán)限控制的)。這些信息不會(huì)直接展示給大家，他們總是需要一路點(diǎn)擊過去。

　　最后，過多的無效工作。團(tuán)隊(duì)成員要花費(fèi)很多時(shí)間和精力在更新及維護(hù)報(bào)告上面，但這些工作并沒有業(yè)務(wù)價(jià)值。

　　在處理復(fù)雜像軟件開發(fā)這類復(fù)雜問題的時(shí)候，使用Command&Control方式效率十分低下。很多情況下即使是最有經(jīng)驗(yàn)的經(jīng)理，由于他不在現(xiàn)場(chǎng)，不掌握全部具體情況，也很難做出準(zhǔn)確的判斷，有效地指揮團(tuán)隊(duì)成員工作。

　　而第二種管理方式(Self-organizing)在解決復(fù)雜問題時(shí)就要有效得多。

　　在復(fù)雜的環(huán)境中，可以通過訓(xùn)練及培訓(xùn)使團(tuán)隊(duì)成員掌握工作的基本原則，把責(zé)任下放給第一線的工作人員，由他們根據(jù)不斷變化的實(shí)際情況，不斷地調(diào)整，完成團(tuán)隊(duì)任務(wù)。