個人的な経験からの物語。 長さについてお詫び申し上げます。
数年前、私たちの開発グループは、個人やチームリーダーに「適切な」測定可能な目標を設定しようとしました。ハードメトリクスは個々の目的に対して実際にはうまく機能しなかったため、実験はわずか1年間続きました（いくつかのリンクと詳細な説明については、このテーマに関する私の質問を参照してください）。
私はチームリーダーであり、技術上司や他のチームリーダーと一緒にすべての計画に携わっていたため、目的は無知な上級管理職によって上から指示されたものではありませんでした。 。ボーナス構造が開発者間の競争を不注意に助長したことも注目に値します。これが私たちが試したことについての私の観察です。
顧客に見える問題
私たちの場合、お客様に提供したサービスの停止をカウントしました。シュリンクラップ製品では、顧客から報告されたバグの数である可能性があります。
利点：これは、上級管理職に見える唯一の実際の指標でした。それはまた、開発グループの外で測定された、最も客観的なものでした。
短所：停止はそれほど多くなく、開発者ごとに1年間で約1回でした。つまり、目的を達成できなかったり超えたりすることは、各チームで発生したいくつかの停止の「責任の所在」の問題でした。これは悪い感情と士気の喪失につながりました。
完了した作業の量
利点：これが唯一の前向きな手段でした。それ以外はすべて「悪いことが起こったときに気づく」で、意気消沈していました。それがなければ、一年中何もしなかった開発者は他のすべての目的を超え、明らかに会社の利益にはならないので、それを含めることも必要でした。完了した作業量を測定することで、タスクサイズを見積もる際の開発者の自然な楽観性を確認できました。これは役に立ちました。
短所：「完了した作業」の測定は、開発者自身によって提供された見積もりに基づいていましたが（通常は良いことです）、それを目的の一部にすることで、システムのゲームで見積もりを膨らませることができました。他に実行可能な作業の測定は完了していません。生産性を測定するための唯一の可能な価値のある方法は「会社の収益への影響」だと思いますが、ほとんどの開発者は直接販売から遠く離れているため、これが個人レベルで実用的であることはめったにありません。
新しい製品コードで見つかった欠陥
昨年のバグは今年の目標ではどの個人にもカウントされるべきではないと感じられたため、この年の間に新しい製品コードに導入された欠陥を測定しました。内部品質チームによって発見された欠陥は、顧客に影響を与えなかったとしても、カウントに含まれていました。
利点：驚くほど少ない。欠陥の導入から発見までのタイムラグは、コードの品質を改善するための即時のフィードバックメカニズムが実際にはなかったことを意味しました。チームレベルでのマクロトレンドはより有用でした。
短所：この目的は欠陥が見つかったときにのみ呼び出され、誰かがそれを非難する必要があったため、ネガティブに重点が置かれました。開発者は自分たちが見つけた欠陥を記録することに消極的であり、単純なカウントは、マイナーなバグが深刻な問題と同じくらいひどいことを意味しました。個人あたりの欠陥の数はまだ非常に少ないため、より大きなサンプルの場合のように、軽微な欠陥と重大な欠陥の数は均等になりませんでした。古い欠陥は含まれていなかったため、コード品質に対するグループの評判（見つかったすべてのバグに基づく）は、今年導入された測定可能な数と必ずしも一致しませんでした。
プロジェクト実施の適時性
適時性は、定められた期限までに社内のQAチームに提供された作業の割合として測定しました。
利点：欠陥のカウントとは異なり、これは開発者が作業の完了時期を効果的に決定するため、開発者が即座に直接管理する手段でした。目的の存在は、タスクを完了することに心を集中させました。これにより、チームは現実的な量の作業に取り組むことができ、開発グループが約束を果たす能力についての内部顧客の認識が向上しました。
短所：開発者の直接の管理下にある唯一の目的として、コードの品質を犠牲にして最大化されました。締め切りの日に、タスクが完了したと言うか、品質の信頼性を向上させるためにさらにテストを行うかを選択できます。開発者はそれを完了としてマークすることを選択し、結果として生じるバグが表面化しないことを望みます。
社内のお客様からの苦情
開発者がソフトウェアの開発およびその後のサポート中に内部顧客とどの程度コミュニケーションをとったかを評価するために、各個人について受け取った苦情の数を記録することにしました。不満はマネージャーによって検証され、有罪判決の可能性を回避します。
利点：本当に何も思い出せません。十分に大きなグループレベルで測定すると、より有用な「顧客満足度」スコアになります。
短所：非常に否定的であるだけでなく、主観的な尺度でもあります。他の目的と同様に、各個人の数はゼロ点付近でした。つまり、誰かについての1つのコメントは、「無限に超えた」と「満たさなかった」の違いを意味する可能性があります。
一般的なコメント
官僚主義：私たちのタスク管理ツールはこれらのメトリックのデータの多くを保持していましたが、それでもすべてを照合するためにかなりの手作業が必要でした。すべての数字を取得するのに費やした時間は楽しくなく、一般的に私たちの仕事のネガティブな側面に焦点を当てており、生産性の向上によって回収されなかった可能性もあります。
士気：個人が問題のせいにされた対策については、「悪い」スコアの人は意気消沈したと感じただけでなく、「良い」スコアの人もチームの士気の低下を嫌い、時にはそう感じたので、上位にランクされたのは、彼らが優れていたからではなく、幸運だったからです。
概要
では、エピソードから何を学びましたか？後年、私たちはいくつかのアイデアを再利用しようとしましたが、「よりソフトな」方法で、個人の責任をあまり重視せず、チームの改善を重視していました。
- 客観的に測定可能で、会社に付加価値を与え、ゲーム化できない個々の開発者の目標を定義することは不可能です。したがって、わざわざ試してはいけません。
- 欠陥の場所が明確にそのチームの責任である場合、つまり、「非難ゲーム」をプレイする必要がない場合、顧客の問題と欠陥はより広いチームレベルで数えることができます。
- コードモジュールの責任レベルでのみ欠陥を測定すると、すべての欠陥を排除することがそのグループの利益になるため、古いバグと新しいバグを測定できます（そして測定する必要があります）。
- グループレベルで欠陥数を測定すると、グループあたりのサンプルサイズが増えるため、軽微な欠陥と重大な欠陥の間の異常が滑らかになり、単純な「バグ数」の測定は、月ごとに改善しているかどうかを確認するなどの意味があります。月。
- 彼らを幸せに保つことが開発グループとしてのあなたの主な目的であるため、上級管理職が気にかけていることを含めてください。私たちの場合、それは顧客に見える停止だったので、測定が時々恣意的または一見不公平であるとしても、それが上司が測定しているものである場合は、あなたも注意する必要があります。
- 上級管理職は、自分の目的にない指標を確認する必要はありません。このようにして、エラーについて個人を非難する誘惑を回避します。
- プロジェクトの提供の適時性を測定することで、開発者の行動が変わり、タスクの完了に重点が置かれました。それは見積もりを改善し、グループが現実的な約束をすることを可能にしました。適時性に関する情報を簡単に収集できる場合は、チームレベルで再度使用して、時間の経過に伴う改善を測定することを検討します。
個々の開発者に測定可能な目標を設定する必要がある場合、これらすべては役に立ちませんが、アイデアがチームの改善に役立つことを願っています。