KPI、またはチーム自殺手当

このメモを書くのに費やされた：

• 旅行のための68,338キロメートル。
• メール通信の場合は72時間。
• 30人のチームでの実験の場合、423人時。
• レポートの準備と会議での講演に88時間。
• アフターパーティーで賢い人々と会話するための17杯のコーヒー。
• このテキストの入力とバグの編集に約25時間かかります:)。
• 死ぬまで、拷問を受けたコピーライターが私の下書き、録音物を解体せざるを得なかった。

たくさんのお金と時間。 おそらく、（神経、時間、お金の面で）最も費用がかかったのは自分のチームでの実験だったので、思い出すのは非常に面倒です。 しかし、それについては以下で詳しく説明します。

遅かれ早かれ、おそらく、すべての監督は公平性を払うことを望んでいます。 仕事のために。 そして今、多くの人がKPI（主要業績評価指標）を実装しようとしています。 これは次のように機能します。ビジネスオーナーとして、従業員に特定の目標を設定します。 彼らはプロセスの目標を達成するか、達成しません。 達成した人はパン（現金ボーナス）を受け取ります。

このアプローチの意味：公平に支払うこと。 どれだけうまくいったか-たくさん受け取った。 正直で、論理的で、素晴らしい！

それは論理的です：

• 営業担当者は、売上高の割合を割り当てる必要があります。 オオカミは空腹でなければなりません。 （はい、このアプローチを適用することは「あなた自身に追加の税金を課す」ことを意味するという別の意見があります。しかし、私に関しては、すべてここで公平です:-)）。
• オフィスプランクトン-給与。 それらの安定性は、存在にとって非常に重要な条件です。

しかし、クリエイティブユニット（デザイナー、プログラマー）では、すべてがはるかに複雑です。

私たちは最近、「クリエイティブユニットの仕事に関連してKPIをどのように使用しますか」というトピックについて、国内の主要なデジタル代理店およびWebスタジオのリーダーを対象に調査を実施しました。



一部の企業（15％）はKPIを使用して、プログラマーとデザイナーの作業の有効性を評価しています。

現在、企業の約25％がKPIを実装しているか、企業内での抵抗に対応しているか、単純化されたスキームに取り組んでいます。

企業の約30％は、マネージャーの主観的な評価に基づいて賃金を支払います。 むしろ、30％がこれを認めています;-)
残りの30％は認識されません。

最も興味深いのは、多くの人がKPIを実装しようとしたか、現在試みていることです。 そして、あまりうまくいきません。 これは、「KPIが悪い」という意味ではありません。 不十分な調理食品は不可能です。 このKPIを調理する方法がわからないだけでしょうか？

しかし、統計によると、圧倒的多数が実装に問題を抱えています。 そして、誰もが共通の問題を抱えているという疑いがあります。 それを理解してみましょう。

KPIを実装するときに最初に直面しなければならないのは、チームの抵抗です

問題が発生します： KPIを実装するとき、開発者にとって最も重要なことは何ですか？

同僚の間でいくつかの実験と調査を行った後、6つの主な理由を特定しました。

1. ノベルティの恐怖。 誰もがイノベーションを完全に恐れており、それが悪化する（お金が減る、仕事が増えるなど）と考えています。
2. 不透明なレイアウト。 多くのパラメータを備えた重要な補償スキームを使用すると、従業員がそれを理解できないリスクが高まります。 最良の結果を達成する方法、または突然収入が少なくなった理由を理解していないと、人々を激怒させ、やる気をなくさせます。
3. 「そこには何がありますか？」 はい、それも起こります。 スキームが、今月の結果が2つまたは3つの後にのみ表示されるように構築されている場合。 「今月は仕事が悪くなりましたが、もっと多くなりました。 だから、私が最後に退屈したとき。 リーダーシップ-ばか、彼らは私の仕事で何も理解していない！」
4. ChSVの従業員。 人の自己の感覚に入り込み、「公平な」ボーナスを与えることはほとんど不可能です。
5. 従業員に対する基準の達成の不完全な依存 。 たとえば、自分が描いたデザインを販売するか、50回編集する必要があるかは、デザイナーに完全に依存するわけではありません。
6. レポート。 レポートを書き、費やした時間を抑え、「正確な日付」を約束するのが好きな人は誰も知りません。

このリストを注意深く見ると、ほとんどのクレームが基準の選択、検討、透明性、および妥当性に関連していることがわかります。

わかった したがって、Good Criteriaを作成する必要があります。

まあ、すべてを理解している人、誰も急上昇しない人、インタビューでも簡単に説明される人。 そして、すべてが正直であり、何度も何度も働きたかったのです。

一般的に、Good Criteriaを見つけようとします。 （ところで、「良い」-誰のため？）。 影響を受ける3つの主要な利害関係者：スタジオの所有者、顧客、開発者。

顧客の観点から良い基準は何でしょうか？ 通常はお金になります（まあ、または実際の結果）：

• ROI-大まかに言えば、これは「金融投資の回収」です。 エコノミストが推測する指標は、開発者に完全に適用できるわけではありません。結局のところ、彼らは仕事の収益を管理し、外出先でお金で測定することはできません。 つまり、インジケーターに直接影響を与えることはできません。
• 低コストの機能。 顧客が低コストの機能を持っていることは有益です。 開発者にとっては、これはテンプレートの中断です（「これはどうですか。安く仕事をするためにもっとお金をもらえますか？」）。
• 満足度。 数える方法はわかりませんが、人々が幸福を望んでいる、または蒸気を減らしたいと考えている場合（©Dmitry Satin）、次の式を提案することもできます。

しかし、現実には、たとえばデザイナーに来て提供するために、彼のRFPが一時的な「顧客満足」に依存することは、デザイナーなしで滞在するための保証された方法です。 このトピックが機能するには、非常に深刻な危機が必要です。 または、多くの優秀なデザイナー。

• リリース日。 すべてが論理的なようです。プロジェクトを時間通りに引き渡します-たくさんのお金を手に入れ、予定より早くそれを与えます-さらにお金を手に入れます。 このインジケーターは適切ですが、既に特定された問題があります。すべてが開発者に依存するわけではありません。 タイムラグは、多くの場合、クライアントマネージャー側から発生します。 （したがって、フェア：「このマネージャーは顧客からコンテンツをノックアウトしなかったのに、なぜ給料を失うべきなのか？」）。

わかった これらの顧客にとって良い基準は、明らかに開発者にとって良いものではありません。 （幻想はありませんが、ビジネスに重要な別の200個の基準を簡単に見つけることができます。書き込み、コメントで説明します:)）

しかし、生産性は測定できます！ とても簡単です！

かどうか？ それを測定するには？ フェンスを塗った場合-すべてが明らかです。 しかし、キャッチがあります。 私たちの業界では、多くの人が考え、創造的で、才能のある人やフェンスを考えることはありません。 プログラマーの例を見てみましょう。 それでは、どのような優れたパフォーマンス基準が思い浮かびますか？

• KSLOC。 それが何であるか知っていますか？ そして、ヒンドゥー教のコードは何ですか-あなたは知っていますか？ 実装-わかります。 KSLOCは、コードの数千行です。 このインディケーターを給与に結び付けると、数千行のコピーアンドペーストを待ちます。 私の友人がバンガロールのどこかで完了した注文を受け取りました。たった10ドルで、最大20 MBのphpスクリプトです。 そして彼は働いた！
• 1時間あたりのたわごとの量（WTF / h）。 1日あたりの描画ページ数、1時間あたりの販売機能数など。 それは通常の測定基準のようです-何かを実際に計算して、パンを配布するために使用できます。 ただし、前の段落と同様の問題が発生します。量の損失に対する品質の低下、技術的負債の増加です。 動機、興味、満足-すべてが急速に落ちています。 その結果、売上高と低い資格。
• バグの数。 バグが少ないほど、より多くの支払いが行われます。 すべてが論理的ですよね？ そうでもない。 スタジオにバグトラッカーが実装されていますか？ もしそうなら、それを忘れてください。 テスターはすぐにプログラマに、書くべきバグの数と同意する数について同意します。そうしないと、これは双方にとって不利益になりません。
• リサイクル。 「あなたが仕事に遅れている場合、あなたはうまく働きません。」 それも論理的ですか？ たとえば、18：00後に電源を切るなど、処理に苦労しています。 ただし、ここで、開発者の心理学はオフィスプランクトンの心理学と根本的に異なることを覚えておく必要があります。彼が夕方まで座っている場合、彼は興味があります（これは奨励されるべきです）。

私たちの地域では、人々は主に彼らが興味を持っているから働きます。

愚かな企業ルールでそれらを気にしないでください。

• フォーカスファクター。 このメトリックは、私のお気に入りのスクラムから来ました。 タスクが理想的にどれくらいかかるか、そして最終的にどれだけ出てきたかを示します。 プロジェクトに対するチームの「集中」。 この基準に基づいてお金を払えますか？ かなりですが、マネージャーが「技術者」ではない場合、プログラマーは自分の時間の見積もりを意図的に過大評価し、自分のリスクを最小限に抑えます。 このアプローチの結果は、時間が長くなり、顧客がinしている（またはあなたから買わない）ことです。 はい、各会議は10分で論争になります。
• 速度 スクラムからも。 悪名高い「パフォーマンス」。 ここでは、人文科学は段落をスキップできます。

前のステップでチームがどれだけ完了したかに応じて、次のステップでチームが入力できるタスクの数を予測できます。 問題はフォーカスファクターと同じですが、さらに1つ追加されます。 多くの場合、マネージャー（特に経験の浅い）は、チームのパフォーマンスを「測定」できることに気付き、このツールを「別の方法で」使用し始めます。 しかし、Velocityは、 同じ条件で同じチームが同じタスクを実行するのにどれくらい時間がかかるかを示します。 ただし、タスクを完了した後、チームはすでに変更されています。この特定の問題の解決方法に関する経験を積んでいます。 そして、メトリックは再び機能しません。

• サイクルタイム。 プロジェクトに機能を実装するというアイデアが生まれた瞬間から、それが完成するまでにどれだけの時間がかかりますか。

私は個人的にこの指標が本当に好きです。 測定と最適化に値する重要な要素の1つ。 しかし、開発者はこの要因に直接影響しません。 これは高すぎるメトリックです。 サイクルタイムに基づいてチームに給与を支払い始める場合、これは、リーダーとして、あなたがチームの問題を解決してプロセスを理解しようとせず、単にすべてをチームに移そうとしていることを意味します。

開発者の給与を高レベルのメトリックに依存させようとする試みは、経営上のインポテンスの証拠です

それでは、チームの効果を測定することは可能ですか？ はい、可能です。特に、このために10個の指標について書いているので。 そして、コメントで考えることができるダースまたは2つ。 別の質問-開発者の給与を指標に依存させる価値はありますか？ しかし、これはすでに危険です。



私は仕事を始めていますが、仕事をするのは良いことです。なぜなら私はプロであり、興味があるからです。 しかし、彼らが愚かなメトリックで私を中傷し始めたら、私はこれらの愚かなメトリックを最適化します。 私は1日あたり1000行を書くか、10のたわごとデザインを描きます。 そして、仕事に対する私の関心は、非常に速く、すぐに尽きてしまいます。 これは、内部動機の代替と呼ばれます-外部。

---

狂気の物語

スタジオの責任者である「私の良き友人」は、非常に公正な報酬を導入するというアイデアを思いつきました。これには、多くのパラメーターが考慮されます。 当然、彼らは大規模に問題に取り組みました。 次のような一連の基準を作成しました。

-労働時間と実際の労働時間の月間計画。

-四半期ごとの販売計画。

-病棟の数とその給与。

-顧客からの積極的なコミュニケーションの量（満足度）;

-新しいプロジェクトで繰り返される顧客リクエストの数。

-専門コンテストでの賞。

-クライアントとの否定的なコミュニケーション。

-QAで見つかったバグの数。

-売掛金の増加。

-プロジェクトの開始後にクライアントが発見したバグの数。

-読書、記事の執筆。

そしてさらに20。（便利なリスト、それを取り去る;-)）。

これらはすべて1つのシステムにまとめられました。 当然、システムのバランスを取る必要がありました。 そのため、最初の数か月で、仮想の「キャンディーラッパー」でキャリブレーションすることが決定されました。 従業員のリストが描かれた大きなボードが発明されました。 さまざまな「キャンディラッパー」が取締役会に掛けられました。支払いが到着するとすぐに、プロジェクトが終了するか、将来の給与に影響する何らかの良い（または悪い）イベントが発生しました。

文字通り1時間以内に、従業員の顔は非常に悲観的になりました。 数日後、「キャンディーラッパーが減ったのはなぜですか？」または「キャンディーラッパーをくれなかったのはなぜですか-Vasyaを助けましたか？」という質問が始まりました。

気分は驚くほどになっていた。 1週間後、プロジェクトを評価するのに以前よりも4倍の時間がかかり始め、各評価は開発者とプロジェクトマネージャーの間で果てしない議論に変わりました。 月末までに、友人を助けたいと思った人はほとんどいませんでした-彼らは「彼らの仕事で十分だ」と説明しました。 形式化できない状況が無数にあることが明らかになりました。 多くのキャンディーラッパーは、主観的な感情に基づいて発行されました。

キャンディーラッパーなしで働きたい人はほとんどいませんでした。緊張が高まりました。 生産性とモチベーションが低下しました。 1か月後、プログラムは縮小されました。 数ヶ月後、不安は消えました。

---

結論として：

さまざまなメトリックは、測定および思考、思考、思考、それらに影響を与える方法に値します。 ただし、高レベルのメトリックを開発者やデザイナーに直接転送しないでください。 その他。

「開発者は、身体、心、心、魂の4つのコンポーネントで構成されています。

1.体にはお金と安全が必要です。
2.心に-愛と認識。
3.理由-開発と自己改善。
4.魂-自己実現。」

S.アルキペンコフ

他の人々を尊重し、彼らが好きなことをする機会を与えてください）。

そして最後。 各リーダーは、自分の組織がKPIに移行する準備ができているかどうかを自分で理解しなければならないという疑念があります。 私たちが収集した記事のこの小さな選択が正しい決定を下すのに役立つことを願っています。

1. ボーナスの危険性について （Joel Spolsky）。
2. 仕事に迷惑をかけないでください （Stas Davydov）。
3. ソフトウェア開発プロジェクトの金銭的動機 （Askhat Urazbaev）。
4. アジャイルのメトリック （AgileRussia.ru 2009-08-18に会う）。
5. 資本主義労働者の打楽器奏者の基本的な指標 （ラリサ・ハラヒノバ）。
6. 開発者はいくら支払う必要がありますか （Habrahabr、翻訳）。
7. ビジネスインテリジェンス （Habrahabr、V.P。Savchuk）。
8. IT専門家の動機 （Habrahabr）。
9. 企業/ユニット管理のツールとしてのバランススコアカード （Habrahabr）。
10. スケジュールと予算がそれほど重要でない場合にどのKPIを測定できるか （Habrahabr）。
11. IT従業員 （Habrahabr）のパフォーマンスインジケーター（KPI ）。
12. モチベーションの神話。 デッドロックを破る （ラインハルト・スプレンジャー）。
13. 従業員の動機付け方法 （Julia Lavrik）。
14. メリット：ジンジャーブレッドで従業員を殺す方法は？ または動機付けの方法 （Valentin Polyakov）。
15. プログラマーが生産性に比例して支払われない理由 （Habrahabr、翻訳）。