プログラマにとって良いSMART目的の例は何ですか？
この質問 に続いて、プログラマーが定期的なレビューサイクルで「良い」目的と見なすことができるもののいくつかのサンプルを人々が提案できるかどうか疑問に思いましたか？
Wikipediaのエントリ の最も一般的な定義からSMARTを定義しましょう。
- 明確な
- 測定可能
- 達成可能
- 関連
- 期限付きの
SMART目標は、人々が修正する必要のある不足があり、人々が成長したり、良い状態から素晴らしい状態に移行したりするのにあまり適していない場合に最適に使用されることに気づきました。たとえば、誰かがタイムシートを実行していない場合、請求を遅らせる必要があるために会社に損害を与えます。「次の6週間で、少なくとも5週間のタイムシートは午前10時までに完了する予定です。次の月曜日の朝。」6週間後、あなたは正しいか間違っているか、開発者はそれを作ったか、見逃しました。新しい習慣が整っているか、請求を遅らせても構わない人をまだ採用するかどうかを決めることができます。 。他の悪い習慣を持っている人にも有効：「今後2週間で、チェックインの75％以上にチェックインガイドライン（内部ドキュメントへのリンク）に準拠したチェックインコメントが付けられます。」 /その短い時間の終わりにはありませんでした。
これらの構成があまり役に立たないと思うのは、時間枠が長くなる場合、目的の達成が曖昧な場合（言語を学ぶ、より役立つ）、または目標が達成されなくても問題ない場合（認定を評価してもよいが、誰かが失敗した場合）彼らのテストでは、おそらく懲戒処分は行われません。）突然、スマートゴールのすべての利点が失われます。これらを修正アクション以外の目的で使用しないでください。それらは簡単に記述でき、開発者が期待したレベルに到達できるように支援し、時間切れになったときに簡単にテストできます。それらの記述に問題があるということは、それらがこの目標に適したツールではないことを意味します。
私は上司と目的を設定する会話に入るので、私が自分のために提案することを検討しているものに似たいくつかの例を追加したいと思いました。
- 3月31日までに、プロジェクトXのコードのテストカバレッジを少なくとも95％に増やします。
- 4月30日までにプロジェクトYアーキテクチャドキュメントの最初のドラフトを完成させて配布する
- アーキテクチャドキュメントのレビューコメントを収集し、必要に応じて更新し、6月30日までにドキュメントのv1.-0を発行します
私は指定した時間内に追加の作業が具体化することを期待しています（結局常にそれは以前にもあります）。その作業は特に「タイムリー」な側面に影響を与える可能性があります。これは問題ではありません。目標は、「達成可能」の基準を引き続き満たしていることを確認するために、定期的に確認する必要があります。私は上司がこれを繰り返すのを確実にする必要があります-誰も不快な年末の驚きを好きではありません...
ソフトウェアまたはソフトウェアを組み込んだ製品を販売する場合...
売り上げをn％増やします。
本当に。
ソフトウェアが機能しなかった場合、その多くを売ることはできません。
ソフトウェアが本当にうまく機能していれば、たくさん売れるでしょう。
（これにより、ソフトウェアの担当者がタカのような営業担当者を監視し、パフォーマンスボーナスを吹き飛ばさないようにします。）
ソフトウェアが社内システムの場合：
企業のコスト削減n％
新しいソフトウェアシステムに10倍の時間がかかる場合、会社の費用がかかります。新しいシステムが高速でエラーを防止できれば、会社はコストを節約できます。
このアプローチは、営業担当者またはビジネス変更プロセスのVPに適用されるように見えますが、実際には、ソフトウェア開発者が両方の種類のプロセスの最前線です。
ここでの私の基本的な考え方は、従業員の報酬体系を会社にとって可能な限り最良の結果と明確に一致させることを試みることです。