如何評量知識工作者/開發人員的績效？
到底如何評定程式設計師的績效？
約耳在「約耳趣談軟體」第二十八章：「測量」這篇文章中，沒有提到解決方法，其實我也沒有想到什麼好的方法，只能以自己目前執行的方法分享一下~
先寫一下約耳這篇文章中很有趣的開頭：
「謝謝你打電話來Amazon.com，有什麼事可以為您服務嗎？」然後，嘟一聲！電話被掛掉了，這實在令人氣憤。已經等了十分鐘，才轉接給真正的人聽，結果電話卻離奇的立刻斷線。
約耳說據他所知，上面這離奇的事件，其實肇因於【當時】Amazon是依據每小時接聽電話數量來考核客戶服務人員，所以提昇考績的最佳方法就是：掛掉客戶的電話，這樣才能增加每小時接聽數量。聽起來非常好笑，但是卻讓我心有戚戚焉。
以前有位直屬主管，曾經試圖考核手下程式設計師的績效，因為他認為公司網頁上要加個某某功能，不是很簡單嗎，為什麼每次都要搞很久，於是他做了一位「行政主管」最常做的要求：請每位Programer寫日報表！
天啊！結果為了日報表好看，開發人員每天上班就開始思考日報表要怎麼寫，甚至中午就已經完成當天的日報表，而程式的進度呢，更加延宕……
進度是需要監控的，工作的品質也需要驗證，但是知識工作者，特別是程式設計師，該如何評定其績效？
我採用的方式其實很簡單，陪同開發人員評估工作範圍、切工作包，然後由他們自行評估所需工時(以0.5~5日為最小~最大單位)，然後就是0/50/100法（交到測試人員手上完成度50%，交付到客戶手上才是100%）。最重要的是，程式交付到客戶手上後，被客戶發現Bug必須Fix，工時必須自行吸收。如果因此造成必須過度加班（這個比較自由心證），項目的績效剩一半，如果因為Bug fix導致後續項目時程必須重新安排，那該項目的績效就byebye了！
換言之，開發人員的績效是由他手上工作包的總績效決定，而工作包的績效則是0-50-100，如期如質如預算就100分，過度加班或是延遲交付就50分，造成後續工作包時程延宕就0分。
這個方法並不見得好，但是我實際執行幾年發現，只要確定開發人員有把測試時間加入工時中，且確認沒有浮報工時（這就是為何要和開發人員一同評估工作範圍的原因），其實大多數開發人員的週績效乃至月績效，幾乎都是滿分，大家開心啊！而且，程式品質也有一定的提昇，交付時程也比較容易掌握，一舉數得。
歡迎大家交流交流~
--------
沒什麼特別的~
不過是一些筆記而已