世界上所有的IT公司都在研究绩效考核标准，希望把绩效考核做到流程化管理，但是从实际结果来看，绝大多数公司仍旧是以主观考核为主。
国内某集团组织人事部内研发出一整套绩效考核标准，高层领导听完汇报之后欣喜若狂，觉得以后可以客观的考核员工了。
但是，具体实施的时候阻力重重，最后还是使用类似360度评价的方法。
制定绩效考核标准需要细致分析公司以及工作内容的特点，制定适合自己的、灵活的绩效考核方法，也可以搭配使用几种绩效考核方法，以达到考核的目的。
处于工作需要，最近我冥思苦想了很久，仍然没有好的思路,所以决定先把自己想到的内容先写下来,慢慢梳理思路，梳理的过程中或许能有收获。
考核的目的是什么?
考核的目的是把目标导向和检查落实环节连接起来，促进企业和个人共同发展。(考核机制不是企业手中的鞭子，应当是业务和员工的灯塔)
考核管理分为两部分，
1.制定考核标准
制定企业级目标 ⇒ 分解目标到各团队 ⇒ 进一步分解目标到项目 ⇒ 具体任务落实到个人。
整个过程让目标清晰明确,让所有干系人对目标达成统--的认识。能让大家在一条船上，冲着--个方向划桨。
2.验收工作结果
根据目标的达成状况，论功行赏,惩罚分明。
有些企业把绩效管理的流程做成了“编表、填表、收表”的形式化工作。最可怕的是，人人都知道这是形式化的东西，分配年终奖的时候，
还要拿这些表格说事，因为管理职没有其他的考核标准，也不想被人说拍脑内决定,因此只能拿这些表格说事，造成员工极其不满。
注意:考核标准如果不能被大多数成员接受的话，就不要使用，否则会适得其反。
谨慎使用KPI的方式量化程序员的工作成果
KPI适用于标准流程管理，在已有相对最优实践时，提升管理效率的最佳方式是KPI。
程序员的工作属于知识密集型工作，需要程序员积极主动思考，寻找最优解决方法，是典型的不适用KPI管理的工作种类。#外包开发项目除外。
一些企业使用KPI管理，把代码行数评审指摘数、BUG检出率等作为量化的元素。我觉得这是不专注于结果，这只专注于衡量标准的做法。
尤其使用代码行数作为考核标准有很多弊端，同样一个功能，程序员A用100行代码实现，程序员B用50行代码实现。
根本没法判断哪位优秀，可能是A的代码冗余，比如做了过多的check，这样会带来性能问题、维护困难等问题。
也有可能是B的代码过于简单，代码的强壮性不好，此如该拋异常的地方没有抛。
这个例子的背景是两位程序员在同一项目内，做的是相同种类的工作。如果一位负责 前端，另一位负责后端的话，该如何拿代码行数考核呢。
如果跨项目的话，一个使用高度封装的框架,很多功能拖拖拽拽就能事项，另一个使用自建框架，代码量要多一些，就更没法在一个平台上考核了。
另外，随着Devops和敏捷的出现，很少有人只写代码了，设计、编码、测试、发布、运维，
调查问题等工作可能由多人负责，也可能由一人负责,这些工作之间如何考核呢。
如果拿代码行数作为考核标准，那么程序员会使用各种方法，智慧的增加自己的代码量，时间久了系统将会臃肿不堪。
注意：不合理的考核标准能将团队带向深渊。
代码行数以外，评审指摘数、BUG检出率等方式，因为存在干得多错误多的问题，所以需要考虑单位比的指摘数和Bug检出类，
这并不是一件简单的事情，
尤其和绩效考核挂钩，员工会提出各类弊端，等我们找到完美的解决方案的时候，发现要消耗大量的工时，做这些考核准备工作。
另外，当 代的软件开发工作存在多变性。
瀑布式开发还好一些，每一个工程都能够把需求定死，每-一个变化都能获得工时。
但是，现实并不会这么美好，大多数时候开发团队要为客户的任性，或者产品经理的愚蠢买单。
(有人会说那是你们变更管理做的不好，理论谁都懂,实际操作的时候会遇到各种问题，搞的太清楚就会变成不懂的协作)
那么如何进行绩效考核?
基本观点:
使用0KR管理部门、团队、项目的目标和绩效，以此来考核部长、团队负责人、项目经理的工作成果。
项目经理负责每位成员的考核，使用绩效考核表，进行360度考核。根据团队的工作内容，可在小团队内部使用KPI进行量化考核。
在《Accelerate: The Science of Lean Software and Dev0ps: Building and Scaling High Performing Technology Organizations》
一书中概述了两个简单的衡量指南，这两个指南和我的团队管理经验不谋而合。
1.专注于结果，而不是产出的衡量指标。
开发部、团队使用OKR方式管理，开发部根据公司的目标设定部内目标，比如公司的目标是增加10%业务量,
1、那么部内的目标可能就是分担其中的5%的增量。(另外5%的增量由其他部巾分担)
2、团队的目标是结合自己团队的特点，和部内领导一起研究分担多少指标，比如Group1分担2%的业务增量。
之后团队领导， 制定工作计划,如何做才能实现目标，需要组织级别给与什么样的援助等等。
3、基于团队领导做工作计划， 项目经理设定工作内容 以及工作目标。
团队领导希望各项目生产环境的故障为0，以此作为营业突破点向客户争取更多的项目，那么生产环境0故障就是各个项目经理的工作目标。
建议使用:OKR管理目标
#OKR的管理方法请参照上一篇文章《OKR 目标和关键成果》https://www.cnblogs.com/HappyBeibei/p/16995274.html。
2. 针对全局或整个团队成果而进行优化的衡量指标，而不是局部或个人成果。
基本观点：
使用0KR管理目标，考核团队和项目。由项目负责人考核成员(设计、开发测试、运维等)。
项目经理和团队负责人一层层考核成员，可以使用考核表，不建议使用KPI式的硬性指标。
因为项目经理拿到了项目压力,就会想办法组织成员去实现目标，把工作分配给成员，指示成员具体行动或者引导成员思考。
这样就不需要统一的指标来考核成员，因为管理团队的时候有很多多变因素，导致指标不适用。更不需要哪指标抢走项目经理的考核权利。
另外，有一个风险是项目经理有徇私舞弊的可能性，按照自己的喜好评价成员。作为解决方法可以对成员进行360度考核,有成员的自我评价,
同级别评价，项目经理评价，团队领导评价、部内领导可以最后做公平性审查，比如，上述各维度的评价结果差异巨大，这时候就需要部内领导介入检查合理性等等。
建议:使用绩效考核表，进行360度考核。
绩效考核表中列出各种考核事项，针对各事项进行打分。
比如说是否按计划开展工作，项目变更是否申报批准，是否及时提交项目文档，代码是否按规范编写，是否提交项目后评估报告等等。
项目经理也可以根据团队自身情况，可以选择针对相同工作种类的成员使用KPI管理，这种考核的主要目的是在团队内部同级别之间进行横向比较。
比如，团队内部有20位编码程序员，10位程序设计，可以设定KPI标准用于内部考核。
总之，最好把对成员的考核权利交给PM，因为他最了解成员，管理项目和团队的时候，也需要这个权利。
另外，回收客户满意度也是一种很好的考核团队的方式，可以制作顾客满意度回收表，
满意度回收表中包含技术能力、工作积极性、提案能力等等各种顾客关心的事项,每个事项分成等级，让顾客给打分，再给留出顾客写主观评语的地方。
比如，提案能力
3分：提案能力优秀，能够针对客户需求，提出合理的可行的最佳实现方案,提案书清晰易懂，并能够帮助客户考虑各种情况。
2分：提案能力良好,和客户进行多次沟通之后，能够提出可行的实现方案。
1分：提案能力有待提高。提案书需要反复修改的问题，经常发生。
最后，绩效评估的方法非常多，包括KPI、OKR(目标管理)、360度考核绩效快照述职法排序法等等。
可能是因为KPI是量化考核的首席代言人，因此很多企业管理者总是盯着KPI，希望把所有指标都定义好，能做到最大程度的量化员工。
思路没有问题，但是不能强求，需要根据工作种类,根据企业特点使用适当的方法。例如，选择OKR和KPI相结合。
360度考核，述职法等虽然有很强的主观成分，但是手机足够多的主观就具有很高的参考价值，
比如360度考核，客户、直属领导、再直属领导、同级别、下属都能给与相同或者接近的评价的话，我们可以认为评价是全面而客观的。