軟體測試人員績效考核新思路

一個軟體工程師好不好？怎麼判斷？記件制？看看代碼寫得多不多？稍有頭腦的人機會立刻反對。精妙的代碼不需要長。如果要比長，本來調用一個公用庫中的函數就好了，現在我就拷貝過來；本來有一個狀態變數可以重用，我再加一個；……程式員的法子多了。

　　高手們全不幹了，有的Bug，查要一個星期，而且每天晚上都得查到淩晨兩點，改起來就一行，這老兄一定跳起來了。所以記件制不行。記時制？每天八小時上班，太容易了。比加班，誰比得過毛頭小夥子啊！而且，你知道我加班幹什嗎？白天我可以天天上網，晚上幹點活。或者我加班就打遊戲，老闆反正不在。時間長了，就變成了大鍋飯。這也不行。

　　做技術的通常想到這兒就沒什麼法子了。人力資源專家通常這個時候跳出來了：KPI嘛！ KPI全稱是Key Performance Index，就是大家每年每季度或每個月要填的表格：

　　考核項      權重  得分

　　工作量      30%

　　工作品質    30%

　　工作態度    10%

　　溝通能力    10%

　　……  ……

　　合計

　　作技術的組長和經理們，雖然一頭霧水：這根本就沒解決我的問題嗎！不過，至少我知道該怎麼幹了。上去三下五除二給它填完了。加班多的，工作量打滿分；打遊戲的，工作態度全扣了…… 這法子實施容易，而且總的來說，至少組長經理們覺得是公平了。老闆看他們同意了，也樂得消停。但是，這種方法也有很大的問題。最大的問題是把人看死了：好人永遠是好人，落後永遠是落後。時間一長，論資排輩，老人把權，企業失去動力。這種方法是以組織圖為中心的考核：組長給組員打分，經理給組長和打分，總經理給經理打分。大概是絕大多數有考評的單位的主要方式。

　　改變這種情況有什麼方法嗎？較好的方法是從以組織圖為中心的變為以項目為中心的考核。抽象的說，就是在每個項目中考核每個成員的評分，此評分是根據技術指標來衡量的；每年每季度每月的考評分就由個人蔘與的在項目中的總分來決定。通常來說，這種評分方式，適用於所有經理以下的人員的考評。而經理的考評，則可以按照MBO的方式，即Manage by Objective來管理。這種考評方式，能夠極大激發基層員工的動力。因為考評結果是在各個項目中得分的總和，他們會樂意參加更多的項目。考評分用技術指標決定，如工作量用完成的功能點來衡量，工作品質用每千行代碼Bug數衡量，技術人員會認為這很公平，從而有動力更努力。這種考評方法，也要求管理層有一種開放的管理態度：從“我要管”到“我來評”的轉變。

　　開放，第一，體現在允許員工內部自由流動。很多基層或中層組織和經理都有一種不願意放人的傾向，從而使得一些內部員工不能到他喜歡和勝任的崗位上去，最後選擇離開公司。與其這樣，不如讓他們自己在公司裡尋找機會，同時也承擔轉崗的後果。第二，相信被充分信任，授權而責任明確的員工會努力完成自己的工作。這比保姆式管理要好的多。以前遇到一個能力很強的組長，經常比喻他做項目是就像兩手護著一圈雞蛋，稍不留心，雞蛋就漏了，以示他的手下多麼不濟；後來這個組長走了，項目的後續版本卻還是正常發布，沒見那個雞蛋打掉了。當然，這種管理方法最大的要求是具備良好的資訊化管理。比如，代碼應該有統一的程式碼程式庫管理，而不是只儲存在程式員個人手裡；Bug也要存在缺陷管理庫中，不是只是去跟程式員講一下。每個項目結束時，每項統計指標的計算也是煩瑣的工作，需要人力和耐心。除了資訊化管理外，各級組織圖上的經理和組長的認可也是很重要的。因為他們在員工的評價的主導權上有所削弱，甚至這種評價方法出來的結果和他們的“影響”不一致。只是需要和他們討論：也許要改變的是個人的成見，而不是評分。