技术领导力实战笔记_28_第22讲_|_验证研发团队价值的绩效考核机制
业务同事的绩效很容易考核，签了多少单，赚了多少钱，清晰可见，容易衡量。
对于做产品研发工作的我们来说，成本很好，计算，但价值却很难衡量。
业务团队能为公司赚钱，研发团队却花公司的钱，研发团队从此就变成了公司的成本中心。
我们需要有一套合理的绩效考核机制，衡量并验证自己的价值。
这套机制需要简单易懂，操作方便，而且需要通过数据说话。
有数据呢还要有对比，需要与自己比较，还要与别人比较。
本文将结合之前第十四讲，从零开始，搭建轻量级研发团队中提到的内容，从绩效考核方面继续探讨下去。
首先，我们针对研发团队考核模型进行深入探讨。
我们的研发团队分为横向职能团队与纵向项目团队。
所有的研发人员都在职能团队中，他们都在所在的项目团队中体现出自己的工作绩效。
因此，绩效考核是基于项目团队进行的，而不是职能团队。
针对不同类型的项目团队而言，需要制定不同的团队目标，采用不同的考核方式，具体可参考图，一，每种项目团队都有共同的考核部分，那就是个人OK.二、它包括两方面，一是个人成长，二是团队贡献个人成长，又包括专业技能和综合技能。
两方面前者是硬技能，后者是软技能。
个人是否得到成长，取决于和自己的曾经做比较，而并非与他人做比较。
团队贡献包括的方面较广，比如技能培训经验分享、偿还技术债，制定并落地规范组织团队活动等。
在本文下一届中将对OKR进行深入探讨。
需要注意的是，个人OK二需要个人结合团队目标来定义，由个人所在职能团队来评审。
个人OK二，也就是说OK二是自底向上的，而KPI却是自顶向下的。
此外呢，我们认为OK二和KPI既不冲突，还能相辅相成，将OK二与KPI有效结合，不仅可以激励团队成长，还能促进团队完成公司的核心目标。
对于功能团队而言，他们的目标是确保以最快的速度高质量的让项目上线。
然而，速度和质量往往是相互制约的，速度太快，质量一般，产会功能。
也正因如此，我们才需要对功能团队的速度加以限制。
否则，项目上线后，一个难以维护的速果即将诞生。
可以想象，随后效率团队一定会踩坑无数。
因此，我们需要对功能团队定义一些技术KPI,才能确保项目的顺利交接。
比如上线时间、代码、质量、产品质量等。
对于效率团队而言，他们的目标是优化现有产品功能，并帮助业务实现目标。
可见，业务的成功取决于效率团队的成功。
我们无需像要求功能团队那样去要求效率团队。
因为他们关心的不再是速度和质量，而是如何不断提升业务效率，帮助业务团队实现业务目标。
因此呢，我们可以将业务KPI作为考核效率团队的参考标准。
对于创新团队而言，他们的目标是帮助公司创造新的商业机会与盈利方式，往往需要通过收入的方式来考核该团队。
我们需要同时设置业务KPI与技术KPI来验证该团队的价值及投入与产出。
当然，不论哪种项目团队都需要考核项目是否延期，上线后是否有bug,而且这些标准都应该是事先确定清楚并和团队达成共识的。
我们相信，先有共识，才有共赢，只有大家一致认同的原则，才可能有效的去执行。
以功能团队和效率团队为例，以绩效考核的具体操作层面上，我们可采用打分制，根据具体情况进行加分或减分，具体呢可参考图二。
需要注意的是，效率团队将对功能团队的交付成果进行考核，不仅是代码，还包括文档，确保功能团队的一点零项目。
这根接力棒可以顺利传递下去。
未来在效率团队的手中，让它变成一点一、一点二、一点三等。
若要开发产品功能二点零可认为这是新的尝试，同样需要功能团队来开发二点零功能上线后再次交给效率团队进行功能迭代，每个季度呢可以进行一次绩效考核，具体的考核成绩将分为SABC四个级别s表示大家心中充满美好期待的那根线。
A表示努力跳起来就能够得着的那根线。
B表示及格线。
C表示不及格，绩效考核的成绩需要公示。
考核结束后，根据具体成绩进行奖金发放，同时个人OK二也在每个季度结束时进行考核，但考核结果不会体现在季度奖金中，而是体现到每年的加薪幅度上。
因为个人OK二是个人的能力提升与团队贡献程度的表现与薪资挂钩会更加合理。
关于OK二方面，虽然他无法直接反映在绩效上，但他对团队的成长是至关重要的，团队成长了，绩效才能提高。
下面我们专门讨论一下OK二的十大要领。
Ok二最早来自于intel公司，最后在google公司得到了更好的应用。
现在呢全球杰出的互联网公司几乎都在用OK二要在企业中更好的应用。
Ok二完全取决于我们自己对它的认识。
Ok二包括两大要素o和k二o是objectives的缩写。
K二是key results的缩写o用于描述我们心中希望通往的美好目标。
K二用于描述衡量实现这个目标的关键结果。
为了让大家更好的理解OK二的精髓，我们提出以下OK二十大要领，一OK二不是一款绩效考核工具，而是一款目标管理工具。
二OK二，包括自顶向下与自底向上的全过程。
三o需要做到简洁且定性，要鼓舞人心。
四k二需要做到明确，且定量用数据说话。
五、一个季度制定一次。
Ok二季度结束，需对OK二进行评审。
六、每周做一次OKR回顾，每月做一次OKR调整。
七OKR制定过程需进行多次评审，以确保它与上级目标不冲突。
八o一般不要超过五个o所包含的k二一般为二到四个九OK二，需要做到透明化，向团队完全公开。
十OK二评审结果可作为加薪的重要参考依据，但不是唯一依据。
对于OKR而言，很多人容易将它理解为绩效考核工具，认为它和KPI是同类，这是一种误解。
如果将OK二理解为考核工具，我们一定无法用好它，也更无法从中受益。
Ok二是一款目标管理工具，它管理的是我们所制定的目标，让我们的目标更加清晰且容易实现。
Kpi是自顶向下的老板，定义了KPI,各级领导去背KPI员工去完成KPI,大家各扫门前雪，达成自己的KPI即可。
然而，OK二却是自顶向下和自底向上的全过程老板结合企业战略去定义企业。
Ok二领导结合企业OK二去制定团队。
Ok二员工结合团队OK二去制定个人。
Ok二，这是OK二制定过程，通过一段时间的努力，随后进入OK二评审过程员工评审个人OK二领导评审团队OK二老板评审企业。
Ok二可见，OK二既包括了资顶向下的制定，也包括了自底向上的评审。
我们务必做到能用一句话来描述o这句话要让团队任何人都能完全理解，即简洁且定性，还要做到鼓舞人心。
例如，如果目前我们的团队文化做的不太好，我们希望未来一个季度可以得到改善。
O如果写成改善团队文化，这句话虽然做到了简洁且定性，但不够鼓舞人心。
我们可以将其改为打造更好的团队文化，让大家爱上这个团队，是否瞬间就产生了正能量呢？每个o都有对应的k二，他们用来说明为了实现这个o应该做到的关键结果是什么？ K二需要做到让团队任何人都能完全衡量及明确且定量，还有做到用数据说话。
例如，如果目前我们的系统架构中微服务的颗粒度较大，数码的可重用性方面比较低。
为了解决这个问题，我们希望对微服务边界进行切分。
如果将其中一个k二写成切分颗粒度较大的微服务，这样是不合乎要求的。
我们可将其表述为至少切分三个颗粒度较大的微服务，增加了一个数字来描述这样的k二就更加容易衡量了，数字是最容易衡量的。
此外，有和没有也比较容易衡量。
通过实践，我们发现一个季度制定一次OKR是非常合理的，季度结束需对我们所制定的OK二进行评审。
Ok二并非制定后就无法调整了，我们自己每周可做一次OKR回顾自行将有问题的地方记录下来。
职能团队每月在一起可做一次OKR调整，以及时修正我们的OK.二、对于个人OKR而言，并非完全由自己制定后就开始执行个人OK.二、制定过程需要进行多次评审，以确保他与团队OK二不冲突o和k二的数量也有限制。
O一般不要超过五个o所包含的k二一般为二到四个。
需要说明的是，OK二要做到透明化，可用电子表格或纸质卡片来管理。
这些表格呢需要向团队完全公开。
此外，每个季度末的OK二考核结果可作为加线的重要参考依据，但不是唯一依据。
我们作为团队领导者，也需制定自己的OKR.我们来看一位研发团队领导者的OKR事例，具体请参见图三所示。
最后总结一下，一个团队需要有目标，也需要对目标完成情况加以考核。
目标与考核往往是相辅相成、缺一不可的。
如果只有目标而没有考核，将无法检验团队的价值。
如果没有目标，而只有考核团队将离我们越来越远。
Ok二不是绩效考核工具，而是目标管理利器，所有人都能理解。
Ok二的定义，但是不是每个人都能很好的应用它。
这也正是OK二的魅力之处。
往往好的工具呢都是理解容易，但应用不易。
大家可以参考我们给出的OK二十大要领，再根据自身实际情况加以调整，就能顺利的实施。
Ok二在组织中发挥出它的效果。
我们认为衡量结果好坏的最简单手段就是数据，只有数据才会让人信服。
绩效考核关键就是用数据说话。
作者简介，黄勇，新任特赞科技CTO图书架构探险作者，smart开源项目作者，TGO鲲鹏会，上海分会会员，q控讲师，十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇轻量级架构思想，喜欢阅读、热爱交流，乐于分享。