Berburu Ghost Engineer: Melihat Kontribusi Nyata Developer

“Ghost engineer”—satu dari sepuluh developer nyaris tidak menghasilkan pekerjaan yang berguna, tetapi sangat meyakinkan saat berpura-pura sibuk. Penyebab sebenarnya—entah bekerja ganda, burnout, atau memang bermalas-malasan—bisa lama sekali tersembunyi dari manajemen. (Studi Stanford 2024: utas asli)

Developer tidak suka ketika kinerja mereka dibicarakan. Setelah profesi ini lama menikmati “masa keemasan”, muncul semacam tabu di industri untuk menanyakan satu hal sederhana: apakah hasil kerja engineering sepadan dengan waktu dan uang yang ditanamkan? Namun, developer juga sama jengkelnya terhadap ghost engineer—dan biasanya timlah, bukan manajemen, yang lebih dahulu melihat masalahnya.

Di Rusia, sejak dulu ada keengganan kuat untuk “mengadukan” orang lain. Akibatnya, banyak orang bisa tahu ada masalah, tetapi tak seorang pun mau bicara. Buat apa ikut terseret dalam urusan orang? Semuanya baru terbongkar ketika kesabaran semua orang sudah habis.

Tapi mungkin ghost engineer itu dibiarkan saja? Toh perusahaan tidak akan jatuh miskin gara-gara uang sebanyak itu.

Masalahnya, tidak sesederhana itu…

Ketika saya mengatakan kinerjanya rendah, saya tidak sedang membicarakan Alex yang bekerja keras tetapi menyelesaikan 10% lebih sedikit daripada Ben. Yang saya maksud berbeda: di setiap stand-up, seluruh tim harus mendengar kisah sedih terbaru—tim lain menghambat, tiketnya tidak jelas, nasib sedang tidak berpihak. Tapi besok tugasnya pasti selesai. Sumpah.

Hanya saja, “besok” itu sudah dikatakan kemarin dan sehari sebelumnya—sampai akhirnya menjadi tradisi.

Tim cepat menangkap hal seperti ini. Orang-orang yang benar-benar memikul beban kerja wajar mulai bertanya: untuk apa bekerja sampai habis tenaga kalau cukup mengarang cerita dan tidak menerima konsekuensi apa pun?

Namun, menyadari masalah saja tidak cukup. Tanpa angka dan fakta, pembicaraan lekas berubah menjadi adu argumen: tim berkata, “Kinerjanya buruk”; si developer menjawab, “Mereka tidak membiarkan saya bekerja.” Biasanya, penyelidikan baru dimulai setelah kesabaran habis dan tim meminta manajer mengganti developer tersebut.

Saat itulah kisah panjang dimulai: mengumpulkan fakta, mendengar kedua pihak, memberikan umpan balik, lalu memberi waktu agar keadaan membaik. Dalam pengalaman saya, akhirnya paling sering si ghost pindah ke perusahaan baru—yang tentu sangat “beruntung”.

Masalahnya bukan sekadar satu orang bekerja lebih sedikit. Perusahaan membayar dua kali: pertama untuk pekerjaan yang tidak pernah selesai, lalu untuk waktu rekan dan manajer yang habis memeriksa ulang, menutup kekurangan, dan mencari tahu penyebabnya. Pada akhirnya, bukan hanya satu developer yang berkinerja buruk. Seluruh tim ikut terdampak.

Bisakah manajer melihat masalah lebih awal—menangkap anomali, meminta konteks, dan menyelidikinya sebelum kesabaran tim habis serta perusahaan kehilangan waktu dan uang?

Dengan pengalaman yang cukup, situasi seperti ini sering bisa dikenali lebih awal dari beberapa pola perilaku khas:

• Setiap keberhasilan adalah jasa saya; setiap kegagalan adalah salah Anda.
• Sudah menyiapkan alasan kegagalan sebelum tugas mulai dikerjakan.
• Kekurangan kompetensi ditutupi dengan terlalu banyak bicara.
• Seiring waktu, manajerlah yang terutama diposisikan sebagai “biang masalah”.
• Berbeda dari orang yang sungguh sedang kesulitan, perilaku ini tidak membaik bahkan setelah mendapat umpan balik langsung.

Namun, kecurigaan membutuhkan jejak digital.

Mari kita lihat alat yang paling umum untuk mengukur kinerja engineering, lalu menilai apakah alat-alat itu bisa membantu menemukan ghost engineer.

Sebelum membandingkannya, saya perlu menyampaikan konflik kepentingan yang sudah jelas: Anda sedang membaca blog resmi DevGhost, dan saya adalah pendiri produknya. Ini sudut pandang penulis, bukan studi independen.

Untuk menilai software engineering itu sendiri—bukan bisnis atau produk secara keseluruhan—saya memakai tiga hal sederhana: kecepatan, kualitas, dan volume. Metrik DORA memberi tahu kita tentang kecepatan; tes dan defect memberi tahu kita tentang kualitas. Volume lebih sulit. Inilah wilayah yang paling jarang dijelajahi—dan tempat ghost yang kita cari cenderung bersembunyi.

DORA: kecepatan dan keandalan rilis

DORA menunjukkan seberapa cepat dan andal sebuah tim membawa perubahan ke production. Modelnya memakai lima metrik: waktu dari commit hingga production, frekuensi deployment, persentase deployment yang menimbulkan kegagalan, waktu pemulihan, serta porsi pengerjaan ulang yang tidak direncanakan.

Ini ukuran yang baik untuk proses delivery, tetapi bukan untuk kontribusi individu. Jika satu orang mengerjakan porsi tiga orang sementara orang lain bersembunyi di balik hasil tim, DORA tidak akan memberi tahu Anda.

Metrik ini juga luar biasa praktis dijadikan KPI. Di salah satu perusahaan tempat saya bekerja, kami sudah “memerahnya” sejak 2018—berhasil membuat semua dashboard hijau sementara semua orang tetap senang. Model DORA saat ini.

Tes dan defect: seberapa baik pekerjaan dilakukan

Metodenya sudah mapan dan terbukti bekerja. Kualitas dikendalikan melalui code review, tes, dan analisis statis; dampaknya dilacak melalui defect dan insiden.

Namun, sinyal ini tidak mengatakan apa pun tentang volume. Satu patch kecil yang sempurna dapat membuat semua indikator hijau—sementara ghost tetap tidak terlihat.

Jira dan story point: berapa tiket yang ditutup

Jira menunjukkan tiket yang ditutup dan story point, tetapi estimasinya ditentukan oleh tim sendiri. Pekerjaan yang sama bisa dinilai 3 atau 13 poin, dipecah menjadi 5 tiket atau digabung menjadi 1.

Story point berguna untuk perencanaan, tetapi tidak andal untuk mengukur kontribusi individu. Begitu poin menjadi target, orang mulai mengoptimalkan poin, bukan pekerjaan.

Ini juga KPI yang praktis. Data dimasukkan dan tiket dipindah-pindahkan semata-mata agar lolos quality gate. Banyak sekali pekerjaan manual yang sia-sia.

Commit dan baris kode: fakta tanpa konteks

Git tidak bergantung pada estimasi tim, sehingga menghitung commit dan baris kode terasa menggoda. Namun, lima commit bisa saja hanya satu patch kecil, sedangkan satu squash commit dapat mewakili pekerjaan selama seminggu.

Pemformatan, kode hasil generator, penyalinan, dan pemindahan kode sama-sama membengkakkan jumlah baris, sementara perbaikan yang sulit mungkin hanya sepanjang sepuluh baris.

Swarmia, LinearB, dan Waydev: seluruh sistem engineering di satu tempat

Swarmia, LinearB, dan Waydev menyatukan Git, issue tracker, dan CI/CD. Manajer dapat melihat metrik DORA, antrean review, lead time perubahan, dan hasil survei.

Platform ini memberikan gambaran berguna tentang sistem engineering—dan sering menunjukkan bahwa masalah ada pada proses, bukan pada seseorang. Namun, mengukur volume kerja developer secara individual dengan skala yang dapat dibandingkan bukanlah pertanyaan utama yang ingin mereka jawab. Swarmia, LinearB, Waydev.

GitClear: yang tersisa setelah noise kode disingkirkan

GitClear membedakan kode yang ditambahkan, dipindahkan, dan disalin, mengecualikan file hasil generator, serta memperhitungkan apakah kode baru kemudian ditulis ulang atau dihapus.

Hasilnya adalah Diff Delta—satuan milik GitClear untuk perubahan bermakna yang tetap berada di codebase. Kode salinan atau kode yang lekas dibuang memiliki bobot lebih kecil daripada perubahan ringkas yang terus berjalan di production. Cara kerja Diff Delta.

Diff Delta tidak menjawab berapa banyak kerja yang dibutuhkan. Ia menjawab berapa banyak perubahan bermakna yang bertahan setelah noise dan pengerjaan ulang. Kekuatan GitClear ada pada pengukuran ketahanan serta kualitas kode, dan pada analisis dampak AI.

Sekarang kita mulai mendekat. Layanan ini menerbitkan benchmark, tetapi Diff Delta tetap merupakan satuan tersendiri: angka 10.000 tidak banyak berarti tanpa pembanding yang tepat dan pemahaman tentang metodologinya. Tidak ada patokan jelas seperti “100% berarti normal”. Benchmark Diff Delta.

BlueOptima: pertanyaan yang sama dalam skala enterprise

Saya mengenal BlueOptima secara langsung. Saya mulai menggunakan platform ini pada 2019. Pengalaman itulah yang menginspirasi saya untuk membangun produk sendiri.

Algoritme Coding Effort menganalisis setiap perubahan source code memakai serangkaian metrik statis, dengan memperhitungkan ukuran, kompleksitas, dan kaitannya dengan bagian kode lain. Hasilnya kemudian dinyatakan dalam jam.

Dengan begitu, developer dari tim dan stack teknologi yang berbeda dapat dibandingkan, termasuk dengan benchmark global. Bagi saya, ini adalah upaya meyakinkan pertama untuk menjawab bukan “Berapa baris yang ditulis developer ini?”, melainkan “Berapa banyak pekerjaan substantif yang diwakili perubahan ini?” Metodologi BlueOptima, benchmark global.

Dalam kasus saya, kemampuan enterprise itu membutuhkan implementasi yang cukup berat: agent harus dipasang di dalam lingkungan jaringan tertutup, harganya tinggi, dan hasilnya memerlukan interpretasi ahli.

Bagi perusahaan dengan ribuan developer, hal itu mungkin layak. Bagi startup atau tim kecil, mungkin tidak. Kesenjangan itulah yang kemudian menjadi salah satu alasan DevGhost hadir.

Tolok ukur yang sama, tanpa proses tender

Ketika membangun DevGhost, saya tidak berniat menciptakan satu lagi platform serba ada yang penuh dengan segala metrik engineering yang bisa dibayangkan.

Saya menginginkan jawaban yang sama seperti yang diberikan BlueOptima—berapa banyak pekerjaan substantif di balik perubahan—tetapi dalam bentuk yang bisa dipakai pemilik startup atau tim kecil tanpa tender, proses implementasi panjang, ataupun satu tim konsultan.

Logikanya sederhana: DevGhost menganalisis perubahan itu sendiri—apa yang ditambahkan, dihapus, dan disusun ulang, serta seberapa sulit hasilnya dibuat dan diverifikasi. Pemformatan, pemindahan kode, penggantian massal otomatis, dan kode hasil generator dipisahkan dari pekerjaan substantif.

Hasilnya adalah estimasi upaya dalam jam ekuivalen: berapa lama waktu yang diperlukan developer tingkat menengah yang memahami codebase dan bekerja tanpa AI untuk menulis kode yang sama. Ini bukan waktu nyata yang dihabiskan di depan keyboard, juga bukan penilaian atas kualitas atau nilai bisnis kode tersebut. Ini adalah tolok ukur bersama untuk membandingkan perubahan. Pelajari metodologi DevGhost.

Ghost% membandingkan estimasi itu dengan output yang diharapkan dari developer tingkat menengah, sambil memperhitungkan berapa banyak waktu orang tersebut yang benar-benar dialokasikan untuk development. Hasil 100% berarti sesuai norma. Hasil lebih rendah adalah alasan untuk menyelidiki; hasil lebih tinggi layak dipelajari dan mungkin dijadikan praktik terbaik.

Benchmark ini sengaja mengasumsikan pekerjaan tanpa AI. DevGhost tidak mencoba menentukan siapa yang menulis potongan kode tertentu—manusia, Copilot, atau agent otonom. Yang dinilai adalah perubahan akhirnya: berapa banyak upaya yang diperlukan developer tingkat menengah untuk membuat dan memverifikasinya tanpa AI.

Artinya, efek AI tidak menghilang di dalam metrik, melainkan menjadi terlihat. Jika dalam satu periode seorang developer membuat dan memverifikasi hasil yang sebelumnya membutuhkan upaya dua atau tiga kali lipat, Ghost% akan mencerminkannya. Pemformatan, pembuatan kode secara massal, dan noise kode lainnya semestinya tidak menghasilkan efek yang sama.

Siapa yang menilai sang penilai?

Pertanyaan paling jelas adalah: mengapa kita harus mempercayai estimasi yang dihasilkan mesin? Jawaban singkatnya, jangan mempercayainya secara membabi buta.

Menilai tingkat kesulitan pekerjaan memang subjektif. Kami mengujinya dengan meminta beberapa developer berpengalaman menaksir perubahan yang sama—dan menerima angka yang cukup berbeda. Setiap orang punya kecepatan, pengalaman, dan pemahaman tentang kesulitan yang berbeda.

DevGhost juga bisa keliru. Keunggulannya bukan akses ke suatu kebenaran mutlak, melainkan bahwa setiap perubahan dinilai dengan tolok ukur yang sama—tanpa pilih kasih, kelelahan, atau pendapat yang sudah terbentuk tentang penulisnya.

Itulah sebabnya Ghost% adalah sinyal, bukan vonis. Hasil rendah mungkin menunjukkan kontribusi yang lemah, tetapi bisa pula dijelaskan oleh tanggung jawab sebagai team lead, pekerjaan arsitektur, mentoring, insiden, atau blocker.

Angka tersebut menunjukkan di mana pertanyaan perlu diajukan. Manajer tetap harus menemukan jawabannya—tetapi kini ia memiliki opini kedua yang independen, bukan hanya intuisi.

“Saya sudah tahu kinerja setiap orang di tim saya”

Salah satu klien DevGhost adalah pemimpin engineering di perusahaan AI yang berkembang pesat. Awalnya ia skeptis terhadap gagasan mengukur kinerja engineering. Posisinya sederhana: pemimpin teknis yang baik sudah tahu kinerja setiap orang tanpa dashboard.

Kami menganalisis riwayat repository yang sangat ia kenal. Sebelumnya sudah ada kekhawatiran terhadap tiga developer: tiket mereka bergerak lambat, tetapi mereka mengerjakan layanan terpisah sehingga sulit dibandingkan dengan anggota tim lain. DevGhost menunjukkan hasil rendah secara konsisten bagi ketiganya selama kira-kira enam bulan.

Kemudian, saat para developer itu mulai keluar, terungkap bahwa selama periode tersebut mereka juga membangun produk sendiri. DevGhost tidak mungkin mengetahui alasannya. Ia hanya menampilkan sesuatu yang tidak terlihat dari jumlah commit, pull request, dan percakapan harian di Slack: volume kerja mereka jelas lebih rendah dari yang diharapkan.

Namun, analisis itu tidak berubah menjadi daftar pemecatan. Bagi dua developer lain, hasil rendah justru memungkinkan pemberian umpan balik yang spesifik, penyelidikan sebabnya, dan perbaikan kinerja. Keduanya tetap bersama tim.

Developer yang ia anggap kuat juga muncul tepat di posisi yang ia harapkan. Kini terlihat bukan hanya siapa yang berkinerja di atas rata-rata, tetapi juga seberapa konsisten mereka melakukannya.

Tentu saja, satu kasus tidak membuktikan bahwa metode ini akurat. Yang mengejutkan klien tersebut adalah betapa dekat gambaran keseluruhannya dengan hal-hal yang sebelumnya hanya diketahui melalui intuisi—dan, dalam beberapa kasus, baru tampak jelas setelah semuanya berlalu.

Bagaimana jika satu developer menghasilkan output tiga orang?

Berburu ghost adalah bagian paling mencolok dari cerita ini. Namun, sisi atas grafik mungkin justru lebih berguna.

Jika seorang developer secara konsisten menghasilkan beberapa kali lipat output rata-rata, ada baiknya mencari tahu persis bagaimana ia melakukannya.

Sekarang pertanyaannya bukan lagi apakah seorang developer memakai AI—bagi banyak orang, AI sudah menjadi bagian normal dari pekerjaan. Pertanyaannya adalah seberapa efektif ia mengubah agent menjadi kapasitas delivery tambahan.

Seseorang berhenti pada autocomplete. Orang lain tahu cara memberi konteks yang tepat kepada agent, menetapkan aturan yang jelas, menjalankan beberapa tugas secara paralel, dan meninjau hasilnya dengan teliti. Akses ke AI yang sama pun dapat menghasilkan lonjakan produktivitas yang sama sekali berbeda.

Ghost% yang tinggi membantu menemukan developer yang sudah mendapatkan hasil kuat dari kolaborasi manusia dan agent itu—serta memahami praktik mana yang dapat diadopsi anggota tim lain.

Jika hasil tinggi tersebut didukung kualitas kerja dan penilaian manajer, developer itu patut dihargai, dipertahankan, dan dipertimbangkan untuk promosi. Praktiknya juga layak dipelajari dan disebarkan ke seluruh tim.

Jangan jadikan tolok ukur sebagai senjata

Setiap metrik menemui nasib yang sama: cepat atau lambat, seseorang mencoba mengubahnya menjadi KPI. Ghost% tidak cocok untuk itu.

Jadikan Ghost% KPI tim, orang akan mulai mengoptimalkan pekerjaan demi angka. Terbitkan peringkat, kepercayaan akan lenyap. Ubah skor menjadi tombol pemecatan, kesalahan menjadi tak terhindarkan.

Saya akan menetapkan empat aturan:

• Jangan menarik kesimpulan dari satu pengukuran atau periode yang singkat.
• Perhitungkan peran orang tersebut, porsi waktunya untuk development, dan pekerjaan di luar kode.
• Tunjukkan hasilnya kepada developer dan beri kesempatan untuk menjelaskan konteks.
• Jangan gunakan Ghost% sebagai satu-satunya dasar keputusan ketenagakerjaan.

Jika hasil rendah terus bertahan, manajer harus lebih dahulu menyelidiki penyebabnya. Mungkin orang tersebut memang kesulitan berkinerja. Atau mungkin ia mengerjakan arsitektur, menangani insiden milik orang lain, atau terhambat proses tim.

Jika masalahnya terbukti, perlu ada rencana perbaikan yang spesifik dan penilaian ulang setelah jangka waktu yang disepakati.

Menolak metrik tidak menghapus penilaian terhadap manusia. Anda hanya akan menyisakan firasat, cerita saat stand-up, dan preferensi pribadi manajer.

Kecepatan, kualitas, dan volume membutuhkan alat yang berbeda. DORA menunjukkan bagaimana perubahan bergerak menuju production. Tes dan defect menunjukkan kualitas. DevGhost menambahkan estimasi pekerjaan di balik perubahan kode.

Tidak satu pun dari metrik ini boleh mengambil keputusan untuk manajer.

Nilai sebuah angka bukan terletak pada kemampuannya menjatuhkan vonis. Nilainya terletak pada kemampuannya membuat percakapan sulit dimulai lebih awal—dan berpijak pada fakta.

Bagaimana Anda menilai volume kerja developer, dan di mana Anda menarik batas antara transparansi yang berguna dan pengawasan?