部门搞绩效考核，两个多月了，各种动脑，到现在才算有了些眉目，但还是不觉得有多理想，要想办法不断完善。

部门里有各种岗位，项目经理，研发经理，需求分析人员，客服人员，程序员，测试员，所有这些人放在一起搞绩效，真有些为难啊。主要困难是，很难弄出个标准来，让这些不同岗位的成员的绩效成绩有可比性。这也是让我觉得非常为难的地方。现在真是非常羡慕那些成员都做相同工作的部门，做绩效非常简单吧，如销售部门，只看销售业绩，绩效成绩有非常大的可比性。

不管多么困难，现在还是搞出了一个绩效考核体系，成果如何恐怕还需要时间验证。在设计这个绩效考核方式时，我引进了一些原则，总结总结。

原则一，体系化。

要不就不要做绩效考核，如果要做，就得有个完善绩效体系，否则，轻则绩效成绩没有任何作用，重则，可能让人觉得不公平，引起军心浮动。

要建立体系，就需要先考虑许多内容。

首先，绩效的目的是什么。然后围绕这个目的去做体系的建立。

其次，绩效成绩出来后，如何奖优，如何罚劣。

再次，要计算成绩，有什么数据支撑，如果数据不够，是不是要重构管理流程，引进管理软件以支持绩效考核。

另外，这些数据是如何获得的，如何保证数据的合理性，如何保证绩效成绩的可比性等。

原则二，公开。

所有加分、减分的原因，计算方式，最终的成果等，一切公开。让所有成员都明白，自己或别人因为做对了什么获得加分，因为做错了什么而被减分。特别是对一些非成果性的考核，如工作态度，团队精神等，公开这种加减分的原则，并且每一次加分的具体理由，尤其来得重要。希望通过这种公开的非常明确的标准以及不断增长的案例，使大家对部门的价值取向有越来越深刻的理解。如果不公开，对考核者来说，可能显得更容易些，但是对被考核者来说，可能总不容易进步，因为不知道自己究竟哪里做得不足。

当然，因为公开，就容易让有心者钻了空子，但是这是可以不断完善的，被钻空子钻多了，自然就越来越健壮。制度与软件一样，需要不断改进。

原则三，强调团队精神。

由于大大小小的项目很多，每个成员都可能分属于不同的项目，一段时间在在这个项目，另一段时间在做那个项目，甚至可能同一时间手头有多个项目在同时进行。

在绩效考核时，会对每个项目的总成绩进行评估，如果项目总成绩差了，那么会影响到参与到这个项目的所有人员。

甚至，全部门也有个绩效总成绩评估，如果部门的成绩不好，那么，所有人绩效都会受影响。

原则四，有时候需要相互制衡。

我们对研发人员，一般会以工作量的标准工时作为考核标准，但这个标准工时怎么定呢？当然不能由开发者自己说了算。这里就有个项目经理与开发者谈判的过程，对于开发者来说，任务的标准工时定得越长越好，对于项目经理来说，这个标准工时定得越少越好（消耗了多少标准工时是对项目经理考核的重要指标），这时候，项目经理与研发人员双方之间就有一个制衡关系，通过这个制衡关系，可以保证这个标准工时不会偏差太远，可能有些任务偏高，有些认为偏低，但是时间长了以后，会趋向于一个比较合理的值的。

原则五，不做强竞争性的考核。

我们部门里面，我更强调相互协作，团队精神比什么都来得重要。然而，如果没有竞争，通过宣传、鼓动，在一段时间内可能有些会有效果，但是绝不是长久之计。因此，我的原则是，有竞争，但不是强竞争。

有这么个历史故事。说是某王让匠人做弓箭与铠甲，做成后让做弓箭的匠人用自己做的箭射做铠甲的匠人做的铠甲，如果射穿，就处死做铠甲的人，如果射不穿，就处死做弓箭的人。这样子搞，质量肯定能上去的。铠甲匠人与弓箭匠人之间就是强竞争，超强竞争，这两种匠人之间的关系可想而知，完全是你死我活的敌我关系。

在设计绩效方式时，我们尽量避免这种竞争方式。

举例，程序员与测试员之间，如果测试员没发现程序员一个bug，就加1分，同时给程序员减1分，这就构成了强竞争的关系。时间久了，这两种岗位之间的人会弄成乌眼鸡的，关系一定会很糟糕，协作精神很难养成。我们强调，测试员与程序员是同一条船上的人，他们共同对软件质量负责，如果有质量问题，程序员与测试员负连带责任。