it-swarm-id.com

Apa contoh yang baik SMART tujuan untuk seorang programmer?

Sebagai lanjutan dari pertanyaan ini , saya bertanya-tanya apakah orang mungkin dapat menyarankan beberapa sampel dari apa yang mungkin dianggap sebagai tujuan "baik" dalam siklus tinjauan berkala untuk seorang programmer?

Mari kita mendefinisikan SMART dari definisi paling populer di entri Wikipedia :

  • Spesifik
  • Terukur
  • Dapat dicapai
  • Relevan
  • Dibatasi waktu
20
Mike Woodhouse

Saya menyadari bahwa SMART tujuan paling baik digunakan ketika orang memiliki kekurangan yang harus mereka koreksi, dan tidak begitu baik untuk saat-saat Anda ingin orang bertumbuh atau beralih dari yang baik ke hebat. Jika seseorang tidak melakukan timesheets, misalnya, dan ini menyakiti perusahaan karena Anda kadang-kadang harus menunda faktur, Anda dapat memiliki tujuan yang cerdas seperti "selama 6 minggu ke depan, setidaknya 5 minggu timesheets akan selesai pada pukul 10 pagi dari Senin pagi berikutnya. "6 minggu kemudian Anda memiliki benar atau salah; pengembang membuatnya atau melewatkannya. Entah kebiasaan baru itu ada atau Anda harus memutuskan apakah Anda ingin tetap mempekerjakan seseorang yang tidak keberatan menunda pembuatan faktur Anda. Berfungsi untuk orang-orang yang memiliki kebiasaan buruk lainnya: "selama dua minggu ke depan, setidaknya 75% checkin Anda akan memiliki komentar checkin yang mengikuti pedoman checkin (tautan ke dokumen internal)." Saya tidak pada akhir waktu singkat itu.

Di mana saya menemukan konstruksi ini kurang bermanfaat adalah ketika jangka waktu diperpanjang, ketika prestasi yang Anda inginkan kabur (belajar bahasa, lebih bermanfaat), atau ketika ok jika tujuannya tidak tercapai (Anda dapat menghargai sertifikasi, tetapi jika seseorang gagal sertifikasi ujian mereka Anda mungkin tidak akan mengambil tindakan disipliner.) Tiba-tiba semua manfaat dari tujuan pintar itu hilang. Jangan mencoba menggunakannya untuk apa pun selain tindakan korektif, dan mereka mudah ditulis, mereka membantu pengembang untuk naik ke tingkat yang diharapkan, dan mereka mudah diuji ketika waktunya habis. Kesulitan menulisnya berarti mereka bukan alat yang tepat untuk tujuan ini.

37
Kate Gregory

Karena saya akan memulai percakapan penetapan tujuan dengan bos saya, saya pikir saya akan menambahkan beberapa contoh yang mirip dengan beberapa yang saya pertimbangkan untuk saya sarankan:

  • Tingkatkan cakupan tes untuk kode di Proyek X hingga setidaknya 95% pada tanggal 31 Maret.
  • Isi dan bagikan draf pertama dokumen Arsitektur Proyek Y paling lambat tanggal 30 April
  • Kumpulkan komentar ulasan untuk dokumen arsitektur, perbarui jika perlu, dan keluarkan dokumen v1.-0 paling lambat tanggal 30 Juni

Saya berharap pekerjaan tambahan terwujud dalam waktu yang telah saya tentukan (selalu seperti sebelumnya, setelah semua) dan pekerjaan yang mungkin memiliki efek pada aspek "Tepat Waktu" pada khususnya. Itu seharusnya tidak menjadi masalah: tujuan harus ditinjau secara teratur untuk memastikan bahwa mereka terus memenuhi kriteria "Achievable". Saya harus memastikan bahwa saya menjaga manajer saya tetap di sini - tidak ada yang suka kejutan akhir tahun yang tidak menyenangkan ...

7
Mike Woodhouse

Jika Anda menjual perangkat lunak atau produk dengan perangkat lunak di dalamnya ...

Tingkatkan penjualan n%.

Betulkah.

Jika perangkat lunak tidak berfungsi, Anda tidak akan menjual banyak.

Jika perangkat lunak bekerja BENAR-BENAR BENAR-BENAR BAIK, Anda akan menjual banyak.

(Ini akan membuat orang-orang perangkat lunak menonton orang-orang penjualan seperti elang memastikan mereka tidak meniup bonus kinerja mereka.)

Jika perangkat lunak Anda adalah sistem in-house:

memotong biaya bisnis n%.

Jika sistem perangkat lunak baru memakan waktu 10x selama itu biaya perusahaan uang. Jika sistem baru cepat dan mencegah kesalahan, perusahaan menghemat uang.

Pendekatan ini sepertinya itu berlaku untuk orang-orang penjualan atau mungkin VP dari proses perubahan bisnis, tetapi sungguh, pengembang perangkat lunak adalah garis depan untuk kedua jenis proses.

Ide dasar saya di sini adalah mencoba menyelaraskan struktur imbalan karyawan secara eksplisit dengan hasil terbaik yang mungkin untuk perusahaan.

2
Tim Williscroft