关于绩效考核

最近，公司为了能够更公正客观地评发季度奖，又开始搞绩效考核了。为什么说“又”呢？答案是：公司以前已经搞过绩效考核了，不知道几次，反正至少一次吧。我知道的那次是因为大家反映要填的表很繁琐，所以搁浅了。这次要填的表倒是简洁了——指标极大简化，只有“工作量”、“工作质量”和“工作态度”三个指标，但除了中层以上领导评价直接下属之外，还增加了不同部门间互评的内容。

本人不是HR，但也觉得这样做绩效考核还是有些问题的。

首先，以评定奖金为目标不合适。有种说法：绩效考核最好不要和工资、奖金什么的挂钩，而要以激励和改进为主。但这个可能在现实中很难做到吧，专业的HR应更有发言权。起码目前在公司的绩效考核体系还没有建立起来的情况下，就把一套不成熟的评价体系用于发奖金，还是欠妥的。恐怕结果不是流于形式，就是引发矛盾，前者的可能性更大。

其次，指标没有区分度和指导性。对于不同职能部门，都用上面那三个指标进行评价，完全是为了发奖金，根本起不到绩效考核所谓的“希望通过多方面的评估，让员工更清楚地了解自己的优劣势，进而调整自己的行为及方向”的目标（这是引用的360°绩效考核的目标，因为公司基本上是打算按照这个思路做的，但现在做得不到位，只有中层以上领导评价直接下属，以及部门之间的互评，不是全员评价）。这些指标对于指导行动甚至评价来说都太过模糊，其结果几乎可以肯定会流于形式（后来交付的评价表的填写情况也证明了这个猜测）。最好是细化考评的指标，不能仅用工作态度和工作质量来评估，要针对具体问题，有针对性地进行评估，要明确，对于项目来说，符合什么标准才是是好的开发人员、或是实施人员、行政人员等等，用这些标准做为评价的指标，否则很难起到真正的参考意义，做为奖惩的标准也欠妥。

最后，一个比较明显的问题是产品组（即开发组）和项目组的互评。在我们这样以项目实施为主导的公司，管理制度和工作流程不够健全，很多时候都是开发人员直接到现场去支持（说白了就是修改程序），所以这里的评价结果就不是一个简单的事情了。具体来说，如果项目经理对产品组的评价很好，可能是这个产品组的确各个方面都做得很好，但也可能是这个产品组态度“好”，项目上无论什么问题随叫随到，尽心尽力解决问题，对于实施人员来说最喜欢这样的开发人员，省了自己无数的力气，大事小情都直接叫开发人员，名曰“为项目着想”。但这样的确是解决了项目眼前的问题，但实施人员应负的责任没有做到，所有问题都落到开发人员身上，最终项目的实施质量和实施成本都会受到影响；对于项目来说，最快的解决问题的方式就是开发人员到现场直接修改程序，如果程序版本都统一在公司，走完整的需求分析、开发和测试流程就会比较慢，但后者显然对项目和公司的长远利益是更有利的。反过来说，如果一个项目很少找开发人员解决问题，实施人员能力强，很多都能自行解决，这样的项目是开发人员最喜欢的。如果实施人员做得再好些，还能让开发人员了解到这些情况，可能会给开发人员留下更好的印象。但实施人员解决问题，必然要改动程序，这样，程序的版本还是很难统一和管理，代码质量也难保证，损失了项目和公司的长远利益。

在和领导沟通以上问题后，领导的意见是：还是要把考核与奖金挂钩，但需要细化考核指标。于是就开始订具体的考核指标，召集了部分中层领导讨论，现在考核的具体方案还在制订中。

现在，绩效考核还没有真正开始，但从目前的这些事情中，还是有些体会：

目前来说，最好还是把绩效考核和奖惩暂时分开，待考核制度逐步完善之后再和奖惩联系起来。在大家都基本认可了绩效考核的方案、过程和结果后，就可以和奖惩联系起来了，也会对考核起到一个最终的推动作用。

很多公司的决策都有急功近利、只顾眼前的倾向，比如绩效考核，是个系统工程，需要制订科学合理的方案，前期对员工进行充分非培训、取得大家的共识，考核后对于评估持续跟踪、指导员工不断改进。可能很多管理上的东西都会随着绩效考核的推进而需要改变，这是难度最大的地方。无论如何，肯定不是订一些指标、评一下奖金就能了事的。虽然这些不会影响到公司的短期效益，但要想基业长青，不踏踏实实地做些工作，早晚是要被历史前进的浪潮所抛弃的。在我们这个行业，公司起起落落已经司空见惯，若干年前曾经辉煌过的公司，现在很多都在走下坡路，甚至不复存在。如果这些真的成为了习惯，老板痛苦、员工更痛苦。一个看不到希望的行业，既不能吸引人才、也不能留住人才，自身水平很难提高，就更看不到希望，这样恶性循环，是不是也拉动了GDP呢？