パフォーマンスレビューの改善

Avitoでのパフォーマンスレビューの仕組みについて、私は社内で何度も話をしましたが、この春は2つのカンファレンス( TeamLeadConfCodeFest)でも話しました 。 私たちはプロセスの改良に積極的に投資しており、多くの実験を行い、有用なデータを収集しているため、新しいパフォーマンスには常に新しいコンテンツが含まれています。 この記事の目的は、既成のボックス化されたソリューションを提供することではなく、途中で発見したすべてのプラクティスと洞察を共有することです。













TL; DR



記事は非常に膨大であることが判明しました。 注目を集めるために、ここで私が話していることのリストを示します。









はじめに



会社の業績への従業員の貢献度をどのように評価するかという問題は、おそらくほぼすべてのマネージャーを心配しています。 この問題を明確に把握することは非常にクールです。従業員の報酬を決定し、チームを互いに比較するための正直なツールを入手できます。 そして、最初の近似では、タスクはあまり複雑に見えません。







Avitoでは、目標設定にOKR方法論を使用しています。 これは、ステロイドに関するMBOのようなものです。 戦略レベルから特定のチームまで、組織全体の目標ツリーを構築します。 目標はビジネスまたはクライアントの価値を決定し、主要な結果は目標を達成するための測定可能で明白な兆候を確立します。 キットにはさまざまな原則が含まれています:野心的な目標、物質的な動機付けからの分離、宣伝、測定可能性-しかし、それは重要ではありません。







理論的には、すべてがクールに聞こえます。目標ツリーは特定の専門家に分割され、四半期ごとの結果を確認し、それらを使用して貢献度を評価します。 しかし、実際には、もちろん、これはそのようには機能しません。 チーム全体が目標を達成するために手を持っている場合、各専門家の個人的な貢献を分離し、方法論で必要とされる特定の何かで評価することは非常に困難です。 まあ、それは本当です-機能が発動して恩恵を受けた場合、これにおけるペティアのメリットはヴァシャの2倍であるとは言えません。 コミットではなく、これを考慮します。







そして、これは問題の片側にすぎません。 ほとんどの場合、従業員の活動は彼のチームだけのものではないことを忘れてはなりません。 彼はプレゼンテーションを行い、他の同僚のタスクを支援し、一般的なエンジニアリングアプローチを促進することができます。 そして、これも有益でもあり、有害でもあります。 そしてもう一つ。 さまざまな方法で目標を達成できます。 誰かが交渉する方法を知っており、関心のあるすべての人に通知し、他の人々の利益を考慮に入れます。 まあ、他の誰かが自分の頭を越えて、他のチームに干渉し、パフォーマンスだけを追いかけることができます。













標準的な状況が得られます。 理論的には、結果に基づいて人を評価することは美しいですが、実際には、額に近づくことはうまくいきません。 私はAvitoに来たときにこれに出くわしました。 私たちには多くのチームがあり、全員がOKRに取り組みましたが、特定の人々の質と有効性を評価する方法がわかりませんでした。 他社の経験を研究した結果、パフォーマンスレビュープロセスを実装する必要が生じました。これは、最初の近似では、GoogleとBadooで使用されるモデルに非常に似ていました。 Googleについては、Laszlo Bokの「Work steers」 による素晴らしいと、Badooについて読むことができます。 記事を読むか、Alexey Rybakの報告を聞いてください。 しかし、これは非常に重要であり、私たちはじっとしていませんでした。 完成したモデルに基づいて、一連の実験を行い、データを収集し、徐々に改善し始めました。







パフォーマンスレビューの仕組み









現在、四半期ごとにパフォーマンスのレビューを行っています。平均して、開始から終了まで約2〜3週間かかります。







このプロセスは、5つの主要なステップで構成されています。









自己評価



最初に、評価された従業員は自己評価を準備します。 これは、座って、過去数か月間何をしていたかを思い出すときの熟考の重要な瞬間です。 私はすぐにプロセスが長くて苦痛だと言うことができます-それは少なくとも1、2時間かかります。 毛布を取り、ココアを注ぎ、メッセンジャーで通知をオフにし、うつ病のわずかなタッチの出現に備えておくと便利です-結果がかなり動揺する可能性があることを自分で知っています。







回答者が思考の流れを簡単に操作できるようにするために、自己評価を4つのセクションに分割することをお勧めします。







最初のセクション。 役割と期待。 あなたのポジションと役割の期待の説明が含まれています。 私たちの場合、これらはConfluenceのドキュメントであり、従業員に期待されるタスクと品質の詳細な説明が記載されています。 これは、エンジニアからの機能的期待に関する情報、メンター、スピーカー、教育プログラムへの参加者、ユニットリーダー、またはそれらの役割の説明です。 リーダーのユニット-要するに、あなたがプレイしているあらゆるポジションと役割。 このデータは、回答者が正しいレビューを書き、会社があなたに何を期待しているかを理解するのに役立つことを目的としています。







2番目のセクション。 彼らは何をしましたか。 最後の評価期間の簡単な結果。 これは、関与しているすべてのプロジェクトとアクティビティをリストする重要なセクションです。 これらは、実際に影響を与えたチームの目標、取り組んだプロジェクト、基本的な機能的責任の詳細などです。 ここでは、成長と開発の計画について言及し、目的を達成するために何をしたかを強調する価値があります。 会議での講演やハッカソンへの参加などの追加アクティビティもここに追加されます。 水を注ぐのではなく、事実についてのみ話してください。 回答者の1人が評価するのに十分な情報を持っていない場合、彼はあなたから冷静にそれを得ることができます。 人々は美しい言葉ではなく、事実を大切にします。







3番目のセクション。 良かった。 ここに、あなたがあなたの主な成果と成功であると考える事実をリストします。 主に仕事の成果に焦点を当てます-プロジェクトの立ち上げ、誰かとの関係の確立、訓練された初心者のリリースに成功しました。 繰り返しますが、冗長にならず、主なものに焦点を合わせようとします。







4番目のセクション。 何が悪かった。 あなたの基本的な失敗をできるだけオープンに、あなた自身が不満なこと、そして将来修正し改善したいことをリストアップしてください。 これには、個人またはチームの前に設定された特定の目標の失敗と、個人的なミスの両方が含まれます。 また、自己批判にぶつかることはあまり価値がありません。誰も焦点をキャンセルしませんでした。







セルフレビューからの良い部分と悪い部分の抜粋を見てみましょう。 一部は発明され、一部は実際の例から取られました。







「ほぼ完全で、アプリケーションに実装する準備が整ったモバイルデザインプラットフォームの開発を開始しました。」

これは良い例です。 評価されると、関係するプロジェクトとそれがもたらした状態を明示的に示します。







「メンタリングに費やす時間が少なかったため、Ivanovを会社に入れるのが計画よりもはるかに悪いのです。」

これも良い充填の例です。 明確に定義されたミス-メンタリングにほとんど時間が費やされず、結果が強調されました-会社への新しい従業員の紹介はうまくいきませんでした。







「私も知らない...私はただ働いた、タスクをやった。」

悪い例-ここでは、原則として、すべてが明確で説明なしです-具体性も、活動を分析したり、有用であるかどうかを理解したりする欲求もありません。







「数回刈りましたが、すべてのルールのようです。」

そしてもう1つの例-評価された1つは、彼が彼の期待を完全に満たしていることを示唆していますが、完全に完璧に見えないために、「数回刈り込まれた」というフレーズが回答者の信頼を得ます。 ここでは、前の例と同じことですが、特定の事実を説明することに抵抗があるため、この人を評価する人の生活は非常に複雑になります。







回答者の定義



この段階で、評価者は回答者を選択します。 それらを4つのグループに分けます。 抽象モバイルアプリ開発者のBonesを使用することを検討してください。













1.マネージャー

最も重要な回答者は、従業員の直属の上司です。 Kostyaの場合、これはモバイルアプリ開発チームの責任者であるIvanです。 KostyaとIvanは異なるチームで働いていますが、これはVanyaが評価に参加するのを妨げません。







2.利害関係者

次の回答者グループは利害関係者です。 Kostyaの場合、これらは2人です。彼のプロダクトマネージャーであるPavelと、機能の責任者であるYegorです。 Pashaはチームの目標に関する作業の枠組みの中でKostyaと常にやり取りし、Yegorは定期的にKostyaを会議の準備とオープンソースプロジェクトの作業に関連付けます。 同じグループには、製品、他のユニットのリーダー、つまりサービスの顧客が含まれる場合があります。







3.ごちそう

通常、最大のグループはごちそうです。 Kostyaは、ここで彼が彼のタスクに取り組んでいるすべてのチームメイトを含めました-これらは、いくつかのiOS開発者、Androidおよびバックエンド開発者、デザイナー、テスターです。 過去数か月にわたって数回、Kostyaは共通のタスクでプラットフォームチームのメンバーと道を交差しましたが、彼らは比較的わずかに連携することができたため、ここに含めないことにしました。 コスティアはまた、彼が昼食やバーに行くだけの人を含めませんでした-彼の生産性の評価は、彼の仕事の成功とは関係がないことを理解しています。 コスティアは、よくやった、コスティアのようになります。







4.部下

そして、回答者の最後のグループは部下です。 コスティアは幸運で、部下はいません。 非公式の部下もここに追加する必要があります。 たとえば、あなたは一流の開発者であり、パートタイムのメンターでもあります。







プロセス開始



3番目の段階は完全にリーダーの肩の上にあります。彼は従業員から受け取ったすべてのデータを読み取り、レビューを準備して参加者に送信します。













まず第一に、リーダーは自己評価の結果を見ます。 彼は注意深く見て、すべての欠点に気付き、どの情報を追加する価値があり、どの情報を削除するかを述べ、フォームに関する追加のヒントを提供します。 頭のすべてのコメントを考慮し、修正する必要があります。







回答者のリストにも同様の手順が適用されます。 リーダーはそれをレビューし、参加者の関連性を評価し、誰かを削除または追加できます。 一般的に言えば、あなたはリーダーにこの人物またはその人物を追加した理由と、過去数か月の間に彼とどのように協力したかをリーダーに説明できるはずです。







次に、マネージャーはパフォーマンスレビュー用のツールでレビューを開始します。 すべての参加者はスラックで通知を受け取り、評価期間が始まります。







評価



ここで、考え方を切り替えて、回答者の役割に切り替えます。 Kostyaが同僚によってどのように評価されるかを見てみましょう。 彼は自己のレビューを読み、自分に関連する添付の期待とメモのリストを調べます-彼が対処し、適切に評価できる活動の側面。







このような格付けのグラデーションがあります。















現在のケースでは、これは彼のチームでの作業に加えて、モバイル開発機能と彼のすべての活動の代表としてのコスティアの活動です。 回答者は別のチームで働いており、コスティアのこの作品を評価することはできません。







評価: 「期待を下回る」



評価に関するコメント:



「助けを求める代わりに、彼は何週間も問題を掘り下げます。 さらに、彼はまだ会社をナビゲートし始めていません。」



何を始めますか:

  • プラットフォーム開発の詳細、
  • 同僚とのコミュニケーションを確立し、
  • アドバイスを求める恐怖を克服します。




やめるべきこと:

  • 夜にPSをプレイ
  • 一般的な同期について黙って、自分の視点を表現することを恐れて、
  • すべての問題を自分で解決してください。


その結果、彼はコスタに「期待以下」の評価を与えました。 同僚のコメントによると、開発者としてのKostyaの主な問題は、問題を解決するために仲間に連絡したくないということです。 2番目の問題は、会社をナビゲートできないことであり、これも期待と一致していません。







いくつかの開発のヒントが含まれています-Tannenbaumを掘り下げるのではなく、より積極的にプラットフォーム開発を研究し、同僚とのコミュニケーションを確立し、アドバイスを求める恐怖を克服します。 最後の2つのポイントは、彼のコメントと直接相関しています。 そして、「やるべきこと」セクションで、回答者は別の興味深い点に触れます-総会での沈黙、自分の視点を積極的に表現し、促進したくない。 フィードバックは建設的で有用に見えます-Kostyaのマネージャーは落ち着いて彼女と協力し始め、状況を修正するのを手伝うことができます。







次に並んでいるのは、2番目の回答者であるPavelです。 私が言ったように、PavelはKostyaが働いているチームのプロダクトマネージャーです。 ポールのコスティアの評価は、彼の活動に対するまったく異なる期待と事実に基づいています。 彼らの相互作用のタイプは完全に異なっていたので、これは絶対に正しいです。







評価: 「期待以上」



評価に関するコメント:



「コスティアは最高です。 彼はユニット計画プロセスの構築を支援し、OKRに到達するための素晴らしいアイデアを提供しました。 Kostyaがいなければ、このユニットはこの四半期を管理できなかったでしょう。」



何を始めますか:

  • ユーザーの問題に没頭し、ユーザーの特定と分析に参加し、
  • 機能横断的な活動に他の同僚を巻き込みます。




やめるべきこと:

  • 週末に仕事をする-6か月で燃え尽きるような速度で、
  • エネルギーを飲む
  • 交渉室で蒸気を吸う。


ポールの評価も非常に異なります-「期待以上」、素晴らしい結果です。 解説はまったく異なる口調で書かれており、ポールはコスティアに非常に満足しており、チームへの彼の利点の多くの例を示しています。 注-前の回答者が対処した欠陥について、ここでは一言も述べていません。 これは人間の反対側にすぎません。







ポールの開発のヒントも異なります。製品分析と機能横断的な相互作用に向けた成長です。 そして、「やることをやめる」セクションはかなり標準です-私が見たすべてのレビューの中で、2人に1人は休暇を取るか、夜または週末に仕事をやめるように頼まれます。 教訓は次のとおりです。評価に非常に異なる人々を関与させる必要があります。これは、活動のさまざまな側面についての批判を集めるのに役立ちます。







まとめ



最後の段階は再びマネー​​ジャーに完全にかかっています。 まず、受信したすべてのフィードバックを集約すると同時に、異常の有無を調べます。 マネージャーが不公平な評価に出くわした場合、マネージャーは自分でそれを調整するか、回答者に連絡してさらなる説明を求めます。 次に、cな式を使用して、最終結果が計算されます。













すでに述べたように、すべての回答者は、マネージャー、利害関係者、同僚、部下の4つのグループに分かれています。 各グループについて、平均スコアが計算され、次に平衡分布を考慮して、すべてのグループの平均が計算されます。 そして、結果の数は、すでにおなじみのカテゴリーの1つに変換されます-期待を下回って、期待を満たします...結果の評価と従業員に伝えられます。







パフォーマンスレビューを要約した後、マネージャーは従業員との会議を開き、最終評価と構造化されたフィードバックを通知します。 このフィードバックは従業員と議論されます。 この会議の結果に基づいて、通常、アクションプランが作成され、マネージャーは四半期中も従業員と協力し続け、見つかった問題を解決します。 さらに、マネージャーと従業員のレビューの評価は、会社の成長のための透明なツールになります。







パフォーマンスレビュープロセスがどのように機能するかを理解したので、詳細に移りましょう。これが本質です。







パフォーマンスレビューのプラクティス



匿名性



すべての従業員のパフォーマンスレビューを完全に開始する前でも、限られたグループで一連の実験を実施して、プロセスのさらなる開発に使用できる最初のデータセットを取得しました。 これらの実験の1つは匿名性に関するものでした。







一般に、パフォーマンスレビューの匿名性はかなり複雑なトピックです。 オフハンドで、いくつかの異なる実装方法が利用可能です。







まず、最も簡単なのは、誰もがすべてを見ることです。 各従業員は、すべての同僚からの完全なフィードバックにアクセスできます。 彼は誰が何を書いたのか、どのグレードを与えたのか知っています。 長所から-壊れた携帯電話の効果が消えます。 評価者は、レビューを離れた人の身元に基づいて、レビューが何に関連していたかを常に理解できます。 そして、あなたが理解していないなら、あなたはいつでも出て行って、個人的に詳細を見つけることができます。 マイナス面-チームの成熟度が不十分な場合、これは深刻な対立や不満を引き起こす可能性があります。 さらに、人々は問題について沈黙し始めることができ、「Cグレード」(期待に応える)と空のコメントを手に入れることを好む。







2番目のオプションは、非個人的なフィードバックであり、著者の明示的な指示はありません。 結果を従業員に公開する前に、すべての回答はマネージャーによってレビューされ、混合され、さらにクリアされます。 このアプローチにより、以前に提起された問題を解決します。 レビューの著者が不明な場合、気分を害する人はいません。 しかし、別の深刻な問題が発生します。非人格的でありながら建設的で有用なフィードバックを提供することは非常に困難です。







まあ、非常に筋金入りのオプション。 マネージャーはすべてのレビューを個別に処理し、これを「何が良かった」、「何を改善する必要があるか」という形式の一連の推奨事項にまとめます。 特別なプラスはありません-実際、これらのアプローチのいずれかを使用して、マネージャーはそのような演習を行う必要があります。 そして主なマイナス点は、コンテキストが失われることです。 マネージャーは、評価された人だけが理解できる重要な個人的な何かを見落としたり、一部の事実を誤って解釈したりする場合があります。













すべての形式で実験を行い、リストした長所と短所を特定しました。 その結果、次の方法に進むことにしました。完全にオープンなフィードバックに到達するという目標を設定しましたが、徐々にこれに進むことにしました。 最初のラウンドでは、マネージャーは常に非人道的なフィードバックを行いました。 一部のレビューは匿名化が困難でしたが、一般的には匿名性を維持することができました。 コメントに率直なゴミを書いた回答者と並行して、教育作業が行われました-複雑なケースを整理し、許容できる行動基準を決定しました。







次のラウンドで、マネージャーの決定によるレビューは、一部の従業員に匿名化されたフィードバックではなく、ほとんどの部分が匿名のままであることを示しました。 結果は優れた結果を示し、競合は1つも見つかりませんでしたが、人々はフィードバックを回答者と話し合い、質問し始め、レビューが存在する理由についてより多くの理解を得ました。







その後の各ラウンドで、私たちは徐々に多くのレビューを開き、従業員をオープンなフィードバックの文化に慣れさせました。 その結果、今ではすべての人がまれな例外を除いてすべてを見ている状態になりました。 たとえば、結成されたチームのみ、またはその他の特殊なケース。 しかし、一般的に言えば、結果の匿名性に関する決定は常にマネージャーに委ねられます。







データを操作する









レビューの最初の主要な展開の瞬間から適切なデータを収集し始めました-これは2017年の第2四半期です。 この間に、1000人の回答者から1万件以上の評価を収集しました。













最初は、レビューの回答者の数に厳密な制限を設定せず、およそ10人のしきい値を概説しました。 その結果、すべてがこの数に達しました。 理由は明らかです。実際、これは2ピザサイズのチームと、チーム外の少数の回答者です。 ここでの「テール」とは、多くのプロジェクトやコミュニケーションがかかっているマネージャー、または非常に小さなチームのエンジニアのいずれかです。













しかし、これは、あるレビュー期間に人々が付けた評価の数のヒストグラムです。 ほとんどの場合、1から11の推定値に及ぶことがわかります。 レビューの平均所要時間は約25分であるため、同僚に評点を付けるには、0.5のフォーカスファクターを考慮して、四半期ごとに6時間以内に殺す必要があることがわかります。 これはかなりの量なので、人々にとって簡単です。













次に、時間の経過に伴う推定値の分布がどのように変化したかを調べてみましょう。 これは、レビューの第1四半期の棒グラフです。 良い方向への強いバイアスがあり、4の数(「期待以上」)が3倍に近づいています(「期待に応える」)。 2つの仮説がありました-過小評価されているスーパープロが多いか、批判的に正しく評価する方法を知らないかです。













次の四半期までに、両方向に取り組みました。 自尊心のある人はポンプでくみ上げられて新しいポストに移され、多数の前向きで不十分な評価で際立った人と一緒に、彼らは追加の作業を行いました。 さらに、今回は、マネージャーが改訂版のレビューを送ることにもっと注意を払った。













興味深いことに、最後の四半期では、スケジュールはあまり変わっていません。 平均マークは文字通りかなり減少し、ヒストグラムの形状も変わりません。 原則として、一定の安定期に達し、さらに実験を行うことで、グラフの現在の形式からの偏差を調べることで、それらの影響を評価できます。













いくつかの興味深い実験がありました。 たとえば、グループ間の対立または敵意の存在の研究について。 すべての回答者がチームのメンバーに与える平均評価と、他のチームのメンバーに与える評価を比較しました。 その結果、実際には深刻な矛盾はなく、平均して、両方のグループの推定値はほぼ等しく、間隔の終わりに最大0.5ポイントの矛盾があります。 人々はチームを過大評価し、他のチームを過小評価する傾向があるという仮説は確認されていません。













私がテストした別の仮説は、回答者が評価に与える役割の影響です。 そして、ここですべてが確認されました。 違いは、プロセスの開始時に最も顕著であり、マネージャーと部下の評価が0.5ポイント異なっていました。 現時点では、違いは解消されていますが、マネージャーは引き続き最も厳しいレビュアーであり続けます-原則として、ステータスに批判的思考があります。







これらの結果は、第1四半期の格付けの分布と強く相関しています。 管理者は当初、評価へのアプローチ方法についてより明確な理解を持っていたことがわかります。 方法論全体を残りの従業員に十分に提供できなかったため、「予想を上回る」見積もりに偏りがありました。







評価プロファイル



各四半期の結果によると、優しさ、正義、または勤勉という3つの評価プロファイルのいずれかに対応する3つの明るい回答者グループを区別しています。







各プロファイルを見て、優しさから始めましょう。 人々は以下の条件でこのグループに分類されます:4つ以上の評価を与え、平均スコアは4.1よりも高く、評価の中に単位やデュースはありません。 通常、このプロファイルに入る理由はいくつかあります。 たとえば、人は本当にとても親切で、批判を書くのは難しいです。 または、回答者の期待が低いので、平均的なレベルでの作業でさえ、彼らはやりすぎだと思われます。 そして、もちろん、評価されている人たちの輪全体がクールなパフォーマーを指していることは本当にあり得ます-しかし、これはむしろ、ルールの例外です。







正義は同じ話ですが、逆も同様です。 2.7未満で、平均以上の評価を与えず、4つ以上のレビューを行った人を探しています。 少なくとも私たちの場合、それらの数はかなり少ないとすぐに言わなければなりません。 ところで、このグループに参加することは、現在のチームで仕事をするのが苦手という事実のマーカーになります。







最後のプロファイル-勤勉さ-は最悪のケースです。 ここには、比較的多くのレビューを行った人が含まれており、平均スコアは3、分散はゼロです。 さて、追加のフィルターとして-残されたコメントのサイズを見て、平均的なボリュームよりはるかに少ないコメントを書く人に焦点を当てます。 この一連の特徴は、他の人のレビューを気にせず、平均的な評価を与え、簡単な返信を挿入して先に進む人を明確に示しています。







評価プロファイルに加えて、他の多くの異常にも注目しますが、その中には非常に明白なものがあります。たとえば、より珍しいコメントなど、多くのコメントを書く人はほとんどいません。













1つの例は、縮退グループの戦略の出現の結果を調べることです。 計算式によると、評価者のすべてのグループの重みは等しくなります。 グループ内では、平均評価を考慮します。 したがって、グループ内の人が小さいほど、その参加者の評価の割合が大きくなります。 次に例を示します-3つのグループがあります。 5人の同僚、3人の部下、1人の利害関係者が人を大切にしています。 その結果、利害関係者の評価は、最終的なものをほぼ1.5ポイント変更し、それを非常に悪い状態から非常に良い状態に移行させることができます。 今、それを遡及的に見ていきますが、レビュー自体の開始前でも状況を平準化する予定です。







グレードの正規化



当社のパフォーマンスレビュープロセスは、それを実施するマネージャーと強く結びついています。 彼はすべての既知の異常に留意し、フィードバックが妥当性と逸脱の存在を調べる必要があります。 これで混乱するのは非常に簡単だったので、次のレビューの後、正規化された評価などを導入しました。













, , , . , , , 3 (« »).







, . , , — 4,3. - , . , 2.7.







. , , , . .













. — 2,4. , . — 4, .







— performance score . — , . .













.











. , , . , , . , , . . , , . — , , . .







, « ». . , , , . , . , . , , . — , 3.977 , 62, 80% , .









, , — .













.

, .

: « ».

: « . — ».







— . , - , — .







— , . , , . , , , .













.

, .

: « ».

: « 2014 , , . , ».







. . Performance review — , .







. -, « » « ». -, . — .













.

, .

: « ».

: «—».







, , — . « » .







. , «».













.

, .

: « ».

: « , ».







, , . , , « » .







, , . , . , . , , .













.

.

: « ».

: « , ».







, , , . , — , -, - , , .







« » — , . — .







ツール



Google Forms









, MVP. . — , , self review, . , , , . , .













— . , . — , . , , . , , . , .













— performance review . — -, , - — . - , , .







, , — , , . . , , , , .







: | | .







自動化



, . , , , . - , . — , , , .













performance review , . .









performance review , . , , .







. , , . , — - . .







— , , « » « ». , , . A/B , , .







— , . , . .







, , . , .







おわりに



, . , .















, — . performance review, . , , . , , , . , — !







参照資料






All Articles