Hayalet avı: geliştiricilerin gerçek katkısı nasıl anlaşılır?

“Ghost engineers” — her on geliştiriciden biri neredeyse hiçbir yararlı iş yapmıyor, yalnızca çok meşgul görünmeyi başarıyor. Bu hareketsizliğin gerçek nedenleri — başka bir işte çalışma, tükenmişlik ya da düpedüz kaytarma — yönetimden çok uzun süre saklı kalabiliyor. (2024 Stanford araştırması: orijinal paylaşım dizisi)

Geliştiriciler performansları gündeme geldiğinde bundan hoşlanmaz. Mesleğin uzun “altın çağından” sonra sektörde basit bir sorunun etrafında tabu oluştu: yazılım geliştirme çıktısı, harcanan zaman ve paraya değiyor mu? Ne var ki hayalet meslektaşlar geliştiricileri de rahatsız eder — üstelik sorunu yönetimden önce genellikle ekip fark eder.

Rusya’da tarihsel olarak “ispiyonculuk” hoş karşılanmaz. Bu yüzden sorunu birçok kişi bildiği hâlde kimse konuşmak istemez: başkasının kavgasına neden karışsın? Her şey ancak ekibin sabrı tamamen tükendiğinde ortaya dökülür.

Belki de onları rahat bırakmalıyız — şu hayaletleri. Sonuçta şirket o paranın eksikliğini bile hissetmez.

Ama işin bir püf noktası var…

Düşük performans derken Ali’nin harıl harıl çalışıp Mehmet’ten %10 daha az iş çıkarmasını kastetmiyorum. Başka bir şeyden söz ediyorum: her stand-up’ta bütün ekip yeni bir acıklı hikâye dinliyor — diğer ekip işi aksattı, görev tanımı belirsizdi, yıldızlar hizalanmadı. Ama yarın görev kesinlikle bitecek. Namus sözü.

Ne var ki bu “yarın” dün de vardı, önceki gün de — artık bir geleneğe dönüştü.

Ekipler böyle şeyleri çabuk fark eder. İşi gerçekten sırtlayanların aklına doğal olarak şu soru gelir: masal anlatıp hiçbir sonuçla karşılaşmamak mümkünse neden kendimizi paralayalım?

Ancak sorunu fark etmek yetmez. Eldeki sayılar ve gerçekler olmadan konuşma hızla tartışmaya döner: ekip “düşük performans gösteriyor” der, geliştirici “çalışmama izin vermiyorlar” diye karşılık verir. Genellikle sabır tükendikten ve ekip yöneticiden geliştiriciyi değiştirmesini istedikten sonra konu araştırılmaya başlanır.

İşte o zaman uzun bir süreç başlar: gerçekleri toplamak, iki tarafı da dinlemek, kişiye geri bildirim vermek ve durumu düzeltmesi için zaman tanımak. Benim deneyimimde bu süreç çoğunlukla hayaletin yeni — ve çok şanslı — bir işverene geçmesiyle sonuçlanır.

Sorun yalnızca bir kişinin daha az iş yapması değildir. Şirket iki kez ödeme yapar: önce hiç tamamlanmayan iş için, sonra da her şeyi yeniden kontrol eden, açığı kapatan ve nedenini anlamaya çalışan ekip arkadaşlarıyla yöneticilerin zamanı için. Sonunda düşük performans gösteren artık tek bir geliştirici değil, bütün ekiptir.

Bir yönetici sorunu daha erken fark edebilir mi — sapmayı görüp bağlam isteyebilir ve ekip sabrını, şirket de zamanla parasını kaybetmeden önce durumu araştırabilir mi?

Yeterli deneyimle bu hikâyeler bazı belirgin davranış kalıplarından önceden anlaşılabilir:

• Başarı benim, başarısızlık senin.
• Henüz başlanmamış bir görevin başarısızlığı için şimdiden bahane hazırlamak.
• Yetkinlik eksikliğini aşırı konuşkanlıkla kapatmak.
• Zamanla özellikle yöneticiyi “suçlu” ilan etmek.
• Gerçekten zorlanan birinin aksine, doğrudan geri bildirimden sonra bile davranışı iyileştirmemek.

Fakat şüpheleri doğrulamak için dijital izlere ihtiyaç var.

Yazılım geliştirme performansını değerlendirmekte kullanılan yaygın araçlara ve hayaletleri ortaya çıkarıp çıkaramadıklarına bakalım.

Karşılaştırmaya başlamadan önce açık çıkar çatışmasını belirteyim: DevGhost’un resmî blogunu okuyorsunuz, ben de ürünün kurucusuyum. Dolayısıyla bu bağımsız bir araştırma değil, yazarın değerlendirmesidir.

İşletmenin ya da ürünün tamamını değil, doğrudan yazılım geliştirme performansını değerlendirmek için basit bir üçlü kullanıyorum: hız, kalite ve iş hacmi. Hızı DORA metrikleri, kaliteyi testler ve hatalar gösterir. İş hacmi daha zordur: en az keşfedilmiş alan burasıdır ve aradığımız hayaletler de burada saklanır.

DORA: sürüm hızı ve güvenilirliği

DORA, bir ekibin değişiklikleri production’a ne kadar hızlı ve sorunsuz ulaştırdığını gösterir. Model beş metriği kapsar: commit’ten production’a kadar geçen süre, deployment sıklığı, başarısızlığa yol açan deployment oranı, toparlanma süresi ve planlanmamış düzeltmelerin oranı.

Bu, delivery süreci için iyi bir ölçüdür; bireysel katkı için değil. Bir kişi üç kişilik işi yaparken diğeri ekibin toplam sonucunun arkasına saklanıyorsa DORA bunu göstermez.

Bu metrikler KPI olarak da son derece kullanışlıdır. Çalıştığım bir şirkette 2018’den beri sonuna kadar sağılıyorlardı: bütün dashboard’lar başarıyla yeşile boyanıyor, herkes mutlu oluyordu. Güncel DORA modeli.

Testler ve hatalar: iş ne kadar iyi yapıldı?

Bu yöntemler uzun zamandır biliniyor ve pratikte işe yarıyor. Kalite code review, testler ve statik analizle kontrol edilir; sonuçlar hata ve incident’lar üzerinden izlenir.

Ancak bu sinyaller iş hacmi hakkında hiçbir şey söylemez. Küçük ve kusursuz tek bir değişiklik bütün göstergeleri yeşile çevirir — hayalet ise görünmez kalır.

Jira ve story point’ler: kaç görev kapatıldı?

Jira kapanan görevleri ve story point’leri gösterir, ancak tahminleri ekibin kendisi belirler. Aynı işe üç ya da on üç puan verilebilir, iş beş göreve bölünebilir veya tek görevde birleştirilebilir.

Story point’ler planlama için yararlıdır ama bireysel katkıyı ölçmekte güvenilir değildir. Puanlar hedefe dönüştüğünde insanlar puanları optimize etmeye başlar.

KPI için de kullanışlıdırlar. Veriler girilir, görevler yalnızca quality gate’leri geçmek için ilerletilir. Bol miktarda anlamsız el işi.

Commit’ler ve kod satırları: bağlamsız gerçekler

Git ekip tahminlerine bağlı değildir; bu yüzden commit’leri ve satırları saymak cazip gelir. Fakat beş commit tek bir küçük düzeltme olabilirken bir squash commit bir haftalık işi temsil edebilir.

Biçimlendirme, kod üretme, kopyalama ve taşıma satır sayısını şişirir; oysa zor bir düzeltme yalnızca on satır tutabilir.

Swarmia, LinearB ve Waydev: bütün mühendislik sistemi tek yerde

Swarmia, LinearB ve Waydev; Git’i, görev takip sistemini ve CI/CD’yi bir araya getirir. Yöneticiler DORA metriklerini, review kuyruklarını, değişikliklerin geçiş süresini ve anket sonuçlarını görebilir.

Mühendislik sistemine dair yararlı bir resim sunarlar — ve çoğu zaman sorunun kişide değil süreçte olduğunu gösterirler. Ancak belirli bir geliştiricinin iş hacmini karşılaştırılabilir bir ölçekte değerlendirmek bu platformların yanıtlamaya çalıştığı temel soru değildir. Swarmia, LinearB, Waydev.

GitClear: kod gürültüsü ayıklandığında geriye ne kalır?

GitClear eklenen, taşınan ve kopyalanan kodu birbirinden ayırır, üretilmiş dosyaları hariç tutar ve yeni kodun sonradan yeniden yazılıp yazılmadığını ya da silinip silinmediğini hesaba katar.

Böylece kod tabanında kalan anlamlı değişiklikler için GitClear’ın kendi birimi olan Diff Delta hesaplanır. Kopyalanan veya hızla çöpe atılan kod, production’da çalışmaya devam eden küçük ve özlü bir değişiklikten daha az ağırlık taşır. Diff Delta nasıl çalışır?.

Diff Delta ne kadar iş gerektiğini değil, gürültü ve yeniden çalışmadan sonra ne kadar anlamlı değişiklik kaldığını söyler. GitClear; kodun kalıcılığını ve kalitesini ölçmekte, ayrıca AI’ın etkisini analiz etmekte en güçlüdür.

Şimdi biraz yaklaştık. Hizmet benchmark’lar yayımlar, ancak Diff Delta kendine özgü birim olarak kalır: 10.000 gibi bir sayı, doğru karşılaştırma ve metodoloji bilgisi olmadan pek anlam taşımaz. Burada “%100 normaldir” gibi açık bir referans noktası yoktur. Diff Delta benchmark’ları.

BlueOptima: aynı soru, kurumsal ölçekte

BlueOptima’yı ilk elden tanıyorum. Platformla 2019’da çalışmaya başladım. Kendi ürünümü geliştirmem için bana ilham veren de bu deneyimdi.

Coding Effort algoritması her kaynak kodu değişikliğini bir dizi statik metrikle analiz eder; değişikliğin boyutunu, karmaşıklığını ve kodun geri kalanıyla ilişkisini hesaba katar, sonucu da saat cinsinden ifade eder.

Bu sayede farklı ekip ve teknoloji yığınlarındaki geliştiriciler, küresel benchmark da dâhil olmak üzere karşılaştırılabilir. Benim için bu, “Bu geliştirici kaç satır yazdı?” sorusu yerine “Bu değişikliklerin arkasında ne kadar anlamlı iş var?” sorusuna verilen ilk ikna edici yanıttı. BlueOptima metodolojisi, küresel benchmark.

Benim durumumda bu kurumsal yeteneklere ulaşmak oldukça ağır bir kurulum gerektirdi: kapalı bir ağ ortamına ajan kurulması gerekiyordu, fiyat yüksekti ve sonuçlar uzman yorumu istiyordu.

Binlerce geliştiricisi olan bir şirket için bu makul olabilir. Bir startup veya küçük ekip içinse muhtemelen değildir. Daha sonra DevGhost’un ortaya çıkma nedenlerinden biri de bu boşluk oldu.

Aynı ölçü, ihale derdi olmadan

DevGhost’u geliştirirken akla gelebilecek her mühendislik metriğini içeren bir platform daha kurmaya çalışmadım.

BlueOptima’nın verdiği yanıtı — değişikliklerin arkasında ne kadar anlamlı iş olduğunu — istedim; fakat bir startup sahibinin veya küçük ekibin bunu ihale, uzun bir kurulum ve danışman ordusu olmadan alabilmesini amaçladım.

Mantık basit: DevGhost değişikliklerin kendisini analiz eder — ne eklendi, silindi ve yeniden yapılandırıldı, sonucu üretmek ve doğrulamak ne kadar zordu? Biçimlendirme, kod taşıma, toplu otomatik değiştirmeler ve üretilmiş kod anlamlı işten ayrılır.

Sonuç, eşdeğer saat cinsinden bir çaba tahminidir: kod tabanını bilen ve AI olmadan çalışan orta düzey bir geliştiricinin aynı kodu yazması ne kadar sürerdi? Bu, klavye başında geçirilen gerçek süre veya kodun kalitesi ya da iş değeri hakkında bir değerlendirme değildir; değişiklikleri karşılaştırmak için ortak bir ölçüdür. DevGhost metodolojisi hakkında daha fazla bilgi.

Ghost%, bu tahmini orta düzey bir geliştiriciden beklenen çıktıyla karşılaştırırken kişinin zamanının ne kadarını gerçekten yazılım geliştirmeye ayırdığını da hesaba katar. %100, normla aynı düzeyde olunduğu anlamına gelir. Daha düşük bir sonuç nedenleri araştırmak için işarettir; daha yüksek bir sonuç ise incelenmeye ve belki iyi uygulamaya dönüştürülmeye değerdir.

Referans değer bilerek AI kullanılmadan çalışıldığını varsayar. DevGhost belirli bir parçayı kimin yazdığını — insan, Copilot veya otonom bir ajan — belirlemeye çalışmaz. Nihai değişiklikleri değerlendirir: orta düzey bir geliştiricinin bunları AI yardımı olmadan üretip doğrulaması ne kadar çaba gerektirirdi?

Böylece AI’ın etkisi metriğin içinde kaybolmaz, görünür hâle gelir. Bir geliştirici belirli bir dönemde eskiden iki veya üç kat fazla çaba gerektirecek bir sonucu üretip doğruluyorsa Ghost% bunu gösterir. Biçimlendirme, toplu üretim ve başka kod gürültüleri aynı etkiyi yaratmamalıdır.

Peki, değerlendiren kim?

En açık soru şu: makinenin ürettiği bir tahmine neden güvenelim? Kısa yanıt: körü körüne güvenmemeliyiz.

İşin zorluğunu değerlendirmek doğası gereği özneldir. Bunu test ettik: aynı değişiklikleri birkaç deneyimli geliştiriciye tahmin ettirdik ve belirgin biçimde farklı sayılar aldık. Herkesin hızı, deneyimi ve zorluk anlayışı farklıdır.

DevGhost da yanılabilir. Avantajı mutlak gerçeğe erişmesi değil, bütün değişiklikleri aynı ölçüyle değerlendirmesidir — sempati, yorgunluk veya yazar hakkında önceden oluşmuş bir görüş olmadan.

Bu nedenle Ghost% bir hüküm değil, sinyaldir. Düşük sonuç zayıf katkıya işaret edebilir; ancak ekip liderliği sorumlulukları, mimari çalışma, mentorluk, incident’lar veya blocker’lar da aynı sonucu açıklayabilir.

Sayı, sorunun nerede sorulması gerektiğini gösterir. Yanıtı yine yöneticinin bulması gerekir — ama artık yalnızca sezgiye değil, bağımsız bir ikinci görüşe de dayanabilir.

“Ekibimde kimin nasıl çalıştığını zaten biliyorum”

DevGhost müşterilerinden biri, hızla büyüyen bir AI şirketinin mühendislik lideri. Başlangıçta yazılım geliştirme performansını ölçme fikrine şüpheyle yaklaşıyordu. Görüşü basitti: iyi bir mühendislik lideri, dashboard olmadan da herkesin nasıl çalıştığını bilir.

İyi bildiği bir repository’nin geçmişini analiz ettik. Üç geliştirici hakkında daha önce de endişeler vardı: görevleri yavaş ilerliyordu, ancak ayrı bir servis üzerinde çalıştıkları için ekibin geri kalanıyla karşılaştırılmaları zordu. DevGhost, üçünde de yaklaşık altı ay boyunca istikrarlı biçimde düşük sonuç gösterdi.

Daha sonra geliştiriciler ayrılmaya başlayınca, bütün bu süre boyunca kendi ürünlerini de geliştirdikleri ortaya çıktı. DevGhost bunun nedenini bilemezdi. Yalnızca commit sayılarının, pull request’lerin ve Slack’teki günlük konuşmaların gösteremediği bir şeyi ortaya çıkardı: iş hacimleri beklenenden belirgin biçimde düşüktü.

Ancak analiz işten çıkarılacaklar listesine dönüşmedi. Diğer iki geliştiricide düşük sonuç, somut geri bildirim vermeyi, nedenleri bulmayı ve performansı artırmayı sağladı. İkisi de ekipte kaldı.

Güçlü bulduğu geliştiriciler de tam beklediği yerde çıktı. Artık yalnızca kimin beklentileri aştığını değil, bunu ne kadar istikrarlı yaptığını da görebiliyordu.

Elbette tek bir vaka yöntemin doğruluğunu kanıtlamaz. Müşteriyi şaşırtan, genel resmin önceden yalnızca sezgi düzeyinde bilinenlerle ne kadar örtüştüğü — ve bazı şeylerin ancak sonradan açık hâle gelmesiydi.

Bir geliştirici üç kişilik çıktı üretirse ne olur?

Hayalet avı bu hikâyenin en çok dikkat çeken kısmı. Fakat grafiğin üst tarafı daha yararlı olabilir.

Bir geliştirici istikrarlı biçimde ortalamanın birkaç katı çıktı üretiyorsa bunu tam olarak nasıl başardığını anlamaya değer.

Bugün soru artık bir geliştiricinin AI kullanıp kullanmadığı değil — AI birçok kişi için işin sıradan bir parçasına dönüştü. Asıl soru, kişinin ajanları ek üretim kapasitesine ne kadar etkili dönüştürdüğüdür.

Biri yalnızca otomatik tamamlamayla yetinir. Diğeri ajanlara doğru bağlamı vermeyi, açık kurallar tanımlamayı, birkaç görevi paralel yürütmeyi ve çıktıyı dikkatle incelemeyi bilir. Dolayısıyla AI’a aynı erişim, bütünüyle farklı verimlilik artışları sağlayabilir.

Yüksek Ghost%, insan-ajan iş birliğinden şimdiden güçlü sonuç alan geliştiricileri bulmaya ve ekibin geri kalanının hangi uygulamaları benimseyebileceğini anlamaya yardımcı olur.

Yüksek sonuç işin kalitesi ve yöneticinin değerlendirmesiyle doğrulanıyorsa bu geliştiriciye değer vermek, onu elde tutmak ve terfi için değerlendirmek gerekir. Uygulamaları da incelenmeli ve ekip içinde yaygınlaştırılmalıdır.

Ölçüyü sopaya çevirmeyin

Her metriğin kaderi aynıdır: er ya da geç biri onu KPI’a çevirmeye çalışır. Ghost% buna uygun değildir.

Ghost%’ı ekip KPI’ı yaparsanız insanlar işlerini ona göre optimize etmeye başlar. Sıralama yayımlarsanız güven kaybolur. Skoru işten çıkarma düğmesine çevirirseniz hatalar kaçınılmaz olur.

Dört kural koyardım:

• Tek bir ölçümden veya kısa bir dönemden sonuç çıkarmayın.
• Kişinin rolünü, zamanının ne kadarını yazılım geliştirmeye ayırdığını ve kod dışındaki çalışmalarını hesaba katın.
• Sonucu geliştiriciye gösterin ve bağlamı açıklama fırsatı verin.
• Ghost%’ı bir istihdam kararının tek dayanağı olarak kullanmayın.

Düşük sonuç sürüyorsa yönetici önce nedenlerini anlamalıdır. Belki kişi gerçekten zorlanıyordur. Belki de mimariyle uğraşıyor, başkalarının incident’larını çözüyor veya ekip süreçleri yüzünden ilerleyemiyordur.

Sorun doğrulanırsa somut bir iyileştirme planı hazırlanmalı ve kararlaştırılan sürenin sonunda yeniden değerlendirme yapılmalıdır.

Metrikleri reddetmek insanları değerlendirmeyi ortadan kaldırmaz. Yalnızca sayıların yerini sezgiler, stand-up hikâyeleri ve yöneticinin kişisel sempatisi alır.

Hız, kalite ve iş hacmi farklı araçlar gerektirir. DORA değişikliklerin production’a nasıl ilerlediğini gösterir. Testler ve hatalar kaliteyi gösterir. DevGhost ise kod değişikliklerinin arkasındaki işi tahmin eder.

Bu metriklerin hiçbiri yönetici adına karar vermemelidir.

Bir sayının değeri hüküm vermesinde değildir. Zor bir konuşmanın daha erken ve gerçeklere dayanarak başlamasını sağlamasındadır.

Siz geliştiricilerin iş hacmini nasıl değerlendiriyorsunuz — yararlı şeffaflık ile gözetim arasındaki sınırı nerede çiziyorsunuz?