软件工程师绩效评估解释

在考虑软件工程师绩效评估的不同方法时，一定会想到一个问题：为什么我们需要使用多种评估模型？ 简单的答案是，软件开发是一个复杂的、多方面的过程，通常涉及数十个人在不同的团队中工作。

高管和利益相关者并不总是对每个开发人员的资格和职责有深入的了解，尤其是在大型组织和团队中。 这就是为什么性能评估应该留给技术熟练的专业人员，这些专业人员能够理解每个软件工程师的职责、能力、技能组合以及在整个软件开发过程中的角色。

那么，进行绩效考核的正确方法是什么？ 答案将取决于许多因素，从组织的规模和目标到工程师绩效的更详细方面。

管理绩效评估

管理人员在工程绩效评估中发挥着主导作用。 在许多较小的组织中，直接经理可能是唯一进行审查的人。 大公司通常不是这种情况，因为他们的审查过程通常更复杂，并且涉及更多不同角色和部门的人。 较大的组织也倾向于比较小的组织更频繁地使用同行评审和自我评估。

自 20 世纪下半叶大公司采用绩效评估以来，绩效评估已经走过了漫长的道路，但绩效评估的历史超出了本文的范围，支持一些绩效评估模型的行为心理学也是如此。 相反，这篇文章侧重于流程的实际方面，从管理层的职责开始。

尽管方法可能因组织的规模和类型而异，但一些基本原则适用于大多数（如果不是全部）审查情况。

管理人员需要如何进行绩效评估

管理层需要彻底规划审查过程，并确保参与的每个人都了解自己的责任。

• 审查过程需要提前定义好，让经理和工程师有足够的时间参与并提交反馈。 最后一分钟的反馈可能价值较小，因为它可能会匆忙提交以赶上最后期限。
• 管理层需要将审查过程的目标、目的和价值传达给工程师和其他利益相关者。 良好的沟通应该消除对流程的疑虑并提高评论的质量。
• 审查模板或表格需要事先商定，并且在设计时应考虑到使用寿命。 理想情况下，它们不应在审查周期之间发生变化，以确保审查结果随着时间的推移具有可比性。
• 该方法应旨在最大限度地减少偏差并确保高度的一致性。 每个经理和工程师都有自己做某些事情的方式，但一致性可以防止个人及其偏见或偏好过度影响结果。
• 当采用同行评审和自我评估时，管理层需要确保评审过程的完整性。

减轻偏见和处理有问题的评论

由于管理层对审查过程的巨大影响，管理人员需要注意可能破坏过程的潜在偏见和其他问题。 即使计划阶段执行得很好，整个过程设计得当，管理层也可能需要消除某些不受欢迎的做法并确保过程的完整性。

• 在流程的所有阶段都需要考虑能力和期望。 粗略地审查每个团队成员可能会导致经理或同事提交过于正面或负面的评论。 假设同行提交了有问题的评论，因为他们不熟悉某个工程师的具体能力。 在这种情况下，管理层需要进行干预并确保此类审查不会影响总体得分。
• 经理也可以拒绝评论。 假设某位经理与一小部分工程师的工作脱节。 在这种情况下，他们不应该直接审查团队的绩效，因为他们可能缺乏平衡和详细审查所需的背景和知识。
• 对特定个人或其职责缺乏深入了解的审阅者可能会觉得有必要提交对其表现的审查以选中一个框，从而生成一个没有太多实质内容并且不会为审查过程增加太多价值的审查。
• 有偏见和片面的评论也会扭曲结果。 如果经理审查违反其意愿聘用的团队成员，或者处理项目的团队未得到特定经理的认可，则他们的审查可能不客观。 或者，审阅者可能会“挑选”特定的绩效指标，以使个人或团队看起来更好，因为这符合他们的兴趣。

理想情况下，经理和高管能够以纯粹客观的心态进行审查，但存在偏见。 然而，意识到它们可以减轻它们的影响。

请记住，经理审查软件工程师的方式可以为经理的绩效和专业水平提供有价值的见解。

同行评审

与经理评论相比，同行评论提供了一些优势，但需要记住一些权衡。

同事往往比经理更有能力评估彼此的表现。 他们对队友的工作有更多的了解。 他们经常从事相同的项目并与相同的人合作，因此往往对团队动态和单个工程师的能力有很好的把握。

然而，同行评审也可能受到偏见的影响。 偏见可以表现为积极的，基于友谊，也可以表现为消极的，由个人问题或团队成员之间的竞争引起。 集体思考也可以影响审查过程，尤其是在紧密结合的团队中，因为人们可能倾向于为他们的队友提供掩护。 鉴于这些可能性，需要以减轻偏见的方式设计同行评审模板和问卷，并尽可能关注特定的能力和客观标准。 团队成员的结果如何跟踪关键绩效指标往往比关于个人特征的主观问题或其他开放式问题更有价值。

潜在的偏见提出了一个关键问题：同行评审应该匿名吗？

可以提出有效的论据来支持匿名和公开审查，但重要的是要考虑不同的组织方案和团队规模。 因此，没有绝对正确或错误的答案，尽管大多数组织都喜欢匿名评论。

匿名与公众反馈

让我们仔细看看匿名反馈的优势：

• 匿名可以鼓励开放性和原创性思维。 如果团队中的大多数人对某事或某人感到积极，那么不同的意见可能不受欢迎。 匿名审阅者可以提供不同的观点，而不会激怒他们的同事。
• 匿名反馈可以包含有价值的信息。 假设专业人士正在为同一个人收集匿名和公开的反馈。 他们很有可能会引用匿名意见来提出他们可能不愿意从公开评论中引用的问题。 一些额外的点可能具有很大的价值，特别是如果在团队其他成员发现问题之前提出问题。 这种预警使管理层和被审查者有机会解决和纠正新发现的缺陷，以免它们升级为更严重的问题。
• 维护关系是匿名反馈的另一个重要方面。 人们以不同的方式对负面评论做出反应，因此保持匿名可以保持凝聚力并防止团队成员之间发生摩擦。
• 如果评论不是强制性的，通常更容易说服人们参与匿名评论。

但是，匿名同行评审也有一些缺点：

• 匿名是双向的。 它鼓励坦率的评论，但它可能会促使一些人滥用它，通过不诚实的评论来宣传他们的议程。 有人可能会利用他们的匿名性来仅仅根据他们的个人喜好来破坏同事。 相反，匿名可用于为不值得他们提交正面评论的人，因为评论者可以选择保护他们的长期同事和朋友，可能以牺牲其他团队成员为代价。
• 公众评论可以发挥更大的作用。 假设一个人从几十个匿名评论者中收到了几行负面反馈。 很有可能，这种反馈不会像从可信赖和受尊重的团队成员那里获得相同的反馈那样有影响力。 当反馈来自亲近的人时，员工更有可能认真对待反馈。
• 在某些组织（即小型组织）中，确保匿名性可能具有挑战性。 每天与他们一起工作的五个人总共收到四条评论的人可能能够分辨出谁提交了哪条评论。 这可能会导致人们将评论视为匿名的，从而破坏了匿名化的全部意义。
• 虽然让人们提交公开评论可能更具挑战性，但评论者更有可能认真对待他们，因为他们知道他们的名字已附上。 因此，他们可以投入更多时间来提供详细、客观和平衡的反馈，而不是将审查过程视为一种形式。

自我评估

自我评估——或自我评价——是另一种常用于绩效评估的方法。 与其他评论模型一样，他们可以提出自己的争议。

员工管理人员通常需要定期进行自我评估，如果目标是使用它们来跟踪进度和随时间的变化，这是有道理的。 很少有组织要求每月进行评估，但每年、每两年甚至每季度的自我评估都很常见。 要求工程师定期提供反馈可能是有益的，尤其是在与高度自治的团队和个人打交道时。 被审查者可以使用这些定期评估来传达需要解决的潜在问题，解释他们如何克服特定挑战，详细说明他们如何以及为什么提高绩效，并确定阻碍他们提高绩效的因素。

减轻自我评估的局限性

不幸的是，自我评估有几个严重的缺点，偏见是最明显的一个。 有些人可能会夸大他们的表现，拒绝透露他们工作中的不足，或者列出阻碍他们表现的问题。 其他人可能对自己过于挑剔。 在任何一种情况下，结果都可能出现偏差。

组织如何减轻缺点？ 管理人员可以设计自我评估表格和问题，以解决偏见并将其影响降至最低。

• 避免允许过多主观性的开放式问题。
• 关注有形的结果，而不是主观的目标和价值观。
• 对被审查者处理的关键责任给予更高的重视。
• 强调关键绩效指标和可量化的目标。
• 重申组织的核心价值观并相应地评估绩效。

为了让工程师解决可能未包含在自我评估表中的问题，请提供评论部分。

360 度评估

360 度反馈流程结合了许多先前讨论过的模型，以提供更广泛的反馈并确定被审核者的优势和劣势。 在 360 度系统中，直接绩效评估、来自工程师同事（同行）、经理、客户和其他来源的评估被制成表格，以生成单一结果，并以易于理解的格式呈现给被评估者。

由于这种方法可确保来自多个来源的反馈，并且涵盖的不仅仅是基本的绩效指标和技能，因此它在许多情况下都很有用。 它提供了工程师绩效的概览，使管理层能够一目了然地获得有价值的见解。 此外，如果一个组织决定不与每个员工分享每次审查的结果，它可以改为分享 360 度反馈的结果。

这种方法评估基本的团队技能，并就工程师的表现、行为、沟通和任何其他所需标准提供团队反馈。 但是，它不适合评估技术技能、特定于单个项目的技能或细粒度的绩效指标。 由于它通常涉及许多具有不同背景和参与程度的人，因此 360 度反馈可能过于主观，无法评估软件工程师绩效的某些方面。

软件工程师绩效评估中包含的内容

为利益相关者创造价值并为他们提供可操作信息的绩效评估中应包括哪些内容？ 审查应该是全面的还是集中在短期内要处理的几个项目上？

答案取决于组织的类型和审查的范围，尽管有些点应该包含在大多数（如果不是全部）绩效审查中。

速度和迭代

开发人员完成任务的速度是任何绩效评估的重要指标，就像他们处理迭代软件开发的方式一样。 在与处理单个项目的大型团队、经常从一个项目和客户跳到另一个项目和客户的个人以及消防工作打交道时，速度和迭代至关重要。 软件工程师的落地运行能力可以决定项目的成败。

代码质量和代码审查

虽然速度是一个关键指标，但如果价格高昂，它的价值就会降低。 代码的质量必须是最重要的，并且不应该为了满足紧迫的期限而妥协。 质量较差的代码可能会在以后给团队或组织的其他成员带来麻烦。

代码审查确保有人检查其他人编写的代码。 这个过程虽然耗时，但简单明了，是确保和保持质量的好方法。 持续的代码审查使组织不必全面审查其开发人员编写的每一行代码。 代码审查员需要是高技能的人，能够识别需要注意的各种问题和关键领域，从设计和功能到样式和文档。

内部沟通与责任

沟通不是一项技术技能，但它可以深刻地影响软件工程师的工作质量。 工程师经常与他们的同行、团队领导、利益相关者和客户进行沟通，并且需要表现出高度的责任感和专业精神。

沟通不畅会破坏他们的工作质量，并使小问题升级为更大、更昂贵的问题。 专业和及时的沟通是基础，应该接受审查。 即使是最令人印象深刻的技术技能也不如承担责任和有效沟通的需要那么重要。

招聘、领导和规划

高级软件工程师和团队负责人通常在招聘中发挥关键作用，因此审查他们在这些方面的表现也很重要。 如果团队负责人做出糟糕的招聘决定，就会影响整个团队，甚至可能影响整个组织。

领导力可能难以衡量和审查，尤其是在团队成员不愿提供负面反馈的情况下。 因此，有必要确保审查过程使他们免受可能因对其上级的不雅审查而受到报复。

计划是另一个主观类别。 领导者需要确保充分规划和执行团队目标。 然而，他们在这方面的表现取决于其他团队成员，包括下属和上级。 错过目标和截止日期是明显的危险信号，但审查过程应考虑可能导致它们的一系列因素，例如，管理不善未能及时采取行动使项目重回正轨或缺乏时间或资源赶上最后期限。。

绩效评估并不容易——不要让他们变得更难

每个组织都应创建适合其特定需求的绩效评估模型。 仅仅因为谷歌或苹果正在做某事，并不一定意味着它适用于另一家公司或团队。

绩效评估需要大量计划和仔细考虑。 有必要在一方面的复杂性和彻底性与另一方面的实用性和有用性之间取得适当的平衡。 小型组织可以进行绩效评估，而不会使过程过于繁琐和困难。 同样，大型组织应尽最大努力使流程尽可能精简。

不要忘记审查审查过程本身。 无论是按季度还是按年度进行审核，在进行下一轮审核之前，请先审核最近一轮审核。 过程顺利吗？ 它是否发现了有用的信息？ 找出任何缺点，解决它们，并努力不断改进审查过程。