SMARTの目標はプログラマにとって有用ですか？[閉まっている]

私が知っているいくつかの組織は、プログラマーにSMART目標を使用しています。SMARTは、特定、測定可能、達成可能、関連性、および時間制限の頭字語です。大企業ではかなり一般的です。

SMARTの目標に対する私自身の以前の経験は、それほど前向きではありませんでした。他のプログラマは、パフォーマンスを測定する効果的な方法を見つけましたか？プログラマーにとってSMARTの優れた目標の例は何ですか（存在する場合）。

一言で言えば

番号

第一に、私は自分のプロジェクトが十分な安定性を保っていなかったので、何らかの意味でSMART目標を確立することができました。プロジェクトで私の役割が変更されてからパフォーマンスのレビューが行われるまでの時間のスケールは、同期がとれていません。

第二に、個人のパフォーマンスを測定することは、「自分の仕事ではない」メンタリティと、個人および/または組織内のさまざまなサブチームとの間の負の競争を生み出す素晴らしい方法です。システムをゲームすることは非常に簡単で、チーム全体を実際に助けていないことを確認してください。私たちは人々がチームプレイヤーになることを奨励するべきですが、それから私たちの組織は正反対のことをします。

これらの種類のシステムのほとんどは、チームビルディングと相反しています。メアリー・ポッペンディークは、LeanEssays：Team Compensationでできることよりもはるかに優れた仕事をしました。

スーはジャニスから人事の電話を受けました。「スー」と彼女は言った。そして、これらの評価入力フォームをすべて記入していただきありがとうございます。しかし、本当に、すべての人に最高の評価を与えることはできません。あなたの平均評価は「期待に応える」べきです。「期待をはるかに超える」人は1人か2人しかいません...」

... 20世紀の偉大な思想的指導者の1人であるWエドワーズデミングは、人、功労制度、およびインセンティブ報酬をランク付けすることにより、測定不能な損害が生じると書いています。デミングは、すべてのビジネスはシステムであり、個人のパフォーマンスは主にシステムの動作方法の結果であると考えていました。彼の見解では、システムはビジネスの問題の80％を引き起こし、システムは管理者の責任です。彼は、管理の問題を個人に解決させるために推奨とインセンティブを使用しても効果がないと書いています。デミングは、出来映えのプライドを破壊し、問題の原因ではなく症状に対処するためにメリットが上がるため、ランキングに反対しました。

...従業員の評価と報酬システムをさらに詳しく調べ、それらが機能不全になる原因を探りましょう...

私が働いている大企業では、SMARTの目標を使用しています。ほとんどの場合、それらは無意味です。

目標は経営陣から下がっており、高尚かつ抽象的なものです。それらを具体的なプロジェクトと開発に関連付けることは、通常冗談です。グループに参加するプロジェクトのほとんどは、ビジネスからのものであり、特定のビジネスニーズを満たすためのものです。したがって、プロジェクトをコーディングし、本番環境に配置して、通常どおり素晴らしい仕事をします。それは、上級管理職の誰かが思いついた目標とどのように関連していますか？

私たちは自分たちの目標を思いついたとき、グループとしてはるかに良くなります。特定のトピックに関するトレーニングや、新しいプロセスの変更の実装が含まれることもありますが、これは実際に私たちの仕事に関連している可能性があります。それらは、少なくともグループを企業環境で前進させるのに役立つものであるため、コーディングの日々の運用とはまだあまり関係がありません。

編集

Mnementhが非常に正しく指摘しているように、私の答えは、SMARTではなくSMARTの目標に基づいています。あなたがプログラマーのマネージャーであり、SMART目標を実装したい場合は、彼らがSMARTであることを確認してください。SMARTゴールを実装しない方法として、私のマンガ家の例を使用してください。あなたがプログラマーを管理しておらず、誰かがあなたが今SMARTゴールを使い始めようとしているのに、彼らが私たちのゴールのようになってしまうと言ったら、バズワードが好きで、それらは実装したもののリストから外れます。

プログラマーは、他の可能な目標を犠牲にして、提示されたどのような基準でも優れた仕事をすることを示す多くの研究があります。

これは、具体的で測定可能な目標を達成するのにうまくいくことを意味し、具体的にリストされていないものではあまりうまくいきません。つまり、目標を設定する際には非常に注意する必要があります。

目標としてコードの行を設定する必要はありません。私を信じて。修正されたバグを設定すると、最初はバグのあるコードを書くことになります。既存のコードのバグ修正を要求すると、「バグ」（および「修正」）の非常にリベラルな定義になります。（また、「達成可能な」部分は、コードがどれだけバグがあったかに依存します。）ある時間内に機能の完全性を要求することは、まあ....

プログラマーにしたいのは、適切な期間に有用なものを優れたコード品質で記述し、コード品質を維持しながらそれを強化および変更することです。自分にとっては良い基準となる具体的で測定可能な目標を見たことはありません。

毎年この演習を行っています。問題は、ここでの開発者は彼らが何をするか（プロダクトマネージャーによって決定されるタスク）に関してほとんど自律性を持たない傾向があることです。少なくとも紙の上では、目標を達成することに専念する時間があります。しかし、現実的には、それよりはるかに少なくなります。

そのフレームワーク内で、自己啓発的な目標を設定することが非常にうまくいくことがわかりました。たとえば、昨年の私の目標の2つは次のとおりです。

1. 設計パターンを読み、おもちゃのプロジェクトを書いて、来年までに各パターンを学び、実証します。これには2年かかりましたが、私のコーディングの改善は顕著です。
2. .NET 3.5の言語機能を学習し、四半期ごとに同僚にプレゼンテーションを行うため。 これはLINQに関する1つのプレゼンテーションになり、同僚は無関心と軽度の興味の間でさまざまな程度に高く評価しました。しかし、私は多くのことを学び、C＃の知識を示したので、かなりクールな新しいプロジェクトに取り組むようになりました。

そう、そう、私はそれをやっている間、私は恩恵を受けて楽しみました。

正直なところ、私たちの会社では、優れた開発者のSMART目標の欠如は、企業の発言へのひねくれた嫌悪感と関係があると思います。

はい、正しく設定されている場合。

正しく設定されていれば、目標はチームと個人の両方を改善できます。彼らも仕事に合わせて、個人のために設計する必要があります。

私は、DBAチーム全体が同じ当たり障りのない目標を持っている場所にいるだけでなく、「KPI委員会によって決定されたグローバルおよび地域のKPIに適合している」などの高レベルの伝承も受けています。もちろん誰も知らない..

それから、私はマネージャーが個々の目標を前もって考えて設定する場所にいました。

編集：

私はメアリー・ポッペンディークの記事を読みましたが、それはスマートに関するものではありません。たとえば、「不可能の知覚」は「達成可能」に失敗します。

個々の目標を設定して、それぞれの強みを共有し、弱点を修正し、チームに貢献する必要があります。測定は個人用です。

xとyの比較はありません。

ただし、xとyの目標は、システム内のランクまたは位置と釣り合っている必要があります。高齢者と後輩には同じ目標を設定していません。ずるい。

限られたポットからボーナスまたは賞金を設定するには、いくつかのベンチマークが必要です。代わりにコードの行をカウントする必要がありますか？ピアレビュー？

また、グローバルな企業理念を変える必要のない有効な代替手段を教えてください。私は、SMARTのない批判を持っていない：私はやる小便貧しい経営者の批判を持っています...

パフォーマンスフレームワークとして、SMARTは、マネージャの目標と目標がどれだけ緊密に連携しているかと同じくらい効果的です。SMARTの目的は、最初にDUMBダウンする必要がある場合があります。それらを作ります：

• 実行可能
• わかりやすい
• 扱いやすい
• 有益

それは奇妙に聞こえるかもしれません。

SMARTタイプの目的設定は、プログラミングのコンテキストでは役立ちますが、インテリジェントに行う必要があります。または、他の回答で指摘されているように、時間を浪費する（または悪化させる）可能性があります。

有用な目的を得るには、SMARTの頭字語の意味を同意することが役立ちます。Googleのクイック検索では、さまざまな定義が見つかりました。

• S：Specificにコンセンサスがあるようです（ただし、それが何を意味するかについては意見の相違があります）
• M：Meaningful and Motivationalは、より一般的なMeasurableに代わるものです
• A：ほとんどの場合、達成可能なことを表していますが、同意したこともあります
• R：見る場所に応じて、現実的、関連性、結果重視
• Tは常にTimeを参照しているようですが、強調は異なります

したがって、最初に、目標設定交渉の両側がプロセスの共通の理解から機能する必要があります。

次に、組織、部門、グループ、チーム（または関連する階層）の全体的な目標を説明し、理解する必要があります。その時点で、個人（IMO、目標は個人レベルで価値があるように設定する必要があります）が、その個人の今後の活動を通知する少数の目標に同意できるようになるはずです。

それがそこで終わったとしても、それはまだみんなの時間の無駄でした。目標は定期的に見直され、調整される必要があります-達成された場合、新しい目標を設定する必要性を考慮し、達成されなかった場合、理由を特定し、必要に応じて是正措置を規定する必要があります。

関係者はだれでも、この種のエクササイズは真剣に取られない場合、またはおそらくよりアルゴリズム的に抽出された値が投入された努力に比例する場合、価値がないことに注意する必要があります。

人々がSMARTの目的に役立つ/価値があると思うものを見るのは有益かもしれません。ここに質問をしました ...

SMART目標の問題は、測定可能なものを選択する必要があることです。測定可能なものと組織の成功にとって重要なものはしばしば同じものではないので（そして、事実上プログラミングには決してありません）、SMARTの目標は私の経験では常にパフォーマンス評価に失敗します。そして時々、物事は測定できるように見えますが、あまり手間がかかりすぎるわけではありません（SMARTの目標のように、4時間以内にすべての電子メールに回答することが1回ありました。情報提供または回答が必要な場合は、送信したメールを見て回答したかどうかを確認し、すべての通話の録音を聞いて回答したかどうかを確認し、IMログで回答したかどうかを確認します。土曜日の夜の真夜中に私に送られたメールはどうですか...）

いいえと答えたすべての人々にとって、あなたの目標はおそらく十分ではありませんでした。

私はそれらを使用しましたが、非常に便利です。あなたは私たちのために働く何かを試してみたいかもしれません：

1. 四半期目標を設定します。
2. 測定可能な目標を設定します。
3. 個人に1つの目標のみを設定する
4. 両方ともあなたが同意する時まで目標があまりにも野心的な再調整であると彼が言うなら、個人に目標を受け入れさせます。
5. 四半期の終わりに、ブール値を見つけます。達成目標= trueまたはfalse。

これは非常に強力であり、開発者に対する説明責任を果たします。言い訳を見つけたい人は、6ヶ月かそこら後に鶏を追い出します。

PS：回答を投票する人々を理解できますが、少なくとも関連するコメントをドロップしてください。私は知らないことを学びます:-)

SMARTは、より良い目標を達成するための基準を覚えている頭字語です。SMARTを導入するということは、この原則に従って経営陣が改善する必要があるということです。とにかくSMART管理がなければ目標は設定されますが、それらは困難すぎる可能性が高くなります。

そのため、プログラマーが変更することはないはずなので、管理者はSMARTを実装するためにスタイルを変更する必要があります。そして、彼らが正しければ、プロジェクトの方向性がより明確になり、時間枠が設定されるなどして、プログラマとしてのあなたの仕事がより簡単になります。

経営陣がそれを正しく行わなければ、大きな変化はありません。