编者注:本文由我们的编辑团队于5/1/23更新. 它已被修改，以包括最近的来源，并与我们目前的编辑标准保持一致.

当考虑不同的软件工程师绩效评估方法时, 一个问题必然会出现在脑海中:为什么我们需要使用多个评审模型? 简单的回答是，软件开发是一个复杂的过程, 多方面的过程，通常涉及在不同团队中工作的数十个人.

高管和利益相关者并不总是对每个开发人员的资格和职责有深入的了解, 尤其是在大型组织和团队中. 这就是绩效评估应该留给员工的原因 技术熟练的专业人员 能够理解每个软件工程师的职责, 能力, 技能, 以及在整个软件开发过程中的作用.

那么，进行软件开发人员绩效评估的正确方法是什么呢? 答案取决于很多因素，比如组织的规模和目标, 以及工程师表现的更细致的方面.

管理层表现检讨

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

自20世纪下半叶大公司采用绩效考核制度以来，它已经走过了漫长的道路, 但是, 业绩回顾的历史 是否超出了本文的范围, 支撑一些绩效评估模型的行为心理学也是如此. 而不是, 本文主要关注该过程的实际方面, 从管理层的职责开始.

尽管方法可能因组织的规模和类型而异, 一些基本原则适用于大多数审查情况.

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

管理层需要彻底计划审查过程，并确保每个参与者都意识到他们的责任.

• 审查过程需要提前定义好, 允许经理和工程师有充足的时间参与并提交他们的反馈. 最后一分钟的反馈可能价值更低，因为它可能是为了赶在最后期限前匆忙提交的.
• 管理层需要沟通目标, 目标, 以及评审过程对工程师和其他利益相关者的价值. 良好的沟通应该消除对过程的疑虑，并提高评审的质量.
• 审核模板或表单需要事先达成一致, 它们的设计应该考虑到寿命. 在理想的情况下, 它们不应该在审查周期之间改变, 确保随着时间的推移，审查的结果具有可比性.
• 该方法应旨在尽量减少偏见，并确保高度的一致性. 每个经理和工程师都有自己做某些事情的方式, 但一致性可以防止个人及其偏见或偏好过度影响结果.
• 当采用同行评审和自我评估时, 管理层需要确保评审过程的完整性.

减轻偏见和处理可疑的绩效评估

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

• 在这个过程的所有阶段都需要考虑到能力和期望. 笼统地评估每个团队成员可能会导致经理或同事提交过于积极或消极的评估. 假设一个同行提交了一份有问题的评审，因为他们不熟悉某个工程师的具体能力. 在这种情况下，管理层需要进行干预，并确保这样的评估不会扭曲整体得分.
• 管理者也可以拒绝或委托他人进行审查. 例如, 如果一个特定的经理与一个小工程师团队的工作脱节, 他们不应该直接评价团队的表现. 他们可能缺乏进行平衡和详细审查所需的背景和知识.
• 缺乏对特定个人或其职责的深入了解的审阅者可能会被迫提交一份绩效评估以勾选复选框, 这样就产生了一个没有多少实质内容，也没有给评审过程增加多少价值的评审.
• 有偏见和片面的评论也会扭曲结果. 如果一个经理审查了一个违背自己意愿雇佣的团队成员，或者一个团队处理了一个没有得到某个经理认可的项目, 他们的评论可能不客观. 另外, 审稿人可能会“挑选”特定的性能指标，使个人或团队看起来更好，因为这符合他们的利益.

理想情况下，经理和高管能够客观地进行评估，但偏见是存在的. 然而，意识到它们可以减轻它们的影响.

请记住，经理审查软件工程师的方式可以为经理的表现和专业精神提供有价值的见解.

软件工程师同行绩效评审

与经理评审相比，同行评审有几个优势, 尽管有一些权衡要记住.

同事往往比管理者更能评估彼此的表现. 他们对队友的工作有了更多的了解. 他们经常在相同的项目上工作，并与相同的人合作, 因此，他们往往能很好地掌握团队动态和个人工程师的能力.

然而，偏见也会影响同行评议. 偏见可以表现为积极的一面, 基于友谊, 或消极, 由个人问题或团队成员之间的竞争引起的. 群体思维也会影响评审过程, 尤其是在紧密结合的团队中, 因为人们可能倾向于为他们的队友打掩护. 考虑到这些可能性, 同行评议模板和调查问卷的设计需要减少偏见, 尽可能关注具体的能力和客观标准. 团队成员的结果如何与关键绩效指标挂钩，往往比关于个人特质的主观问题或其他开放式问题更有价值.

潜在的偏见提出了一个关键问题: 同行评议应该匿名吗?

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

匿名vs. 公众反馈

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

• 匿名可以鼓励开放和原创思维. 如果团队中的大多数人对某件事或某个人都持积极态度, 反对意见可能不受欢迎. 匿名评论者可以提供不同的观点，而不会引起同事的反感.
• 匿名反馈可能包含有价值的信息. 假设一个专业人员为同一个人编译匿名和公开的反馈. 他们很有可能会引用匿名的意见来提出他们可能不愿意从公开审查中引用的问题. 一些额外的点可以有很大的价值, 特别是如果问题在团队其他成员发现之前就提出了. 这种早期预警给管理层和评审人员一个机会来处理和纠正新发现的缺点, 以免他们升级成更严重的事情.
• 保持关系是匿名反馈的另一个重要方面. 人们对负面评论的反应不同, 因此，保持匿名可以保持团队成员之间的凝聚力，防止摩擦.
• 如果审查不是强制性的, 通常更容易说服人们参与匿名评论.

然而，匿名同行评议也有一些缺点:

• 匿名鼓励坦诚的评论, 然而，它可能会促使一些人滥用它，通过不诚实的评论来推动他们的议程. 有一种风险是，有人会利用匿名的身份，仅仅基于个人喜好来诋毁同事. 相反, 匿名可以用来给那些不应该得到好评的人提供好评, 因为审稿人可以选择保护他们的长期同事和朋友, 可能会以牺牲其他团队成员为代价.
• 公众评论更有分量. 假设一个人从几十个匿名评论者那里收到几行负面反馈. 很有可能这种反馈不会像从一个值得信任和尊敬的团队成员那里得到同样的反馈那样有影响力. 员工更有可能认真对待来自亲近之人的反馈.
• 在小型组织中，匿名性可能很难保证. 每天从5个同事那里收到4条评论的人可能会知道是谁提交了哪条评论. 这可能导致人们将评论视为公开的, 这样就破坏了匿名化的全部意义.
• 虽然让人们提交公开评论可能更具挑战性, 评论者更有可能认真对待他们, 知道他们的名字是附加的. 因此, 他们可以花更多的时间来提供细节, 客观的, 平衡反馈，而不是把审查过程当作一种形式.

自我评价

自我评估是另一种在绩效评估中常用的方法. 与其他评审模型一样，它们可能存在争议.

管理者通常会要求员工定期进行自我评估, 如果目标是使用评估来跟踪进度和随时间的变化，那么哪一个有意义. 很少有组织要求每月进行评估, 但年度, 一年两次, 甚至季度自我评估也很常见. 问 软件工程师 定期提供反馈是有益的, 尤其是在与高度自治的团队和个人打交道时. 审核员可以使用这些定期评估来沟通需要解决的潜在问题, 解释他们是如何克服具体挑战的, 详细说明他们如何以及为什么提高他们的表现, 找出阻碍他们提高表现的因素.

减轻自我评估的局限性

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

组织如何减轻缺点? 管理者可以设计自我评估表格和问题来考虑偏见，并将其影响降到最低，记住以下几点:

• 避免开放性的问题，因为这会让你有太多的主观性.
• 关注有形的结果，而不是主观的目标和价值观.
• 对评审人处理的关键职责给予更高的评价.
• 强调关键绩效指标和可量化的目标.
• 重申组织的核心价值，并相应地评估绩效.

允许工程师解决可能不包括在自我评估表格中的问题, 提供注释部分.

360度评估

360度反馈过程结合了之前讨论的模型，以提供更广泛的反馈，并确定审稿人的优点和缺点. 在一个360度的系统中, 直接的工作表现评估, 来自工程师同行的评论, 经理, 客户, 其他来源被制成表格，以生成单个结果，并以易于理解的格式将其呈现给审阅者.

因为这种方法确保了来自多个来源的反馈，并涵盖了比基本绩效指标和技能更多的内容, 它在很多情况下都很有用. 它概述了工程师的工作表现, 让管理层一眼就能获得有价值的见解. 除了, 组织是否应该决定不与每个员工分享每次评审的结果, 它可以分享360度反馈的结果.

这种方法评估基本的团队技能，并为工程师的表现提供团队反馈, 行为, 沟通, 以及任何其他期望的标准. 然而, 这不是评估技术技能的理想方法, 特别是那些特定于单个项目的, 或粒度性能指标. 因为它通常涉及许多具有不同背景的人，以及与审稿人的参与程度, 360度反馈对于评估软件工程师表现的某些方面可能过于主观.

软件工程师绩效评估应该包括哪些内容

开发人员绩效评估应该包括哪些内容，从而为涉众产生价值，并为他们提供可操作的信息? 评估应该是全面的还是集中在近期的几个项目上?

答案取决于组织的类型和审查的范围, 虽然有些要点应该包括在大多数绩效评估中.

速度和迭代

开发人员完成任务的速度是任何性能评估的基本指标, 这也是他们处理迭代软件开发的方式. 在处理大型团队处理单个项目时，速度和迭代是至关重要的, 经常从一个项目和客户跳到另一个项目和客户的人, 消防工作. 软件工程师快速开始贡献的能力可以成就或破坏一个项目.

代码质量和代码审查

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

A 代码评审 确保有人检查其他人编写的代码. 这个过程, 尽管耗时, 是一种确保和维持质量的直接的好方法吗. 持续的代码审查使组织不必审查开发人员编写的每一行代码. 代码审查人员需要是高度熟练的个人，能够识别各种问题和需要注意的关键领域，如设计和功能, 风格和文档.

专业的沟通

沟通不是一种技术技能, 但是它会深刻地影响软件工程师的工作质量. 工程师与他们的同行交流, 团队领导, 利益相关者, 客户也需要表现出高度的责任感和专业精神.

沟通不畅会破坏他们的工作质量，让小问题升级为更大、代价更高的问题. 如果工程师直接与客户合作， 沟通问题 是否能够瓦解整个项目并促使客户寻找其他地方.

专业及时的沟通 是基础的，应该接受审查吗. 即使是最令人印象深刻的技术技能，也没有承担责任和有效沟通的需要重要.

招聘、领导和规划

高级软件工程师和团队领导经常参与其中 招聘中的关键角色，所以回顾他们的表现的这些方面也是很重要的. 如果团队领导做出了糟糕的招聘决定, 这会影响整个团队，甚至整个组织.

领导力很难衡量和评估, 尤其是当团队成员不愿意提供负面反馈时. 因此, 有必要确保审查程序保护他们，使他们免受可能因对上级不利的审查而遭到报复.

规划是另一个主观范畴. 领导者需要确保团队目标的充分规划和执行. 然而, 他们在这方面的表现取决于其他团队成员, 下属和上级. 错过目标和最后期限是明显的危险信号, 但审查过程应考虑一系列可能导致这些问题的因素, 比如管理不善，未能及时采取行动使项目回到正轨，或者缺乏时间或资源来满足最后期限.

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

每个组织都应该创建一个适合其特定需求的绩效评估模型. 仅仅因为谷歌或苹果在做一些事情, 这并不一定意味着它适用于不同的公司或团队.

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

别忘了 审查审查过程本身. 是否进行季度或年度审查, 在进行下一轮审查之前，回顾最近一轮的审查. 整个过程顺利吗? 它是否发现了有用的信息? 识别任何缺点，解决它们，并努力不断改进审查过程.