Ana sayfa → Ekip Yönetimi

Darboğaz Yazmak Değil, İncelemek: AI Sonrası Ekip Hızı

Çeyrek sonu toplantısı. Ekran paylaştım: haftalık ortalama açılan PR sayısı 19’dan 34’e çıkmış. Odada memnun bir sessizlik. İkinci slaytta teslim edilen iş vardı: neredeyse aynı. Üçüncüde sebebi: review kuyruğunda bekleme süresi 0,9 günden 2,5 güne çıkmıştı. Daha hızlı yazıyorduk ve aynı hızda teslim ediyorduk. Fark, birilerinin ekranında bekliyordu.

Sertaç Yıldırım · 22 Eylül 2026, 15:00 · 7 dk okuma

Neden hızlanmadık?

Cevap sistem düşüncesinde: bir hattı hızlandırdığında hat hızlanmaz, darboğaz yer değiştirir. Yazma adımını iki kattan fazla hızlandırdık; sıradaki adımlar aynı kaldı.

Tablonun söylediği şey açık: yazmada kazandığımız 1,3 günü, incelemede 1,6 gün kaybettik. Üstelik kimse kötü bir şey yapmadı; herkes daha çok üretti. Sistem, daha çok üretimi teslime çeviremedi.

Ölçüyü değiştir

İlk yaptığım şey slaytı değiştirmek oldu. PR sayısı, satır sayısı ve kapanan ticket sayısı artık ekipte konuşulmuyor; üçü de AI ile birlikte yukarı gidiyor ve hiçbir karar üretmiyorlar.

Metrik değişince konuşma da değişti. “Kim ne kadar yazdı” kimseyi bir yere götürmüyordu; “iş nerede bekliyor” sorusunun cevabı ise bir tabloda duruyor ve düzeltilebiliyor. Performansı ölçmekle ilgili eski kural burada da geçerli: kolay sayılan şey, ölçülmesi gereken şey değildir.

Dört değişiklik

1. Açık PR sayısına sınır

Kişi başı en fazla 2 açık PR. Üçüncüsünü açmadan önce birini kapatman gerekiyor — bu genelde “git birinin PR’ını incele” demek. Kural kulağa bürokratik geliyor; etkisi ilk haftada göründü: açık PR sayısı 23’ten 11’e düştü, bekleme süresi 2,5 günden 1,1 güne indi. Fark yeni koddan gelmedi; birikmiş kodun teslim edilmesinden geldi.

2. PR boyutu: 400 satır

400 satırı geçen PR’a bot otomatik yorum atıyor: “bu PR bölünebilir mi?” Yasak değil, soru. Ölçtüğümüz fark ikna edici:

Üçüncü sütuna dikkat: yorum sayısı 400 satıra kadar artıyor, ondan sonra düşüyor. Sınırı tam oraya koymamızın sebebi de bu. Düşen yorum sayısı incelemenin iyileştiğini değil, bırakıldığını gösteriyor. 1.400 satırı kimse satır satır okumuyor; onay “çalışıyor gibi görünüyor” seviyesinde veriliyor ve geri alma oranı neredeyse dört katına çıkıyor.

AI burada çözümün de parçası: aynı araçla büyük değişikliği üç parçaya bölmek, eskiden elle yapılan sıkıcı işti. Artık bahane yok.

3. “Neden” açıklaması zorunlu

AI ile yazılan kodda yeni bir boşluk var: kodu yazan kişi bazen neden öyle olduğunu bilmiyor. “Böyle önerdi, çalıştı.” İnceleyen kişi de bilmiyor. İki kişi, kimsenin gerekçesini bilmediği bir kodu onaylıyor.

PR açıklaması şablonuna üç satır ekledik:

• Ne denendi, ne çalışmadı? (Bir cümle yeter.)
• Bu değişikliğin riski nerede? Yazarın kendi cevabı.
• Kodu kasten bozunca hangi test kırmızıya döndü? (Test gerçekten bir şey yakalıyor mu?)

Üçüncü madde en çok işe yarayanı oldu. AI test de yazıyor ve yazdığı testin gerçekten bir şeyi kontrol edip etmediği ayrı bir soru. Kodu kasten bozup testin kırmızıya döndüğünü görmek 2 dakika sürüyor; ilk ayda 6 testin hiçbir şeyi kontrol etmediğini bu şekilde bulduk.

4. İnceleme takvime girer

“Boşta kalınca bakarım” en iyi niyetli ertelemedir; kimse boşta kalmaz. Sabah 09:30–10:15 arası takvimde bir blok: inceleme. Toplantı konmuyor. Kuyruk eriyene kadar değil, her gün.

Bunun ekip üzerindeki etkisi beklediğimden fazla oldu: inceleme “işin arasına sıkıştırılan bir şey” olmaktan çıkınca yorumların tonu değişti. “LGTM” yerine gerçek sorular gelmeye başladı: “bu alan null gelirse ne oluyor?” Aşağıdaki tabloda yorum sayısının ve geri alma oranının nereye gittiği duruyor; o rakamlar bu bloğun tek başına sonucu değil, dört değişikliğin birlikte etkisi.

Sahadan: altı hafta

İlk iki satır kasıtlı: açılan PR sayısı düştü, teslim edilen iş arttı. Düşen PR sayısı bir başarısızlık değil; biriken iş azaldı. Ekibe söylediğim cümle şuydu: “Daha az başlayacağız, daha çok bitireceğiz.”

Yöneticinin işi burada ne?

Üç şey, üçü de popüler değil:

• Kapasiteyi kaydırmak. İnceleme ve test tarafına zaman ayırmak, yeni özellik yazımından eksiltmek demek. Bunu savunacak kişi sensin; ekip savunamaz.
• Üretim metriklerini gündemden çıkarmak. Yukarıya rapor veriyorsan orada da değiştirmen gerekiyor, yoksa ekip iki farklı ölçüye göre çalışır. Yukarı yönetmenin tam olarak işe yaradığı yer burası.
• Junior’ın öğrenme yolunu korumak. Üretim artınca en çok sıkışan kişi öğrenen kişidir: kod hazır geliyor, inceleme kuyruğu uzun, soru sorma alanı daralıyor. AI mı, liderlik mi yazısındaki mesele burada somutlaşıyor: eşleştirme, açıklama ve bilinçli yavaşlatma.

Ne izlemeli?

• Lead time (p50 / p85). Tek sayı değil dağılım; uzun kuyruk nerede?
• İncelemede bekleme. PR açılışından ilk yoruma kadar geçen süre.
• Aynı anda açık PR. WIP; artıyorsa teslim değil, başlangıç artıyordur.
• PR boyutu dağılımı. 400 satır üstü oranı.
• PR başına yorum. Düşüyorsa inceleme bırakılıyordur.
• Canlıda geri alma oranı. Kalitenin en dürüst sayısı.
• İnceleme yükünün dağılımı. İncelemelerin yarısını bir kişi yapıyorsa o kişi bir sonraki darboğaz.

Kontrol listesi

Sonuç

O toplantıda gösterdiğim ilk slayt yanlış slayttı. 34 PR güzel bir sayıydı ve hiçbir şey anlatmıyordu; anlatan sayı, teslim edilen işin değişmemiş olmasıydı. Ekip daha çok üretiyordu ve sistem aynı hızda teslim ediyordu; aradaki fark birinin ekranında, birikmiş hâlde bekliyordu.

Altı haftada yaptığımız şeylerin hiçbiri yeni değil: WIP limiti, küçük parçalar, incelemeye ayrılmış zaman, doğru metrik. Yeni olan tek şey, yazma adımının artık darboğaz olmaması. O yüzden AI sonrası ekip yönetimi bir “AI konusu” değil, eski bir akış problemi — sadece darboğaz bir adım ileri taşındı.

Akılda kalacak cümle: daha az başla, daha çok bitir. Üretim ucuzladıysa değerli olan üretim değildir; teslimdir.