绩效评估和激励的方法

　　激励要从精神和物质两个方面，对程序员来说可能精神激励更为重要，应该在保持适度压力的情况下，让开发团队始终开心的工作，为他们提供充足的培训、良好的工具和开发环境，使他们在开发过程中技能不断提高，这样才能不断生产出高质量的软件。

　　单纯用Bug数来衡量程序员的工作，甚至与金钱挂钩，通常是不好的做法，过于草率、粗暴，我所了解的国内企业很少这样做。通常这很难操作，增加管理开销，很可能会引起程序员的反感，甚至起到反作用。

　　组织最终也很难得到好的回报。因为软件的质量包括很多方面，不仅仅是Bug数的多少。大量的Bug只是一种更深层原因的表象。同时，推出产品的内容和速度也很重要。不能片面强调质量。

　　程序员出现了很多Bug，应该分析一下原因，是程序员个人的原因（无意还是有意，通常他们是无辜的），还是组织管理的原因（比如培训不足，过程缺陷，管理失误，协作不利，......）。所以，程序员写了很多Bug，首先应该改进组织，帮助他提高技能，减少Bug，相信他能做好，而不是对他进行惩罚，这一般不会收到好的效果。

　　当然，我们又要防止吃大锅饭。建议用集体目标，比如阶段性成果（每日建立、次发布、主发布、里程碑是否通过）而不是Bug的多少作为考核程序员的主要依据，这两者是有区别的。Bug数可以作为一种评比指标，在完成集体目标的情况下，对模块质量高的给予奖励，对质量差的一般不要进行惩罚，而应该提供帮助。把程序员负责模块的Bug公布于众，这种社会和精神压力已足以令他警醒了。如果他无动于衷，就会被淘汰。

　　另外像微软的做法，如果某个人使得每日建立不能通过，破坏了整个进程，可能会被戴上一顶引人注目的帽子（《微软的秘密》），也有可能被罚款。所以，采用那种措施，应该根据企业的具体情况而定。

　　评估程序员的绩效，除了他负责的模块质量外，还应包括他对集体、他人的贡献和协作能力等指标，以防止每人“只扫各自的门前雪”。我翻译的《软件架构——组织原则与模式》对一个开发团队的协作模式进行了有趣的探讨。

　　原则是，失败了可以对某个人（最好连带整个团队）进行惩罚，但同时成功了也要及时奖励。关键是建立一个所有团队成员都一致认同的，公平、公正、积极向上、符合企业实际的激励文化。