目標が機能しない場合でも、開発者に目標を設定する必要がある[クローズ]

ソフトウェア開発者に測定可能な目標を設定することは機能しないと一般に認められています。目標に焦点を合わせすぎると、組織の目標に反する行動につながる可能性があるためです（いわゆる「測定機能障害」）。

しかし、私の会社では、すべてのスタッフに目標を設定する必要があり、人事部からSMARTにするように勧められています。過去に、私の仲間の第1レベルのマネージャー（チームリーダー）と私はいくつかのアプローチを試みました：

1. 「テクノロジーXのトレーニングを行う」、「誰も理解できないコードYのドキュメントを作成する」など、通常の仕事に追加される測定可能な目標を設定します。年次業績評価に関しては、開発者を書面による目標ではなく、通常の仕事の測定不可能な価値についての私の意見に基づいて評価してください。それが実際に会社が関心を持っているからです。
2. 「タスク管理システムによって記録された日数の作業」、「導入されたバグの数」、「発生した生産の数」など、非常に具体的な目標を設定します。これは、より良い「スコア」を達成するために、膨らんだ見積もりとバグの誤った分類につながりました。興味深いことに、このシステムで高得点を獲得した開発者でさえ、チーム内の本質的な信頼が損なわれ、常に高い地位に値するとは限らなかったため、それを気に入らなかった。
3. 「通常の仕事を上手くやる」のバリエーションである漠然とした目標を設定します。年次評価に関しては、それらの評価は目標に対するパフォーマンスを反映していますが、目標自体は測定可能または達成可能ではなく、それは嫌われています。

これらのどれも理想的ではありません。ソフトウェア開発者にとって、その有効性に反する証拠があるにもかかわらず、意味のある測定可能な目標を作成しなければならないという同様の状況にあった場合、どのアプローチが最も効果的でしたか？

私が見つけた関連する質問は、同じ点に完全には対応していません。

• ソフトウェアエンジニアにとって良いパフォーマンス目標は何ですか？
• 開発者のパフォーマンス目標の設定
• プログラマーに適したパフォーマンス指標は何ですか？
• プログラマーにとって公正な生産性測定手法とは何ですか？
• 来年のキャリア「目標」が必要です

更新（2009年11月18日）：私の質問には10の賛成票があり、最高評価の回答には4つの賛成票しかありません（私からの賛成票を1つずつ含む）。私は、これは私たちに何かを伝え思う：ジョエルと他の人が正しいかもしれないこと、およびstackoverflowのの組み合わせの知恵が思い付くことができないことをあらゆる悪の真（測定不能）値に影響を与えずにgamedすることができませんでした開発者にとって魅力的な、測定可能な目標彼ら作業。試してくれてありがとう！

どのアプローチがあなたにとって最も効果的でしたか？

唯一の目的は、バグを見つけたり、他の批判をしたりせずに、私をレビュー担当者として、コード検査/ピアレビューに合格することです。

ノート：

• 私は新入社員の迅速な終了能力を測定しておらず、次のことを奨励していませんでした。私は人々にうまく終了する方法を学んでもらいたいと思っていました（
• 人々は私がコードレビューで探していたものを学びました。つまり、それは単なる管理目標ではなく、学習の機会であり、品質管理の手段です。
• 私のコメントには2つのカテゴリがあります。
  1. これはバグです。チェックインする前にこれを修正する必要があります
  2. 提案として、私はそのようなことをしたでしょう
• しばらくすると、ある人のコードをレビューしても、「修正が必要な」アイテムが見つからなくなります（その時点で、その人の作業をレビューする必要はなくなります）。

個人的に私は2種類の目標を設定しようとしています：

• ビジネスに焦点を当てた目標（これが結局私たちが報酬を得ている理由です）。たとえば、「2009年6月1日までにプロジェクトXを完了してください」）。これらの目標は、チームの複数のメンバー間で共有されることがよくあります（そして彼らはこれを認識しています）。チームは、プロジェクトを早期に実施するか、必要な機能を超えることで、目標を超えることができます。個人は、より多くの機能を作成したり、バグを減らしたり、チームの他のメンバーを指導およびサポートしたりすることで、目標を超えることができます。

• 個人の成長目標。たとえば、開発者がスキルセットに追加したいテクノロジーを含むプロジェクトを完了する、ユーザーのドメインをよりよく理解する、リーダーシップの経験を積むなど。

次のことが重要だと思います。

• 目的はSMARTです
• 目的はビジネスのニーズと一致しています
• あなたは目的に「通常の仕事」を含めます、実際、これらは最も重要な目的です！
• 従業員には、設定した目標を超える機会があります

最後に、私は目的としてソフトウェアメトリクスを避けます-それらはゲームするのが簡単すぎて、おそらくあなたが必要とするものをあなたに与えないでしょう。私は、特定の行動の内外で誰かを指導したい場合にのみメトリックを使用します。

これはすべて、「第1レベルの管理職」であり、ほとんどの管理職は従業員を知らないという事実に要約されます。実際の日々の計画と開発の一部ではなく、SMARTのようなものがポップアップします。マネージャーが実際の仕事をしている人たちともっと時間を過ごすとしたら、これは必要ありません。

個人的には、生産性と品質意識の観点から開発者の誰が実行するかが明らかなアジャイル環境で作業することを好みます。真のアジャイルアプローチでは、開発者だけでなく、設計者、テスター、顧客、製品マネージャーもプロセスに含める必要があります。これは当然、マネージャーの観点からより良い洞察につながります。

私がこれまでに見た測定可能な目標：

• 証明書試験に合格する
• テクノロジーXを研究し、それについてのプレゼンテーションを行う
• コミットされたビルド破壊変更の数
• 内部ナレッジマネジメントについて書かれたwiki記事の数

開発者に、目的に使用できる自己啓発のアイデアがあるかどうかを直接尋ねてはどうでしょうか。

開発者が機能しない場合でも、開発者の目標を設定する必要があります

あなたの開発者が動作しない場合は、おそらくいくつかの目的があるだけで、彼らは彼らにいくつかのインセンティブを与えるために必要なもの？;-)

「コードの少なくともn％が適切な単体テストでテストされていることを確認してください」カバレッジツールを使用してそれを証明し、他の誰かにテスト品質を確認してもらいます。

SMART（実際には同じ場所で作業しているかもしれません）という非常に具体的な目標を前もって持っていることは、実際には良い考えのように思えますが、ほとんどのチームにとってはあまり実用的ではありません。

問題は、実際には段階的な目標の変更です。ビジネスは変化し、開発者として、適切かつ合理的な時間枠で対応し、対応する必要があります。

組織内のチームまたはグループの目的に関連する目標を設定することを検討してください。それが目的、つまりマクロの目的を果たさなければ、あなたのチームは資金提供されません。チーム全体に存在し、ビジネスに沿った集合的な目標を設定します。人々に責任を与え、人々に説明責任を負わせます。彼らの成功と失敗を祝いましょう（私たちが失敗しない場合、私たちはおそらく試みていないでしょう、そしてそれはあなたが人々に望んでいることです）。HTH

プログラマーが作業するときに収集される、次のような多くのメトリックがあります。

• 変更/追加されたSLOCの数
• プロセスのさまざまな段階（ピアレビュー中、ピアレビュー後、リリース後）に挿入されたエラー/バグの数
• 変更要求が実行/拒否されました
• 正式なドキュメント（ソフトウェアバージョンの説明、設計ドキュメントなど）

これらはすべて、管理やソフトウェア品質保証のためのプレゼンテーションで役立つと思う具体的なものです。しかし、私はそれらが人々のパフォーマンスの実際の評価にひどく役立つとは思っていませんでした-それはあなたがリストしたいくつかのリンクによってなされたポイントです。ここでのジョエルのポイントは有効であることがわかりました。指標がチームの雰囲気を良くすることは決してありません。

残念ながら、私たちは皆、他の人（管理、品質保証、外部の請負業者など）がメトリックを必要とする世界に住んでいます。バランスを取る必要があることがわかりました。これらの指標を提供するだけでなく、無形の証拠も提供します。無形は、各プログラマーが達成したことであり、必ずしも追跡されるわけではありません。たとえば、他の誰も触れたくないレガシーコードの調査に多くの時間を費やしたプログラマーがいました。その期間、彼の測定基準は低かったものの、その努力は非常に貴重でした。

そのようなものを含めることがわかった唯一の方法は、追加の無形のカテゴリの作成を推進し、他のメトリックと同等の重みを与えることでした。通常、これは特定のプログラマーのバランスをとるのに十分です。

問題の1つは、部門/部門のIT組織が測定可能な戦略的目標を持っていないことであるように思われます。そうすれば、個人の目標を設定するのが簡単になります。

たとえば、発生する問題のあるチケットの数を減らすための部門のイニシアチブがあった場合、管理するソフトウェアに関連するチケットの数に基づいて、個人の目標を設定できます。

ソフトウェア開発は大部分が協調的であるため、チームレベルで目標を設定し、チームへの貢献度に応じて個人を評価する方が理にかなっています。

私が好きな目的は次のとおりです。

プロジェクトクライアントからプロジェクトへの関与についてN件の肯定的なレビューを求めます。

これは、顧客（内部または外部）からの肯定的なフィードバックを書面で受け取ることは常に良いことであるため、役立ちます。入手するのは難しくなく、関連性があり、簡単ですが、リストに無意味ではありません。

自己啓発を実行中のプロジェクトにどのように合わせるかを決定することは、これにおける重要なポイントだと思います。開発者に自分自身を分析して弱点を見つけてもらい、他の人にフィードバックを与えることは、何が改善されるかを見つけ、それを測定する方法を見つける方法かもしれません。たとえば、完成したアイテムなどを文書化することはめったにない場合があります。その年の目標では、これを改善したいと述べ、作成する文書の量がその尺度になります。私が実際にそれに従う方法に応じて、それはうまくいくかもしれないし、逆効果になるかもしれません。一方で、これには、私が自分の仕事をどのように改善し、適切な方法と見なされる可能性のあることを行うかという正当な懸念があるかもしれませんが、受動的攻撃的または幼稚な見方は、そうでない場合は大量のドキュメントを作成することです。

効果的な開発者を定義することは、これに対するもう1つの要素です。バグを最もよく修正するのはその人ですか？新しいものは最も速く動作しますか？新しい作業は、迅速に行われていなくても、テストとドキュメントで完了しますか？「状況によって異なります」という標準的な対応をここで明確にする必要がある ため、何を効果的と呼んでいますか。