Bir yazılım projesi ilerlemediğinde ilk refleks genellikle aynıdır: Tekniğe bakmak.

Kod kalitesi konuşulur, mimari sorgulanır, kullanılan teknoloji tartışılır. Bazen ekip yetersiz bulunur, bazen “yanlış teknolojiyle başlanmış” denir. Sorunun teknik olduğuna dair güçlü bir kanaat hızla oluşur.

Oysa benzer teknik koşullarda bazı projeler ilerlerken, bazıları neden sürekli tıkanır? Aynı yazılımcılarla, benzer teknolojilerle, hatta aynı ürün fikriyle bile sonuçlar neden bu kadar farklıdır?

Çoğu durumda cevap kodda değil; karar alma biçiminde ve organizasyonel belirsizliklerde saklıdır.

Bu noktaya gelmeden önce yapılan hatalar çoğu zaman daha erken başlar. Birçok projede sorun, daha en başta yanlış sorularla yola çıkılmasıdır.

Teknik Sorunlar Neden Daha Görünürdür?

Teknik problemler somuttur. Hata vardır, performans düşüktür, sistem çöker. Ölçülebilir ve gösterilebilirler.

Organizasyonel problemler ise dağınıktır. Birinin net karar verememesi, önceliklerin sık değişmesi, onay süreçlerinin belirsizliği tek bir ekranda görünmez. Bu yüzden konuşulmaları daha zordur.

Bir de psikolojik tarafı vardır. Teknik bir sorunu işaret etmek, sorumluluğu kodun ya da teknolojinin üzerine bırakır. Organizasyonel bir sorunu işaret etmek ise kararların, rollerin ve alışkanlıkların sorgulanmasını gerektirir.

Bu yüzden birçok projede görünür olan teknik sorunlar, görünmez organizasyonel problemlerin sonucu olarak ortaya çıkar.

Teknik sorunlar konuşuldukça çözülüyormuş hissi yaratır; organizasyonel sorunlar ise çoğu zaman sessizce birikir.

Organizasyonel Sorun Ne Demektir?

Organizasyonel sorun, şirketin büyük ya da küçük olmasıyla ilgili değildir. Tek kişiyle yürüyen projelerde de, kalabalık ekiplerde de aynı şekilde ortaya çıkabilir.

En sık görülen biçimleri şunlardır:

  • Karar yetkisi ile sorumluluğun aynı kişide olmaması
  • “Herkes dahil ama kimse sahip değil” durumu
  • Önceliklerin net bir çerçeveye dayanmaması
  • Onay mekanizmalarının belirsizliği

Bu sorunlar tek tek küçük gibi görünür. Ama birlikte çalıştıklarında, projeyi sessizce kilitlerler.

Bir noktadan sonra teknik ekip “ne yapılacağını” değil, “kimin karar vereceğini” beklemeye başlar.

Doğru Teknik Kararlar Neden İşe Yaramaz?

Bir projede doğru teknolojiler seçilmiş olabilir. Mimari makul, kod kalitesi iyi, ekip deneyimli olabilir.

Yine de proje ilerlemiyorsa, çoğu zaman sebep şudur: Doğru kararlar yanlış zamanda alınmıştır.

Organizasyonel netlik olmadan alınan teknik kararlar, kısa vadede mantıklı görünür. Ama zamanla bağlam değişir, öncelikler kayar, kararların neden alındığı unutulur.

Bu noktada teknik ekip; daha önce alınmış kararları savunmak zorunda kalır, neden böyle yapıldığını açıklayamaz ve her yeni isteği mevcut yapıya zorla uydurmaya çalışır.

Bu durum özellikle dış kaynaklarla çalışırken daha görünür hale gelir. Çünkü karar çerçevesi net değilse, kime ve nasıl karar verileceği sorusu sürekli geri gelir.

En Sık Görülen Organizasyonel Kilitlenme Senaryoları

Ürün sahibinin net olmaması, önceliklerin sürekli değişmesi, kararların toplantılarda alınıp uygulanmaması ve kimsenin “hayır” diyememesi projeleri kilitleyen en yaygın senaryolardır.

Bu durumların ortak noktası, teknik eksiklikten çok organizasyonel kararsızlıktır.

Bu tür projelerde yazılım ilerler gibi görünür ama aslında aynı yerde dönüp durur.

Teknik Borç Nasıl Organizasyonel Bir Sonuçtur?

Teknik borç çoğu zaman kod kalitesiyle açıklanır. Oysa teknik borcun önemli bir kısmı, geçmişte ertelenmiş kararlardan doğar.

“Şimdilik böyle yapalım”, “sonra düzeltiriz” gibi cümleler teknik değil, organizasyoneldir. Kodda görünen borç, karar süreçlerinin gecikmiş bedelidir.

Bu yüzden yalnızca refactor yapmak borcu kalıcı olarak çözmez.

Aynı organizasyonel belirsizlik devam ediyorsa, borç farklı bir biçimde yeniden ortaya çıkar.

Sağlıklı İşleyen Projelerde Ne Farklıdır?

Sağlıklı ilerleyen projelerde teknik mucizeler yoktur. Ama karar yetkisi nettir, teknik ekip neyi neden yaptığını bilir ve yapılmayacaklar açıktır.

Bu projelerde sorunlar yine çıkar ama büyümez. Çünkü kime gideceği bellidir.

Organizasyonel Netlik Olmadan Teknik İyileştirme Ne Olur?

Organizasyonel sorunlar çözülmeden yapılan teknik iyileştirmeler geçici kalır. Refactor edilen sistemler tekrar bozulur, yeniden yazılan projeler aynı problemleri üretir.

Bu durum “bu sefer oldu” hissinin tekrar tekrar kırılmasına yol açar.

Organizasyonel Netlik Nasıl Başlar?

Organizasyonel netlik genellikle şu sorularla başlar: Bu kararı kim veriyor? Sorumluluğu kimde? Yanlış çıkarsa ne olacak? Hangi karar özellikle ertelenmeli?

Bu sorular netleştiğinde teknik ekip rahatlar. Çünkü artık çözmesi gereken problem bellidir.

Yazılım projelerinde sorunların büyük kısmı koddan önce başlar. Teknik kararlar organizasyonel belirsizliklerin üzerine inşa edildiğinde, en doğru çözümler bile zamanla etkisini kaybeder.

Gerçek ilerleme çoğu projede, kod değişmeden önce kararların netleştiği noktada başlar.