在过去十几年的软件工程师生涯中，我经历过十几次的绩效评估。对于这些评估，有些已经忘记了，有些还可以，但其中很大一部分只能说非常糟糕。通常，这些坏的评估也常常让我“心生离意”，它让我失去了对经理的信任，也让我决定离开团队或公司。当我成为一名经理的时候，我暗暗发誓要尽我所能地来避免那些尴尬和糟糕的绩效评估。
本文总结了我准备和实施绩效评估的方法，这些绩效评估是公平的、能够同员工建立信任并激励他们。在过去的三年里，我已经采用这种方法进行了 50 多次的绩效评估，其中大多数都很受欢迎。我之所以要写这篇文章，是源于我在公司内部和本地参加的一些小型聚会，大家对我的一些分享非常感兴趣并希望能够把它们推广出去。
希望你能够把它当作灵感和新想法的源泉，而不是一个死搬硬套的框架。把它当作一种挑战自己的方式：针对绩效评估你可以如何改进？
注意：本文主要面向绩效评估的实施者（经理）。而对于被评估者（员工），我会写一篇后续的文章，以便为绩效评估做出更好的准备。
本篇文章涵盖的内容有：
我是如何进行绩效评估的：准备，写评语，消除偏差，执行评估
公平绩效评估的先决条件：职级、职能、预期
为使绩效评估公平，职位分级以及相应的预期要明确。否则，即使你依然可以得到良好的反馈，但这都是主观的反馈而没有客观的依据。所有优秀的科技公司都有明确定义的职级和预期要求等。这些通常作为内部资源保留，公司内部的所有工程师和经理都可以看到。我工作过的大多数公司都是这样。幸运的是，一些公司正在公开他们的评估准则。下面是一些很好的例子：
Monzo的渐进框架可适用于很多地方，而不仅仅是软件工程领域。
"Rent the Runway"的职业进阶，由《管理者之路》的作者Camille Fournier分享。
Square的软件工程职业进阶，详细请参照他们的博客。
对于公司内部的职位分级，Levels.fyi是一个不错的资源。值得一提的是，我发现很多企业内部的职级还是比较模糊的。
如果你的公司还没有为开发人员明确定义职级以及相应预期的话，这会影响绩效评估的公平。如果你是一个管理者，那么你的首要工作就是解决这件事，把有经验的管理者和工程师召集起来，共同构建第一个版本。
糟糕的绩效评估
我进行绩效评估的大部分方法都来自于我的一些糟糕经历：
零细节。那种满是套话而毫无实质内容的评估。从表面上看，这样的评估可能不错，有像“做得好”或“继续保持”这样的评价。但是当你要求提供细节时，你的经理却不能给出一个例子或者任何建设性的反馈。虽然你可能认为这是来自你经理的褒奖，但是请三思，你并没有得到任何关于你如何成长的具体反馈，你的经理似乎也没有花费哪怕五分钟的时间来写你的评语。这样的经理能有多关心你？
我的经理和我的日常工作脱节。你经历了一段很棒的时期，输送了一些有影响力的东西。然而，这些在考核里都没有被提及到，只能算是一些微不足道的副业。为什么他们没有提到你工作的主体？既然他们从来没有提起过这些内容，那他们知道你在做什么吗？根据我的经验，他们很可能不会。既然他们没有，就不要指望他们会在你晋升到下一级别时为你担保。
“让我们直接跳到数字”。在会谈中，你非常激动：最终，一个不会让你久等的经理，会给你一直在等待的东西：奖金和工资数字，然后问你是否有任何问题。你还在考虑如何花这笔钱，所以你根本不会有问题，尤其是如果数字还看起来不错的话。会议结束后，你重新评估这是否是你真正想要的考核。这是一次绩效评估，只不过你们并没有谈论一件事：那就是你的绩效。第二天你可能会觉得很尴尬，不想提起这件事。这种类型的评估并不比“零细节”评估更好。
不公平的，片面的评估。这是一种会让你离开时怒气沸腾的绩效评估。在评估过程中，你会得到一些负面的反馈，而你的经理试图用一种文明的方式来传达这些反馈，所以他还附带了一些例子。但是这些例子是片面的，遗漏了关键的细节，也没有很好的阐述出来。你可能会质疑这一点，但只会让你的经理采取防范措施。而且说实话，他们也不得不这样做，对吧？评估的等级决定了你的奖金，而且不能再改变了。所以会议结束后，你们俩都很沮丧。当你指出遗漏的事实时，你会为自己的不公平对待而感到沮丧，然后觉得被忽视了。最坏的情况就是，你的经理对你很生气，认为你的抱怨是没有根据的，你只是在无谓的辩解。你觉得修复这种（破裂）关系的可能性有多大？
有偏差的评估。这里不是指正面的偏差，而是负面的偏差。这可能是近期偏差，专注于近期完成的工作，但忽略了很多以前完成的很棒的工作。这也可能是性别偏差，尤其是如果你是女性，更多地关注你的行为而不是你的成就，或者淡化这些。还有一些其他偏差，会让你觉得你的贡献被贬低了。
那种“万万没想到”的评估。这也是最重要的一个。如果一个评估完全出乎你的意料（通常不是一个好的意料），那这是你的经理在反馈表达上的失败。好的评估会有很多新的信息，但是很少有意想不到，切记。
对高科技公司绩效评估的三点看法
在接受了十几次的绩效评估以及同很多人分享交流之后，我现在坐到了桌子的另一边，并完成了近百次的绩效评估，下面是我从整个过程中收获到的三点看法。
员工和经理之间的信任最有可能因为糟糕的绩效评估而破裂。糟糕的绩效评估会破坏信任，是员工寻找其他机会的第一步。我本人以及与我交谈过的人都这样认为。
很少有技术经理会花费大量的时间去写那些有实质性反馈意见的评语。我自己的很多经理以及我认识的一些经理都会在这项工作上偷工减料，借口说他们没有时间。没有时间也经常被认为是一个不肯花心思的糟糕的借口。
对工作成就的认可与评分考核里的数字一样重要。我对评估最大的失望从来不是对数字的失望，即使它们低于我的预期。我之所以失望是因为他们不承认我的工作，也缺乏对我的成就和成长的关注。虽然管理者并不能总是控制数字，但他们是能完全控制自己说谢谢的方式或者压根不说。
我是如何进行绩效评估的
当我第一次进行绩效评估的时候，我想避免那些我所看到的以及经历过的糟糕的绩效评估，并时刻记住这些评估对人们所产生的影响。
我根据绩效评估的结果设定目标：
公平、无偏差和清晰的反馈。反馈应该基于先前设定的预期，期望值应该经过校准，并清楚地说明该员工是否达到、低于或高于该预期。
激励。我希望我们在评估结束后都很受激励。这如何做到？首先承认所有好的工作，然后讨论下一步要关注什么。这里有一个棘手的部分：如果员工的实际表现不支持我试图传达的信息怎么办（低于预期）？
建立信任。由于绩效评估是经理和员工之间信任的最大考验，我的目标是去扭转这种情况，并加强我们两人之间的信任。这至少要求评估是一次诚实的双向对话。
设定目标之后，接下来看我是如何进行评估的。但在开始正式的考核会议之前，前期准备是关键。当我说准备的时候，我的意思是从最开始的几个月就开始准备，甚至从新员工刚刚那个加入到团队的时候就开始准备。
为评估做准备：几个月之前
如果你不了解这个人，并且没有提前设定预期基准的话，你很可能无法做出好的绩效评估。因此，一旦有新人加入我的团队，我就会从以下几点开始准备：
了解他们的目标和动机。他们希望从这里的工作中获得什么？他们最关心的是什么：成长，头衔，领导力，影响力？他们在工作之外的优先级是什么？我也会问他们在这份工作之后的梦想是什么：我们都知道这不是他们的最后一份工作，这也不是我的最后一份工作，我想帮助他们实现除了这个公司和职位之外的目标。
明确我作为管理者的角色，以及他们对我的期望。我总是强调他们的职业生涯掌握在自己手中：也就是说，不要指望别人来督促这件事。然而，作为一名管理者，他们应该期望我能够定期给予反馈，为成长创造机会，并在有机会时充当导师或教练。
定期的 1：1 会议。这是专门为他们安排的时间，也是双方分享反馈和谈论他们心中重要事情的地方。如果有关于工作表现方面的问题，我会在这里提出来，讨论并解决它们。
明确晋升和职业成长之间的区别。特别是对于职业生涯早期的工程师来说，许多人认为升是唯一的成长方式，有些人也以此为目标。我对晋升有很多看法，而这些看法忽略了职业成长的很多方面，所以我会尽早把它们表达出来。
为评估做准备：几周之前
我认为有必要为重要的会议做准备。会议越重要，就需要越多的准备。对于工程师来说绩效评估是最重要的会议之一，尤其是与新经理的第一次会议。所以我也会做相应的准备。
我大部分的时间都用来收集“什么”和“如何”类的信息。我想确保我获得了正确的信息，同软件工程师一起工作，他们的大部分工作都很容易获得。以下是我要收集的信息：
1：1 会议记录。
工程师参加的项目，他们贡献了什么？
产生的输出：代码，文档，电子邮件。
他们收到的反馈：同行反馈，通过电子邮件或其他方式收到的感谢，以及我能找到的其他反馈。
他们给出的反馈：代码审查、计划文档审查、与他人的交互。
自我评估：他们从自己的工作中收集到了什么？我会把这一个放到最后，尽可能收集他们可能遗漏的东西。
我会在这部分上花费很多时间，尤其是如果这是第一次给团队中的新人做评估。我的目标是发现他们一直在做的所有很棒的工作，即使是他们可能已经忘记的事情。我保存了一个清单，我会在每个周期之前更新它：
写评语
绩效评估的评语有一个推荐的格式，不过我基本上不怎么用。下面是我如何在一个单独的文档中写我的评语：
列出所完成的工作
根据我的准备工作，我会先总结过去一段时间所完成的工作。我通常按时间顺序列表，列出更有影响力或更具挑战性的贡献。
这个列表有三个目的。首先，它认可团队成员所做的工作。其次，我可以暂停绩效评估，询问他们是否遗漏了任何内容。如果真的漏了，我们就补上它。第三，它通常使人们相信这是一次公平的评估，他们常常对这个列表中包含的细节感到惊讶。这也反映出了我为这次会议所做的准备。
职能
我重新阅读了所有的职能要求，并设定预期来对应这些职能。
参照已完成的工作，以及如何完成的，我来确定这个人是否符合，超过或低于其对应的职能要求。
我总是提供例子和具体的反馈来帮助改进。当某人没有达到预期时，这一点尤其重要：反馈需要具体、可行。当人们达到了预期但又没有超出预期时，这同样重要。对于超出预期的人，我有时会提出一些额外要求来锻炼他们。
完成评语
简短的总结：我把这个总结放到最后，清楚地表明这个人与本身级别相比所处的位置，以及离晋升到下一个级别的距离。
三个重点关注的地方：我会从他们的角度总结三件为了更快的成长而需要关注的事情。我试着把这些建议具体化。这将是评语的核心内容，希望是激励性的内容。
我重新阅读所有材料，确定没有重复的例子。我还会做一些调整，确保所有信息都能够支持前面的总结。
校正并消除偏差
我们都会有偏差，我也不例外。为了减少偏差，我做了以下几件事：
逐一比对参加绩效考核的对象，特别关注最好和最差的人，以及与我不同的人。我参照的是同一个标准么？我是否使用了相似的语言或语气来称呼成就或缺点？
同我的上级分享这些评论，要求他对评估标准和偏差给予反馈。这不仅是一个获得反馈的好方法，而且还可以让我的上级对手下的人有所了解。
为下属做准备
由于我在截止日期之前就早早完成了书面评估，我需要确保团队成员也多少能有些心理准备，尤其是一些新出现的不达标成员。我会仔细检查这种情况，并提醒他们本次评估会得到什么样的反馈，以及将要讨论的改进空间。
进行绩效评估
我一般会把绩效反馈和奖励通知分成两个会议。我尝试过不同的办法，但只有这个方法可以获得高质量的讨论和反馈效果。人们一旦听到他们的薪酬数字，他们的大脑就会失去对其他事情的注意力，任何关于改进的讨论都是没有意义的。这是我自己的经验，也是我所有下属遇到的情况。尽管人们很想知道这些数字，但我不会在同一个会议上告知他们结果。
会议开始时，我会设定一些期望：会议的形式是什么，并把所有这些都写下来。我还会明确表示，我希望这是一个双向的对话，以及在每个环节结束之后我会如何听取他们的反馈。
我首先会讨论对方在这段时间的工作成就，这是建立信任的好方法，也表明我也做了功课。然后讨论每一部分的反馈。我反对“三明治”式的反馈，只发送一个信息。我会中断一下，通过诸如“你觉得怎么样?”、“你有不同意的地方吗?”或者“你感觉这个评估符合实际情况么?”这类的问题来鼓励对方分享他们的想法。我会注意对方的身体语言，当人们紧张时，他们可能会下意识的反对，我会试着让他们尽量说出来。毕竟现在谈总比以后谈好。
最后，我会询问一些问题来确认本次评估的效果，问题诸如“你感觉怎么样?”，“最让你惊讶的是什么?”以及“你不同意哪一点?”等。
如果对方不同意怎么办？我有几次公开邀请人们说出他们的顾虑，果然，有几个人觉得评估的一小部分或大部分是不正确或不公平的。我一般并不强求去了解所有事情的前因后果。因此，如果我遗漏了信息、事实或反馈，那么评估可能并不能反映他们的真实表现。这也是我通常从讨论他们的工作成果开始的另一个原因。
当我很明显地遗漏或者误解了一些关键部分时，我会让他们尽快收集例子，并在第二天召开一个后续会议。当我忽略了某些重要的细节而对方又正确地指出这一点时，我会修改自己的评估结果。
如果对方不同意我对达到预期的解释怎么办？这个问题比较棘手，但解决这个问题是保持两者之间信任的关键。这就是为什么我会事先准备一些低于或超过预期的具体例子，以及关于如何改进和达到目标的可行的反馈。
不管怎么样，我认为如果人们不满意他们的评估结果，一定要尽早表达出来。这也是为什么我总是把奖励会谈与这种反馈分开。人们可能对绩效反馈感到高兴或不高兴，但对金融数字的感觉却不同。前者比后者更容易解决。
评估之后
到这里绩效评估还没有完全结束，还有一些事情需要完成：
发送书面评语。我通过电子邮件发送我们讨论过的评估。我知道有些人花了很多时间来阅读它。即使我们有一个单独的评估系统，我仍然喜欢发送我自己的文档，因为在我的文档中，我可以用更清晰的形式突出关键成长部分。
当人们不同意部分反馈时，我们会很快进行一个跟进会议。在跟进会议上，我们讨论具体的问题。在几乎所有的案例中，我发现问题要么是遗漏了信息，要么是不同意具体例子的解释。
单独开会讨论奖金和工资。人们可能对他们的业绩评估感到满意，但对数字感到不满意。所以最好把两者分开。我甚至遇到过一个对他的考核不满意但是对奖金数字很高兴的人。如果我们把两个会议放在一起，我可能永远都不会知道他对我的反馈不满意。
前瞻性的目标设定。对于那些在某一地方没有达到预期的人来说特别重要。对于那些超出预期的人来说，尽早开始也很有帮助，他们可以为晋升到下一个级别做准备。
绩效评估模板
我把我所用的绩效评估模板都放在一起。分享它只是为了激发灵感。如果你是实施绩效评估的人，我鼓励你建立自己的模板。把这些信息整合在一起，可以使重点更加清晰，确保人与人之间的交流一致，同时也减少了偏差。尤其是提前写好反馈意见，充分准备是一个强有力的工具，可以提供更客观、更少偏差的反馈。
我的绩效评估模板，点击这里查看Google文档
“专业人士” 眼中优秀的绩效评估是什么样子？
毫无疑问，前面只是我个人的方法：你的情况可能会完全不同，对我有效的方法对你可能不起作用。不过我很好奇：管理行业对于优秀的业绩评估有哪些主要的观点？于是我求助了一个权威资源，《哈佛商业评论》，并且浏览了他们内部具有最多阅读量的一些关于绩效评估的文章。以下是他们的观点：
在《提供有效的绩效评估》(HBR，2011)一书中，Rebecca Knight 提出了以下建议：
前期准备。尽早设定预期。奠定基础：提前几周准备评估。尽早定下基调，不要使用”三明治“式的反馈。
期间：建设性地指导。询问他们的感受。谈论具体的事，而不是职位或级别。
坚持你的立场。单独进行绩效评估和奖励讨论。实现目标应该达到预期：不要给出超出预期的反馈，从而使目标膨胀。
在《为什么大多数绩效评估是有偏差的，以及如何解决这些问题》(哈佛商业评论，2019)一文中，LoriMackenzie，JoAnneWehner 和 Shelleyj.Correll 提出了一些具体的建议：
开箱式反馈（无结构的反馈）对于男性和女性都是一种有偏差的方法。
限制反馈的形式以消除偏差：工作职能很有帮助。根据职能要求或评分准则进行评估，提出更具体的问题（例如描述员工如何达到预期的）。
在你写下所有的评语之后，对它们进行一致性检查，以消除偏差。
无偏差的反馈可以带来更好的表现。
从他们的文章中，我们可以得出这样的结论：
我们所了解到的是，评估中的模棱两可会导致偏差。他们利用这一点，找到了使用评分准则来保持一致和公平的方法。相信自己的直觉固然是一个很吸引人的想法，但挑战在于悄然潜入的隐性偏差，它们很难被发现，也很难阻止它的发展。
公平绩效评估的原则
根据我的个人经验、方法和成功，并与 HBR 出版社的专家建议进行交叉对比，我总结出了一些为写出好的绩效评估而值得考虑的原则：
做好绩效评估需要很多的时间，一定要挤出这些时间。经理人没有投入足够的时间，但如果你这样做，你将获得一个巨大的胜利。找时间进行一次适当的深入的评估，尤其是在与下属建立信任的阶段。
工程师的工作是具体的，为具体工作提供具体反馈。工程师们花费大量时间编写代码、文档和电子邮件。我们也一起交流和工作。这意味着工程师的工作是非常具体的。在提供反馈时使用这些细节。不要只是给出“代码很糟糕”类的反馈，要具体一点。如果合作可以更好，使用一个特定的项目示例。在表扬的时候，也要这样做。
反馈越频繁越好。绩效考核不应该是一个“出乎意料”的对话。本文主要关注那些大型绩效评估的准备工作。每 6 到 12 个月发生一次。但是为了能够有一个富有成效的会谈，你需要不断地收集和给予反馈。持续的反馈和良好的正式绩效评估可以帮助人们成长。
人们真的很喜欢得到高质量的反馈。你的下属会看到你是否把时间和精力投入到绩效评估中，他们会非常感激具体的和可行的反馈。大多数开发人员都没有收到高质量的绩效评估。通过这样做，你可以建立信任，帮助他们成长，你也可以在提供优秀反馈方面变得更好。
好的绩效评估可以带来更多的信任，更快的增长和更少的摩擦。好的绩效评估已经在我的团队中得到了回报，低摩擦、高信任、更快的成长和晋升。在与人力资源专业人士分享我的方法时，我也得到了类似的反馈，他们中的许多人都对我在这个过程中付出的努力感到惊讶。随着时间的推移，这种努力会变得越来越小。一旦你掌握了其中的一些技巧，收集反馈就会变得更加容易。
如果你是一个管理者，请参考本文，至少在一个方面挑战自己改进你的绩效评估。管理者没有什么理由去做准备不足、不公平或有偏差的绩效评估，你的确是节省了一些时间，但造成的坏处会影响更大。让我们改变绩效评估的方式，把这些有压力的谈话变成进一步加强信任的谈话，评估结束后让人们感到充满动力并决心进一步成长。
原文链接：
https://blog.pragmaticengineer.com/performance-reviews-for-software-engineers/
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论