在本人为期时间并不长的管理时间里，困扰的问题有很多，然而最困扰的问题就是人员的绩效考核。在一个企业的发展过程中，不可能绕开绩效考核这样一个课题。
关于这个课题业界有各种各样的管理书籍汗牛充栋，网上也是各种课程，博文铺天盖地的，因此说明这个问题是一个普遍的问题，大家都会碰到这个问题，也都思考怎样去解决这个问题。从另一个方面来讲，这也是一个非常个性化的问题，没有普适性方法去覆盖每一个场景。
本人试着在工作过程中总结相关的现象，写下自己关于现象问题的思考过程，再在之后的工作过程中去实践。
一. 为什么要考核
任何一个课题，首先要考虑的就是为什么要做这个事情。对于绩效考核而言，我认为是当企业或者组织发展到了一定的规模之后，为了引导团队，将不同价值观的人统一起来，并将组织发展需要的人才挑选出来，最终达到组织和个人的成功。
绩效考核不是为了考核而考核。而是为了实现企业或者组织的战略目标，通过绩效考核来挑选出适合的人员和团队。
一个团队必须建立相应的淘汰机制，人人都有危机感，都有随时被淘汰的可能，才能实现优胜劣汰，保持团队活力的同时，尽可能的保持最大的竞争力。就像是鱼群里的鲶鱼，随时威胁大家的生存，才能保证让大家都动起来。在具备有效的员工淘汰机制之前，有哪些问题是我们需要探讨的呢？比如“如何把真正的‘末位’员工剔除出来？“，“到底是从员工的工作质量、工作态度、个人品德、交际能力还是其他方面进行衡量？”或者“谁来评价，才能做到公正合理？”可以说，在企业内部建立淘汰机制是必要的，关键是如何做到“有效”，把不符合企业要求的员工进行淘汰，这才是我们应该真正关心的，也是绩效考核想要达到的目标。
二. KPI考核方式
引用百度百科上的定义：关键绩效指标(KPI：Key Performance Indicator)是企业中非常常用的一种考核方式。是通过对组织内部流程的输入端、输出端的关键参数进行设置、取样、计算、分析，衡量流程绩效的一种目标式量化管理指标，是把企业的战略目标分解为可操作的工作目标的工具，是企业绩效管理的基础。
这里提到一个关键的点就是要将指标量化，只有量化之后才能进行考核。另外一个关键点就是分解，那么意味着KPI的通常是一个自顶向下的过程：
逐步向下分解
KPI方式的优点很明显：分解方式易操作，方便将公司的发展方向和战略逐层分解到个人，保证大部分人可以往相同的方向努力。KPI方式对业务/市场团队相对而言较为好分解和评估，对研发团队就比较难落地实践一点，下面针对本人所在的初创企业来讲一讲。
拿一个IT部门一般的组织结构来讲(上图)
1. 首先来讲开发团队，开发团队往往是研发团队中占比最大的。因此开发团队绩效分解和评估至关重要。
开发制定KPI时碰到的第一个问题就是：开发的工作内容和工作量往往是不确定的，我碰到过很多次和开发的同事沟通KPI，永远都只有两项工作：做版本需求 + 修改BUG，很明显，这样的分解是无效的，评定的时候也无法量化。需求也许可以计划，但是BUG是无法预测的。
我们考虑制定的时候统一写做版本需求 + 修改BUG，但是只要到了评定的时候可以直接评定，还是可以区分出优良中差来。这里存在的问题就是通过一个什么样的标准去评定，最直接的想法就是根据开发的输出来做评定，开发的输出就是代码，最容易看到的就是代码行数。但是代码行数这个很明显不靠谱：
有无数种办法可以增加代码行数而不提高代码质量，甚至可能可以为了增加行数而增加大量冗余代码，造成大量的维护工作量。而我们需要的是代码质量而不是代码数量。
不同语言之间的代码行数之间是完全没有可比性的。
无法准确的评估代码质量，靠人一行一行的去评审是不现实的
那么，还有一个思路就是通过测试提出的BUG量来衡量开发的工作输出。这里同样存在一些问题：
bug是针对业务的，那么有可能维护公共代码的人就很明显会吃亏，很多问题的归属都会落到这段公共代码上来。
bug不一定是由代码造成的，可能是因为需求考虑不全，场景未分析到等等原因造成的，问题由开发来解决，锅也由开发来背不合适。考虑过这种情况可以把锅甩到产品处，实际上，如果通过这样组与组之间互相考核的话，容易造成组与组之间的隔阂和组员之间的对立，而我们的目标是想让团队凝聚在一起，而不是形成一些大公司之间的部门墙。
也考虑过，只记录由代码错误产生的bug，或者重复出现的bug来进行负向事件减分。但是这样需要组织大量的人力和时间去进行论证，不是一个快速向前团队愿意看到的。
还有重要的一点就是，开发团队不仅仅是一个码代码的码农团体，开发团队应该是一个具有探索型思维的团队，在各个方面都需要有不停的演进，从代码架构、开发效率、语言选择都需要不断的探索新的可能性，那么就必须有容错的机制在里面。如果单纯的去通过bug和版本通过率去评估绩效，就会扼杀这种可能性。
2. 接下来看看和开发休戚相关的测试团队。和开发团队一样，同样在制定绩效的时候，也容易陷入到模板化的无法量化的指标中：测试版本 + bug跟踪。也是无法去计划和预估考核周期内有多少个bug的存在。和开发类似的，我们也来看看在评估绩效时，会碰到哪些问题
bug量无太大指导意义，一个简单的界面元素样式不合适/阻碍业务流程 这样的两个BUG重量级是无法匹配的，因此一般会考虑将bug分成多个等级来进行评估。然后综合bug的质量和数量对测试进行评估，这里的一个问题同样是这里会存在一个类似仲裁官的角色，来确定bug的等级，然后这个角色就成为了团队的不稳定因素。
和开发一样，对一个初创团队而言，测试也是需要进行一些探索性的工作，比如更好的性能测试，容灾，自动化等等方面的探索，也是需要考虑在内的。
3. 还有一个关键角色，就是产品经理，这个角色的绩效评估难度也是比较大。产品经理的输出一般来说就是需求质量，一般可以通过改动/返工的次数来评估，但是一般来说，很多需求是客户本身也没想明白的，有一句话是只有你做出来了，客户才知道自己想要什么。所以这样的一个改动和变更也是较为正常的。很难区分是客户没想明白，还是由于产品经理的疏漏造成的。
4. 其他的角色，比如运维，DBA之类的同样，一个周期内环境出问题多是优秀，还是不出问题是优秀，不出问题是运维厉害，还是开发的代码写的好呢？让人很是纠结。
总的看来，KPI是自顶向下分解，由于研发的不确定性和问题的多样性，分解后需要上级或者一个第三方(QA)之类的角色像监工一样来不停的跟踪记录绩效的执行情况，否则无法准确的完成评估。如果无法完成准确的评估，就无法公平公正的进行考核，就会导致各种问题。
上面多次提到，研发团队应该一个具有探索型精神的团队，如何在做好绩效评估的同时，让团队有充分的空间去进行试错，是一个需要好好考虑的问题。
KPI考核在制定时一般都是计划中的工作，大部分为日常工程化工作，考核评定时难以区分出差距，而能拉开差距的是在于在工作过程中对于出现的问题的思考和解决方案的探索，这部分无法在制定考核时就确定的，而且计划是跟不上变化的，问题是时时刻刻出现的，真正能体现出人才的闪光点是在每个解决问题的过程当中，这些问题就想试着用更合适的方法去解决。
三. OKR的方式
在认识到现行的KPI方式有这样一些问题之后，就通过了各个渠道去了解解决方案，OKR就是在最近提的比较多，也比较火的一中方法。
引用百度百科上的定义：OKR（Objectives and Key Results）即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法，由英特尔公司创始人安迪·葛洛夫（AndyGrove）发明。并由约翰·道尔（JohnDoerr）引入到谷歌使用，1999年OKR在谷歌发扬光大，在Facebook、Linked in等企业广泛使用。OKR（Objectives and Key Results）即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法，由英特尔公司创始人安迪·葛洛夫（AndyGrove）发明。并由约翰·道尔（JohnDoerr）引入到谷歌使用，1999年OKR在谷歌发扬光大，在Facebook、Linked in等企业广泛使用。
下面聊一聊我自己对这个OKR的理解：
OKR包含两个部分，O为objective，即目标。KR为key results。直译过来是关键结果，我理解应该是为了达到这个目标要实现的几个关键点，可以理解成子目标。或者可以为关键事件吧。
和KPI的一个区别在于都是基于自顶向下的进行目标的统一，但是OKR更注重分解目标执行人的主观能动性。上层组织只是提出目标，而不限定指标和方法，将指标和方法的主动权放在执行人的一方。
下面再讲讲接下来想践行OKR的一些想法
首先对自己的团队做一个评估，是否有实施OKR的条件。本人的团队是toB的业务，有一定的交付压力和相对固定的交付周期，对于这一部分。可能还是KPI的考核方法更加合适，如果一股脑切换到OKR上来，很有可能水土不服，况且对这个新鲜事物没有过尝试。
但是作为创业团队，必须进行试错，开发需要引入新的架构，新的技术，测试需要引入新的测试理论和方法，都是为了进一步的提高研发效率。因此需要在一部分人员上先试行。
OKR的一个关键点在于如何确定和评估一个有挑战性的目标，这个目标一定是对制定者而言有挑战性的，是需要执行者去跳一跳才能够得到的一个标准，这就对制定者和评估者有一定的难度。如果制定的目标没有挑战性，那么就失去了OKR的意义了。因此团队的自驱力是实行OKR的一个至关重要的前提。而对于管理者而言，判断某个人是否有足够的自驱力，对技术目标难度有足够清醒的判断，也是OKR顺利实施的一个重要条件。
很多文章提到OKR不适合用于绩效考核，也就是不要和奖金，升职，工资这样的利益挂钩。我自己的理解是可以将部分自驱力较强的人的绩效考核分成两部分，一个是工程化部分，也就是平时的业务研发部分，这部分还是采用KPI的方式进行评估。另外一个部分是探索型工作部分，这部分是为了团队和个人的成长进行的工作，采用OKR目标管理。作为一个加分项。
OKR是否适合团队，需要逐步的进行验证和试验，无法一刀切的进行转换
不管是KPI，还是OKR，没有更好的方式，只有更合适的方式，两种方式都需要管理这对过程有足够的了解才能做好准确的评估。
四. 最后
不管是KPI还是OKR，都是一种管理的工具，都适用于各自的场景。而企业和组织中会存在各种场景，管理者需要根据自身情况，确认好团队目标，充分了解人员特点和业务过程之后，再考虑是使用那种工具去进行管理。最终的核心还是在于观察日常工作过程，引导人员和团队成长，才是绩效考核和绩效管理最终的目标。