軟件測試人員績效考核新思路 軟件測試方法
關鍵字：考核 軟件人員管理，一向被認為是一件難題。尤其是年中年底的評價問題，涉及到加工資，發獎金，稍有差池，就會民怨沸騰，來年是該走的不走，不該走的全走了。 一個軟件工程師好不好？怎么判斷？記件制？看看代碼寫得多不多？稍有頭腦的人機會立刻反對。精妙的代碼不需要長。如果要比長，本來調用一個公共庫中的函數就好了，現在我就拷貝過來；本來有一個狀態變量可以重用，我再加一個；……程序員的法子多了。高手們全不干了，有的Bug，查要一個星期，而且每天晚上都得查到凌晨兩點，改起來就一行，這老兄一定跳起來了。所以記件制不行。記時制？每天八小時上班，太容易了。比加班，誰比得過毛頭小伙子��！而且，你知道我加班干什么？白天我可以天天上網，晚上干點活�；蛘呶壹影嗑痛�游戲，老板反正不在。時間長了，就變成了大鍋飯。這也不行。 做技術的通常想到這兒就沒什么法子了。人力資源專家通常這個時候跳出來了：KPI嘛！ KPI全稱是Key Performance Index，就是大家每年每季度或每個月要填的表格： 考核項 權重 得分 工作量 30% 工作質量 30% 工作態度 10% 溝通能力 10% …… …… 合計 作技術的組長和經理們，雖然一頭霧水：這根本就沒解決我的問題嗎！不過，至少我知道該怎么干了。上去三下五除二給它填完了。加班多的，工作量打滿分；打游戲的，工作態度全扣了…… 這法子實施容易，而且總的來說，至少組長經理們覺得是公平了。老板看他們同意了，也樂得消停。但是，這種方法也有很大的問題。最大的問題是把人看死了：好人永遠是好人，落后永遠是落后。時間一長，論資排輩，老人把權，企業失去動力。這種方法是以組織結構為中心的考核：組長給組員打分，經理給組長和打分，總經理給經理打分。大概是絕大多數有考評的單位的主要方式。 改變這種情況有什么方法嗎？較好的方法是從以組織結構為中心的變為以項目為中心的考核。抽象的說，就是在每個項目中考核每個成員的評分，此評分是根據技術指標來衡量的；每年每季度每月的考評分就由個人參與的在項目中的總分來決定。通常來說，這種評分方式，適用于所有經理以下的人員的考評。而經理的考評，則可以按照MBO的方式，即Manage by Objective來管理。這種考評方式，能夠極大激發基層員工的動力。因為考評結果是在各個項目中得分的總和，他們會樂意參加更多的項目�？荚u分用技術指標決定，如工作量用完成的功能點來衡量，工作質量用每千行代碼Bug數衡量，技術人員會認為這很公平，從而有動力更努力。這種考評方法，也要求管理層有一種開放的管理態度：從“我要管”到“我來評”的轉變。開放，第一，體現在允許員工內部自由流動。很多基層或中層組織和經理都有一種不愿意放人的傾向，從而使得一些內部員工不能到他喜歡和勝任的崗位上去，最后選擇離開公司。與其這樣，不如讓他們自己在公司里尋找機會，同時也承擔轉崗的后果。第二，相信被充分信任，授權而責任明確的員工會努力完成自己的工作。這比保姆式管理要好的多。以前遇到一個能力很強的組長，經常比喻他做項目是就像兩手護著一圈雞蛋，稍不留心，雞蛋就漏了，以示他的手下多么不濟；后來這個組長走了，項目的后續版本卻還是正常發布，沒見那個雞蛋打掉了。當然，這種管理方法最大的要求是具備良好的信息化管理。比如，代碼應該有統一的代碼庫管理，而不是只保存在程序員個人手里；Bug也要存在缺陷管理庫中，不是只是去跟程序員講一下。每個項目結束時，每項統計指標的計算也是煩瑣的工作，需要人力和耐心。除了信息化管理外，各級組織結構上的經理和組長的認可也是很重要的。因為他們在員工的評價的主導權上有所削弱，甚至這種評價方法出來的結果和他們的“影響”不一致。只是需要和他們討論：也許要改變的是個人的成見，而不是評分。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
