公司領導有問我，有沒有什么能夠激勵程序員的方案，于是我參考了一些文檔，也加上了自己的一些想法，寫了這篇文章，如果有不對的地方，希望大家指正

1.程序員的標準不統一

程序員的績效考核問題，是很多軟件公司致力追求卻一直無法做到量化的目標。很多考核標準都只是一個框架，但卻無法具體細致下去，不僅沒有達到激勵效果，反而起反作用，到最后都是無果而終，無法堅持下去。但還是有很多人，特別是不懂得技術的管理者，樂此不疲，希望以此種方法來作為程序員報酬的衡量標準。軟件編程行業的任務，懂點編程的人都知道，這個行業是一個創造性、思維性的行業。一個任務的工作量多與少是沒有一個衡量標準的，原因就是軟件功能的實現結果，根本就沒有一個最好的標準。更不能成為技術層面之外的人簡簡單單的薪酬衡量標準。用簡單思想框架來束縛程序員的思維創造性，這是拖累研究，極易打擊程序員的研究主動性。

也有人用工作時長來進行衡量，也就是所謂的加班，程序員一定有辦法蒙你，不可取。
還有人會用定級的方式，按級別給績效，想過沒有，升上去容易，降下來就難了。
還有人按工齡，按Bug數量設計的，說實話都不可取。
單純強調考核會打壓其本身的工作積極性，不符合客觀規律。

真沒辦法為程序員計算勞動所得嗎？對研發人員的考核，建議不要過于強調結果，應該注重對過程的關注。程序員這種腦力勞動，類似于研發考核，由于其工作性質本身要求創造性，結果比較難于掌握。個人覺得，對程序員的考核只要能確定他們是認真工作、努力工作、態度端正，一切圍繞目標開展就可以了。針對項目的技術貢獻以及任務完成的質量貢獻，項目獎比起冷冰冰的績效考核溫暖得多

2.我覺得應該通過多個角度觀察員工

2.1工作態度

• 是否服從上級領導交代的工作任務，積極履行工作職責。
• 是否文明用語，耐心回答工作問題。
• 是否愛護公司財產，不輕易損壞硬件設備。
• 是否充分理解業務需求，并且主動完善或提出業務建議。
• 是否與團隊保持良好合作，幫助同事解決現有問題。

2.2工作效率

• 是否按時完成工作任務。
• 注意每個職位的分工是否合理，每個職位完成了多長時間和多少工作。
• 注意每個職位的工作職責，避免互相推卸責任。
• 完成工作任務時，中間是否有穿插別的任務，穿插任務分配是否合理。

2.3工作質量

• 是否符合軟件設計規范。
• 是否如實將需求實現轉化。
• 是否編寫開發文檔。
• 是否編寫單元測試。
• 是否低代碼出錯率
• 是否有影響軟件運行或者不符合設計文檔的問題。
• 代碼出錯率要確定是否是產品邏輯還是代碼邏輯。
• 是否應用性能是否達標。

2.4個人創新能力

• 是否克服某些業務上的技術難題，提供有效的解決方案。
• 是否能發現現存業務上的技術缺陷。
• 是否愿意為團隊提供公共組件庫。
• 是否能節約開發成本。

3.標目激勵方案

由于軟件開發分為好幾種階段，實現階段，測試階段， 完善階段

3.1 開發階段（指新程序，或者定制版本,增加功能等

在產品部提交完成的需求后，與開發人員溝通，開發人員評估后進行時間的預估，并由上級領導確定時間是否合理，若開發人員在規定的時間內完成開發，并無重大影響程序運行的bug，應給予開發獎勵，項目獎金
評定標準：在規定的時間內完成設計文檔上的所有功能，并達到提測標準。若不能完成則與產品溝通，修改設計文檔說明，由產品部確認功能是否都實現，測試部遵照產品提供設計文檔測試，經過三輪測試后，無重大影響功能bug（程序無法正常使用）給予開發獎勵（項目獎金）

3.2 測試階段

在修改完測試提出的bug后，由產品部確認測試人員提出的修改方案是否合理，由開發人員評估后進行修改，在沒有時間限制的前提下，修改bug沒有導致重大的問題的產生
評定標準：由測試部確定需要修改的所有bug是否修改成功，并無改出其他重大bug（影響程序正常運行）

3.3 優化階段

在產品維護階段，對程序進行優化，如界面的啟動速度，提升30%，找到并解決內存泄露的點
評定標準：由項目經理確認，是否有對程序重大提升，或者解決某個技術難題，基于獎勵

3.4 團隊獎勵

做出一些對團隊有意義的事情，應給予一定的獎勵
如共享組件庫，提升了團隊開發效率
發現了新的工具，為團隊節省了開發成本等
評定標準：由項目經理確認，是否做出對團隊有意義的事情，給予獎勵