Yazılım projelerinde çoğu kilitlenme aniden olmaz. Bir hata, bir kriz ya da tek bir yanlış karar yüzünden gerçekleşmez.

Asıl kilitlenme, zaman içinde mantıklı görünen ama tekrar ele alınmayan kararların birikmesiyle ortaya çıkar.

Bu yüzden birçok ekip şu noktada şaşırır:

“Aslında yanlış bir şey yapmadık…
Peki nasıl bu hale geldik?”

Kararların görünmeyen etkisi

Bir yazılım projesinde alınan her karar:

  • o gün için bir problemi çözer,
  • ama aynı zamanda gelecekteki seçenekleri sınırlar.

Bu sınırlama ilk başta fark edilmez. Çünkü proje hâlâ ilerliyordur.

Kod çalışır.
Ürün kullanılıyordur.
Yeni özellikler eklenebiliyordur.

Sorun, kararların bağlamı değiştiğinde başlar.

MVP aşamasında başlayan kilitlenme

MVP döneminde sıkça şu kararlar alınır:

  • “Şimdilik basit tutalım”
  • “Sonra değiştiririz”
  • “Henüz buna gerek yok”

Bu kararlar MVP için genellikle doğrudur. Problem, bu kararların MVP sonrasında otomatik olarak geçerli kabul edilmesidir.

MVP bitmiş, ürün büyümeye başlamıştır. Ama kararlar hâlâ erken aşama refleksiyle çalışıyordur.

Bu noktada kilitlenme yavaş yavaş başlar.

Büyüme sırasında görünür hale gelen sınırlar

Ürün büyüdükçe:

  • kullanıcı sayısı artar,
  • senaryolar çeşitlenir,
  • ekip genişler.

Bu büyüme, yeni sorunlar yaratmaz. Var olan kararların sınırlarını görünür kılar.

Şu cümleler duyulmaya başlar:

  • “Bu yapıyla zor”
  • “Burayı değiştirmek riskli”
  • “Bunu planlamamıştık”

Bu aşamada sorun teknik değil, kararların hâlâ geçerli olup olmadığının sorgulanmamasıdır.

Legacy hissi ne zaman başlar?

Bir sistemin legacy olarak algılanması için eski olması gerekmez.

Şu an yazılmış, modern teknoloji kullanan bir sistem de legacy olabilir.

Eğer:

  • kimse bazı alanlara dokunmak istemiyorsa,
  • değişiklikler orantısız risk yaratıyorsa,
  • kararlar artık savunulmadan korunuyorsa,

ürün fiilen kilitlenmiştir.

Bu noktada ekip şunu düşünür:

“Baştan yazsak daha mı iyi olur?”

Ama bu soru genellikle çok geç sorulur.

Asıl sorun: kararların sahiplenilmemesi

Sahada en sık gördüğümüz problem şudur:
Kararlar alınır ama ömürleri tanımlanmaz.

Kimse şunu sormaz:

  • “Bu karar hangi koşulda geçersiz olur?”
  • “Ne zaman tekrar ele alacağız?”
  • “Büyüme olursa neyi değiştireceğiz?”

Bu sorular sorulmadığında kararlar:

  • sessizce kalıcı hale gelir,
  • zamanla hareket kabiliyetini azaltır,
  • en sonunda ürünü kilitler.

Daha sağlıklı bir karar yaklaşımı

Ürünü kilitlemeyen ekiplerin ortak refleksi şudur:
Kararları mutlak doğrular olarak değil, geçici varsayımlar olarak ele alırlar.

Bu ekipler:

  • karar alırken hızlanır,
  • ama kararları düzenli olarak gözden geçirir,
  • bağlam değiştiğinde tereddüt etmeden günceller.

Bu yaklaşım:

  • MVP’de esneklik,
  • büyümede denge,
  • legacy aşamasında kontrol sağlar.

Kapanış

Yazılım projelerini kilitleyen şey:

  • karmaşık mimariler,
  • yanlış teknolojiler,
  • yetersiz ekipler değildir.

Asıl kilitlenme nedeni:

Doğru zamanda alınmış ama yanlış zamanda sorgulanmayan kararlardır.

Bu yüzden asıl kritik soru şudur:

“Bu karar bugün hâlâ geçerli mi,
yoksa sadece alışkanlıktan mı devam ediyor?”

Bu soruyu düzenli sorabilen ekipler, ürünlerini değil, hareket kabiliyetlerini büyütür.