Bagaimana cara menulis "SMART" Tujuan sebagai pengembang gesit?

Seperti banyak perusahaan, perusahaan tempat saya bekerja bertransisi ke sistem peninjauan kinerja berdasarkan tujuan SMART . Tim saya adalah tim pengembangan gesit yang berfungsi tinggi menggunakan praktik-praktik dari Extreme Programming . Untuk keuntungan besar kami, penerapan praktik lincah kami mendapat dukungan penuh dari manajemen langsung dan atas.

Untuk menyelesaikan pekerjaan, tim kami menggunakan iterasi tiga minggu. Di luar iterasi langsung kami memiliki rencana umum yang ditata menjadi perempat. Berarti apa yang akan kita capai beberapa kuartal dari sekarang jauh lebih berbahaya daripada apa yang akan kita capai dalam kuartal langsung. Kami tentu memiliki gagasan umum tentang ke mana tujuan proyek kami, tetapi kata kunci di sini bersifat umum .

Mengingat pendekatan kami kepada anggota perencanaan proyek tim saya, termasuk saya merasa kesulitan untuk menulis tujuan yang spesifik, terukur, dapat dicapai, relevan, dan terikat waktu (SMART).

Dua pertanyaan yang ada tentang SoftwareEngineering.se melakukan pekerjaan yang baik untuk mengatasi beberapa masalah kami:

• Apa contoh tujuan SMART yang bagus untuk seorang programmer?
• Apakah sasaran SMART bermanfaat bagi programmer?

Namun, pertanyaan-pertanyaan tersebut menghasilkan respons yang lebih umum daripada spesifik untuk menangani tujuan-tujuan SMART ketika bekerja pada tim pengembangan yang gesit. Sebagai pengembang yang gesit, bagaimana Anda menulis lima hingga tujuh tahun sasaran yang spesifik, terukur, dapat dicapai, relevan, dan terikat waktu?

Jawaban ini ditulis dari sudut pandang seseorang yang memiliki sistem manajemen kinerja seperti itu ditempatkan di sekitar tim Agile; seperti Anda, semua orang di tim menyadari kesulitan / kegunaan dari tujuan SMART selama setahun yang diterapkan pada kelompok Agile, di mana, ketika berfungsi penuh, penerapan Agile dapat dianggap secara inheren / sudah SMART.

Tidak benar-benar! Panggil berikut rasionalisasi jika Anda perlu (jika logika setengah matang ...), tetapi menjelaskannya kepada pengulas di luar organisasi langsung telah menetapkan panggung untuk "tujuan" yang sebenarnya kita masukkan ke dalam sistem manajemen kinerja.

• S untuk spesifik : selama setiap perencanaan sprint, tim menyetujui serangkaian tugas khusus untuk dicapai, dan berkomitmen untuk melakukannya. Tugas (dan kisah pengguna), menjawab pertanyaan tentang apa yang ingin saya capai, tujuan / manfaat dari mencapai tujuan, siapa yang terlibat, di mana itu terjadi, dan kendala.
• M untuk terukur : daftar tugas ini, ditambah pergerakan tiket di seluruh sprint, dari pengembangan ke peninjauan kode ke QA untuk dirilis (atau apa pun aliran Anda), menjawab pertanyaan tentang seberapa banyak pekerjaan dan kapan akan diselesaikan .
• A untuk dapat dicapai : kelompok Agile yang berfungsi biasanya tidak berkomitmen pada sesuatu dalam tahap perencanaan kecuali jika itu jelas dapat dicapai - semua bagian ada untuk mengetahui bagaimana mencapainya
• R untuk relevan : pertanyaan seperti apakah itu berharga, apakah ini waktu yang tepat, apakah itu cocok dengan upaya kami yang lain - cerita dan tugas tidak ditarik ke dalam sprint, dan berkomitmen untuk, kecuali jawabannya adalah ya untuk semua pertanyaan ini ( biasanya ... YMMV)
• T untuk batas waktu : sprint harus terikat waktu, baik itu 2 minggu, 3 minggu, lebih, atau kurang.

Jika Anda memahami / meyakinkan diri sendiri bahwa pekerjaan triwulanan Anda (dan dengan demikian pekerjaan sepanjang tahun Anda) itu sendiri adalah satu tujuan SMART yang besar, dan bahwa Anda tahu Anda mencapai tujuan Anda karena tim berkinerja baik, kecepatannya positif, pelepasan terjadi. , lalu Anda sampai ke titik pertanyaan Anda, yang pada akhirnya adalah bagaimana menerjemahkan proses SMART ke dalam serangkaian tujuan SMART untuk kepentingan orang lain.

Saya sudah bisa melakukan ini dengan sukses di masa lalu dengan menulis sesuatu yang bagi saya terlihat samar-samar dan, yah, tidak terlalu SMART, tetapi sebenarnya bisa diterima oleh orang lain.

Beberapa contoh yang telah saya lakukan di tempat lain:

• "Saya ingin merilis versi baru dari WidgetMaker setiap tiga bulan di tahun berikutnya, dengan mengikuti proses pengembangan perangkat lunak internal kami, untuk menyelaraskan dengan jadwal pengembangan produk secara keseluruhan (bla bla)."

• "Saya ingin meningkatkan kecepatan pengembangan tim sebesar n% dari rilis A ke rilis B, dengan fokus pada perubahan bertahap pada proses perawatan backlog, untuk meningkatkan efektivitas kami dan mengurangi keterlambatan pengiriman produk."

Anda tahu dan saya tahu bahwa ini bukan prinsip panduan dari grup pengembangan Anda yang sebenarnya, tetapi mereka tidak sepenuhnya terkait, dan dalam pengalaman saya adalah jenis hal yang tampak sangat SMART dan berguna bagi orang-orang di luar organisasi langsung Anda (tanpa kebohongan langsung atau lumpuh total).