95 lines
11 KiB
Markdown
95 lines
11 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
022 验证研发团队价值的绩效考核机制
|
||
业务同事的绩效很容易考核，签了多少单？赚了多少钱？清晰可见，容易衡量。对于做产品研发工作的我们来说，成本很好计算，但价值却很难衡量。业务团队能为公司赚钱，研发团队却花公司的钱，研发团队从此就变成了公司的“成本中心”。
|
||
|
||
我们需要有一套合理的绩效考核机制，衡量并验证自己的价值。这套机制需要简单易懂、操作方便，而且需要通过数据说话。有数据还有要对比，需要与自己比较，还要与别人比较。
|
||
|
||
本文将结合之前的文章（第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 讲师。十年以上互联网软件架构与技术管理经验，擅长敏捷开发，推崇“轻量级”系统架构。喜欢阅读，热爱交流，乐于分享。
|
||
|
||
|
||
|
||
|