• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            HUUYUU

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

            1. 程序員寫出自認為沒有Bug的代碼。

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

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

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

            5. 重復3次步驟3和步驟4。

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

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

            8. 已經領了項目獎金的程序員不知跑到哪里去了。

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

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

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

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

            13. 程序員寫出自認為沒有Bug的代碼。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

             管理者只要懂管理就可以,不需要懂技術。

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

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

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

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

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

            posted on 2006-10-30 08:49 HUYU 閱讀(285) 評論(0)  編輯 收藏 引用

            日韩一区二区久久久久久| 青青久久精品国产免费看| 精品久久久久久中文字幕大豆网 | 久久亚洲综合色一区二区三区| 综合久久一区二区三区 | 国产精品久久久久免费a∨| 欧美日韩精品久久久免费观看| 久久精品人人做人人爽电影 | 国产成人精品久久亚洲高清不卡| 久久99国产精品久久99| 亚洲国产成人久久笫一页| 欧美精品乱码99久久蜜桃| 国产V综合V亚洲欧美久久| 精品久久久无码中文字幕天天 | 久久久中文字幕| 欧美精品福利视频一区二区三区久久久精品 | 午夜精品久久久久久久无码| 亚洲中文精品久久久久久不卡| 久久99精品国产99久久| 久久久久久久精品妇女99| 77777亚洲午夜久久多喷| 久久综合精品国产一区二区三区 | 91精品观看91久久久久久| 久久99国产精品久久99小说| 国产一久久香蕉国产线看观看| 精品国产青草久久久久福利| 久久精品国产精品亚洲下载| 久久亚洲精品中文字幕| 久久久久久久免费视频| 精品久久久久久国产牛牛app| 国内精品久久久久久99蜜桃| 精品国产青草久久久久福利| 欧美日韩精品久久久久 | 欧美大香线蕉线伊人久久| 久久久久久国产a免费观看黄色大片 | 亚洲女久久久噜噜噜熟女| 亚洲精品高清一二区久久| 热久久国产欧美一区二区精品| 国产—久久香蕉国产线看观看 | 久久久亚洲欧洲日产国码aⅴ| 理论片午午伦夜理片久久 |