エンジニアリング管理

ソフトウェアエンジニアのパフォーマンスレビューの説明

ソフトウェアエンジニアのパフォーマンスレビューへのさまざまなアプローチを検討するとき、1つの質問が頭に浮かぶはずです。なぜ複数のレビューモデルを使用する必要があるのでしょうか。簡単な答えは、ソフトウェア開発は複雑で多面的なプロセスであり、さまざまなチームで数十人の個人が関与することが多いということです。

経営幹部や利害関係者は、特に大規模な組織やチームでは、各開発者の資格や責任について常に深い知識を持っているとは限りません。これが、業績評価を任せるべき理由です。技術的に熟練した専門家ソフトウェア開発プロセス全体における各ソフトウェアエンジニアの責任、能力、スキルセット、および役割を理解することができます。

では、業績評価を実施する正しい方法は何ですか？答えは、組織の規模や目標から、エンジニアのパフォーマンスのより詳細な側面に至るまで、多くの要因によって異なります。

管理パフォーマンスレビュー

マネージャーは、エンジニアリングパフォーマンスレビューで主導的な役割を果たします。多くの小規模な組織では、レビューを実施するのは直属の上司だけかもしれません。大企業では、レビュープロセスがより複雑で、さまざまな役割や部門のより多くの人が関与することが多いため、これは通常は当てはまりません。大規模な組織は、小規模な組織よりもピアレビューや自己評価を頻繁に使用する傾向があります。

20世紀後半に大企業が採用して以来、業績評価は大きく進歩しましたが、業績評価の歴史一部の業績評価モデルを支える行動心理学と同様に、この記事の範囲を超えています。代わりに、この記事では、管理者の責任から始めて、プロセスの実際的な側面に焦点を当てています。

アプローチは組織の規模とタイプによって異なる場合がありますが、すべてではないにしても、ほとんどのレビュー状況にいくつかの基本的な信条が適用されます。

マネージャーが業績評価に取り組む必要がある方法

経営陣は、レビュープロセスを徹底的に計画し、関係するすべての人が自分の責任を認識していることを確認する必要があります。

レビュープロセスは事前に定義する必要があります。これにより、マネージャーとエンジニアは十分な時間をかけて参加し、フィードバックを送信できます。締め切りに間に合わせるために急いで提出される可能性があるため、直前のフィードバックは価値が低い可能性があります。
管理者は、レビュープロセスの目標、目的、および価値をエンジニアやその他の利害関係者に伝える必要があります。良好なコミュニケーションは、プロセスに関する不安を取り除き、レビューの質を向上させるはずです。
レビューテンプレートまたはフォームは事前に合意する必要があり、長寿を念頭に置いて設計する必要があります。理想的には、レビューサイクル間で変更してはならず、レビューの結果が時間の経過とともに比較可能であることを保証します。
方法論は、バイアスを最小限に抑え、高度な一貫性を確保することを目的とすべきです。すべてのマネージャーとエンジニアには特定のことを行う独自の方法がありますが、一貫性があるため、個人とその偏見や好みが結果に過度に影響を与えることはありません。
ピアレビューと自己評価を採用する場合、経営陣はレビュープロセスの完全性を確保する必要があります。

バイアスの軽減と疑わしいレビューの処理

レビュープロセスに対する管理者の影響は非常に大きいため、マネージャーは、プロセスを損なう可能性のある潜在的なバイアスやその他の問題に注意する必要があります。計画段階が適切に実行され、プロセス全体が適切に設計されている場合でも、管理者は特定の望ましくない慣行を排除し、プロセスの整合性を確保する必要がある場合があります。

競争優位の例ビジネスプラン

プロセスのすべての段階で、能力と期待を考慮する必要があります。幅広いブラシですべてのチームメンバーをレビューすると、マネージャーや同僚が過度に肯定的または否定的なレビューを提出する可能性があります。同僚が特定のエンジニアの特定の能力に精通していないために疑わしいレビューを提出したとします。その場合、経営陣が介入し、そのようなレビューが全体的なスコアを歪めないようにする必要があります。
管理者はレビューを拒否することもできます。特定のマネージャーがエンジニアの小さなチームの仕事から切り離されていると仮定します。その場合、バランスの取れた詳細なレビューに必要なコンテキストと知識が不足している可能性があるため、チームのパフォーマンスを直接レビューするべきではありません。
特定の個人またはその職務についての深い知識が不足しているレビュー担当者は、チェックボックスをオンにするためにパフォーマンスのレビューを提出する必要があると感じる場合があります。そのため、内容が少なく、レビュープロセスにあまり価値がないレビューが生成されます。
偏った一方的なレビューも結果を歪める可能性があります。マネージャーが希望に反して採用されたチームメンバーをレビューした場合、またはプロジェクトを処理するチームが特定のマネージャーによって承認されなかった場合、レビューが客観的でない可能性があります。あるいは、レビュー担当者は、特定のパフォーマンス指標を「チェリーピック」して、個人またはチームの見栄えを良くすることができます。

理想的には、マネージャーとエグゼクティブは純粋に客観的な考え方でレビューを行うことができますが、バイアスが存在します。ただし、それらを認識することで、それらの影響を軽減できます。

マネージャーがソフトウェアエンジニアをレビューする方法は、マネージャーのパフォーマンスとプロフェッショナリズムに関する貴重な洞察を提供できることを覚えておいてください。

ピアレビュー

ピアレビューには、マネージャーのレビューと比較していくつかの利点がありますが、覚えておくべきいくつかのトレードオフがあります。

同僚は、お互いのパフォーマンスを評価するために、マネージャーよりも有利な立場にある傾向があります。彼らはチームメイトの仕事にもっとさらされています。彼らは同じプロジェクトに取り組み、同じ人々と協力することが多いため、チームのダイナミクスと個々のエンジニアの能力をよく理解している傾向があります。

ただし、ピアレビューもバイアスの影響を受ける可能性があります。バイアスは、友情に基づいてポジティブに見えることもあれば、個人的な問題やチームメンバー間の競争によって引き起こされるネガティブに見えることもあります。 Groupthinkは、特に緊密に編成されたチームでは、レビュープロセスに影響を与える可能性があります。これは、人々がチームメイトをカバーする傾向があるためです。これらの可能性を考えると、ピアレビューテンプレートと質問票は、バイアスを軽減する方法で設計する必要があり、可能な限り特定の能力と客観的な基準に焦点を合わせます。チームメンバーの結果が主要業績評価指標にどのように追跡されるかは、個人の特性に関する主観的な質問やその他の自由形式の質問よりも価値が高くなる傾向があります。

バイアスの可能性は重要な問題を提起します： ピアレビューは匿名にする必要がありますか？

匿名レビューと公開レビューの両方をサポートするために有効な議論を行うことができますが、さまざまな組織スキームとチームサイズを検討することが重要です。したがって、ほとんどの組織は匿名のレビューを支持していますが、明確に正しいまたは間違った答えはありません。

匿名vs.パブリックフィードバック

匿名フィードバックの利点を詳しく見てみましょう。

匿名性は、開放性と独創的な思考を促進することができます。チームのほとんどが何かまたは誰かについて前向きに感じている場合、反対意見は人気がない可能性があります。匿名のレビューアは、同僚に敵対することなく、異なる視点を提供できます。
匿名のフィードバックには、貴重な情報が含まれている可能性があります。専門家が同じ人物の匿名および公開のフィードバックを編集しているとしましょう。公開レビューから引用するのを嫌がる可能性のある問題を提起するために、匿名の意見を引用する可能性があります。特にチームの他のメンバーに明らかになる前に問題が提起された場合は、いくつかの追加のポイントが大きな価値を持つ可能性があります。この早期警告により、経営陣とレビュー対象者は、新たに特定された欠点に対処して修正する機会が与えられ、より深刻な問題にエスカレートすることがなくなります。
関係を維持することは、匿名のフィードバックのもう1つの重要な側面です。人々はさまざまな方法で否定的なコメントに反応するため、匿名性を維持することで、結束を維持し、チームメンバー間の摩擦を防ぐことができます。
レビューが必須でない場合は、通常、匿名のレビューに参加するように人々を説得する方が簡単です。

ただし、匿名のピアレビューにはいくつかの欠点があります。

匿名性は両方の道を切り開きます。それは率直なレビューを奨励しますが、それでも一部の人々はそれを悪用して不誠実なレビューを通じて彼らの議題を宣伝することに拍車をかける可能性があります。誰かが自分の匿名性を利用して、個人的な好みだけに基づいて同僚を弱体化させるリスクがあります。逆に、匿名性は、おそらく他のチームメンバーを犠牲にして、長年の同僚や友人を保護することを選択できるため、匿名性を使用して、それに値しない人々に肯定的なレビューを送信できます。
公開レビューはより重要になる可能性があります。個人が数十人の匿名のレビューアの1人から数行の否定的なフィードバックを受け取ったとします。そのフィードバックは、信頼され尊敬されているチームメンバーから同じフィードバックを得るほど影響力がない可能性があります。従業員は、近くにいる人からのフィードバックを真剣に受け止める可能性がはるかに高くなります。
一部の組織、つまり小規模な組織では、匿名性を確保するのが難しい場合があります。毎日一緒に仕事をしている5人から合計4件のレビューを受け取った人は、誰がどのレビューを提出したかを知ることができるでしょう。これにより、人々はレビューを匿名以外のものとして扱う可能性があり、したがって、レビューを匿名化するという全体的なポイントを無効にする可能性があります。
公開レビューを投稿してもらうのは難しいかもしれませんが、レビュー担当者は自分の名前が付けられていることを知って真剣に受け止める傾向があります。したがって、レビュープロセスを形式的なものとして扱うのではなく、詳細で客観的でバランスの取れたフィードバックを提供するためにより多くの時間を費やすことができます。

自己評価

自己評価（または自己評価）は、業績評価で一般的に使用されるもう1つのアプローチです。他のレビューモデルと同様に、彼らは独自の論争を提示することができます。

ノードjsが使用される場所

自己評価は通常、スタッフの管理者が定期的に必要とします。これは、時間の経過に伴う進捗状況や変化を追跡するためにスタッフを使用することが目標である場合に意味があります。毎月の評価を義務付ける組織はほとんどありませんが、年次、半年ごと、さらには四半期ごとの自己評価が一般的です。エンジニアに定期的にフィードバックを提供するように依頼することは、特に高度な自律性を持って活動しているチームや個人を扱う場合に有益です。レビュー対象者は、これらの定期的な評価を使用して、解決する必要のある潜在的な問題を伝え、特定の課題をどのように克服したかを説明し、パフォーマンスを改善した方法と理由を詳しく説明し、パフォーマンスの改善を妨げている原因を特定できます。

自己評価の限界を緩和する

残念ながら、自己評価にはいくつかの重大な欠点があり、バイアスが最も明白なものです。一部の人々は、彼らのパフォーマンスを誇張したり、彼らの仕事の欠陥を明らかにすることを拒否したり、彼らのパフォーマンスを妨げる問題を挙げたりする可能性があります。他の人は自分自身に批判的すぎるかもしれません。いずれの場合も、結果は歪曲される可能性があります。

組織はどのようにして欠点を軽減できますか？管理者は、バイアスを考慮してその影響を最小限に抑えるために、自己評価フォームと質問を設計できます。

主観が多すぎるような自由形式の質問は避けてください。
主観的な目標や価値観ではなく、具体的な結果に焦点を合わせます。
レビュー対象者が処理する重要な責任をより重視します。
主要業績評価指標と定量化可能な目標を強調します。
組織のコアバリューを繰り返し、それに応じてパフォーマンスを評価します。

エンジニアが自己評価フォームに含まれていない可能性のある問題に対処できるようにするには、コメントセクションを提供します。

360度評価

360度のフィードバックプロセスでは、前述の多数のモデルを組み合わせて、より広範なフィードバックを提供し、レビュー対象者の長所と短所を特定します。 360度のシステムでは、直接の業績評価、同僚のエンジニア（ピア）、マネージャー、クライアント、およびその他のソースからのレビューが表にまとめられ、単一の結果が生成され、わかりやすい形式でレビュー対象者に提示されます。

360度フィードバックパフォーマンスレビューモデル

このアプローチは、複数のソースからのフィードバックを保証し、基本的なパフォーマンス指標とスキル以上のものをカバーするため、多くのシナリオで役立ちます。エンジニアのパフォーマンスの概要を提供し、管理者が一目で貴重な洞察を得ることができるようにします。さらに、組織がすべてのレビューの結果を各従業員と共有しないことを決定した場合、代わりに360度フィードバックの結果を共有できます。

このアプローチは、基本的なチームスキルを評価し、エンジニアのパフォーマンス、行動、コミュニケーション、およびその他の望ましい基準に関するチームフィードバックを提供します。ただし、技術的なスキル、個々のプロジェクトに固有のスキル、または詳細なパフォーマンス指標を評価するのには理想的ではありません。通常、さまざまなバックグラウンドとレビュー対象者との関わりのレベルを持つ多くの人々が関与するため、360度のフィードバックは主観的すぎて、ソフトウェアエンジニアのパフォーマンスのいくつかの側面を評価できない場合があります。

ソフトウェアエンジニアのパフォーマンスレビューに含めるもの

利害関係者に価値を生み出し、実用的な情報を提供する業績評価には何を含める必要がありますか？レビューは包括的である必要がありますか、それとも短期的に取り組むべきいくつかの項目に焦点を当てるべきですか？

答えは組織のタイプとレビューの範囲によって異なりますが、すべてではないにしても、ほとんどのパフォーマンスレビューにいくつかのポイントを含める必要があります。

速度と反復

開発者がタスクを完了する速度は、反復型ソフトウェア開発を処理する方法と同様に、パフォーマンスレビューにおいて重要な指標です。単一のプロジェクトに取り組んでいる大規模なチーム、あるプロジェクトやクライアントから別のプロジェクトにジャンプすることが多い個人、および消防活動を扱う場合、スピードと反復が重要です。ソフトウェアエンジニアが着実に実行できる能力は、プロジェクトを成功または失敗させる可能性があります。

コード品質とコードレビュー

速度は重要な指標ですが、価格が高い場合は価値が低くなります。コードの品質は最優先事項である必要があり、厳しい期限に間に合わせるために妥協してはなりません。品質の低いコードは、後でチームの他のメンバーや組織に頭痛の種を引き起こす可能性があります。

にコードレビュー誰かが他の誰かによって書かれたコードを検査することを保証します。このプロセスは時間がかかりますが、簡単で、品質を確保および維持するための優れた方法です。継続的なコードレビューにより、組織は開発者によって作成されたコードのすべての行を完全にレビューする必要がなくなります。コードレビューアは、設計や機能からスタイルやドキュメントに至るまで、注意が必要なさまざまな問題や重要な領域を特定できる高度なスキルを持つ個人である必要があります。

ホールフーズ価格対ウォルマート

社内コミュニケーションと責任

コミュニケーションは技術的なスキルではありませんが、ソフトウェアエンジニアの仕事の質に大きな影響を与える可能性があります。エンジニアは、同僚、チームリーダー、利害関係者、およびクライアントと定期的にコミュニケーションを取り、高度な責任とプロ意識を示す必要があります。

コミュニケーションが不十分だと、仕事の質が低下し、小さな問題がより大きく、はるかにコストのかかる問題にエスカレートする可能性があります。専門的でタイムリーなコミュニケーションは基本であり、レビューの対象となる必要があります。最も印象的な技術スキルでさえ、責任を持って効果的にコミュニケーションする必要性ほど重要ではありません。

採用、リーダーシップ、および計画

シニアソフトウェアエンジニアとチームリーダーはよく遊びます採用における重要な役割、したがって、パフォーマンスのこれらの側面も確認することが重要です。チームリーダーが採用決定を下すと、チーム全体、場合によっては組織全体に影響を及ぼします。

特にチームメンバーが否定的なフィードバックを提供することを躊躇している場合、リーダーシップの測定とレビューは難しい場合があります。したがって、レビュープロセスが、上司の不愉快なレビューに対する報復の可能性から彼らを保護することを保証する必要があります。

計画は別の主観的なカテゴリです。リーダーは、チームの目標と目的の適切な計画と実行を確実にする必要があります。ただし、この点での彼らのパフォーマンスは、部下と上司の両方の他のチームメンバーに依存します。目標と期限を逃したことは明らかな危険信号ですが、レビュープロセスでは、プロジェクトを軌道に戻すためのタイムリーなアクションを実行できなかった不十分な管理や、必要な時間やリソースの不足など、それらを引き起こした可能性のあるさまざまな要因を考慮する必要があります。締め切りに間に合います..

業績評価は簡単ではありません-それを難しくしないでください

各組織は、特定のニーズに合わせたパフォーマンスレビューモデルを作成する必要があります。 GoogleやAppleが何かをしているからといって、それが別の会社やチームで機能するとは限りません。

業績評価には、多くの計画と慎重な検討が必要です。一方では複雑さと徹底性、もう一方では実用性と有用性の間で適切なバランスを取る必要があります。小規模な組織は、プロセスを煩雑で困難にすることなく、業績評価を実施できます。同様に、大規模な組織は、プロセスを可能な限り無駄のないものにするために最善を尽くす必要があります。

することを忘れないでください レビュープロセス自体をレビューする 。四半期ごとにレビューを行う場合でも、年ごとにレビューを行う場合でも、次のレビューに進む前に、最新のレビューを確認してください。プロセスはスムーズに進みましたか？それは有用な情報を明らかにしましたか？欠点を特定して対処し、レビュープロセスの継続的な改善に努めます。