Mühendislik Metrikleri: Karne Değil, Pusula

Sahadan: sıralı tablo ve Can’ın 9 PR’ı

Mayıs başında bir pano kurdum. Niyetim iyiydi: “görünürlük”. Kişi başına üç sayı vardı: açılan PR, değişen satır ve sprint’te kapatılan story point. Panoyu her Pazartesi toplantısında ekrana açtım. Kimseyi eleştirmedim, sadece gösterdim. Gerek de yoktu; sıralı bir tablo kendi yorumunu kendisi yapıyor.

Altı hafta sonra sayılar şöyleydi:

Kimse hile yapmamıştı. Herkes panonun ödüllendirdiği şeyi yapmıştı. PR’lar bölünmüştü, tahminler büyümüştü. Son satır ise en sessiz ama en pahalısıydı: inceleme panoda sayılmıyordu, o yüzden inceleme yapılmıyordu. “LGTM” yazıp geçmek, kendi PR’ını açmaya ayrılacak zamanı kurtarıyordu.

Sonra o Pazartesi geldi. Can tablonun en altındaydı. Oysa altı hafta boyunca para çekme akışında, bazı çekimlerin iki kez işlenmesine yol açan bir hatanın peşindeydi. Üç servisi okudu, hatayı tekrar üretti, düzeltmeyi tek bir dikkatli PR olarak açtı. Tablo bunu “9” olarak gösterdi. Toplantıdan sonra yanıma geldi: “Bir dahaki sefere bunu beş PR’a bölerim.” Şaka yapmıyordu.

Hata benimdi. Panoyu o hafta kaldırdım ve bir sonraki toplantıda ekipten özür diledim. Ölçmekten vazgeçmedim; neyi ve kimi ölçtüğümü değiştirdim.

Bireysel metrik neden oyunlaşıyor

Bunun bir adı var: Goodhart yasası. Bir ölçü hedef hâline geldiğinde, iyi bir ölçü olmaktan çıkar. Yazılımda bu yasa özellikle hızlı çalışıyor, çünkü mühendisler sistemi optimize etmek için para alıyor. Önlerine bir sayı koyarsan, onu da optimize ederler.

Story point ayrıca bir yanlış anlamaya dayanıyor. Story point bir tahmin birimi, üretkenlik birimi değil; işi sprint planning’de kapasiteyi konuşmak için var. Onu kişiler arasında karşılaştırmak, iki farklı cetveli yan yana koymak gibi.

Asıl zarar ise sayıların dışında kalıyor. Pano, sayılmayan her işi görünmez kıldı: inceleme, yeni gelene yardım, gece olay çözmek, zor bir hatanın peşinde üç gün okumak. Bir ekibi ekip yapan işlerin çoğu tam olarak bunlar.

Karne ile pusula arasındaki fark

Aynı sayı iki farklı şekilde kullanılabilir. Fark sayıda değil, kullanımda:

DORA: ekibi ölçen dört sayı

Temmuz’da yeniden başladım, bu sefer DORA araştırmasının dört metriğiyle. Seçme sebebim basit: dördü de ekibin sayısı. Hiçbiri tek bir kişiye bölünemiyor. Deploy’u bir kişi yapmaz, olayı bir kişi çözmez.

• Deploy frequency: ne sıklıkla canlıya çıkıyorsun.
• Lead time for changes: bir commit’in canlıya ulaşması ne kadar sürüyor.
• Change failure rate: deploy’ların yüzde kaçı bir şeyi bozuyor.
• Time to restore: bir şey bozulduğunda hizmeti ne kadar sürede geri getiriyorsun.

İlk ikisi hız, son ikisi kararlılık. İkisini ayırma. Sadece hızı ölçersen ekip hızlı ve kırılgan olmayı öğrenir; sadece kararlılığı ölçersen hiç deploy etmemek en iyi skoru verir.

Tanımları kâğıda yazmak şart, çünkü takım düzeyindeki metrik de oyunlaşabilir. En kolay yolu, bozuk deploy’u “olay değil, küçük bir sorundu” diye saymamak. Bizim tanımlarımız şöyle:

DEPLOY FREQUENCY : canliya cikan surum sayisi / hafta
                   kaynak: deploy logu. config degisikligi sayilmaz.

LEAD TIME        : ilk commit -> canlida calisiyor (medyan)
                   kaynak: git + deploy logu. backlog bekleme dahil degil.

CHANGE FAILURE   : bozuk deploy / toplam deploy
                   bozuk = su uc seyden biri olduysa:
                     1) surum geri alindi
                     2) 24 saat icinde hotfix cikti
                     3) olay kaydi acildi
                   "kucuk bir sorundu" diye bir istisna YOK.

TIME TO RESTORE  : olay basladi -> kullanici etkisi bitti
                   kaynak: olay kaydi. kok neden cozumu degil,
                   hizmetin geri gelmesi olculur.

Sayı nereye bakacağını söyler

İlk ölçümde lead time medyanı 6,5 gün çıktı. Toplantıda ilk tepki “kod yazmak uzun sürüyor” oldu; herkesin aklına ilk gelen buydu. Süreyi parçalara ayırınca tablo başka bir şey söyledi:

                    TEMMUZ    KASIM
kod yazma            1,2       1,1
review bekleme       1,1       1,0
merge -> canli       4,2       0,7    <-- asil fark burada
-----------------------------------
toplam               6,5       2,8

# Temmuz: merge edilen is Persembe surum trenini bekliyordu.
# Kasim : merge sonrasi otomatik test + tek tik deploy.
# not: parcalar ayri ayri medyan; toplam yaklasik degerdir.

6,5 günün 4,2 günü, işin bitmiş hâlde haftalık sürüm trenini beklemesiydi. Kimse daha hızlı kod yazmadı; kod yazma adımı zaten neredeyse aynı kaldı. Değişen tek şey, merge edilen işin Perşembe’yi beklememesi oldu. Bu kararı almak için bir sayıya ihtiyacım vardı ve kişi başı pano bana bu sayıyı hiç vermedi.

Burası metriğin gerçek işi. Sayı teşhis koymaz, nereye bakacağını söyler. Teşhisi yine ekip koyar. Teknik strateji yazısında teşhisin rakamla yazılması gerektiğini söylemiştim; bu dört sayı o rakamların ilk kaynağı oldu.

Ne izlemeli?

Dört haftalık pencerelerle ölçüyoruz. Temmuz ilk ölçüm, Kasım son dört hafta:

Bir çekince: dört haftada iki olay istatistik değil, anekdot. 35 dakikalık bir olay ile 61 dakikalık bir olayın ortalaması, bir sonraki ay tek bir kötü gece ile ikiye katlanabilir. Bu yüzden tek bir ayın sayısıyla karar vermiyoruz; üç pencere üst üste aynı yöne gidiyorsa trend diyoruz.

Nasıl kullanıyoruz

• Ayda bir, 30 dakika, ekiple. Sayıları önce ekip görüyor. Yönetime giden rapor, ekibin yorumuyla birlikte gidiyor; tek başına tablo gitmiyor.
• Karşılaştırma yok. Ne kişiler arası ne ekipler arası. Ödeme ekibinin lead time’ı ile mobil ekibin lead time’ı aynı şeyi ölçmüyor.
• Hedef sayı yok, yön var. “Lead time 2 güne insin” demedik. “Lead time nerede bekliyor?” diye sorduk. Hedef sayı koyduğun gün Goodhart geri geliyor.
• Değerlendirmeye bağlanmıyor. Bu dört sayı hiçbir kişinin performans görüşmesine girmiyor. Girdiği gün pusula yeniden karneye döner.

Peki kişiyi nereden göreceğim?

Panoyu kaldırdığımda ilk gelen soru buydu, hem ekipten hem yukarıdan: “Kim ne yapıyor, artık nasıl bileceğiz?” Dürüst cevap şu: yedi kişilik bir ekipte kimin ne yaptığını bilmek için panoya ihtiyacın varsa, eksik olan veri değil. Eksik olan konuşma.

Can’ın altı haftasını pano görmedi ama ben görebilirdim. Daily’de her gün aynı hatadan bahsediyordu, PR’ındaki açıklama iki sayfaydı, iki ekip arkadaşı onun bulgusu sayesinde kendi servislerinde benzer bir sorunu kapatmıştı. Bunların hiçbiri bir sayı değildi. Hepsi, bakmayı bilen birine görünüyordu.

Kişiyi görmenin yolu hâlâ aynı: bire bir, iş arkadaşlarının geri bildirimi, işin kendisini okumak. Yavaş ve sayılamaz. Ama oyunlaştırılamaz da. Sayıyı ekibin sistemine, dikkati insana ayırdığımda ikisi de daha iyi çalıştı.

Bende işe yaramayanlar

• Panoyu anonimleştirmek. Kişi başı panoyu kaldırmadan önce isimleri gizlemeyi denedim. Yedi kişilik ekipte herkes kimin kim olduğunu iki günde çözdü.
• Dört metriği tek skora çevirmek. “Mühendislik sağlık puanı” diye tek bir sayı ürettim. Puan düştüğünde kimse neden düştüğünü anlamadı; tek sayı, dört sorunun dördünü de sakladı.
• Araç satın almakla başlamak. İlk ay bir metrik aracı denedik; varsayılan panosu yine kişi başı PR sayısı gösteriyordu. İlk üç ay sayıları deploy logundan ve olay kayıtlarından, basit bir tabloyla çıkardık. Tanım netleşmeden araç, yanlış sayıyı daha güzel gösteriyor.

Kontrol listesi

Sonuç

Can’ın 9 PR’ı, o altı haftanın en değerli işiydi. Tablo onu en alta koydu, çünkü tablo tam olarak benim ona sorduğum soruyu cevaplıyordu: “Kim çok PR açtı?” Yanlış olan sayı değildi, soruydu.

Dört DORA metriği mükemmel değil. Ama ikisi hızı, ikisi kararlılığı ölçtüğü ve hiçbiri bir kişiye bölünemediği için oyunlaştırılması zor. Daha önemlisi, bize kod yazmanın değil, Perşembe’yi beklemenin yavaş olduğunu gösterdiler.

Test şu: metriğin, ekibine hangi soruyu sorduruyor? Cevap “kim geride kalıyor” ise elinde bir karne var. “Nerede bekliyoruz” ise, pusula.