SMARTゴールはプログラマーにとって有用ですか？
私が知っているいくつかの組織は、プログラマーに [〜＃〜] smart [〜＃〜] 目標を使用しています。 SMARTは、特定、測定可能、達成可能、関連性、時間制限の頭字語です。これらは大企業ではかなり一般的です。
SMARTの目標に関する私自身のこれまでの経験はそれほど良いものではありませんでした。他のプログラマーがパフォーマンスを測定する効果的な方法を彼らに見つけましたか？良い例はいくつかありますSMART =プログラマーの目標（存在する場合）。
一言で言えば
いいえ
最初に、私はSMART目標を任意の意味で確立できるほど十分に安定した状態を維持したことがありませんでした。プロジェクトでの役割の変更時とパフォーマンスレビューの完了時の間の時間は同期がずれすぎています。
第二に、個人のパフォーマンスを測定することは、個人や組織内のさまざまなサブチーム間で「自分の仕事ではない」考え方や否定的な競争を生み出す優れた方法です。システムをゲームするのは非常に簡単で、チーム全体を助けるのではなく、自分自身を探していることを確認してください。私たちは人々にチームプレーヤーになることを奨励する必要がありますが、それから私たちの組織は正反対のことをします。
これらの種類のシステムのほとんどは、チームビルディングとは正反対です。メアリーポッペンディックは、これを私が今までにできるよりもはるかに優れた形で表現しています LeanEssays：Team Compensation 。
スーは人事部でジャニスから電話を受けた。 「スー」と彼女は言った、「あなたのチームは素晴らしい仕事をしました！そして、それらすべての評価入力フォームに記入してくれてありがとう。しかし、実際には、みんなに最高の評価を与えることはできません。あなたの平均評価は「期待に応える」はずです。 「期待をはるかに超えた」人は1人か2人しか持てません...」
... 20世紀の最大の思想的リーダーの1人であるWエドワーズデミングは、測定不可能な損害は、人、メリットシステム、およびインセンティブペイのランク付けによって生じると書いています。デミングはすべてのビジネスはシステムであり、個人のパフォーマンスは主にシステムの動作方法の結果であると信じていました。彼の見解では、このシステムはビジネスの問題の80％を引き起こし、システムは管理者の責任です。彼は、個人に管理の問題を解決させるために勧めやインセンティブを使うことは、単にうまくいかないと書いています。デミングは、技量の誇りを破壊するためランキングに反対し、問題の原因ではなく症状に対処することでメリットを高めます。
...従業員の評価と報酬のシステムをさらに詳しく見て、彼らが機能不全になる原因を探ります...
私たちが使用しているSMART目標は、私が働いている大企業で使用されています。これらの目標は、ほとんどの場合無意味です。
目標は上級管理職から降りてきて、高尚で抽象的なものです。それらを具体的なプロジェクトや開発に関連付けることは、通常冗談です。グループに入るプロジェクトのほとんどはビジネスからのものであり、特定のビジネスニーズを満たすためのものです。したがって、プロジェクトをコーディングし、本番環境に配置して、いつものように素晴らしい仕事をします。それは、上級管理職の誰かが思いついた目標とどのように関連していますか？
私たちが自分の目標を思いついたとき、私たちはグループとしてはるかにうまくやります。ときには、特定のトピックに関するトレーニングや、新しいプロセス変更の実装も含まれます。これは、実際に私たちの仕事に関連している可能性があります。それらは、少なくとも、企業環境でグループを前進させるのに役立つものであるため、コーディングの日々の運用とはあまり関係がありません。
[〜＃〜]編集[〜＃〜]
Mnementhが正しく指摘しているように、私の答えはSMARTゴールではなくSMARTであることに基づいています。プログラマーのマネージャーであり、実装したい場合は= SMART目標、それらがSMARTであることを確認してください。SMART目標を実装しない方法として、私のマンガ家の例を使用してください。プログラマーや誰かを管理していない場合SMART=ゴールを使い始めると、ゴールは私たちのゴールと同じように終わり、バズワードが好きでチェックできる人が上層部にいることを理解します。彼らが実装したもののリストからそれらを。
他の可能な目標を犠牲にして、プログラマーが提示された基準にかかわらず、プログラマーが優れた仕事をすることを示す多くの研究があります。
これは、具体的で測定可能な目標を達成するのが得意であり、具体的にリストされていないものは得意ではないことを意味します。つまり、目標の設定には細心の注意が必要です。
コード行を目標として設定する必要はありません。私を信じて。修正されたバグを設定すると、まずバグのあるコードが作成されます。既存のコードのバグ修正を要求すると、「バグ」（そしておそらく「修正」）の非常に寛大な定義になります。 （また、「達成可能な」部分は、コードがどれほどバグが多かったかによって異なります。）一定の時間内に機能の完全性を要求することは…….
プログラマーにしてもらいたいことは、妥当な期間内に優れたコード品質で有用なものを記述し、コード品質を維持しながらそれを拡張および変更することです。私自身が良い基準となる具体的で測定可能な目標を見たことがありません。
私たちはこの演習を毎年行っています。問題は、ここの開発者は自分たちが何をするか（製品マネージャーが決定するタスク）についてほとんど自律性がない傾向があることです。幸いにも、少なくとも紙面では、目標達成に専念できる時間があります。ただし、現実的には、それよりもはるかに少なくなります。
そのフレームワークの中で、自己開発の目標を設定することは非常にうまく機能することがわかりました。たとえば、昨年の2つの目標は次のとおりです。
- デザインパターンを読み、おもちゃのプロジェクトを書いて、来年までに各パターンを学習およびデモします。これには2年かかりましたが、私のコーディングの改善目立ってきました。
- 。NET 3.5言語機能を研究し、四半期ごとに同僚にプレゼンテーションを行うこれは、私の同僚がLINQで1つのプレゼンテーションになることになりました無関心と軽度の関心の間のさまざまな程度で高く評価されています。しかし、私は多くのことを学び、私のC＃の知識を実証したので、かなりクールな新しいプロジェクトに取り組むようになりました。
それで、ええ、私はそれをしている間、恩恵を受け、楽しみました。
正直なところ、私たちの会社では、優れた開発者の欠如SMART目標の欠如は、企業の発言へのひどく嫌な嫌悪にもっと関係があると思います。
はい、if正しく設定されています。
正しく設定されていれば、目標はチームと個人の両方を向上させることができます。彼らも仕事に合わせて、個人のために設計する必要があります。
私は、DBAチーム全体が同じ目的を持っていて、「KPI委員会によって決定されたグローバルおよび地域のKPIに準拠する」などの高レベルのサポートを受けている場所にいます。もちろん誰も知りません。
繰り返しになりますが、私はマネージャーが個々の目的を前もって考えて設定する場所にいます。
編集：
メアリー・ポッペンディックの記事を読みましたが、それはSMARTに関するものではありません。たとえば、「不可能の知覚」は「達成可能」に失敗します。
個人の目標を設定して、その強みを共有し、弱点を修正し、チームに貢献する必要があります。測定は個人用です。
Xとyの比較はありません。
ただし、xとyの目標は、システム内のランクまたは位置に見合ったものにする必要があります。高齢者と後輩に同じ目標を設定するわけではありません。ずるい。
限られたポットからボーナスまたはペイライズを設定するには、いくつかのベンチマークが必要です。代わりにコード行をカウントする必要がありますか？ピアレビュー？
そして、グローバルな企業精神を変える必要のないvalid代替案を見せてください。私はSMARTを批判していません：私はdo小便の悪いマネージャーを批判しています...
パフォーマンスフレームワークとして、SMARTは、目標がマネージャの目標とどの程度一致しているかに応じてのみ効果があります。SMART目標は最初にDUMBする必要がある場合があります、つまり、次のようにします。
- できる
- 理解できる
- 扱いやすい
- 有益
それは奇妙に聞こえるかもしれません。
SMART-type Objective-settingcanはプログラミングコンテキストで役立ちますbut他の答えで指摘されているように、それはインテリジェントに実行する必要があります。
SMART頭字語の意味：a quick Google search found varying definition ：
- S：スペシフィックでコンセンサスがあるようです（ただし、それが何を意味するかについては意見の相違があります）
- M：意味のある、やる気を起こさせることは、より一般的な測定可能なものに代わるものです
- A：ほとんどの場合、達成可能を表すようですが、同意済み
- R：どこを見れば、現実的で、関連性があり、結果重視の
- Tは常に時間を参照しているようですが、強調は異なります
したがって、最初に、目的設定交渉の両側は、プロセスの共通の理解から機能する必要があります。
次に、組織、部門、グループ、チーム（または関連するあらゆる階層）の全体的な目標を説明し、理解する必要があります。その時点で、個人（IMO、目標は価値があるように個人レベルで設定する必要があります）が、その人の今後の活動を通知する必要がある少数の目的に同意できるようになるはずです。
それがそこで終わっても、それはまだみんなの時間の無駄です。目標は定期的に見直し、調整する必要があります。達成された場合、新しい目標を設定する必要がある可能性を検討し、達成されなかった場合は、理由を特定し、必要に応じて是正措置を規定する必要があります。
関係者全員が、この種の演習は、真剣に、またはおそらくよりアルゴリズム的に取られなければ、価値のないものであることを認識しておく必要があります。抽出される値は、加えられた労力に比例します。
SMART目的。 ここに質問を掲載しました ...
SMART目標の問題は、測定可能なものを選択する必要があることです。測定可能なものと組織の成功にとって重要なものは、多くの場合同じではありません（そして、プログラミングにはほとんどありません）ので、= SMART目標は、私の経験では常にパフォーマンス評価に失敗します。そして、物事は測定可能であるように見えますが、それほど多くの努力なしではありません（SMART 4時間以内にすべてのメールに回答する。1年に数千通のメールをやりたいと思っている人は本当に、それが情報であるか、回答が必要かを判断し、送信されたメールを見て、回答したかどうかを確認します。すべての通話の録音を聞いて応答したかどうか、IMログで応答したかどうかなどを確認します。土曜日の夜深夜に私に送信されたメールはどうですか...）
いいえと答えたすべての人にとって、あなたの目標はおそらく十分ではありませんでしたSMART十分です。
私はそれらを使用しましたが、それらは信じられないほど便利です。あなたは私たちのために働く何かを試してみたいかもしれません：
- 四半期ごとの目標を設定します。
- 測定可能な目標を設定します。
- 個人の目標を1つだけ設定する
- 目標が野心的すぎると彼が言った場合は、両方が同意する時まで個人に目標を受け入れさせます。
- 四半期の終わりに、ブール値を考え出します。目標達成= trueまたはfalse。
これは非常に強力で、開発者に説明責任をもたらします。言い訳を見つけたい人は6カ月くらいでチキンアウト。
PS：私は答えを投票する人々を理解できますが、少なくとも私が知らないことを学ぶために関連するコメントをドロップしてください:-)
SMARTは、より良い目標のためのいくつかの基準を覚えておくための頭字語です。したがって、SMARTを導入するということは、経営者がこの原則に従ってより良くする必要があるということです。 SMARTがなければ、経営陣はとにかく目標を設定しますが、それらはあまりに難しい可能性が高くなります。
したがって、プログラマーが変更を加えてはならないため、管理者はSMARTを実装するためにスタイルを変更する必要があります。プロジェクトの方向性が明確になり、タイムフレームが設定されるなど、プログラマーとしての作業が容易になります。
経営陣がそれを正しく行わなければ、あまり変化はありません。