Bir yazılım fikriyle gelen insanların çoğu aynı noktadan başlar: “Şunu yapabilir miyiz?” Asıl soru ise genelde hiç sorulmaz: “Bunu gerçekten yapmalı mıyız ve nasıl yapmalıyız?”
Yazılım geliştirmede başarısızlıkların büyük kısmı kod kalitesinden değil, erken ve yanlış alınmış ürün ve teknik kararlardan kaynaklanır. Üstelik bu kararlar çoğu zaman “mantıklı” görünürken alınır.
Teknik kararlar neden sandığımızdan daha kritiktir?
Teknik kararlar çoğunlukla framework, veritabanı veya altyapı seçimi olarak algılanır. Oysa pratikte bu kararlar; ekibin ne kadar hızlı ilerleyebileceğini, sistemin ne kadar karmaşık hale geleceğini ve hangi noktada geri dönüşün zorlaşacağını belirler.
Bir teknoloji seçimi yalnızca teknik bir tercih değildir. Aynı zamanda organizasyonel ve operasyonel bir karardır. Yanlış bir teknik karar doğru bir ürünü bile zor durumda bırakabilirken, doğru bir karar vasat bir fikrin ayakta kalmasını sağlayabilir.
Asıl problem: Kararların çok erken kilitlenmesi
Sahada en sık gördüğümüz hata şudur: Belirsizliğin en yüksek olduğu anda, kararların en kesin şekilde alınması.
Henüz kullanıcıyı tam tanımamışken, ürünün nasıl evrileceği belli değilken ve iş modeli netleşmemişken mimariyi ve teknolojiyi taşa yazmak çoğu zaman benzer sonuçlara yol açar: yeniden yazım ihtiyacı, hızla artan teknik borç ve ekip içinde motivasyon kaybı.
Yanlış ama çok yaygın yaklaşımlar
“En iyisini baştan kuralım” yaklaşımı
Bu yaklaşım genellikle iyi niyetlidir ancak tehlikelidir. Çünkü “en iyi” diye bir şey bağlamdan bağımsız olarak var olmaz. Erken aşamada kurulan aşırı karmaşık mimariler hız kazandırmaz, aksine ilerlemeyi yavaşlatır. Çoğu ürün için erken aşamada doğru olan mimari, en esnek olanıdır.
“Sonra düzeltiriz” düşüncesi
Karar almaktan kaçınmak da bir karardır ve genellikle en pahalı olanıdır. Hiç karar almamak belirsizliği azaltmaz; yalnızca ileride daha sert ve maliyetli kararlar alınmasını zorunlu kılar.
Ürün ve tekniği ayrı ele almak
Gerçek dünyada ürün kararları teknik kısıtlarla, teknik kararlar da ürün hedefleriyle şekillenir. Bu iki alanı birbirinden kopuk ele almak, ilerleyen aşamalarda uyumsuzluk ve sürtüşme yaratır.
Daha sağlıklı bir karar çerçevesi nasıl kurulur?
Sağlıklı kararlar genellikle üç ortak özelliğe sahiptir: geri alınabilir olmaları, varsayımlara dayanmaları ve bugünün gerçeklerini optimize etmeleri.
Karar almadan önce şu soruların sorulması kritik önemdedir: Bu karar neyi kolaylaştırıyor? Neyi zorlaştırıyor? Altı ay sonra bu karardan dönmek istersek neyle karşılaşırız?
Risk ne zaman gerçekten başlar?
Risk, sistem büyüdüğünde değil; kararların geri dönülemez hale geldiği noktada başlar. “Bunu artık değiştiremeyiz” ifadesi ekip içinde sıklaşmaya başladıysa, teknik risk çoktan oluşmuştur.
Gerçek hayattan güçlü sinyaller
Gerçek projelerde tekrar eden bazı işaretler vardır. Yeni bir özelliğin eklenmesi her seferinde daha uzun sürüyorsa, küçük değişiklikler beklenmedik yerleri etkiliyorsa veya ekip karar almaktan kaçınmaya başlamışsa, sorun genellikle teknolojide değil, geçmişte alınmış kararlardadır.
Deneyim gösteriyor ki, başlangıçta biraz daha yavaş ama esnek ilerleyen ekipler uzun vadede daha az kriz yaşar, daha az yeniden yazım yapar ve daha sürdürülebilir ürünler geliştirir.
Kapanış
Yazılım geliştirmede doğru kararlar her şeyi en baştan bilmekle değil, belirsizlikle yaşamayı ve onu yönetmeyi bilmekle alınır. Çoğu zaman asıl mesele, hangi kararların hemen alınması gerektiği değil; hangilerinin bilinçli olarak ertelenmesi gerektiğidir.
