公司领导有问我，有没有什么能够激励程序员的方案，于是我参考了一些文档，也加上了自己的一些想法，写了这篇文章，如果有不对的地方，希望大家指正

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 团队奖励

做出一些对团队有意义的事情，应给予一定的奖励
如共享组件库，提升了团队开发效率
发现了新的工具，为团队节省了开发成本等
评定标准：由项目经理确认，是否做出对团队有意义的事情，给予奖励