Ana sayfa → Ekip Yönetimi
Darboğaz Yazmak Değil, İncelemek: AI Sonrası Ekip Hızı
Çeyrek sonu toplantısı. Ekran paylaştım: 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.
- Darboğaz yok olmaz, taşınır. Yazma hızlanınca sıradaki adım dolar: inceleme, test, canlıya çıkarma, anlama.
- Üretim metrikleri artık hiçbir şey anlatmıyor. PR sayısı, satır, kapanan ticket — hepsi AI ile yukarı gider. Bakılacak üç sayı: lead time, geri alma oranı, inceleme bekleme süresi.
- PR boyutu yeni disiplin alanı. 1.400 satırlık PR incelenmez, onaylanır. Bizde 400 satır sınırı; büyükler ortalama 3,1 gün bekledi, küçükler aynı gün kapandı.
- “Neden” açıklaması zorunlu. AI’ın ürettiği kodda yazarın gerekçesi eksik olabiliyor; PR açıklamasında ne denendi, ne çalışmadı yazmıyorsa inceleme tahmine dönüyor.
- İnceleme takvime girer. “Boşta kalınca bakarım” kuyruğu büyütür; sabah 45 dakikalık blok kuyruğu eritti.
- Yönetici işi kapasiteyi kaydırmak. Ekibe “daha çok yazın” demek değil; inceleme, test ve çıkış tarafına adam ve zaman vermek.
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 katına çıkardık; sıradaki adımlar aynı kaldı.
| Adım | Önce | AI sonrası | Değişim |
|---|---|---|---|
| Kod yazma | 2,1 gün | 0,8 gün | Hızlandı |
| İnceleme kuyruğunda bekleme | 0,9 gün | 2,5 gün | Yavaşladı |
| İnceleme süresi (okuma) | 0,4 gün | 0,7 gün | PR’lar büyüdü |
| Test / düzeltme turu | 1,2 gün | 1,4 gün | Değişmedi sayılır |
| Canlıya çıkarma | 0,6 gün | 0,6 gün | Aynı |
| Toplam (lead time) | 5,2 gün | 6,0 gün | Daha kötü |
Tablonun söylediği şey açık: yazmada kazandığımız 1,3 günü, incelemede 1,6 gün kaybettik. Üstüne bir de 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.
- Açılan PR sayısı
- Eklenen/silinen satır
- Kapanan ticket sayısı
- Kişi başı “üretkenlik”
- Lead time: ticket açılışından canlıya
- İnceleme bekleme süresi: PR açıldıktan ilk yoruma kadar
- Geri alma oranı: canlıda geri alınan değişiklik yüzdesi
- Açık PR sayısı: aynı anda bekleyen iş
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. Yeni kod yazılmadı; var olan kod teslim edildi.
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:
| PR boyutu | Ortalama bekleme | Yorum sayısı | Geri alma |
|---|---|---|---|
| < 100 satır | 0,3 gün | 2,1 | %1 |
| 100–400 satır | 0,9 gün | 4,7 | %3 |
| 400–1.000 satır | 2,2 gün | 3,9 | %7 |
| > 1.000 satır | 3,1 gün | 1,8 | %11 |
Üçüncü sütuna dikkat: PR büyüdükçe yorum sayısı azalıyor. Bu, 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ı üç 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ı.
- Hangi testi bozmayı denedin? Testi kasten bozup kırmızı olduğunu görmek.
Üçü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, incelemenin kalitesi de arttı. Yorum sayısı PR başına 3,2’den 5,1’e çıktı ve geri alma oranı %6’dan %2’ye indi.
Sahadan: altı hafta
| Ölçüm | Başlangıç | 6 hafta sonra |
|---|---|---|
| Açılan PR / hafta | 34 | 31 (hedef değil) |
| Aynı anda açık PR | 23 | 9 |
| İncelemede bekleme | 2,5 gün | 0,8 gün |
| Ortalama PR boyutu | 620 satır | 240 satır |
| PR başına yorum | 3,2 | 5,1 |
| Lead time | 6,0 gün | 3,4 gün |
| Canlıda geri alma | %6 | %2 |
İlk satır kasıtlı: PR sayısı düştü ve bu bir başarısızlık değil. Teslim edilen iş arttı, çünkü 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
- Hangi adım hızlandı? Sıradaki adım aynı kapasitede mi?
- Lead time’ı ölçüyor muyum, yoksa PR sayısını mı?
- Aynı anda kaç PR açık? Kişi başı sınır var mı?
- PR’ların kaçı 400 satırın üstünde?
- Büyük PR’larda yorum sayısı düşüyor mu?
- PR açıklamasında “ne denendi, ne çalışmadı” var mı?
- Testin gerçekten kırıldığını kim kontrol etti?
- İnceleme takvimde mi, boşlukta mı?
- İncelemelerin kaçını bir kişi yapıyor?
- Junior bu kodun neden öyle yazıldığını sorabiliyor mu?
- Yukarıya verdiğim rapor hangi metriği övüyor?
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.