- Kesalahan yang sering dilakukan saat mengukur produktivitas developer
- Masalah dalam mengukur input
- Mengandalkan input atau upaya seperti ‘jam kerja’ akan mendorong perilaku yang keliru
- Misalnya, jika budaya perusahaan menghargai dan memberi imbalan pada waktu yang dihabiskan di depan layar, developer bisa mencurahkan waktu ke sana, tetapi kualitas pekerjaan sulit dijamin
- Dalam lingkungan yang lebih keras, ini bisa berubah menjadi persaingan untuk ‘datang paling pagi dan pulang paling malam’
- Masalah dalam mengukur output
- Metrik terburuk seperti jumlah baris kode atau jumlah commit termasuk dalam kategori ini
- Developer dapat menulis baris kode dalam jumlah besar dengan sangat cepat, sehingga mudah untuk mengukurnya
- Semua metrik output harus dipahami sesuai konteksnya
- Masalah dalam mengukur hasil dan dampak
- Tantangan dari dua metrik ini adalah memahami ‘seberapa besar tanggung jawab tim DevOps’
- Saat mengukur peningkatan pendapatan bisnis, mustahil untuk mengaitkannya hanya pada tanggung jawab developer
12 komentar
Ngeri juga. Sepertinya memang ada perbedaan antara sudut pandang manajer dan sudut pandang praktisi lapangan,,
Rasanya ini memang bagian yang pas untuk LLM.
Ada sisi di mana makna yang ingin disampaikan memudar karena tulisan ini tidak menawarkan alternatif. Saya setuju dengan pendapat bahwa jumlah output harus dikecualikan dari pengukuran hasil, tetapi saya tidak bisa setuju bahwa jam kerja harus dikecualikan sepenuhnya dari pengukuran input karena itu tidak sesuai dengan realitas. Bagaimanapun, waktu tetap berjalan selama melakukan kerja pengetahuan, jadi saya pikir waktu harus dipertimbangkan dalam pengambilan keputusan.
Menurut saya, akan lebih mudah dipahami dan lebih efisien untuk membahas produktivitas developer setelah mengukur indikator pendahulu seperti total progres = (jumlah kebutuhan yang terpenuhi / jam kerja)
Belakangan ini saya cenderung melihat tulisan-tulisan semacam ini dengan cukup kritis, karena saya merasa kesimpulan yang akhirnya diambil orang setelah membacanya adalah memilih untuk tidak melakukan pengelolaan apa pun. Apa pun metrik yang digunakan untuk mengelola, pada akhirnya masalah serupa tetap ada. Selain itu, ketika suatu metrik digunakan untuk kompetisi atau perbandingan antarindividu maupun antartim, efek samping pun akan muncul. Karena itu, pengelolaan tidak boleh dilakukan hanya dengan satu metrik; perlu mengelola metrik-metrik yang saling melengkapi secara bersama-sama, dan saya pikir metrik seharusnya digunakan untuk membantu tim melakukan perbaikan secara mandiri.
Bagaimana menurut Anda jika mengukurnya berdasarkan jumlah PR dengan unit yang bermakna yang diajukan?
Faktanya, ada perusahaan besar tertentu di dalam negeri yang mengukur kinerja dari jumlah baris kode yang ditulis huhu
Haha, saya juga pernah melihatnya.
Dia terus mengunggah commit yang hanya mengubah nama variabel.. hehe
Sepertinya ini lingkungan yang tidak menjalankan code review ya?
Haha, reviewer kode juga harus menerima code review.
Mereka saling bantu satu sama lain..
Wkwkwkwk, aduh...
hello hell world ;)
Apakah ini pengukuran produktivitas LOC yang selama ini cuma saya dengar lewat omongan? 😨