原文出自 Taiwan CNET, 若有侵犯版權, 請版主刪除 http://taiwan.cnet.com/enterprise/technology/0,2000062852,20089551,00.htm    解雇不適任的軟體工程師 Erik Engbrecht原著 2004/05/19 軟體的品質議題不僅會造成安全問題，更容易導致時間一再延後、預算超支、無法部署或部署可能性較低等問題的出現。因此，在軟體開發過程中，任何個人（從菜鳥程式師到資深經理）的不適任，都可能導致軟體客戶對公司交付的產品價值失去信心。 作為軟體開發人員，取得正式的資格證書（證明一個人能夠適任某項特定的工作）並不是最重要的要求。一味強調開發人員具備資格證書，只會增加成本，助長官僚作風，而無法導致工作品質的提升。事實上，許多工作相當出色的人並不具備其相關領域的學歷。相反，很多取得學歷的人們卻不見得能適任本職工作。 企業要的是什麼？ 首先，我們需要採用一種方法，能夠對軟體工程師的表現和管理能力進行有效的評估。在網路狂飆時期，人們爭相閱讀《Learn （C /Java/Visual Basic/etc） in 21 days》系列叢書，並在求職簡歷中聲稱自己是程式師。他們因此迅速爭取到超過其自身價值的高額薪水，而具備真實技能的程式師也僅僅是處於相同的薪水標準。是的，「21 Days」系列叢書很多時候被認為是成為優秀軟體工程師的入門書籍。但由於缺乏有效的評估和測試手段，使得具備工作能力的人員與不能適任工作的人員，基本上沒有薪水或職位的差異。 在《人月神話：軟體專案管理之道》（Mythical Man Month）一書中，Frederick Brooks指出：一個不能適任工作的程式師與一個優秀程式師相比較，兩者之間的工作效率相差十倍。Frederick同時指出：根據統計顯示，各人的閱歷與其工作效率之間並不存在直接的關聯性。 發表人 - osx 於 2004/05/20 14:53:39

企業面臨的問題是：如何對能力差異進行斷定？在許多情形中，我們都能夠意識到（至少是部分意識到）差異的存在。舉一個例子：新進同事擁有35萬美元的年薪，但在位多年的老工程師卻僅只有1.4萬美元年薪。他或許工作相當努力，但他努力工作所創造出的價值卻極為有限，是否公司根本不值得雇用這樣的員工？針對這種情形，讓許多經理感到為難的是，他們缺乏勇氣對一個努力工作的員工指出他不能適任這份工作。事實上，我們很清楚許多持有資格證書的程式師並不能適任他們的工作，但由於沒有及時糾正或改變這種狀況，最終可能導致工作的嚴重失誤。 概括的來說，有很大一部份所謂的「軟體工程師」並沒有做出任何有價值的貢獻（儘管他們的工作相當努力），甚至可能影響整個團隊的工作效率；然而，他們的薪水卻與能夠創造價值的員工保持一致。 從管理者的角度考慮，儘管我旗下大多數程式師其實僅值基本薪資的水準，但我無法真的給這麼低的薪水，同時我也不可能要求他們通通走路，只留下真正優秀的人才，因為這麼做一定會嚴重影響員工的士氣。管理者會想：我可把你們全都解雇，然後把職務移去印度，那我付的薪水更可遠低於基本薪資，且裡面總是會有幾個很厲害的吧。 沒錯，由於沒有主管膽敢把不適任的人員通通解雇，到頭來反而拖累整個團隊，公司乾脆把整個團隊給外移了。 回到資格證書的問題。資格證書是衡量程式師能否適任工作的標準嗎？答案是否定的，因為只有在實際工作中才能看出程式師的真實才能。許多有才能的人們並不具備正式的學歷背景；同樣，具備良好學歷背景的人們卻不一定能夠適任他們的工作。因此，經理應該對他們的開發人員進行實際有效的評估和考察。 我們要求經理客觀公正地對程式師的工作能力進行評估。然而，有哪些確定的方法能夠對軟體工程師的個人工作表現進行追蹤測定呢？此外，我們還應該認識到，客觀的測評工作可能僅僅只是一種形式。因為沒有人願意唱黑臉，將不能適任工作的壞消息轉告給當事人。 但不管如何，公司還是得去蕪存菁才行。

客戶的認知 當我們決定開除不適任的程式師後，問題又來了：大部分寫出來的軟體依然不安全且缺乏功能性。為何如此？這很簡單，沒出過事大家就不會很在意。在專案的開發過程中，總是伴隨著許多的需求、擔心逾期或超支等問題。結果呢？有人(可能是經理)會注意到許多時間都花在系統穩定度、安全性與擴充性，於是他可能會暗示說：「我們對既有的程式庫不夠有信心，若我們還有多一個月的時間，我們一定可以好好調整，但我們沒那麼多時間。」問題是，這些都不是文件上載明的需求，沒錯，可擴充延伸的系統在維護上的成本低很多，但那是明年的預算了。至於安全性？我們不是已經有防火牆了嗎？自家公司內應該沒有人會鑽安全漏洞吧？ 現實的情況是，軟體工程師寫出好軟體反而會挨罵，因為管理階層寧可開發出更多功能，而非穩定的系統。原因很簡單，因為這才是客戶所期望的。客戶往往對原始碼不感興趣，他們不會跟你反應：「你的程式碼違反了物件導向（object-oriented）的設計原則。未來怎麼加入新功能？」或者提出：「你應該對所有靜態和綜合的變數進行考慮，對系統進行重新編寫才能有多線緒功能。你編寫的軟體或許能夠滿足10個用戶的要求，但它是否能夠滿足1000個用戶的需求呢？」或者說：「你完全沒有考慮到交易處理的互隔離性問題，以及參照一致性問題。萬一6個月後，我的資料庫中會不會出現一堆交易不全的壞資料呢？」 不會的，客戶用過系統後的需求往往是：「我希望多加一個某某功能的按鈕...」或者「你使用EJB了嗎？我希望能夠使用EJB的系統。XML怎麼沒看到？若沒這些熱門的東西，我怎麼跟老闆交代？」 這麼說來這都是客戶的錯囉？非也，軟體工程師有職責協助客戶做出正確的決策。簡單的說，我們必須可以讓客戶知道急就章作出來的系統在整個生命週期中所付出的代價一定會高出設計良好的系統許多，若他們不理會，以後嚐到苦頭就知道教訓了。

這個問題的確值得思考.... ================================================= 題外話... 轉貼別的網頁文章時,最好不要全文轉貼 避免有著作權的糾紛...