IT企業でパフォーマンスレビューを整理する方法：Badooエクスペリエンス

こんにちは、Habr！ 私の名前はAlexey Rybakです。私はBadooの開発責任者です。 2月、モスクワのBadooオフィスでTechleadsミーティングが開催され、パフォーマンスレビュープロセスについて話しました。 この記事は私のプレゼンテーションに基づいています。

パフォーマンスのレビューは非常に物議を醸すトピックです。 ロシアでは、ソフトウェア企業ではKPI、「測定」、またはパフォーマンスレビューは機能しないだけでなく、完全に有害であるといまだに広く信じられています。 このカテゴリ性は常に私を驚かせましたが、このトピックを詳細にカバーするという最終決定は、RBC自体に関する記事を読んだ後、私の中で成熟しました。

この記事では、ABBYYのネガティブな経験について説明し、プログラマーを測定しない方が良いというかなり一般的な結論を導きますが、興味深い仕事を与えて放っておけばいいだけです。 そして、彼らは言う、すべてが素晴らしいだろう。 そして、結局のところ、ABBYYは、その経験が議論として引用されている唯一の会社とはほど遠いものであり、 Microsoftに関するはるかに有名な物語もあります 。

客観性に関するこれらの否定的な例の議論の余地のない価値は、Performance Reviewが正常に機能しているGoogle 、 Facebook 、および他の多くの企業の例で補完されるべきです。 これは、レビュープロセスが成功した場合と失敗した場合の両方で実装できることを示しています。 したがって、この記事の主な目的は、作業レビューにつながるアプローチの1つについて話すことです。 Badooでは、このアプローチがほぼ7年間機能しており、この機会を利用して、このアプローチで「感染」した妻ソコロフ（元Google、元バドゥ）に感謝したいと思います。

この投稿では：

• エンジニアリングマネージャーの観点から、レビューが必要な理由について説明します。
• Badooでこのプロセスがどのように発生するかを簡単に説明します。
• この会社があなたの会社にとって必要かどうかを理解するために答える必要がある質問を策定します
• そしてコメントであなたの質問にお答えしたいと思います。

会社のレビューと価値

パフォーマンスレビューは、非常に簡単な場合でも、組織の有効性を高めるための体系的な方法の1つです。 機械的には、可能な限り簡素化して、レビューは、会社の「弱い」場所と「強い」場所を特定し、「弱い」場所を引き締めることができる遡及的なプロセスです。 各従業員は自分の結果について話し、「評価」を受け取り、注意を払う必要のあるプロジェクトまたは個人的資質についてコメントします（一般的な推奨事項の形で、特定の検証済みの目標の形で改善する場合があります）。

Badoo値

ただし、レビューを開始する前に、Badooと当社の価値についていくつかの言葉を話す必要があります。 各企業には、外部または内部の何らかの種類の資産があり、それらは変更できないか、変更が非常に困難です。 そのような「境界条件」の例としては、活動の方向性、会社がどのように収益を上げるか、企業文化においてどのような価値が普及するかなどがあります。 異なる企業では、「効果的であること」とは異なることを意味するため、レビューを価値観から切り離して議論することは実際的な意味を持ちません。

Badooは、新しい人と出会うための出会い系アプリとソーシャルネットワークを開発しています。 当社の主力製品は「デート」ニッチにありますが、社会的発見の分野でプロジェクトを開発しています-関心のある人々を近くで検索します。 ある意味では、Badooは多くの異なるアプリケーションが作成される基盤となるプラットフォームを表しています。 内部では、プロジェクトは非常に複雑になる可能性がありますが、外部はすべて非常にシンプルに見えます。 世界中の非常に多くのチームが同時に同じプロジェクトを行っています。 したがって、私たちが働く市場では、非常に高速である必要があります。機能を非常に迅速に確認し、機能しない場合はテストし、機能しない場合は閉じ、機能する場合は、何かをひねって実験サイクルを繰り返します。 これは、当社の文化全体を定義します。 そして、エンジニアのすべての痛み：彼らが言うように、どこにでもストローが置かれているとき、彼らはこの速度と快適なゆったりとした開発の間のバランスを見つけるのに十分難しいです。

オーディエンスでプロジェクトをテストするプロセスで要件が変わり始めると、アイデアレベルではほとんど何も変わっていないように見えます。ただし、一部の構文文は他の構文文に置き換えられますが、 設計レベルでは、変更にはインターフェイスの深刻な処理が必要になる場合があり、プログラミングレベルでも処理が終了することがあります仕事の週。 そのため、エンジニアは要件の変更に敏感であり、チームが高いモチベーションを維持するには、これらの変更に対する特別なサポートが必要です。 エンジニアのモチベーションの要素の1つは著者のものであり、エンジニアが長年行ってきたことを誇りに思って「長期にわたる」プロジェクトに取り組む方がより快適であるため、かなり短い時間で行う必要のあるクールなことを手放すのは難しい場合があります。しかし、彼らは撃ちませんでした。

したがって、スピードとエンジニアリング値のバランスが会社の文化を決定します。 そして、私たちはすべての従業員がその価値を定期的に説明するよう努めます。 外からの人には、彼らは野barに見えるかもしれません。 これは、彼らがすべてのエンジニアにとって理想的であると言うことではありません：それはキャラクターに大きく依存します。

この段階では、バリューシステムは3つのコンポーネントで構成されています。

値1：配信

私たちにとって最も重要なことは、ユーザーへの実際の製品の配送です。 ある程度までは、すべての視聴者に使用することがどれほど完璧であっても気にしません。 あらゆる種類の機能フラグを最大限に活用して、プロセスの何かを測定するために、クラスターの一部または対象ユーザーで実行するようにします。 視聴者の一部にとって機能がどのように機能するかがわからない場合は、「理解できる」部分のみに機能を配置する方が簡単です。完全に役に立たない場合はどうでしょう。

プログラマーを実質的に関与させずにさまざまなアイデアを広めるために、A / Bテストの実行に多くの時間が費やされます。 まず、実験的な方法でソフトウェアを作成します。これは、「譲渡できない」ソフトウェアの開発者の利点です（厳密には、モバイルアプリストアでの公開サイクルが遅いため、速度が大幅に制限されますが、サーバー開発とWeb /モバイルWebは非常に迅速にリリースできます。通常はリリースされます。週末の前日を除き、厳密に1日に2回）。

値2：品質

2番目は品質 -品質です。 私たちのアプローチの1つは、品質とQA全体が、エンジニアやプログラマーと一緒にプロセスを所有する組織の一部であり、それ以上のものであるということです。 したがって、私たちはロールのバランスの取れた分布を取得します。なぜなら、プログラマー（特に高速で作業するプログラマー）は、それらを制限するもののために単に詰まっており、QAの形でバランスが取れていないためです-開発から完全に独立している-私たちは低製品を得るリスクを抱えています品質。 そして、これは私たちが目指していることではありません。

値3：保持

最後に、上で言ったように、私たちにとって人々が会社に来て、会社に長く留まることは非常に重要です。 この値は保持 、保持です。 私たちの入場基準は非常に高く、人を見つけるのは簡単ではありません。

会社が小さいとき、誰もがお互いを知っており、チームとして働き、誕生日やその他の祝日を祝い、さらには贈り物を交換するだけで、すべてが簡単な方法で自然に起こります-会社の規模は誰もが知っている規模-家族、友人のグループ、クラスまたは学生グループに適合するためです しかし、会社（会社）が成長し始め、従業員の数が増えると、「通常の」方法では、年に数人を雇うのではなく、すぐに仕事をやめ、数十人を雇う必要があります。 そして、成功の主なパラメーター（主に開発段階）は、人をどれだけ速く成長させ、雇用し、維持できるかです。 したがって、有能で効率的な従業員の雇用と維持の問題は、当社にとって非常に重要です。

レビューが必要な人とその理由は？

パフォーマンスレビューに戻りましょう。 どんなに優秀な人が会社で働いていても、成長するほど、やり取りは複雑になります。 モデルの形で会社を表す場合、ある部分から別の部分に多くの条件付き矢印があると、そのような分岐構造が得られます。 会社が大きくなればなるほど、これらの矢印が多くなり、これらの矢印の損失が増えます-相互作用、コミュニケーションに。

あなたが小さな会社を持っている場合、1人で十分です-リーダー、愛好家-誰もが走り回り、「点火」することができます。 会社が大規模である場合、技術エージェントの「レイヤー」を作成することが非常に重要であり、できれば互いに同期し、それぞれがその分野の問題を解決します。 このスキームで何かがうまくいかない場合-あいまいな目標、弱い非アクティブなリード、曲がりくねった権力、緩慢な協力、または敵意と妨害行為さえ引き起こします-生産性が低下し始め、特に無視された場合、会社は単に「悪化」し始めます。

したがって、レビューとは、そのような「崩壊」に体系的に対処できるプロセスです。 このレビューは万能薬ではありませんが、会社全体で定期的にパフォーマンスチェックを行う方法の1つと考えています。 そして、小さな「税」（ボーナスシステム）を犠牲にしてそれを行います。

Badooは10年以上前から存在しており、私たちにとって重要なのは、私たちの人々が長く私たちと一緒にいることです。 何人かはここで9年から10年働いています。 私たちは、常に従業員の期待に遅れないようにし、生活の中で何が起こっているのかを知るよう努めています。 もちろん、彼らの期待は常にリーダーの地位と一致するとは限りませんが、少なくとも定期的なやり取りを保証し、従業員に会社内で成長する機会を提供します。 社会全体に投影すると、最高の代表者が社会をリードし、リードする機会があれば幸いです。 そして、社会の最も活発な代表者のための社会的エレベーターの欠如は、これらの人々がせいぜい無関心であり、最悪の場合革命的な気分になりやすいという事実につながる可能性があります。

しかし、「レビュー」に戻ります。 これはプロセスであり、何かすべきことがどこにあるかを示すフレームワークの一部です。 ここで重要な質問は、他の人々を大切にし、フィードバックを与えるだけでなく、プロジェクトに関する詳細な情報を受け取る人々の存在です。

とりわけ、このレビューは私が上で述べた期待を更新します。 それが終わるたびに、リーダーとチームのメンバーの間で会話が行われます。 会社が急速に成長し、元のITマネージャーがマネージャーになったとき、人々がこれらの定期的な会話、コミュニケーション、行われた仕事に対する感謝の定期的な表現の意味を理解することは重要です。このプロセスは偶然に任されるべきではありません。 まず第一に、会社の従業員を維持することは非常に重要です。 誰もがこれに向かっているフレームワークがある場合、そのような相互作用の数と「感謝」の数は着実に増加しています。 そして、この数字は会社にとって非常に重要です。

残念ながら、一部の組織では、レビューはボーナスシステムから切り離されて行われます。ほとんどの場合、それは「見せるため」でした。 これは悪くて効果がありません-それは必然的に何らかの励ましにつながるに違いないと思います。人々は最終的に何かを得るためにこのプロセスに参加しなければなりません。

だから、レビュー：

• 「停止」する場所を定期的に表示します。
• 成功（または失敗）について話します。
• 長期的および短期的な期待を実現し、「良い」を教えます。
• 定期的に「ありがとう」と言って、欠陥に気づかせます。
• 少しの「税」のすべての喜び。

レビューは悪くて良い

悪いレビューについてのいくつかの言葉。 最悪なのは、それがあまりにも官僚的で複雑な場合です。 「それは常に官僚的です」とあなたは言います、そしてあなたは正しいでしょう。 しかし、ここでは、すべての場合と同様に、対策が必要です。

悪いレビューのもう1つの特性は、無関係です。 たとえば、ずっと前に行われたものに対してボーナスが支払われると、フォーカスはすでに失われているため、定性的に情報を収集したりフィードバックを受け取ったりする機会はなくなります。 この場合、人々は間違いなくレビューを不公平と考えるでしょう。 そのような人々の大部分は常にそこにいることに注意してください-それはすべての人を完全に満足させるためにうまくいかないので、コンセンサスに達することが非常に重要です。

最後に、悪いレビューには明白な価値が含まれておらず、それに参加する意味はありません。 これらの値の多くが存在する可能性がありますが、それでも主なもの（あなたはどう思いますか？）お金です。

良いレビューは何ですか？ まず第一に-可能な限りシンプル。 絶対にあらゆる状況に適用可能でなければなりません。 さらに、分析対象にできるだけ近い、関連性があり、望ましいものである必要があります（ボーナスコンポーネントについて話している場合、またはフィードバックを収集している場合）。 そして私たちのプロジェクトは一定の期間（非常に長い間、条件付きで1ヶ月、何かをしてから2週間、さらに2つ）存在するので、私たちはそれが生産でどのように生きているかを見て、最終的には完全に変更する必要があると判断しましたこの場合、タイムレビューをシフトするのは非常に間違っています。

良いレビュー

• シンプル;
• あらゆる状況に適用可能。
• 高速/関連性があり、定期的。
• 明らかです;
• いいね（$）。

レビューの構成

このレビューは、ある種のフレームワークに関するプロセスと考えています。 何で構成されていますか？ 3つの部分：

• 仲間-同僚;
• プロセス自体のレビュー。
• はしご-キャリアレベル。 ブラケットだけでなく、それらに結び付けられた給与プラグ。

レビューは複雑なプロセスであり、誰かが責任を負う必要があります。 理想的には、人事スペシャリスト、管理機能を持つ人。 正しいレビューはいくつかの段階で行われますが、私たちが発見したように、それは常に一種の官僚主義であり、それ自体では動きません-誰かが絶えず人々をプッシュし、残っているものを見て、システムをある状態から別の状態に移さなければなりません。

プロセス自体は、成績の発行で構成されています-成績。 レビュー期間の評点（良い/そうでない）、または専門職の成長の進捗に関するグローバルな評点があります。 グレーディングスケールの形成にはさまざまなアプローチがありますが、一般的にそれらはすべて特定の期待に基づいて構築されます。

非常に単純な数式があり、トリッキーなKPIを使用した素晴らしいオプションがあります。 私は単純さの原則を固守しているので、「良い」程度または「期待に応える」程度のスケールを構築することが最善だと思います。 たとえば、従業員が期待を完全に満たしている、または改善のための提案をいくつか持っている、またはそれらを満たしていない、またはその逆が期待を超えている、または昇進に値するほど期待を超えているなどです。 昇進はフレームワークの長期的な部分であり、人をキャリアのはしごに乗せることができます。

大企業でのキャリアのはしごは、多くの場合、非常に長く、副社長1番、副社長2番などの多数の番号があります。 Badooでは、よりシンプルなシステムを実践しており、多くのソフトウェア企業と同様に、エンジニアにマネージャーのキャリアパスとエンジニアのキャリアラダーの両方を移動する機会を与えています。 これを規制する文書の最も重要なコンポーネントの1つは、従業員の期待に応えることです。 彼が専門家として成長したい場合、このはしごのレベルについて説明します。 したがって、人は自分のキャリアのはしごのレベルを理解しています。 これはかなり退屈な話ですが、従業員の数が多い企業はそれなしではできません。

会社にもキャリアレベルがある場合、給与フォークを定期的に確認する必要があります。 これは、チームまたは外部のコンサルタントが収集したデータを分析することにより行われます。 多くの場合、分析はあまり有益ではありませんが、たとえば、従業員の昇進や交渉の実施、カウンターオファーの発行など、何らかの方法で賃金を変更するためのガイドラインを提供します。

プロセス自体を確認する

レビュー手順とは何ですか？ 評価の対象が以前の約束または何らかの計画のデータである慣行があります。 私たちは、人々が何をしようとしているのかを事前に伝えることを決して提供しません。計画は、人の制御を超えた理由で変更される可能性があり、彼は動揺し、レビューは不公平であってはなりません。 各従業員が記入するフォームでは、最も重要な結果のリストを作成するだけで、ピアを選択することが提案されます。

原則として、報告期間中に、人は3/5/10プロジェクトに取り組み、それらを示します。 人々は、何が生産されているのか、極端な場合は完了しており、開発サイトで既に作業しているプロジェクトの部分だけを示すようにお願いします。 したがって、私たちはもう一度言います：みんな、主なことは完全に完了したタスクであり、疲労の程度を評価するのではなく、最終的な結果のみを評価します。

長期的なタスクに取り組む従業員のためのOKR（目的とキーの結果）があります。 計画したことと実行したことを比較することもありますが、一般的に、これらの指標はレビューから解放されます。 繰り返しますが、これは非常に重要です。深刻な刺激を引き起こす可能性があるからです。 Badooは非常にダイナミックな企業であるため、このアプローチを使用することはできません。 したがって、事実についてレビューが行われます。これとそれが行われます。

仲間

評価を取得するには、まず同僚からフィードバックを収集する必要があります。 フレームワークの最も重要な部分はピアです。 従業員は、同僚、プロジェクトで作業した同僚、タスクをテストしたテスター、やり取りした製品チームのメンバー（マネージャー以外）を選択します。 その後、マネージャーは同僚を見て次のように言います。「聞いて、なぜここに一人のQAエンジニアがいないのですか？ あなたには重要な仕事があり、良い（またはあまり良くない）フィードバックがありました。 完全性のためにQAエンジニアのレビューを受けたいと思います。」 特定の調整プロセスがあり、マネージャーは従業員を追加または削除できます。

さらに、「撤去」はかなり一般的な話です。極端な場合、全員が宴会に加わると、従業員のモチベーションがゼロになりがちな官僚制になります。 宴会は3〜5回であることが望ましい。 極端な場合は7つですが、私の意見では、7つはすでにたくさんあります。

ピアは、行われたことを見て、評価を行い、コメントを書きます。 さらに、彼らはコメントとして、すべての人にアクセス可能で、プライベートに書く機会を持っています。 さらに、これはすべて収集され、マネージャーは評価を行います。

校正

しかし、それだけではありません。 先は重要なプロセス-キャリブレーションです。 Badooでは、次のように機能します。ほとんどすべてのマネージャーが1つの部屋に集まり、評価を検討し始めます。 重要なポイント（評価が高すぎる、低すぎる、高すぎる、低くなった）があり、マネージャーの視点を議論し理解する必要があることがすぐにわかります。 このミーティング中に情報が交換され、私たちにとって何が良いのか、何が悪いのか、何が良い結果なのか、何が期待されているのか、何が素晴らしい結果なのかを決定します。 人が成長するとき、私たちは彼が彼の給料を増やし、異なるレベルを与え、私たちのシステムの中に異なるタイトルを入れる必要があると言います。

個人的な会話

そして、それだけではありません！ 主なものは1対1の会話で、マネージャーはチームの各メンバーと必ず保持する必要があります。何が起こったのか、なぜ、何が予想されているのか、何を変更する必要があるのか​​を伝えるためです。

これがフレームワークの一般的な仕組みです。

ところで、Badooには2つのオフィスがあります。1つはモスクワに、もう1つはロンドンにあり、両方とも開発中です。 2011年以降、モスクワのオフィスで私たちが引っ越して成長したとき、チームの数は変わりませんが、ロンドンのチームは成長しています。 そして最初に、モスクワでレビューを開始し、このプロセスをテストしました。何とどのように合意し、マネージャー間の同期を達成し、この評価が何を意味するのかを自分で決定しました。 その後、ロンドンオフィスが接続されました。

今では非常に大きく、レビューは2つの都市で並行して行われています。もちろん、それらをすべて一緒にまとめることはできません。 私たちは、大規模なチーム全体を相互に機能するチームに分割し、個別に調整しようとしています。 通常、別々にモスクワ、別々にロンドンになりますが、かなりの数のチームが2つの都市に分散されているため、すべてのチームがキャリブレーションに参加する必要があります。

問題を確認する

問題1：ボーナス

最初に遭遇した問題は、ボーナスに対する異なる態度です。 ここには2つのアプローチがあります。 1つのアプローチ（特に西洋で人気があります）は、ほぼ保証された年間ボーナスに基づいています。年間ボーナスの割合として、それはあなたにとって非常に多く、すべてがうまくいけば、全額支払われます。 質問があるか、いくつかのKPIが確立されている場合、彼らが言うように、オプションは可能です...一般に、このアプローチでは、ボーナスは通常、完全にまたはほぼ完全に支払われます-つまり、ボーナスの変更は明らかに「罰」です。 しかし、従業員は収入のこの部分が彼に保証されると期待しているため、それをプレイしようとするのが難しくなります。

別のアプローチを選択しました。 従業員全体が会社の期待を満たせば、そのような年間ボーナスを受け取ると言います。 しかし、彼はこれらの期待を超えることができます。 したがって、非常に良い成績と悪い成績の両方を得ることができるフレームワークを使用します。

「罰」は、率直に言って仕事をしていない人だけに必要だと信じる人は何でしょうか？ 彼らはこのフレームワークで最大の評価を与えようとします。 最大スコアはボーナスを2倍にします。 ですから、彼らがすべてが好きで、すべてが正常である場合、これは正常な評価であり、すべてが期待を満たしていることを伝えることが非常に重要です。 同様に、従業員と話す必要があります。 一般に、これは非常に重要です-ボーナスを管理する必要があります。レイジーマネージャーは単純に最大のボーナスを提供するため、システムは効率を改善するだけでなく、逆に減衰を強化するように働きます。

ところで、テキストの説明に加えて、短い録音に使用する番号もあります。 そして、これは私たちにとって問題です。 人が学校の成績のカテゴリーで考えている場合、彼は考えます：「なぜ私は最大スコアを持っていないのですか？ 最大にする必要があります！ 私は常に優秀な学生でした、私はクールです。 なぜ私の評価が最もクールではないのでしょうか？」誰もがそのような考え方の変更に取り組む必要があります：マネージャーとエイチャー。

問題2：評価アルゴリズムを見つける

次の問題は、単純な「推定アルゴリズム」を見つける試みです。 ほとんどのプログラマーは、分析の性質上、最大評価を取得するための明確なスキームを構築しようとします。 さらに、管理者はこのアプローチを採用し、この評価またはその評価をどのように、なぜ行ったかについて独自のストーリーを発明し始め、それによって自分自身の責任を軽減します（私ではありません！

このような「分析」動作の別の例。 給与の見直しを行うたびに、一部のマネージャーは常にこう言います。「この従業員は中央値ではありません。 それは不公平です-あなたは彼を中央値に引き上げなければなりません！」 しかし、このアプローチに従えば、結果として、従業員の給与が不釣り合いに増えて成功する可能性があります。 実際、この中央値には最初から非常に大きな間違いがすでにあります。 したがって、中央値は非常に大まかなガイドラインであり、特に「プルアップ」する必要はありません！ しかし実際には、多くの要因を組み合わせて分析する必要があります。 まず、人の成功と、その人が会社で長い間働いていた場合、この人の給与が数年にわたってどのように増加したか。

プログラマーが分析ツールを使用してこれまたはその評価を試みているという事実は、多くの問題に関連しています。 数式で直接表現される非常に複雑なKPIがある場合、人々は単に高い指標を得るために指標を増やし始める可能性が高くなります。「ああ、今はこの官僚制度をハッキングします！..」-手をこすります。 そのため、フレームワークは分析ツールを使用する機会をできる限り少なくする必要があります。

陳腐な言い方をします。会社が大きくなればなるほど、異なる部門間のやり取りは少なくなります。 そして、より多くの人々が誰にも何も話す義務はないと信じています-彼らは単に「自分自身」を動かし、いくつかの小さな州を形成しました。 問題？ もちろん。 そしてこれに対処する唯一の方法は、すべての関係者にコミュニケーションの必要性を説明することです。 誰かがまったく重複していないと考えている場合、他の誰かと別々にレビューを行う可能性を検討する価値があります。オフィスで調整しないでください。

さらに、企業が大規模になるほど、特にプロモーションでは、キャリブレーションプロセスが難しくなります。 人々は単にこれに気付いていないかもしれません。 そして、一部には、一般的に、会社の構造単位の活動の説明はあまり効果的ではなく、これに対処する必要があることを示唆しています。

問題3：評価とレベルのインフレ

次のポイントはインフレです。 インフレの見積もりとインフレレベルを区別します。

インフレーションの見積もりでは、すべてが非常に簡単です-原則として、通常の範囲で発生します。 期待を超えるものとは何ですか？また、「完全に準拠した」期待とはどう違うのですか？ 私の立場では、一定の数のプロジェクトがあり、それらがすべて予定通りにまたはわずかに遅れて完了した場合（最大25％-しかし、単一のルールはありません）、これは期待を超えています。 締め切りが通常破られていると言うのは私にとってではありません。 :)一部のマネージャーは異なるアプローチを採用しています。 しかし、いずれにせよ、期限が迫るとすぐに、これは、どの期限が設定され、最終的にすべてが完了したかについての情報を含む何らかの種類の文書がレビュー手順に入ることを意味します。 これ自体は非常にクールです-締め切りに責任を負わせます。

インフレ水準との戦いはより困難です。 要するに、上位レベルは通常あまり明確ではありません。 たとえば、専門家。 それ自体では、説明なしで、これはかなりあいまいな表現です。 マネージャーは、人々が成長し、成長していることを理解していることがわかります。 今、彼らはすでに専門家レベルの価値があります-つまり、昇進する必要があります。 一部の専門家を他の専門家と比較し、絶えず説明を改善するか、少なくとも互いに話し合うことが非常に重要です。これは特定のレベルを意味します。

この点でBadooが従うべき例であるとは言えません。 一方では、このシステムを形式化しようとしていますが、他方では、システムに触れてレベルをもう少し詳しく説明し始めるとすぐに、従業員は期待に間違いを犯し始め、「私はこれをすべてやります、価値があります！ 何が間違っているのですか？」したがって、レベルのインフレとの戦いは、ほとんどの場合、各レベルのより詳細な説明ではなく、より良いキャリブレーションによって解決されます。

この意味で、紛争解決手順は非常に重要です。 調整するとき、人が休んだときに状況が発生する可能性があります-それがすべてですが、プロセスは動作するはずです。 最も効率的な方法を使用しているかどうかはわかりませんが、現在のルールは次のとおりです。 報告期間内に作業の評点を与えただけであれば、たとえそれがあまり公平ではないと考えていても、この評点をより多く発行するマネージャーを信頼します。 そして、従業員を次のレベルに昇進させることについて話していて、これに反対する十分な数の人々がいる場合、私たちはこの過半数をより信頼します。 論理は明確です。人がチームで働いている場合、マネージャーは彼をやる気にさせる方法をよく知っています。 しかし、マネージャーが従業員を昇進させると、彼はシステム全体に影響を与え始め、この人が大まかに言ってよくやっていることを他の人に見せ始めます。 そして、これが不公平に発生すると、システム全体に対する信頼が大きく損なわれます。

したがって、この従業員の仕事を観察する時間を提供する十分な数の人々がいる場合、彼の立候補は次回考慮されます。

もう1つのポイント：レビューには常に2つの要素があります。 一方では、短期間で起こることのない専門的な成長があります-それには何年もかかり、社会的なエレベーターとキャリアのはしごに関するこれらすべての話は、従業員の専門的なレベルの変化に結び付けられるべきです。 , - , “” , – - . : - , , , .

. . , , , . , , , — . どのように機能しますか？ , , , . , , , – .

,

, ? . , . , «» , , , .

, , . , , . ? , – .

. , . , , . “ ” – - . – : , , – .

– . , , . , . , , , , … : , , .

(, , ), , “” – . .

, , , ( ). , – , HR-. , .

おわりに

, .

, , – , . "" “” , .

KPI? , ? R&D ? , – , , .

, , ? , “ ” . “” .

, , . – . . – “” . .

他社のレビューシステムの仕組みについて詳しく知りたい場合は、Laszlo Bokの本「Jobs Steers！」を読むことをお勧めします。いくつかの章では、Googleのパフォーマンス評価システムについて詳しく説明しています（Googleのプロセスはさまざまな方法で繰り返されます）。

どのような問題に遭遇しましたか？コメントでこれを議論しましょう。