Setiap Desember, ada saja yang menulis "ship lebih cepat" dan "tingkatkan kualitas kode" di whiteboard lalu menyebutnya target tim engineering untuk tahun depan. Setiap Februari, tidak ada yang ingat whiteboard itu pernah ada. Saya sudah cukup lama menjalankan tim engineering untuk tahu bahwa masalahnya bukan ambisi, melainkan target itu tidak pernah benar-benar dimiliki oleh orang-orang yang diharapkan mencapainya.
Target yang ditulis sendiri oleh manajer lalu diserahkan ke bawah hanya akan diangguki di all-hands dan diabaikan sebelum hari Selasa berakhir. Target yang dirumuskan bersama tim, dengan angka yang mereka pilih sendiri dan bisa mereka pertanggungjawabkan, cenderung bertahan menghadapi kuartal yang sibuk. Bedanya bukan pada isi targetnya. Bedanya ada pada siapa yang memegang pena saat target itu ditulis.
Berikut struktur yang benar-benar saya pakai: tiga kategori, masing-masing dengan target konkret yang dibantu ditetapkan oleh tim, ditinjau setiap bulan, bukan dinilai sekali di bulan Desember.
Target delivery: komitmen, bukan poin velocity
Lewati story points dan velocity chart sebagai target. Velocity mengukur bagaimana tim melakukan estimasi, bukan bagaimana tim benar-benar bekerja, dan mengoptimalkan untuk itu justru mengajarkan orang untuk menggelembungkan estimasi. Yang sebenarnya Anda butuhkan adalah komitmen yang diyakini tim bisa dicapai, dan rekam jejak dalam mencapainya.
Target delivery yang berhasil: "80% komitmen sprint terkirim pada sprint yang dikomitmenkan, diukur secara rolling per kuartal." Bukan 100%, karena 100% hanya berarti tim menggelembungkan estimasi demi menjamin kemenangan mudah. 80% menyisakan ruang untuk kenyataan bahwa kadang ada dependency yang rusak atau eskalasi klien yang menghabiskan dua hari.
Biarkan tim yang menetapkan angkanya. Jika mereka menolak dan bilang 80% tidak realistis dengan staffing saat ini, itu informasi berharga untuk Anda, bukan negosiasi yang harus dimenangkan. Tim yang berargumen untuk 65% dan konsisten mencapainya lebih berharga daripada tim yang menyetujui 90% tapi meleset setiap sprint sambil diam-diam mendendam pada targetnya.
Target kualitas: defect dan rework, bukan jumlah baris atau coverage
Metrik jumlah baris kode dan persentase test coverage mentah adalah cara tercepat untuk mendapatkan metrik yang diakali alih-alih software yang lebih baik. Developer yang diminta mencapai 80% coverage akan menulis test yang menyentuh baris tanpa benar-benar menguji perilakunya. Saya pernah melihatnya terjadi dalam hitungan sebulan.
Target kualitas yang lebih baik:
| Metrik | Kenapa efektif |
|---|---|
| Insiden produksi per rilis | Berkaitan langsung dengan dampak ke pelanggan, sulit diakali |
| Rework rate (tiket dibuka kembali dalam 2 minggu) | Menangkap pekerjaan "selesai" yang sebenarnya belum selesai |
| Waktu dari laporan bug hingga fix di produksi | Mengukur responsivitas, bukan sekadar volume |
Tetapkan baseline terlebih dahulu. Jika Anda belum tahu rework rate saat ini, habiskan satu sprint hanya untuk mengukurnya sebelum menetapkan target terhadapnya. Menebak titik awal adalah cara Anda berakhir dengan target yang terlalu mudah atau justru mustahil.
Target pembelajaran: satu skill, dikaitkan dengan proyek nyata
Ini kategori yang paling sering dilewatkan kebanyakan tim, dan justru inilah yang mencegah engineer senior keluar karena bosan. Pilih satu kesenjangan skill teknis yang benar-benar dimiliki tim, bukan teknologi yang sedang tren tapi belum dibutuhkan siapa pun, lalu kaitkan dengan pekerjaan nyata yang akan datang, bukan kursus pelatihan yang tidak pernah diselesaikan siapa pun.
Jika tim Anda akan segera membangun sesuatu yang membutuhkan disiplin staging dan rollback yang proper, itulah target pembelajaran kuartal ini, bukan "belajar Kubernetes" secara abstrak. Saya sudah menulis lebih dalam soal kenapa staging environment secara spesifik cenderung menjadi celah yang paling menggigit tim: Kenapa Bisnis Anda Butuh Staging Environment.
Jika kuartal depan tim Anda akan mengevaluasi AI coding tools, jadikan itu target pembelajaran, dengan deliverable yang konkret: rekomendasi tertulis tentang tool mana yang akan diadopsi tim dan alasannya. Saya membahas cara menjalankan evaluasi itu di Perbandingan AI Coding Assistant: Memilih untuk Tim Anda.
Cara menjalankan sesi perumusan bersama
Sediakan 90 menit dengan seluruh tim, bukan sebagian. Bawa angka nyata dari kuartal lalu, bukan opini, apa pun data delivery dan defect yang Anda punya sekalipun masih kasar. Ajukan tiga pertanyaan secara berurutan.
- Apa yang menghambat pengiriman tepat waktu di kuartal lalu, secara spesifik?
- Apa yang rusak di produksi yang seharusnya tidak terjadi, dan kenapa?
- Satu hal apa yang belum kita tahu caranya, yang akan dibutuhkan pekerjaan kuartal depan?
Target akan muncul sendiri dari jawaban-jawaban itu. Tugas Anda adalah mengubah diskusi menjadi tiga angka dengan pemiliknya masing-masing, bukan datang dengan angka yang sudah ditulis lebih dulu.
Meninjau tiap bulan, bukan menilai di bulan Desember
Target tahunan gagal sebagian karena satu tahun adalah feedback loop yang terlalu panjang bagi siapa pun untuk menyesuaikan arah. Jadwalkan check-in 30 menit setiap bulan di kalender. Bukan performance review, melainkan status check: apakah kita sedang menuju angka itu, dan jika tidak, apakah angkanya yang salah atau eksekusinya yang salah. Keduanya jawaban yang valid. Menyesuaikan target di tengah kuartal karena tim belajar sesuatu yang nyata bukanlah kegagalan, itu adalah proses penetapan target yang bekerja sebagaimana mestinya.
Kesimpulan
Target tim engineering yang bertahan sepanjang tahun punya tiga ciri: timnya sendiri yang menulis angkanya, metriknya tahan terhadap manipulasi, dan ada yang benar-benar meninjaunya sebelum Desember tiba. Lewati velocity chart, ukur apa yang benar-benar dirasakan pelanggan, dan jadwalkan satu check-in nyata di kalender setiap bulan. Itu permintaan yang lebih kecil dibanding kebanyakan dek perencanaan tahunan, dan itulah versi yang masih dijalankan di kuartal ketiga.