從笑話中悟出C++開發(fā)管理之"道"

1. 程序員寫出自認(rèn)為沒有Bug的代碼。

2. 軟件測試，發(fā)現(xiàn)了20個Bug。

3. 程序員修改了10個Bug，并告訴測試組另外10個不是Bug。

4. 測試組發(fā)現(xiàn)其中5個改動根本無法工作，同時又發(fā)現(xiàn)了15個新Bug。

5. 重復(fù)3次步驟3和步驟4。

6. 鑒于市場方面的壓力，為了配合當(dāng)初制定的過分樂觀的發(fā)布時間表，產(chǎn)品終于上市了。

7. 用戶發(fā)現(xiàn)了137個新Bug。

8. 已經(jīng)領(lǐng)了項(xiàng)目獎金的程序員不知跑到哪里去了。

9. 新組建的項(xiàng)目組修正了差不多全部137個Bug，但又發(fā)現(xiàn)了456個新Bug。

10. 最初那個程序員從斐濟(jì)給飽受拖欠工資之苦的測試組寄來了一張明信片。整個測試組集體辭職.

11. 公司被競爭對手惡意收購。收購時，軟件的最終版本包含783個Bug。

12. 新CEO走馬上任。公司雇了一名新程序員重寫該軟件。

13. 程序員寫出自認(rèn)為沒有Bug的代碼。

　　要我說，如果真有這樣的公司，不倒閉對不起人民。

　這個笑話從程序員開始，到程序員結(jié)束，從頭到尾都在說程序員的不是。但是我要說的是，這完全是管理者的失敗，從整個過程中，看不到任何管理工作。這種管理者不但無知無能，還很無恥——將自己的失敗責(zé)任推給程序員。

　1、程序員憑什么證明他的代碼沒有BUG？有Test case嗎？有Code review嗎？這個環(huán)節(jié)管理缺失。

　2、測試發(fā)現(xiàn)BUG有進(jìn)行BUG管理嗎？有跟蹤嗎？這個環(huán)節(jié)管理缺失。
　3、憑什么證明程序員已經(jīng)把那10個BUG修改好了？另10個又為什么不是BUG？BUG的評價標(biāo)準(zhǔn)難道是程序員說了算？這個環(huán)節(jié)管理缺失。

　4、5個不能工作的BUG修改問題有沒有追究責(zé)任？增加新BUG是修改過程中不可避免的事情，但是如果有有效的單元測試機(jī)制，可以大大減少這種情況。這個環(huán)節(jié)管理缺失。

　5、迭代是正常的，但是問題處理于發(fā)散而不是收斂發(fā)展，可見沒有有效的管理調(diào)控。這個環(huán)節(jié)管理缺失。

　6、過于樂觀的時間表和不可能達(dá)到的最后期限，都表現(xiàn)出管理者的無知和無能。而在這樣的情況下強(qiáng)行推出產(chǎn)品，那就是無知者無畏了。

　7、這是對用戶的不負(fù)責(zé)任，管理者要負(fù)最大的責(zé)任。

　8、這樣的情況還能發(fā)項(xiàng)目獎金，只能說管理者不是一般的愚蠢。

　9、管理工作沒有任何的改進(jìn)，問題仍然處于發(fā)散迭代狀態(tài)。管理工作依然沒有到位。

　10、拖欠測試部門工資體現(xiàn)出管理者對質(zhì)量管理工作的忽視以及對人力資源管理方面一無所知。

　11、送被收購者兩個字：活該。送收購者兩個字：瞎眼。

　12、可見新管理者與原管理者半斤八兩，都沒有認(rèn)識到問題的根本所在。不過也只有這樣的管理者才會作出收購這種公司的決策。

　13、歷史的重演是必然的。

　一個正常的企業(yè)或是項(xiàng)目，其運(yùn)作必須應(yīng)該是循環(huán)向上進(jìn)行的。而保障這種運(yùn)行的工作就是管理。而管理工作的主要內(nèi)容就是控制，包括控制循環(huán)的節(jié)奏——不能太快也不能太慢，控制發(fā)展的方向——只能向上不能向下，控制運(yùn)作的穩(wěn)定——不能大起大落或時聚時散等。
　而這一切，在這個例子中都看不到。

　在這個笑話的例子中，一切都是以開發(fā)工作在驅(qū)動，這首先就是一個方向性錯誤，產(chǎn)品是為用戶服務(wù)的，當(dāng)然應(yīng)該是以用戶和市場作為驅(qū)動，并且結(jié)合自身的能力最終 確定工作的重點(diǎn)。這一錯誤折射出管理者對被管理的內(nèi)容很不了解，只好任由比較了解的程序員擺布——事實(shí)上他們除了技術(shù)，并不會了解更多。

　一個管理者如果對自己所管理的內(nèi)容不了解，他就不可能管理得好。

　這是一件毫無疑問的事，可是國內(nèi)的軟件業(yè)似乎總是不相信這一點(diǎn)。中國軟件業(yè)中流毒最深的謊言之一就是：

　管理者只要懂管理就可以，不需要懂技術(shù)。

其實(shí)這不過是那些無知無能無恥的管理者為了騙錢而編出來的，相信這句話的人必將付出金錢的代價。

　其次是質(zhì)量管理。基本的質(zhì)量管理常識告訴我們，每次循環(huán)結(jié)束前，最重的工作就是總結(jié)改進(jìn)。只有這樣才能保證循環(huán)運(yùn)作是向上發(fā)展，而不是失去控制地向下發(fā)展。 也只有有效的質(zhì)量管理，才能保證迭代過程是收斂發(fā)展，并最終達(dá)到目標(biāo)。但在這個例子中，這個部分顯然是缺失的——其中雖然有測試部門，但是他們的作用僅僅 是質(zhì)量管理中的質(zhì)量檢測環(huán)節(jié)，管理部分還是缺失的。

　然后是人力資源管理。軟件開發(fā)是一項(xiàng)勞動密集型的工作，雖然這是腦力勞動，但同樣意味著人在因素在其中占有決定性的地位。而例子中未改完BUG的程 序員拿到項(xiàng)目獎金，而同樣辛苦工作的測試人員卻被拖欠薪資，除了表現(xiàn)出管理者對他們的工作內(nèi)容的不了解，以及對質(zhì)量管理工作的不重視以外，還表現(xiàn)出管理者 完全不會管人，這是一種謀殺團(tuán)隊(duì)的行為——謀殺一個團(tuán)隊(duì)遠(yuǎn)比建設(shè)要容易得多。

　最后，這個失敗的管理者把他的經(jīng)歷編成這個笑話，讓大家看到他被程序員們害得多慘，把程序員妖魔化為一群騙子。但只要稍懂管理的人簡單分析一下就可以看出來，只不過是這個人的無知和無能造成了他現(xiàn)在的結(jié)果，而把責(zé)任推給別人的行為更是表現(xiàn)出他的無恥。

　作為身居高位的管理者，如果連應(yīng)該承擔(dān)的責(zé)任都要推卸，他們還能勝任什么事情呢?