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