Mengukur produktivitas pengembang baru dan yang sudah ada – Beragampengetahuan

Mengukur pekerjaan pengembang berbeda dari peran tradisional karena setiap fitur baru, perbaikan bug, atau pemfaktoran ulang berbeda dan memiliki tingkat kompleksitas yang berbeda-beda. Artikel ini memperkenalkan beberapa cara lama namun lebih baik untuk mengukur produktivitas pengembang.

Peran pengembang

Perannya terutama berkisar pada pemecahan masalah, namun solusinya tidak selalu jelas dan menambah beban tambahan dalam mempertahankan kerangka kerja yang ada. Kecuali jika masalahnya adalah pengulangan dari pengalaman sebelumnya, pengembang memerlukan lingkungan bebas gangguan untuk menyelesaikannya.

Ada berbagai jenis pengembang saat ini, tetapi jika kita berbicara tentang pengembang yang tugasnya menambahkan fitur baru, memperbaiki bug, dan berpartisipasi dalam keputusan arsitektur, maka peran di atas akan sesuai dengan kebutuhan. Apa pun yang terjadi, pengembang berada dalam kondisi lancar, dan gangguan dapat memengaruhi produktivitas.

cara lama

Tiket Gila

Beberapa organisasi mengandalkan JIRA sebagai pengelola tugas tempat fitur dan bug yang diminta dimasukkan dalam bentuk tiket. Orang yang paling banyak menutup tiket dalam kurun waktu tertentu pasti orang yang paling produktif bukan?

Mungkin, mungkin juga tidak. Tiket-tiket ini sepenuhnya mengabaikan kompleksitas setiap proyek, sehingga memperlakukan mereka secara setara akan menciptakan persepsi yang salah. Mereka yang menangani tiket yang lebih mudah akan menjadi yang teratas, sementara sisanya akan turun dengan tiket yang lebih sulit.

Tapi sama seperti kita menambahkan prioritas pada tiket, mungkin kita juga bisa memperkirakan kerumitannya? Hal ini memang menambah kemampuan pengamatan, namun perkiraan non-insinyur akan sering kali salah.

Menambahkan sesuatu seperti “menu tarik-turun sederhana” dapat menjadi masalah besar jika bertentangan dengan pengaturan saat ini atau memerlukan penyelesaian utang teknis sebelumnya untuk melangkah lebih jauh. Anda mungkin bisa meminta teknisi menulis tiket yang akurat, tetapi hal ini membuang waktu pengembang yang berharga. Resolusi JIRA atau jenis tiket apa pun pada akhirnya bukanlah indikator yang baik.

titik cerita

Poin cerita adalah ukuran berapa lama waktu yang dibutuhkan untuk mengembangkan suatu fitur dibandingkan dengan fitur lainnya. Memperkirakan dalam pengembangan perangkat lunak adalah salah satu hal yang paling sulit untuk dilakukan, dan poin ceritanya mungkin bagus, namun justru memperburuk keadaan.

Banyak perusahaan saat ini menggunakan ini sebagai ukuran produktivitas dan menilai tim berdasarkan skor yang mereka peroleh dalam sprint saat ini, dan amit-amit jika skornya lebih rendah dari skor sebelumnya. Hal ini secara efektif mendorong permainan sistem dan memberikan perkiraan yang lebih panjang, sehingga menggagalkan tujuan.

pertemuan kemajuan

Pada prinsipnya, mungkin merupakan ide bagus bagi manajer Anda untuk menanyakan kabar Anda dan apakah ada hambatan, namun dalam praktiknya, rapat kemajuan rutin dapat membuang-buang waktu semua orang dan mengalihkan fokus dari pekerjaan sebenarnya ke rapat itu sendiri.

Seringkali, satu pertemuan menghasilkan pertemuan lanjutan, sehingga kita terjebak dalam siklus tanpa akhir yang terlihat. Kecemasan saat rapat adalah fenomena umum, dan tidak ada salahnya jika orang tidak dapat fokus pada pekerjaan mereka sampai rapat selesai.

cara baru

Mengukur produktivitas teknik selalu menjadi tantangan, namun penelitian dan survei selama bertahun-tahun telah mengembangkan metrik yang dapat memberikan wawasan berharga tentang kinerja tim dan membantu mengidentifikasi hambatan tersembunyi dan tanda-tanda kelelahan. Ini disebut metrik DORA (lihat Pengiriman Perangkat Lunak) dan dikembangkan oleh tim riset dan penilaian DevOps Google.

Pengiriman perangkat lunak diukur terutama melalui empat metrik utama:

• Ubah waktu tunggu: Seberapa cepat kita bisa bergerak maju?
• Frekuensi penerapan: Seberapa sering kita melakukan produksi?
• Ubah persentase kegagalan: Seberapa andal penerapan kami?
• Waktu pemulihan penerapan yang gagal: Seberapa cepat kami dapat memulihkannya?

Metrik ini memberikan visibilitas sekilas kepada tim Anda dan menyertakan berbagai sub-metrik untuk ditelusuri bila diperlukan. Tim DORA menerbitkan laporan setiap tahun untuk memahami bagaimana industri menggunakan metrik ini, rata-ratanya, dampaknya, dan banyak lagi. 2025 adalah versi terbaru, namun sangat fokus pada pengembangan yang dibantu AI. Anda dapat melihat versi 2021 untuk mempelajari sesuatu tentang perkembangan tradisional.

Ukur indikator DORA, dll.

Dalam organisasi yang ketat dengan hanya segelintir pengembang, tidak perlu menggunakan alat untuk mengukur produktivitas tim, namun seiring pertumbuhan tim, ada sesuatu yang perlu diperhatikan. Di sini, Anda dapat memanfaatkan alat observasi yang mengukur metrik DORA, seperti Swarmia, LinearB, dan Codemetrics.

Saya akan secara khusus menyebutkan Codemetrics di sini karena memiliki harga per kursi termurah dan saya telah terlibat dengannya sejak awal. (Pengungkapan penuh)

Langkah dan keputusan yang paling sulit adalah memberikan beberapa izin tampilan untuk memilih bagian dari repositori kode, namun alat ini menggunakan metadata dari permintaan tarik untuk menghitung semua statistik, sehingga kode Anda tetap tidak terlihat dan aman.

Anda juga dapat mengedit dan mengatur jenis metrik yang ingin Anda lacak untuk memastikan Anda memiliki tampilan yang tepat untuk Anda. Codemetrics memiliki manfaat lain selain melacak metrik DORA, dan meskipun segala sesuatu yang berhubungan dengan kode sumber memerlukan akses ke sana untuk analisis, ini tidak disertakan secara default.

Jika Anda belum pernah mencoba jenis alat ini sebelumnya, ada baiknya Anda melihat apakah alat tersebut sesuai dengan kebutuhan bisnis Anda. Mereka juga selalu hadir dengan demo atau uji coba gratis, jadi Anda tetap menggunakannya hanya jika berhasil.