特にHabrとこの記事の読者の中には、従業員だけでなく、部長もいます。 私たちの経験から判断すると、従業員の相互に適切な評価のタスクは、彼らにとってしばしば重要です。 そのため、この記事は多くの人にとって有用で興味深いものに思えます。 ここでは、スキル評価の実践を共有します。読者の皆さん、ディスカッションに参加してください。
だから、順番に。 ある会社での経験をお伝えします。 たとえば、コンサルタントの評価と言います（ただし、この手法は他の専門家にも非常に適しています）。 最初は、従業員の資格に関する対話が基礎となるように、出力は従業員の評価と自己評価を含む表である必要があることを理解していました。 同時に、評価方法論の作業の最初の段階で、議論の余地がある多くの問題に直面しました。
コンセプト
評価の一般的な概念はすぐに特定されましたが、最初の質問がすぐに現れました。 たとえば、コンサルタントには特定の能力がありますが、彼の仕事の結果、解決された問題が表示され、能力は表示されません。 では、これらのうち、最終的に評価する方が便利なのはどれですか？
最初に、念のため、用語を定義します。 ここで、「能力」とは、さまざまな資質、知識、スキルを指します。 たとえば、自動化システムの機能に関する知識、インタビューを行うスキル、注意力などの品質。 「タスク」は一連のコンピテンシーで構成されています。 たとえば、コンサルタントの「役割指示の開発」のタスクは、自動化システムの機能に関する知識、ITサービスを管理するためのプロセスを設計するスキル、ドキュメントを開発するスキル、および時間管理の品質で構成されます（たとえば、このタスクに関連する能力の簡略リストが提供されます）。
タスクとコンピテンシーの評価に関しては、最初にリーダーと従業員がコンピテンシーを評価します（従業員の場合、これは自己評価です）。 しかし、議論と最終評価は、それらからコンパイルされたタスクについて既に行われています。 この場合、必要に応じて、コンピテンシーのレベルに戻り、別のコンテキストで従業員の評価を分析できます。
そこで、方法論の構造についておおよその理解を得ました：リーダーによる評価のための能力のリスト、従業員による自己評価のための能力のリスト、および能力がタスク全体に散在し、同時にリーダーと従業員の評価が見える最終要約表。
次に、特定のポジションへの従業員の任命または異動の決定をより透明にするために、各ポジションの目標値（最小しきい値）を入力する必要があることに気付きました。 したがって、次のステップはターゲット値の配置でした。 最初の反復では、この貼り付けはほとんど直感的でした。 以下の反復は、問題のポジションの従業員をテストすることから成りました。 これにより、各ポジションの各タスクの各コンピテンシーの成績を明確にすることができました。
目標の設定に加えて、実施されたテストでは、対処すべき別の重要な問題が明らかになりました。 自己評価とリーダーの評価を比較すると、前者の方がはるかに高いことがわかりました。 これは主に、従業員が自分の資質の多くを知っていたという事実によるもので、職場ではまだそれを示すことができませんでした。 そして、ここで新たな疑問が生じました。「評価の計算をこの状態のままにすると、従業員の評価中に対立、誤解、長い議論が避けられなくなります。 同時に、従業員がマネージャーが気付く可能性のある資質のみを評価することに同意する場合、彼の他の有用なスキルについて学ぶことはできません。 それを行う最良の方法は何ですか？」
長時間の議論の後、従業員の自己評価シートで、評価される各基準の回答オプション「はい」と「いいえ」を含む個別のフィールド「実用アプリケーション」を強調することにしました。 したがって、従業員のスキルの最終評価は、このスキルが適用された場合でも変更されず、実際の適用がなかった場合は係数が減少すると見なされます（図1を参照）。
図1.「実用的なアプリケーション」フィールドの使用例
従業員の証明書を考慮に入れて同様の状況が発生しました-それらを考慮する方法は？ 見積もりの計算をさらに複雑にしたくはありませんでした。さらに、多数の異なる係数が病院の平均気温につながり、従業員の知識について具体的なことは何も言えませんでした。 そのため、この場合、追加の係数を導入するのではなく、証明書が取得された最終的な知識とスキルの要約表で色の強調表示に限定することにしました。 しばらくして、得られた評価方法に触発されて、証明書のレベルに応じて多色の強調表示を行いました。 :-)
証明書の会計処理とスキルの実用化について考えると、おそらく最も論争の的になる質問に出くわしました。後で、繰り返し質問しました。「技術を詳しく説明し、複雑にするとき、いつ停止する必要がありますか？ どのような場合に、さまざまなタスク、さまざまなグレーディングスケールのパラメーターにさまざまな重みを追加する必要がありますか。また、いつ統一指標を使用すれば十分ですか。
正確な答えが見つからなかったため、運用後の期間については、マトリックスの最初のバージョンの次の評価機能に限定して、さらなる検討を行うことにしました。
- 評価は、少なくとも2人の従業員とその上司によって実施されます。
- 従業員の能力が最初に評価されます。
- 最終評価は、タスクのコンテキストで計算されます-コンサルタントのコンピテンシーの関連付け。
- 各コンピテンスは、異なる係数を持つ異なるタスクに含まれます-この特定のケースでの重要性に応じて。
- 評価尺度は、まれな例外（0から2または0から4）を除いて、0から3の値によって決定されます。
- 成績を設定する際の意見の相違や誤解を減らすために、各能力評価について、その正確な定義が策定されました。
- 従業員証明書の可用性は、証明書のレベルに応じて最終表で強調表示されます。
- スキルを実際に適用するかどうかは、係数を使用して考慮されます。
ファイナルテーブルの例を以下に示します（図2を参照）。 その上で、開発した評価機能の実装を明確に見ることができます。
図2.要約表の例
欠点
もちろん、コンサルタントの能力を評価するこのアプローチの完全な客観性と普遍性について話すことはできません。 そのような形式化に内在する多くの潜在的なリスクを認識しなければなりません。 まず、評価の柔軟性が低下します。これにより、すべての従業員を特定のフレームワークに合わせてカスタマイズし、同様のコンサルタントを「スタンピング」できます。 この可能性はおそらくそれほど悪くはありません。特に、従業員が最終的に相互交換可能になり、彼らが何を目指しているかを正確に理解するという事実を考えると、おそらくそうです。 一方、個人の開発は制限され、具体的な何かの有能なコンサルタントは、認識されていない専門家のままになるリスクを負います。
第二に、二重性があります：一方で、既知の評価基準はパブリックドメインにあるため、評価の主観性を減らしますが、他方では、得られた推定値の分散を増やします（特定の固定スケールの使用のため）。
最後に、第三に、形式化されたシステムを作成する場合、別の重要なリスクがあります-プライマリエラーのリスクです。 たとえば、サマリーピボットテーブルで重みまたはリレーションシップを設定するときに表示される場合があります。 ただし、このようなエラーを検出するのは難しい場合が多くありますが、その結果は深刻なものになる可能性があります。
同時に、コンサルタントの資格を評価するための手順全体をより客観的にするために、そのようなマトリックスが評価の唯一の要因になり得ないことを覚えておくことが重要です。 評価された従業員との議論と経験は、記入されたマトリックスが与える見解を補完します。 したがって、従業員の資格を最も完全かつ客観的に理解するには、それを評価できる人々の輪を決定する必要があります。 これにより、上記のすべてのリスクと欠点が最小限に抑えられます。また、経営陣、HR、および会社の推定従業員の間の会話において、能力評価マトリックスが便利な補助ツールに変わります。
結論
作業の結果とこの記事をまとめると、マトリックスの最初のバージョンは非常に便利で便利で直感的であることがわかりました。 いくつかの欠点は避けられませんが、マトリックス開発の主な目的は達成されました。
今、私たちは新しい、より野心的な目標を見ています。 最初にコンサルタントを評価するためにマトリックスが開発された場合、現在、能力やその他の機能的役割を評価するための汎用ツールを作成することを計画しています。 それで、親愛なる指導者と私たちの他の同僚は、私たちの経験を議論し、共有しましょう。 :-)