軟體人員績效考核新思路

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

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1037866


相關文章