Barış Bey – CTO

Giriş Kurumsal hayatta bazı krizler “insani” sebeplerle başlar ama “teknik” metriklerle patlar. Bu senaryoda da tam olarak bu yaşanıyor: sürekli fazla mesai, son release’te ciddi hatalara dönüşüyor. Senin hedefin sprint planını değiştirmek; yani hız/kalite dengesini yeniden kurmak.

Buradaki kritik detay şu: Müdür Barış Bey bir CTO ve sabırsız, teknik. “Ekip yoruldu”, “motivasyon düştü” gibi argümanları zayıf buluyor. Onun dilinde ikna; verimlilik, bug sayısı, deploy hızı, risk ve ölçüm üzerinden ilerliyor. Bu yüzden aynı gerçeği (fazla mesainin kaliteyi bozması) anlatmanın iki yolu var:

• Duygu/konfor çerçevesi: “Yorulduk, nefes alamıyoruz.”
• Sistem/çıktı çerçevesi: “Hata oranı arttı, rework yükseldi, cycle time uzadı, risk büyüdü.”

Kovuldun verilerinde 4 oyunun 3’ü ikna ile bitmiş. Bu da şunu gösteriyor: Doğru metriklerle ve doğru pazarlık kurgusuyla bu CTO ikna edilebiliyor. Ama konu “fazla mesai” olunca bile, bunu kalite ve teslimat ekonomisi olarak anlatmak şart.

---

Neler işe yaradı (ikna eden yaklaşımlar) Bu senaryoda kazanan oyunların ortak noktası, CTO’nun zihnindeki iki soruya net cevap vermesiydi:

1) “Hız”ı yeniden tanımlamak: Deploy değil, hatasız teslimat hızı CTO’lar çoğu zaman hızı “daha sık deploy” olarak görür. Kazanan yaklaşımlarda ise hız, hatasız üretime giden toplam süre olarak çerçevelendi.

• Fazla mesaiyle kısa vadede commit/deploy artabilir.
• Ama bug patlayınca rework, hotfix, rollback, müşteri şikâyeti ve ekip bölünmesi gelir.
• Sonuç: Görünürde hızlı, gerçekte yavaş bir sistem.

Bu çerçeve, sprint planı değişikliğini “yavaşlamak” değil toplam throughput’u artırmak gibi konumlandırır.

2) Metrik konuşmak: Bug oranı, batch hatası, kalite hedefi Barış Bey’in “dinleme eşiği” metrikle açılıyor. Başarılı örneklerde sprint değişikliği; “daha rahat edelim” diye değil, hata oranını belirli bir seviyeye indirmek için önerildi.

Özellikle şu tür ifadeler CTO zihninde netleşir: - “1000’lik batch’te X hata → Y hataya düşürme hedefi” - “Hata oranını %95 azaltma” gibi iddialar (abartı riski taşısa da) bir hedef çıpası koyar - “Üretim %20 düşük görünebilir ama hata %1’e inecek” gibi trade-off’u açıkça sahiplenme

Burada en güçlü hamle, “kısa vadeli çıktı” ile “kalite” arasındaki pazarlığı saklamamak: CTO, gizlenen maliyetten nefret eder; açık pazarlığa daha kolay “evet” der.

3) Pilot ve geri dönüş kapısı: “Olmazsa geri döneriz” güveni Teknik liderler, geri dönüşü olmayan büyük değişikliklerden kaçınır. Kazanan mesajlarda bu yüzden bir pilot süre, ölçüm planı ve geri dönüş opsiyonu vardı.

• “20 günlük projeyi 24 günde teslim edelim” gibi sınırlı kapsam
• “1 ay test edelim” yaklaşımı doğru yönde olsa da (aşağıda neden yine de kaybettiğini konuşacağız) tek başına yetmiyor
• “Eğer olmazsa tekrar eski düzene döneriz” güvencesi, CTO’nun risk algısını düşürür

Pilot fikri, sprint planı değişikliğini “ideolojik bir talep” olmaktan çıkarıp kontrollü bir deney haline getirir.

---

Neler başarısız oldu (yanlış yaklaşımlar) Tek bir oyunun başarısız olması bile önemli; çünkü bu CTO profilinde hangi hataların affedilmediğini gösteriyor.

1) Sorunu yanlış eksene taşımak: Home office / trafik / enerji Başarısız yaklaşım, krizin kök sebebini (fazla mesai → kalite düşüşü) çalışma modeli tartışmasına çevirdi:

• “Trafik 3 saat, odak bozuluyor”
• “Haftanın 2 günü home office”

Bu argümanlar gerçek olabilir; fakat Barış Bey’in filtresinden geçerken şu soruya takılır:

> “Bu, bug sayısını ve deploy güvenilirliğini nasıl düşürecek?”

Home office talebi, bu senaryoda sprint planı değişikliği hedefinden sapma gibi görünür. Dahası, CTO bunu “konfor pazarlığı” olarak okuyabilir.

2) Metrik var ama bağ kopuk: Ölçümün CTO metriklerine bağlanmaması “Trafik yüzünden performans düşüyor” gibi ölçümler, CTO için ikna edici sayılmaz; çünkü ürün kalitesi ve teslimat metriğine doğrudan bağlanmıyor. Bu senaryoda ölçüm konuşacaksan:

• bug leakage (prod’a kaçan hata)
• hotfix sayısı
• rollback oranı
• cycle time
• incident sayısı
• test coverage / flaky test oranı

gibi metrikleri masaya koyman gerekir.

3) “Ertesi gün öğlene kadar izin” gibi yan faydalar Bu tür öneriler, sprint planı değişikliği yerine “ekstra izin” pazarlığına döner. Barış Bey gibi bir CTO, bunu duyunca “çıktı kaybı” görür; kalite kazanımı net anlatılmadıysa kaybedersin.

---

Sonuç Barış Bey gibi sabırsız ve teknik bir CTO’yu ikna etmek, “ekip yoruldu” demekle değil; bug sayısı, deploy güvenilirliği ve toplam teslimat hızı üzerinden konuşmakla mümkün.

Bu senaryoda kazananlar; sprint planı değişikliğini bir konfor talebi değil, ölçülebilir bir kalite/çıktı optimizasyonu olarak sundu. Kaybeden yaklaşım ise problemi çalışma modeli tartışmasına kaydırıp CTO’nun asıl derdine (prod kalitesi ve teslimat riski) doğrudan bağ kuramadı.

Kovuldun’da bu tarz bir CTO ile masaya oturduğunda, tek hedefin şu olmalı: “Sprint değişikliği = daha az risk, daha az rework, daha öngörülebilir deploy.” Bunu metrikle, pilotla ve geri dönüş planıyla söylediğinde, sabırsız CTO bile dinler.