85

ソフトウェア開発者に測定可能な目標を設定してもうまくいかないことは一般に受け入れられています。目標に焦点を合わせすぎると、組織の目標に反する行動 (いわゆる「測定機能不全」) につながる可能性があるためです。

しかし、私の会社では、すべてのスタッフに目標を設定することが義務付けられており、人事部から目標をSMARTにするよう奨励されています。過去に、同僚の第 1 レベルのマネージャー (チーム リーダー) と私は、いくつかのアプローチを試みました。

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

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

私が見つけた関連する質問は、同じ点にまったく対処していません:

更新(2009 年 11 月 18 日): 私の質問には 10 の賛成票があり、最高評価の回答には 4 つの賛成票しかありません (私からの各 1 票を含む)。これは何かを教えてくれると思います。おそらく、Joel と他の人たちは正しく、stackoverflow の知恵を組み合わせても、開発者の真の (測定不可能な) 価値に悪影響を与えずにゲーム化することのできない、説得力のある測定可能な目標を見つけることはできないということです。仕事。でも試してくれてありがとう！

4

11 に答える 11

21

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

目的は 1 つだけです。私がレビュアーであるコード インスペクション/ピア レビューに合格し、バグを見つけたり、他の批判をしたりすることなく、何かをやり直すように依頼することです。

ノート：

  • 私は、新入社員がすぐに仕事を終える能力を測定していませんでしたし、そうするように勧めもしませんでした: 私は人々にうまく仕事を終える方法を学んでほしかった (なぜなら、仕事がうまく終わっていなければ、仕事は終わっていないからです)。
  • コード レビューで私が探していたものを人々が学びました。つまり、これは学習の機会であり、品質管理の手段であり、単なる管理目標ではありません。
  • 私のコメントには 2 つのカテゴリがあります。
    1. これはバグです: チェックインする前にこれを修正する必要があります
    2. 提案として、私はそのようなことをしただろう
  • しばらくすると、ある人のコードをレビューしても、「修正が必要」な項目が見つからなくなりました (その時点で、その人の作業をレビューする必要はなくなります)。
于 2009-01-15T14:07:09.547 に答える
14

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

  • ビジネスに焦点を当てた目標 (これが、最終的に支払われる理由です)。たとえば、「2009 年 6 月 1 日までにプロジェクト X を完了してください」)。これらの目標は、多くの場合、チームの複数のメンバー間で共有されます (そして、彼らはこれを認識しています)。チームは、プロジェクトを早期に開始するか、必要な機能を超えることで、目標を超えることができます。個人は、より多くの機能を作成したり、バグを減らしたり、チームの他のメンバーを指導およびサポートしたりすることで、目標を超えることができます。

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

私は次のことが重要だと感じています。

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

最後に、目標としてのソフトウェア メトリックには近づきません。それらはゲームが簡単すぎて、おそらく必要なものを提供しないでしょう。私は、特定の行動の内外で誰かを指導したい場合にのみ、指標を使用します。

于 2009-01-29T21:51:37.783 に答える
9

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

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

于 2009-01-15T13:41:48.833 に答える
8

これまでに目にした測定可能な目標:

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

目標に使用できる個人的な開発のアイデアがあるかどうか、開発者に直接尋ねてみませんか?

于 2009-01-15T13:43:09.097 に答える
8

うまくいかなくても、開発者の目標を設定しなければならない

開発者がうまくいかない場合、おそらくいくつかの目標は彼らにインセンティブを与えるために必要なものでしょうか? ;-)

于 2009-01-15T14:26:35.530 に答える
7

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

于 2009-01-15T13:35:59.313 に答える
4

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

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

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

于 2009-01-15T13:50:15.633 に答える
3

プログラマーが作業を行う際に収集される、次のような多くの指標があります。

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

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

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

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

于 2009-01-15T15:28:55.297 に答える
2

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

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

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

于 2009-01-15T14:01:17.187 に答える
1

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

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

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

于 2009-01-15T21:47:22.363 に答える