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

2則回應

分享

    

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

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

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

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

本[網路部落格]文章僅反映作者個人意見，不代表ZDNET立場，並已獲作者同意以CC授權轉載。原文請見：作者部落格。