Apakah sasaran SMART bermanfaat bagi programmer? [Tutup]


57

Beberapa organisasi yang saya kenal menggunakan tujuan SMART untuk programmer mereka. SMART adalah singkatan dari Specific, Measurable, Achievable, Relevant, dan Time-Bound. Mereka cukup umum di perusahaan besar.

Pengalaman saya sebelumnya dengan tujuan-tujuan SMART belum terlalu positif. Pernahkah programmer lain menemukan mereka cara yang efektif untuk mengukur kinerja? Apa saja contoh sasaran SMART yang baik untuk programmer (jika ada).


Sementara saya ingin percaya jawabannya adalah ya, saya belum mengalami peningkatan besar yang harus saya berikan ketika berbicara tentang kekuatan saya. ;)
JB King

17
"Spesifik, Dapat Dicapai, Relevan, dan Terikat Waktu" - tidak ada nama membosankan yang dapat digunakan.

Itu akan membutuhkan proses air terjun yang ketat. Sementara itu yang dianggap usang dan berbagai versi lincah digunakan sebagai gantinya selama lebih dari satu dekade sekarang.
vartec


1
Saya akan menyampaikan bahwa tidak berguna untuk hampir semua profesi. Mengukur apa yang mudah atau mungkin untuk mengukur hasil numerik dalam mengukur hal yang salah pada umumnya.
HLGEM

Jawaban:


52

Dalam sebuah kata

Tidak

Pertama: Saya belum pernah proyek saya tetap cukup stabil sehingga saya bisa menetapkan tujuan SMART dengan makna apa pun. Skala waktu antara ketika peran saya berubah pada proyek dan ketika tinjauan kinerja selesai terlalu tidak sinkron.

Kedua: Mengukur kinerja individu adalah cara yang bagus untuk menciptakan mentalitas "bukan pekerjaan saya" dan persaingan negatif antara individu dan / atau berbagai sub tim dalam suatu organisasi. Sangat mudah untuk memainkan sistem dan memastikan Anda mencari sendiri dan tidak benar-benar membantu seluruh tim. Kita harus mendorong orang untuk menjadi pemain tim, tetapi kemudian organisasi kita melakukan sebaliknya.

Sebagian besar dari jenis sistem ini bertentangan dengan pembangunan tim. Mary Poppendieck telah melakukan pekerjaan yang jauh lebih baik dalam mengartikulasikan hal ini daripada yang dapat saya lakukan di LeanEssays: Kompensasi Tim .

Sue mendapat telepon dari Janice di bidang sumber daya manusia. “Sue,” katanya, “Kerja bagus yang dilakukan tim Anda! Dan terima kasih telah mengisi semua formulir input penilaian itu. Tapi sungguh, Anda tidak bisa memberi semua orang peringkat teratas. Peringkat rata-rata Anda harus 'memenuhi harapan'. Anda hanya dapat memiliki satu atau dua orang yang 'jauh melebihi harapan' ... "

... Salah satu pemimpin pemikiran terbesar abad ke-20, W Edwards Deming, menulis bahwa kerusakan tak terukur diciptakan oleh orang-orang peringkat, sistem jasa, dan upah insentif. Deming percaya bahwa setiap bisnis adalah sistem dan kinerja individu sebagian besar adalah hasil dari cara sistem beroperasi. Dalam pandangannya, sistem menyebabkan 80% masalah dalam bisnis, dan sistem adalah tanggung jawab manajemen. Dia menulis bahwa menggunakan nasihat dan insentif untuk membuat individu menyelesaikan masalah manajemen sama sekali tidak berhasil. Deming menentang peringkat karena menghancurkan kebanggaan dalam pengerjaan, dan pantas diangkat karena mereka mengatasi gejala, bukan penyebab, masalah.

... mari kita lihat lebih dalam evaluasi karyawan dan sistem penghargaan, dan jelajahi apa yang menyebabkannya menjadi tidak berfungsi ...


Sepotong bagus, tetapi tidak terkait dengan SMART ...
gbn

Saya melihatnya mirip dengan GBN: tidak terkait dengan SMART. Tim pengembangan akan mendapatkan tujuan dari manajemen (atau langsung dari pelanggan), jika mereka mengikuti kriteria SMART atau tidak.
Mnementh

3
Alasan saya mengutipnya adalah bahwa tujuan SMART biasanya dilakukan dengan tujuan mengukur kinerja individu dengan tujuan menetapkan bonus dll secara individual. Artikel lain yang menari di ruang yang sama tentang bagaimana sebagian besar korps menangani ulasan kinerja ... joelonsoftware.com/articles/fog000000007070.html
MIA

3
Itu bukan tujuan dari SMART. SMART harus membantu Anda (atau manajemen) untuk mencapai tujuan yang lebih baik. Anda akan memiliki sasaran dalam proyek apa pun, apakah itu SMART atau tidak. Lihat en.wikipedia.org/wiki/SMART_criteria
Mnementh

4
@Mnementh - Tujuan vs implementasi adalah dua hal yang berbeda. SMART biasanya merupakan aroma yang menunjukkan bahwa suatu organisasi akan menghargai kinerja individu daripada kontribusi tim. Saya yakin ada organisasi yang melakukannya dengan benar, tetapi saya belum pernah secara pribadi menemukan satu.
MIA

14

Kami telah menggunakan sasaran SMART di perusahaan besar tempat saya bekerja. Mereka tidak berarti untuk sebagian besar.

Tujuan turun dari manajemen atas dan tinggi dan abstrak. Mengaitkannya dengan proyek-proyek konkret dan pengembangan biasanya hanya lelucon. Sebagian besar proyek yang masuk ke dalam grup berasal dari bisnis dan untuk memenuhi kebutuhan bisnis tertentu. Jadi Anda membuat kode proyek, memproduksinya dan melakukan pekerjaan yang luar biasa seperti biasa. Bagaimana hal itu berhubungan dengan tujuan yang dibuat oleh seseorang di manajemen puncak?

Kami melakukan jauh lebih baik sebagai kelompok ketika kami datang dengan tujuan kami sendiri. Kadang-kadang mereka termasuk pelatihan tentang topik tertentu atau menerapkan perubahan proses baru, sesuatu yang sebenarnya bisa terkait dengan apa yang kita lakukan. Mereka masih tidak benar-benar terkait dengan operasi sehari-hari pengkodean oleh mereka setidaknya hal-hal yang membantu memindahkan foward grup di lingkungan perusahaan.

SUNTING

Seperti yang ditunjukkan Mnementh dengan benar, jawaban saya didasarkan pada sasaran-sasaran SMART yang tidak, yah, SMART. Saya akan menambahkan jawaban saya bahwa jika Anda seorang manajer programmer dan ingin menerapkan tujuan SMART, pastikan bahwa mereka SMART. Gunakan contoh mangagers saya sebagai cara TIDAK untuk mengimplementasikan tujuan SMART. Jika Anda tidak mengelola pemrogram dan seseorang memberi tahu Anda bahwa Anda sekarang akan mulai menggunakan sasaran SMART dan akhirnya berakhir seperti kami, maka pahami bahwa Anda memiliki orang-orang di manajemen tingkat atas yang menyukai kata-kata buzz dan dapat memeriksa mereka dari daftar hal-hal yang telah mereka terapkan.


4
Jika sasarannya tinggi dan abstrak, sasarannya tidak CERDAS. S = spesifik. Jadi, pengalaman Anda bukan tentang tujuan-SMART, ini tentang tujuan, yang tidak cocok dengan kriteria pintar.
Mnementh

1
@Mnementh - Itu benar. Mungkin Anda ingin mendidik manajemen senior kami ??
Walter

3
Jika Anda mendidik atasan saya. Dia bahkan memiliki keberanian manajemen proyek dengan kami, SMART menjelaskan. Tapi tidak ada yang berubah, tujuannya adalah keruh seperti sebelumnya.
Mnementh

OK jadi masalah kuncinya adalah akronim SMART cenderung digunakan oleh orang-orang yang menyadari bahwa tujuan mereka tidak tetapi belum menyadari bahwa SMART bukanlah bahan yang dapat Anda tambahkan ke "sasaran" non-SMART yang telah Anda miliki. sudah memilih, sebaliknya itu adalah peringatan untuk memilih berbagai jenis tujuan.
reinierpost

10

Ada banyak penelitian untuk menunjukkan bahwa programmer akan melakukan pekerjaan dengan sangat baik pada kriteria apa pun yang disajikan kepada mereka, dengan mengorbankan tujuan yang mungkin lainnya.

Ini berarti bahwa mereka akan berhasil dalam mencapai tujuan yang spesifik dan terukur, dan kurang baik dalam hal apa pun yang tidak tercantum secara spesifik. Itu berarti Anda harus sangat berhati-hati dalam menetapkan tujuan.

Anda tidak ingin menetapkan baris kode sebagai sasaran. Percayalah kepadaku. Mengatur bug tetap mengarah untuk menulis kode kereta untuk memulai. Meminta perbaikan bug dalam kode yang ada akan menghasilkan definisi "bug" yang sangat liberal (dan mungkin "perbaikan"). (Juga, bagian "dapat dicapai" tergantung pada seberapa buggy kode itu.) Meminta kelengkapan fitur dalam waktu tertentu, baik ....

Apa yang Anda ingin programmer Anda lakukan adalah menulis hal-hal yang berguna dalam periode waktu yang wajar dengan kualitas kode yang baik, dan meningkatkan dan memodifikasinya sambil mempertahankan kualitas kode. Saya belum pernah melihat tujuan spesifik dan terukur yang akan menjadi kriteria yang baik.


3
Bisakah Anda menautkan ke beberapa penelitian itu?
Nicolas Bouliane

9

Kami menjalani latihan ini setiap tahun. Masalahnya adalah bahwa pengembang di sini cenderung memiliki sedikit otonomi atas apa yang mereka lakukan (tugas ditentukan oleh manajer produk). Kami beruntung bahwa, setidaknya di atas kertas, kami memiliki waktu yang didedikasikan untuk mengejar tujuan kami. Secara realistis, kita mendapat jauh lebih sedikit dari itu.

Dalam kerangka itu, saya telah menemukan bahwa menetapkan tujuan pengembangan diri bekerja sangat baik. Sebagai contoh, dua tujuan saya dari tahun lalu adalah:

  1. Untuk membaca Pola Desain dan menulis proyek mainan untuk mempelajari dan mendemonstrasikan setiap pola pada tahun depan. Ini akhirnya memakan waktu 2 tahun, tetapi peningkatan pada pengkodean saya telah terlihat.
  2. Untuk mempelajari fitur bahasa .NET 3.5 dan melakukan presentasi kepada rekan kerja saya setiap kuartal. Ini akhirnya menjadi 1 presentasi tentang LINQ yang dihargai rekan kerja saya dalam berbagai tingkat antara apatis dan sedikit tertarik. Namun, saya belajar banyak, dan setelah menunjukkan pengetahuan C # saya, saya telah dipindahkan untuk bekerja pada proyek baru yang cukup keren.

Jadi, ya, saya mendapat manfaat dan bersenang-senang saat melakukannya.

Sejujurnya, di perusahaan kami, saya pikir kurangnya pengembang yang baik Tujuan SMART lebih berkaitan dengan keengganan untuk berbicara di perusahaan.


8

Ya, jika diatur dengan benar.

Jika diatur dengan benar, tujuan dapat meningkatkan tim dan individu orang. Mereka harus diselaraskan dengan pekerjaan juga dan dirancang untuk individu.

Saya telah berada di tempat-tempat di mana seluruh tim DBA memiliki tujuan lunak yang sama, serta tingkat tinggi menjatuhkan saya seperti "sesuai dengan KPI global dan regional sebagaimana ditentukan oleh komite KPI". Yang tidak ada yang tahu tentu saja ..

Kemudian lagi, saya pernah berada di tempat-tempat di mana manajer menetapkan tujuan individu dengan pemikiran di muka.

Sunting:

Saya telah membaca artikel Mary Poppendieck dan ini bukan tentang SMART. "Persepsi Ketidakmungkinan" gagal "Dapat Dicapai" misalnya.

Tujuan harus ditetapkan bagi individu, untuk membagikan kekuatan mereka, membantu memperbaiki kelemahan, berkontribusi pada tim. Pengukuran adalah untuk individu.

Seharusnya tidak ada perbandingan x vs y.

Tujuan untuk x dan y harus sepadan dengan pangkat atau posisi mereka di dalam suatu sistem: seseorang tidak menetapkan tujuan yang sama untuk senior dan junior. Itu tidak adil.

Beberapa tolok ukur diperlukan untuk menetapkan bonus atau pembayaran dari pot terbatas: haruskah kita menghitung baris kode saja? Ulasan rekan?

Dan tunjukkan kepada saya alternatif yang valid yang tidak mengharuskan saya untuk mengubah etos perusahaan global saya. Saya tidak memiliki kritik terhadap SMART: Saya memang memiliki kritik terhadap manajer yang kencing ...


5

Sebagai kerangka kerja kinerja, SMART hanya seefektif seberapa dekat tujuan Anda selaras dengan para manajer Anda. Terkadang tujuan SMART Anda harus DUMB dulu, yaitu. buat mereka:

  • Bisa dilakukan
  • Bisa dimengerti
  • Dikelola
  • Bermanfaat

Aneh kedengarannya.


4

Penetapan tujuan tipe-SMART dapat berguna dalam konteks pemrograman tetapi harus dilakukan secara cerdas atau, sebagaimana ditunjukkan dalam jawaban lain, kemungkinan besar akan membuang-buang waktu (atau lebih buruk).

Untuk mendapatkan tujuan yang bermanfaat, akan membantu untuk menyetujui apa arti singkatan SMART: pencarian cepat Google menemukan berbagai definisi :

  • S: tampaknya memiliki konsensus di Spesifik (meskipun ada beberapa perbedaan pendapat tentang apa artinya)
  • G: Bermakna dan Motivasi adalah alternatif dari yang lebih umum
  • A: sepertinya paling sering mewakili Dapat Dicapai, tetapi saya juga telah melihat Setuju
  • R: tergantung di mana Anda melihat, Anda dapat menemukan Realistis, Relevan, Berfokus pada hasil
  • T sepertinya selalu merujuk Waktu, meskipun penekanannya bervariasi

Jadi pertama-tama, kedua sisi negosiasi penetapan tujuan harus bekerja dari pemahaman umum tentang proses tersebut.

Selanjutnya, tujuan keseluruhan untuk organisasi, divisi, grup, tim (atau hirarki apa pun yang relevan) perlu dijelaskan dan dipahami. Pada titik itu harus mungkin bagi individu (IMO, tujuan harus ditetapkan pada tingkat individu untuk menjadi berharga) untuk dapat menyepakati sejumlah kecil tujuan yang harus menginformasikan kegiatan orang itu ke depan.

Jika itu berakhir di sana, itu masih membuang-buang waktu semua orang. Tujuan perlu ditinjau dan disesuaikan secara berkala - jika tercapai, kemungkinan kebutuhan untuk menetapkan tujuan baru harus dipertimbangkan, jika tidak tercapai, alasan harus diidentifikasi dan tindakan korektif ditentukan jika diperlukan.

Setiap orang yang berkepentingan harus menyadari bahwa latihan semacam ini tidak bermanfaat jika tidak dianggap serius, atau mungkin lebih algoritmik, nilai yang akan diekstraksi sebanding dengan upaya yang dilakukan.

Mungkin instruktif untuk melihat apa yang menurut orang mungkin berguna / bermanfaat untuk tujuan SMART. Saya sudah mengajukan pertanyaan di sini ...


4

Masalah dengan tujuan SMART adalah mereka harus memilih apa yang dapat diukur. Karena apa yang dapat diukur dan apa yang penting bagi keberhasilan organisasi seringkali bukan hal yang sama (Dan hampir tidak pernah ada dalam pemrograman), tujuan SMART selalu gagal dalam penilaian kinerja dalam pengalaman saya. Dan kadang-kadang hal-hal tampak terukur tetapi tidak tanpa terlalu banyak usaha (Seperti tujuan SMART, saya punya satu waktu untuk menjawab semua email dalam waktu 4 jam. Sungguh yang ingin mencoba melalui ribuan email yang saya dapatkan setahun, tentukan apakah itu informatif atau membutuhkan jawaban dan kemudian melihat email yang saya kirim untuk melihat apakah saya benar-benar menjawabnya dan kemudian mendengarkan rekaman semua panggilan telepon untuk melihat apakah saya menjawabnya, periksa log IM saya untuk melihat apakah saya menjawabnya, dll. Dan bagaimana dengan email yang dikirimkan kepada saya pada Sabtu malam tengah malam ...)


3

Untuk semua orang yang menjawab TIDAK, Sasaran Anda mungkin TIDAK cukup Pandai.

Saya telah menggunakannya dan saya menemukan mereka sangat berguna. Anda mungkin ingin mencoba sesuatu yang bekerja untuk kami:

  1. Tetapkan Tujuan Triwulanan.
  2. Tetapkan tujuan yang terukur.
  3. Tetapkan hanya satu tujuan untuk individu
  4. Buat individu menerima tujuannya, jika dia mengatakan Goal terlalu ambisius menyesuaikan sampai waktu ketika Anda berdua setuju.
  5. Di akhir kuartal, muncul dengan nilai Boolean. Sasaran yang dicapai = benar atau salah.

Ini sangat kuat, itu menciptakan akuntabilitas untuk Pengembang. Orang-orang yang ingin mencari alasan ayam keluar setelah 6 bulan atau lebih.

PS: Saya bisa mengerti orang-orang yang memilih, tapi tolong berikan komentar yang relevan, setidaknya saya akan belajar sesuatu yang saya tidak tahu :-)


Saya sangat mendorong Anda untuk membaca tulisan Mary Poppendieck yang ditautkan dalam jawaban @ Jim Leonardo.
Gary Rowe

@Gary: Saya sudah membaca artikel itu, saya tidak setuju dengan 100% hal di dalamnya meskipun ada sesuatu yang bisa dipelajari darinya. Beberapa hal dalam Sistem telah diperbaiki misalnya. sistem peringkat meskipun masih ada tidak dalam urutan 1-10 tetapi juga mengurus pengaruh yang disebutkan kemudian dalam artikel. Satu lagi semua Organisasi berbentuk Piramida tidak peduli seberapa datar, promosi tidak bisa menjadi satu-satunya cara untuk menghargai orang.
Geek

1
Geek, dapatkah Anda memberi saya contoh tujuan yang menurut Anda bermanfaat?
Craig Schwarze

1
@Craigs: Sobat tujuan sederhana, seperti mengirimkan komponen XYZ dengan kualitas 80% dalam 3 bulan atau Memberikan paket layanan dengan 100 perbaikan bug dalam 3 bulan. Kuncinya di sini adalah HANYA SATU TUJUAN, jangan campur hal. Setelah Anda hanya memiliki satu tujuan, Anda tahu apa yang harus Anda fokuskan dan hasilnya adalah boolean (benar atau salah). Juga Melebihi / Memenuhi / Sebagian dipenuhi dapat didefinisikan dengan sangat mudah untuk misalnya 110 perbaikan masalah = melebihi, 100 = tercapai, 90 = tercapai sebagian.
Geek

1
@ Justin: Saya mungkin kehilangan poin yang ingin Anda sampaikan. Jawaban saya: Memperbaiki 100 bug hanyalah perkiraan dan Manajer (seseorang yang memahami produk dan teknis bug) harus menerima telepon. Misalnya, perbaiki 100 bug yang masing-masing memakan waktu 10 jam atau perbaiki 500 bug yang merupakan kesalahan ketik pada layar. Kuncinya di sini adalah bahwa pada awal Quarter Anda tahu, bug mana yang ingin Anda perbaiki dan berapa banyak waktu yang dibutuhkan untuk memperbaiki masing-masing. Juga akan ada varian 5-10% pada beberapa masalah. Anda mungkin juga ingin meninjau tujuan Anda di tengah kuartal.
Geek

3

SMART adalah akronim untuk mengingat beberapa kriteria untuk tujuan yang lebih baik. Jadi, memperkenalkan SMART berarti, manajemen Anda harus menjadi lebih baik dengan mengikuti prinsip ini. Tanpa manajemen SMART akan menetapkan tujuan, tetapi mereka akan lebih mungkin terlalu sulit.

Jadi, agar programmer tidak mengalami perubahan, manajemen harus mengubah gayanya untuk menerapkan SMART. Dan jika mereka melakukannya dengan benar, pekerjaan Anda sebagai programmer dapat menjadi lebih mudah, karena arah proyek lebih jelas, kerangka waktu ditetapkan, dan sebagainya.

Jika manajemen tidak melakukannya dengan benar, tidak banyak yang akan berubah.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.