從一個笑話看軟體開發管理(奇怪的過程,以及我的3點體會)

來源:互聯網
上載者:User

標籤:

從一個笑話看軟體開發管理

1. 程式員寫出自認為沒有Bug的代碼。
2. 軟體測試,發現了20個Bug。
3. 程式員修改了10個Bug,並告訴測試組另外10個不是Bug。
4. 測試組發現其中5個改動根本無法工作,同時又發現了15個新Bug。
5. 重複3次步驟3和步驟4。
6. 鑒於市場方面的壓力,為了配合當初制定的過分樂觀的發布時間表,產品終於上市了。
7. 使用者發現了137個新Bug。
8. 已經領了項目獎金的程式員不知跑到哪裡去了。
9. 新組建的項目組修正了差不多全部137個Bug,但又發現了456個新Bug。
10. 最初那個程式員從斐濟給飽受拖欠工資之苦的測試組寄來了一張明信片。整個測試組集體辭職。
11. 公司被競爭者惡意收購。收購時,軟體的最終版本包含783個Bug。
12. 新CEO走馬上任。公司雇了一名新程式員重寫該軟體。
13. 程式員寫出自認為沒有Bug的代碼。

  這樣的公司,不倒閉對不起人民。

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

 1、程式員憑什麼證明他的代碼沒有BUG?有Test case嗎?有Code review嗎?這個環節管理缺失(三點關鍵:要把關鍵的功能列出Test Case,其餘bug自己管理;另外重要功能或者技術痛點應該預研;技術高手要自己培養)。

 2、測試發現BUG有進行BUG管理嗎?有跟蹤嗎?這個環節管理缺失。

 3、憑什麼證明程式員已經把那10個BUG修改好了?另10個又為什麼不是BUG?BUG的評價標準難道是程式員說了算?這個環節管理缺失。

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

 5、迭代是正常的,但是問題處理於發散而不是收斂發展,可見沒有有效管理調控。這個環節管理缺失。

 6、過於樂觀的時間表和不可能達到的期限,都表現出管理者的無知和無能。而在這樣的情況下強行推出產品,那就是無知者無畏了。

 7、這是對使用者的不負責任,管理者要負最大的責任。

 8、這樣的情況還能發項目獎金,只能說管理者不是一般的愚蠢。

 9、管理工作沒有任何的改進,問題仍然處於發散迭代狀態。管理工作依然沒有到位。

 10、拖欠測試部門工資體現出管理者對品質管理工作的忽視以及對人力資源管理方面一無所知。

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

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

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

 一個正常的企業或是項目,其運作必須應該是迴圈向上進行的。而保障這種啟動並執行工作就是管理。而管理工作的主要內容就是控制,包括控制迴圈的節奏——不能太快也不能太慢,控制發展的方向——只能向上不能向下,控制運作的穩定——不能大起大落或時聚時散等。

 而這一切,在這個例子中都看不到。

 在這個笑話的例子中,一切都是以開發工作在驅動,這首先就是一個方向性錯誤,產品是為使用者服務的,當然應該是以使用者和市場作為驅動,並且結合自身的能力最終 確定工作的重點。這一錯誤折射出管理者對被管理的內容很不瞭解,只好任由比較瞭解的程式員擺布——事實上他們除了技術,並不會瞭解更多。

 一個管理者如果對自己所管理的內容不瞭解,他就不可能管理得好。

 這是一件毫無疑問的事,可是國內的軟體業似乎總是不相信這一點。中國軟體業中流毒最深的謊言之一就是:

 管理者只要懂管理就可以,不需要懂技術。
其實這不過是那些無知無能無恥的管理者為了騙錢而編出來的,相信這句話的人必將付出金錢的代價。

 其次是品質管理。基本的品質管理常識告訴我們,每次迴圈結束前,最重的工作就是總結改進。只有這樣才能保證迴圈運作是向上發展,而不是失去控制地向下發展。 也只有有效品質管理,才能保證迭代過程是收斂發展,並最終達到目標。但在這個例子中,這個部分顯然是缺失的——其中雖然有測試部門,但是他們的作用僅僅 是品質管理中的品質檢測環節,管理部分還是缺失的。

 然後是人力資源管理。軟體開發是一項勞動密集型的工作,雖然這是腦力勞動,但同樣意味著人在因素在其中佔有決定性的地位。而例子中未改完BUG的程 序員拿到項目獎金,而同樣辛苦工作的測試人員卻被拖欠薪資,除了表現出管理者對他們的工作內容的不瞭解,以及對品質管理工作的不重視以外,還表現出管理者 完全不會管人,這是一種謀殺團隊的行為——謀殺一個團隊遠比建設要容易得多。

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

 作為身居高位的管理者,如果連應該承擔的責任都要推卸,他們還能勝任什麼事情呢。

從一個笑話看軟體開發管理(奇怪的過程,以及我的3點體會)

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.