拿軟體品質來評員工績效,沒搞錯吧?

歲末年終是公司主管替員工評考績的時刻,多數的公司會在年初請員工擬定今年度的工作目標(通常稱做MBO或KPI),在年終時評估員工年初擬定目標的達成狀況,再決定年終獎金、升遷、加薪等規劃。

關於員工的績效考核,通常是看這位員工整年度的工作表現和貢獻度,為求客觀起見,有些公司會要求員工要有具體數字佐證自己的工作表現,Sales很容易取得有可量化的數字(例如今年度的業績數字、拿到的客戶數等),所以要評定Sales的績效不難;可是要評定技術人員的績效就不容易了,因為技術人員能提出較具體的數字頂多是有幾個專案結案,拿到幾張證照等等,不過這跟工作表現並沒有直接關係。

幾年前景氣不佳時,陸續傳出軟體公司合併的消息,聽說某家軟體公司為了達成合併後的超高營收目標,要求一切績效導向,因而要求公司員工必須制定客觀的量化KPI。前面提到,軟體業的技術人員(尤其是programmer)很難把工作產出量化,所以該公司的某些技術單位將軟體品質(例如bug數、CR數)(註)這個較容易取得的數字,成為評鑑技術人員的績效標準。個人認為,除非專案經理在分配工作時,可以把工作責任區分的很清楚 (不過這在現實的工作環境似乎不太可能),否則拿軟體品質來評鑑員工的績效,反而會引起很多爭議,而導致評量失真,例如Bug的產生有可能是因為系統分析階段的需求沒有談清楚,或者需求變更(change request)的發生可能是因為用戶業務流程的改變,不一定全是技術人員的責任。

軟體是專案成員是團隊合作的產物,軟體品質的好壞是整個專案團隊(甚至是公司)的責任,拿來評量單一員工的績效並不妥當。有些主管會憑印象來評定員工考績,這也沒什麼不好,只是這麼做通常資深員工就較佔優勢了。過去業界一直都沒有較好的方法做技術人員的績效評量,所以用印象分數來評技術人員的績效,似乎成了沒辦法中比較好的方法了。

註:要度量軟體的品質,在軟體工程中比較常用的方式是計算"缺陷密度",它的公式是軟體規模除上缺陷數,軟體規模可以用程式行數(line of code)或者功能點數(function point),缺陷數則通常是系統bug數。

(本文同步轉載於ZDNet)

相關文章

如何將電腦畫面經由 Chromecast 投放到電視螢幕上

Mac與Android裝置傳輸檔案的方法

Chrome 的檔案續傳功能

使用 Line Bot API 製作聊天機器人