關於程式設計師的績效考核問題，相信是很多軟體公司致力追求卻一直無法做到量化的目標。很多考核標準都只是一個框架，但卻無法具體細緻下去，從而引發了很多勞資方面的糾紛，到最後都是無果而終，無法堅持下去。但還是有很多人，特別是不懂得技術之人，樂此不疲，希望以此種方法來作為程式設計師報酬的衡量標準。
最突出的就是“任務量”問題。軟體程式設計行業的任務，懂點程式設計的人都知道，這個行業是一個創造性、思維性的行業。一個任務的工作量多與少是沒有一個衡量標準的，原因就是軟體功能的實現結果，根本就沒有一個最好的標準。
有的人就以工作時數來進行衡量。真的可以嗎？舉個例子：相同的任務且相同實力的程式設計師，有的程式設計師花了一天就完成。也有的程式設計師花了兩天完成，還有的花了三天，四天，五天完成的。花一天完成的程式設計師做了功能上的實現，它是完成的，針對績效考核來說，是滿分的。但是，比他花多得多時間的程式設計師呢？他們除了花在功能實現上，還花了很多時間在程式碼最佳化以及介面操作設計上。那麼，從績效考核來講，也僅僅是滿分。花一天與花幾天的程式設計師的工作量真的可以相等嗎？誰都知道不可能的。再打個比方，兩個工作任務，有可能在任務量上它真的就一樣。但是，在任務安排上，一個專案組由於技術力量及時間限制上較為寬裕，在一個月內寬鬆地完成了，而另一個專案組由於在人力資 源以及時間限制上，加班加點，用了十天就完成。以此相比，是哪個專案組的任務量更大一點呢？
所以，績效考核的框架是死的，而程式設計師的任務是活的，用一個死的框架套住一個活的思想，程式設計師只為績效的要求而實現，久而久之，一個軟體專案根本就毫無創造性可言，就是一個生產線生產出來的一個標準化產品而已。
所以，我覺得，程式設計師的生產，就是個研發，而研發就是創造，不是生產工具，不能以簡簡單單的任務量來衡量，更不能成為技術層面之外的人簡簡單單的薪酬衡量標準。用簡單思想框架來束縛程式設計師的思維創造性，這是拖累研究，極易打擊程式設計師的研究主動性。
關於程式設計師的績效考核問題，相信是很多軟體公司致力追求卻一直無法做到量化的目標。很多考核標準都只是一個框架，但卻無法具體細緻下去，從而引發了很多勞資方面的糾紛，到最後都是無果而終，無法堅持下去。但還是有很多人，特別是不懂得技術之人，樂此不疲，希望以此種方法來作為程式設計師報酬的衡量標準。
最突出的就是“任務量”問題。軟體程式設計行業的任務，懂點程式設計的人都知道，這個行業是一個創造性、思維性的行業。一個任務的工作量多與少是沒有一個衡量標準的，原因就是軟體功能的實現結果，根本就沒有一個最好的標準。
有的人就以工作時數來進行衡量。真的可以嗎？舉個例子：相同的任務且相同實力的程式設計師，有的程式設計師花了一天就完成。也有的程式設計師花了兩天完成，還有的花了三天，四天，五天完成的。花一天完成的程式設計師做了功能上的實現，它是完成的，針對績效考核來說，是滿分的。但是，比他花多得多時間的程式設計師呢？他們除了花在功能實現上，還花了很多時間在程式碼最佳化以及介面操作設計上。那麼，從績效考核來講，也僅僅是滿分。花一天與花幾天的程式設計師的工作量真的可以相等嗎？誰都知道不可能的。再打個比方，兩個工作任務，有可能在任務量上它真的就一樣。但是，在任務安排上，一個專案組由於技術力量及時間限制上較為寬裕，在一個月內寬鬆地完成了，而另一個專案組由於在人力資 源以及時間限制上，加班加點，用了十天就完成。以此相比，是哪個專案組的任務量更大一點呢？
所以，績效考核的框架是死的，而程式設計師的任務是活的，用一個死的框架套住一個活的思想，程式設計師只為績效的要求而實現，久而久之，一個軟體專案根本就毫無創造性可言，就是一個生產線生產出來的一個標準化產品而已。
所以，我覺得，程式設計師的生產，就是個研發，而研發就是創造，不是生產工具，不能以簡簡單單的任務量來衡量，更不能成為技術層面之外的人簡簡單單的薪酬衡量標準。用簡單思想框架來束縛程式設計師的思維創造性，這是拖累研究，極易打擊程式設計師的研究主動性。