业务同事的绩效很容易考核，签了多少单？赚了多少钱？清晰可见，容易衡量。对于做产品研发工作的我们来说，成本很好计算，但价值却很难衡量。业务团队能为公司赚钱，研发团队却花公司的钱，研发团队从此就变成了公司的“成本中心”。

我们需要有一套合理的绩效考核机制，衡量并验证自己的价值。这套机制需要简单易懂、操作方便，而且需要通过数据说话。有数据还有要对比，需要与自己比较，还要与别人比较。

本文将结合之前的文章（第 14 讲：从零开始搭建轻量级研发团队）中提到的内容，从绩效考核方面继续探讨下去。首先，我们针对研发团队考核模型，进行深入探讨。

研发团队考核模型

我们的研发团队分为横向“职能团队”与纵向“项目团队”，所有的研发人员都在职能团队中，他们都在所在的项目团队中，体现出自己的工作绩效。因此，绩效考核是基于项目团队进行的，而不是职能团队。针对不同类型的项目团队而言，需要制定不同的团队目标，采用不同的考核方式（如图 1 所示）。


图 1：项目团队考核方式

每种项目团队都有共同的考核部分，那就是“个人 OKR”，它包括两方面：一是个人成长，二是团队贡献。个人成长又包括专业技能和综合技能两方面，前者是“硬技能”，后者是“软技能”。个人是否得到成长，取决于和自己的曾经作比较，而并非与他人作比较。团队贡献包括的方面较广，比如：技能培训、经验分享、偿还技术债、制定并落地规范、组织团队活动等。在本文下一节中将对 OKR 进行深入探讨。

需要注意的是，个人 OKR 需要个人结合团队目标来定义，由个人所在职能团队来评审个人 OKR。也就是说，OKR 是自底向上的，而 KPI 却是自顶向下的。此外，我们认为 OKR 和 KPI 既不冲突，还能相辅相成。将 OKR 与 KPI 有效结合，不仅可以激励团队成长，还能促进团队完成公司的核心目标。

对于功能团队而言，他们的目标是确保以最快的速度，高质量地让项目上线。然而，速度和质量往往是相互制约的，速度太快，质量一般不会太高。也正因如此，我们才需要对功能团队的速度加以限制，否则项目上线后，一个难以维护的成果即将诞生，可以想象，随后效率团队一定会踩坑无数。因此，我们需要对功能团队定义一些“技术 KPI”，才能确保项目的顺利交接，比如：上线时间、代码质量、产品质量等。

对于效率团队而言，他们的目标是优化现有产品功能并帮助业务实现目标。可见，业务的成功，决定于效率团队的成功。我们无需像要求功能团队那样去要求效率团队，因为他们关心的不再是速度和质量，而是如何不断提升业务效率，帮助业务团队实现业务目标。因此，我们可将业务 KPI 作为考核效率团队的参考标准。

对于创新团队而言，他们的目标是帮助公司创造新的商业机会与盈利方式。往往需要通过收入的方式来考核该团队，我们需要同时设置业务 KPI 与技术 KPI 来验证该团队的价值，即投入与产出。

当然，不论哪种项目团队，都需要考核项目是否延期？上线后是否有 Bug？而且这些标准都应该是事先确定清楚并和团队达成共识的。我们相信：先有共识，才有共赢。只有大家一致认同的原则，才可能有效地去执行。

以功能团队和效率团队为例，在绩效考核的具体操作层面上，我们可采用“打分制”，根据具体情况进行加分或减分（如图 2 所示）。


图 2：绩效考核打分制

需要注意的是，效率团队将对功能团队的交付成果进行考核，不仅是代码，还包括文档。确保功能团队的 1.0 项目这根“接力棒”可以顺利传递下去，未来在效率团队的手中，让它变成 1.1、1.2、1.3 等。若要开发产品功能 2.0，可认为这是新的尝试，同样需要功能团队来开发，2.0 功能上线后再次交给效率团队进行功能迭代。

每个季度可进行一次绩效考核，具体的考核成绩将分为 S、A、B、C 四个级别，S 表示大家心中充满美好期待的那根线，A 表示努力跳起来就能够得着的那根线，B 表示及格线，C 表示不及格。绩效考核的成绩需要公示，考核结束后根据具体成绩进行奖金发放。同时，个人 OKR 也在每个季度结束时进行考核，但考核结果不会体现在季度奖金中，而是体现到每年的加薪幅度上，因为个人 OKR 是个人的能力提升与团队贡献程度的表现，与薪资挂钩会更加合理。

关于 OKR 方面，虽然它无法直接反应在绩效上，但它对团队的成长是至关重要的，团队成长了，绩效才能提高。下面，我们专题讨论一下 OKR 的十大要领。

OKR 十大要领

OKR 最早来自于 Intel 公司，随后在 Google 公司得到了更好的应用，现在全球杰出的互联网公司几乎都在用 OKR。要在企业中更好的应用 OKR，完全取决于我们自己对它的认识。

OKR 包括两大要素：O 和 KR，O 是 Objectives（目标）的缩写，KR 是 Key Results（关键结果）的缩写。O 用于描述我们心中希望通往的美好目标，KR 用于描述衡量实现这个目标的关键结果。

为了让大家更好地理解 OKR 的精髓，我们提出以下 OKR 十大要领：

  • OKR 不是一款绩效考核工具，而是一款目标管理工具。
  • OKR 包括自顶向下（制定）与自底向上（评审）的全过程。
  • O（目标）需要做到简洁且定性，要鼓舞人心。
  • KR（关键结果）需要做到明确且定量，用数据说话。
  • 一个季度制定一次 OKR，季度结束需对 OKR 进行评审。
  • 每周做一次 OKR 回顾，每月做一次 OKR 调整。
  • OKR 制定过程需进行多次评审，以确保它与上级目标不冲突。
  • O 一般不要超过 5 个，O 所包含的 KR 一般为 2-4 个。
  • OKR 需要做到透明化，向团队完全公开。
  • OKR 评审结果可作为加薪的重要参考依据，但不是唯一依据。

对于 OKR 而言，很多人容易将它理解为绩效考核工具，认为它和 KPI 是同类，这是一种误解。如果将 OKR 理解为考核工具，我们一定无法用好它，也更无法从中受益。OKR 是一款目标管理工具，它管理的是我们所制定的目标，让我们的目标更加清晰且容易实现。

KPI 是自顶向下的，老板定义了 KPI，各级领导去背 KPI，员工去完成 KPI，大家各扫门前雪，达成自己的 KPI 即可。然而，OKR 却是自顶向下和自底向上的全过程，老板结合企业战略去定义企业 OKR，领导结合企业 OKR 去制定团队 OKR，员工结合团队 OKR 去制定个人 OKR，这是 OKR 制定过程。通过一段时间的努力，随后进入 OKR 评审过程，员工评审个人 OKR，领导评审团队 OKR，老板评审企业 OKR。可见 OKR 即包括了自顶向下的制定，也包括了自底向下的评审。

我们务必做到能用一句话来描述 O，这句话要让团队任何人都能完全理解，即简洁且定性，还要做到鼓舞人心。例如，如果目前我们的团队文化做得不太好，我们希望未来一个季度可以得到改善，O 如果写成“改善团队文化”，这句话虽然做到了简洁且定性，但不够鼓舞人心。我们可以将其改为“打造更好的团队文化，让大家爱上这个团队”，是否瞬间就产生了正能量？

每个 O 都有对应的 KR，它们用来说明为了实现这个 O，应该做到的关键结果是什么。KR 需要做到让团队任何人都能完全衡量，即明确且定量，还要做到用数据说话。例如，如果目前我们的系统架构中微服务的颗粒度较大，代码的可重用性方面比较低，为了解决这个问题，我们希望对微服务边界进行切分，如果将其中一个 KR 写成“切分颗粒度较大的微服务”，这样是不合乎要求的，我们可将其表述为“至少切分 3 个颗粒度较大的微服务”，增加了一个数字来描述，这样的 KR 就更加容易衡量了。数字是最容易衡量的，此外“有”和“没有”也比较容易衡量。

通过实践我们发现，一个季度制定一次 OKR 是非常合理的，季度结束需对我们所制定的 OKR 进行评审。OKR 并非制定后就无法调整了，我们自己每周可做一次 OKR 回顾，自行将有问题的地方记录下来，职能团队每月在一起可做一次 OKR 调整，以及时修正我们的 OKR。对于个人 OKR 而言，并非完全由自己制定后就开始执行，个人 OKR 制定过程需要进行多次评审，以确保它与团队 OKR 不冲突。O 和 KR 的数量也有限制，O 一般不要超过 5 个，O 所包含的 KR 一般为 2~4 个。

最后，需要说明的是，OKR 要做到透明化，可用电子表格或纸质卡片来管理，这些表格需要向团队完全公开。此外，每个季度末的 OKR 考核结果可作为加薪的重要参考依据，但不是唯一依据。

我们作为团队领导者，也需制定自己的 OKR，以下是一位研发团队领导者的 OKR 示例（如图 3 所示）。


图 3：一位研发团队领导者的 OKR 示例

写在最后

一个团队需要有目标，也需要对目标完成情况加以考核，目标与考核往往是相辅相成、缺一不可的。如果只有目标而没有考核，将无法检验团队的价值；如果没有目标而只有考核，团队将离我们越来越远。

OKR 不是绩效考核工具，而是目标管理利器，所有人都能理解 OKR 的定义，但不是每个人都能很好的应用它，这也正是 OKR 的魅力之处，往往好的工具都是理解容易，但应用不易。大家可参考我们给出的 OKR 十大要领，再根据自身实际情况加以调整，就能顺利地实施 OKR，在组织中发挥出它的效果。

我们认为，衡量结果好坏的最简单手段就是数据，只有数据才会让人信服，绩效考核关键就是用数据说话。

作者简介

黄勇，现任特赞科技（tezign.com）CTO，图书《架构探险》作者，Smart 开源项目作者，TGO 鲲鹏会上海分会董事会成员，QCon 讲师。十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇“轻量级”系统架构。喜欢阅读，热爱交流，乐于分享。