Yazılım projelerinin büyük bölümü, kullanılan teknoloji ya da ekip kalitesi yüzünden değil; yanlış bir başlangıç kararı yüzünden zorlanır.

Genelde gördüğümüz en yaygın problem, “bir an önce geliştirmeye başlayalım” refleksiyle, henüz kararlar yeterince netleşmeden yazılım geliştirme sürecine girilmesidir.

Bu refleks genellikle iyi niyetlidir. Zaman kaybetmemek, rakiplerden geri kalmamak ya da fikri hızlıca hayata geçirmek istenir. Ancak aceleyle alınan kararlar, çoğu zaman projeyi hızlandırmaz; aksine ilerleyen aşamalarda ciddi yavaşlamalara ve maliyet artışlarına yol açar.

Bu yazıda, yazılım yaptırmadan önce netleştirilmesi gereken temel noktaları, gerçek proje deneyimlerinden süzülmüş bir bakışla ele alıyoruz.

Yazılım projeleri neden daha başlamadan zorlaşır?

Birçok projede sorunlar, geliştirme başladıktan aylar sonra görünür hale gelir.

İlk başta her şey yolunda gibidir: toplantılar yapılır, ekranlar tasarlanır, kod yazılmaya başlanır. Ancak bir noktadan sonra şu cümleler duyulmaya başlar:

  • “Biz aslında bunu böyle düşünmemiştik.”
  • “Bu bizim asıl ihtiyacımızı çözmüyor.”
  • “Bunu baştan farklı yapsak daha iyi olurmuş.”

Bu noktada sorun teknik değildir. Sorun, başlangıçta doğru soruların sorulmamasıdır.

1. Gerçekten hangi problemi çözmeye çalışıyoruz?

Birçok projede anlatılan şey bir çözüm fikridir, problem değil.

“Mobil uygulama yapalım” ya da “bir sistem kuralım” problem tanımı değildir.

Biz genelde şu soruyla başlarız:

Bu yazılım olmadan bugün neyi manuel yapıyorsunuz, nerede zaman kaybediyorsunuz, hangi noktada kontrolü kaybediyorsunuz?

Problem netleşmeden başlanan projelerde:

  • kapsam sürekli değişir
  • yeni ihtiyaçlar sonradan eklenir
  • ekip ile iş sahibi arasında algı farkı oluşur

Bu da hem zaman hem bütçe açısından projeyi yıpratır.

2. Bu problem için gerçekten yazılım geliştirme sürecine girilmeli mi?

Buradaki soru “hazır bir araç var mı?” sorusu değildir.

Asıl soru şudur:

Bu problem için özel yazılım geliştirmeye zaman, bütçe ve odak ayırmak için doğru noktada mıyız?

Bazı durumlarda problem gerçektir ama çözüm henüz yazılım geliştirmek değildir.

Örneğin:

  • süreç henüz net değildir
  • kullanıcı davranışı yeterince anlaşılmamıştır
  • beklentiler sürekli değişmektedir

Bu gibi durumlarda doğrudan yazılım geliştirmeye başlamak, belirsizliği çözmez; sadece belirsizliği koda gömer.

Yanlış zamanda başlanan yazılım geliştirme süreci, doğru bir fikir bile olsa pahalıya patlar.

3. İlk aşamada neyi özellikle yapmamaya karar veriyoruz?

Projeleri kurtaran şey çoğu zaman yapılacaklar listesi değil, yapılmayacaklar listesidir.

“Sonra ekleriz” denilen her başlık:

  • ilk günden mimariyi etkiler
  • teknik kararları ağırlaştırır
  • maliyeti sessizce büyütür

İlk versiyon için kritik olmayan ama “ileride lazım olur” denilen kararlar, daha ilk günden sistemin esnekliğini azaltır.

Bu yüzden erken aşamada şu soru hayati önem taşır:

İlk aşamada hangi ihtiyaçları bilinçli olarak dışarıda bırakıyoruz?

4. Başarıyı neye bakarak “başarılı” sayacağız?

Bir yazılımın çalışıyor olması, başarılı olduğu anlamına gelmez.

Başarı, baştan belirlenen hedeflere göre ölçülür.

İlk aşamada amaç:

  • öğrenmek mi?
  • kullanıcı davranışı görmek mi?
  • satış denemesi yapmak mı?
  • operasyonel bir süreci rahatlatmak mı?

Bu net değilse, proje sonunda herkes farklı bir başarı tanımıyla masadan kalkar.

Bu da “proje bitti ama kimse memnun değil” durumunu doğurur.

5. Yanlış başlarsak bunun geri dönüş maliyeti ne olur?

Yanlış başlangıçlar genelde hemen patlamaz.

Sorunlar aylar sonra ortaya çıkar ve o noktada yön değiştirmek çok pahalıdır.

Yanlış alınmış kararlar:

  • mimariyi kilitler
  • ek geliştirmeleri zorlaştırır
  • her yeni değişikliği daha pahalı hale getirir

Bu yüzden yazılım geliştirmeye başlamadan önce kararları gözden geçirmek, çoğu zaman geliştirmeden daha kritik bir adımdır.

Bu noktalar net değilse, doğrudan geliştirmeye girmek yerine önce kapsamlı ama odaklı bir değerlendirme yapmak, uzun vadede en güvenli yoldur.

Bu noktada birçok ekip, bu netliği tek başına masa başında aramak yerine, varsayımları başka bir bakışla konuşarak netleştirmenin daha sağlıklı olduğunu fark ediyor. Çünkü en pahalı hatalar, genellikle bu sorular netleşmeden verilen kararlardan çıkıyor.