Yıllarca, yazdığım her satır kodun, tasarladığım her sistemin tamamen teknik birer başarı göstergesi olduğunu düşündüm. Ancak, 20 yıla yakın tecrübenin ardından anladım ki, yazılımın gerçek başarısı klavyede yazılan koddan çok daha fazlası; aslında bir organizasyonun kendisiyle yüzleşme biçimiydi. Bu ‘gerçeği’ kavramak, kariyerimde attığım en önemli adımlardan biri oldu.
Bu yanılgı, beni birçok projede teknik olarak mükemmel çözümler üretmeye iterken, sahadaki gerçek sorunların bazen bambaşka yerlerde yattığını gözden kaçırmama neden oldu. Bir üretim ERP’sinde çalışırken, bir özelliğin devreye alınmasıyla birlikte ortaya çıkan aksaklıkların, kodda değil, operasyonel ekiplerin iletişim eksikliğinde veya mevcut işleyişe dirençlerinde yattığını gördüm.
Kod Neden Her Zaman Sorunun Kendisi Değildir?
Çoğu zaman, bir yazılım projesinde karşılaştığımız aksaklıkları hemen kod tabanında, mimaride ya da kullanılan teknolojide ararız. Ben de uzun yıllar bu refleksle hareket ettim. Bir veritabanı yavaşladığında hemen index’lere, query’lere ya da connection pool ayarlarına bakardım; bir serviste hata aldığımda logları tarar, systemd unit’lerini kontrol ederdim. Bu, teknik bir uzmanın doğal tepkisidir.
Ancak, özellikle büyük ve karmaşık kurumsal projelerde, sorunların kökeni sandığımızdan çok daha derinde olabiliyor. Bir keresinde, bir üretim ERP’sinde geliştirdiğimiz yeni bir üretim planlama modülü, test ortamında kusursuz çalışırken, canlıya alındığında sürekli olarak “geç sevkiyat” raporları üretmeye başladı. İlk tepkim hemen AI ile üretim planlama algoritmalarını, PostgreSQL’deki sorguları veya Redis’teki cache mekanizmalarını incelemek oldu. Saatler süren teknik debug sonunda, kodda bir sorun olmadığını fark ettim.
Organizasyonel Akış Yazılımı Nasıl Etkiliyor?
Geç sevkiyat raporlarının sebebi, yazılımın kendisi değildi; sahadaki operatörlerin yeni arayüze alışma süreci ve eski, kağıt tabanlı alışkanlıklarından vazgeçmekteki zorluklarıydı. Operatörler, sistemin anlık önerilerini takip etmek yerine, eski usul planlama şablonlarına göre hareket etmeye devam etmişlerdi. Yazılım, teknik olarak doğru çalışıyor, ancak insanların onu kullanma biçimi, tasarladığımız verimliliği altüst ediyordu.
Bu durum, bana yazılım mimarisinin aslında bir organizasyonel akış mimarisi olduğunu çok net gösterdi. Bir yazılım projesinde, teknik gereksinimler kadar, hatta bazen daha fazla, mevcut iş süreçlerini, departmanlar arası iletişimi ve kültürel dinamikleri anlamak gerekiyor. Yazdığımız kod, bu dinamiklerin bir yansımasıdır.
Yanlış İnançtan Gerçek Derslere Nasıl Geçtim?
Bu tür deneyimler beni, bir projeye başlarken sadece teknik spec’lere değil, aynı zamanda “bu yazılım kimler tarafından, nasıl kullanılacak ve mevcut işleyişi nasıl değiştirecek?” sorularına odaklanmaya itti. Artık sadece “nasıl yaparım?” değil, “neden yapıyoruz ve bu kimin hayatını nasıl etkileyecek?” sorularını da soruyorum.
Bir başka örnek, kendi yan ürünlerimden birinde başıma geldi. Basit bir görev yönetim uygulaması geliştirirken, kullanıcıların belirli adımları atlamasına izin veren esnek bir yapı kurdum. Teknik olarak bu “esneklik” harikaydı. Ancak, gerçek kullanımda bu esneklik, kullanıcıların görevleri tamamlamaktan çok, sistemi manipüle ederek işleri “tamamlanmış” göstermelerine yol açtı. Sorun, kodda bir bug değil, iş akışındaki gevşekliğin insan doğasıyla birleşmesiydi. Bunu düzeltmek için esnekliği kısıtlayan, daha yönlendirici bir arayüz tasarlamak zorunda kaldım.
Yazılım Mimarisinin Görünmeyen Katmanları Nelerdir?
Yazılım mimarisi dediğimizde aklımıza genellikle katmanlar, servisler, veritabanları ve API’lar gelir. Ancak benim için, bu görünür katmanların altında bir de görünmeyen, ancak çok daha etkili bir katman var: Organizasyonel Mimari.
graph TD; A["Yazılım Mimarisi (Görünür)"] --> B["Kod Tabanı"]; A --> C["Veritabanı Şeması"]; A --> D["API Tasarımı"]; A --> E["Altyapı (Bulut/Bare-metal)"]; F["Organizasyonel Mimarisi (Görünmez)"] --> G["İş Süreçleri"]; F --> H["Departman İletişimi"]; F --> I["Kullanıcı Alışkanlıkları"]; F --> J["Kültürel Dinamikler"]; F --> A;
Bu diyagramda gösterdiğim gibi, yazılımın teknik bileşenleri (A), aslında organizasyonel yapıdan (F) derinlemesine etkilenir. G, H, I ve J gibi faktörler, yazılımın nasıl kullanılacağını, hangi özelliklere ihtiyaç duyulacağını ve hatta hangi hataların ortaya çıkacağını belirler.
Sonuç: Yazılım, Organizasyonun Aynasıdır
Uzun yıllar sonra geldiğim nokta şu: Yazılım sadece bir araç değil, organizasyonun kendisinin bir yansımasıdır. Bir organizasyonun sorunlu iş akışları, kopuk iletişim kanalları veya kültürel dirençleri varsa, yazdığınız yazılım ne kadar teknik olarak mükemmel olursa olsun, bu sorunları ortadan kaldırmak yerine, çoğu zaman sadece dijitalleştirir ve daha görünür hale getirir.
Bu yüzden, bir sonraki yazılım projenize başlarken, sadece teknik gereksinim listesine değil, aynı zamanda projenin etki edeceği insanların ve süreçlerin dinamiklerine de derinlemesine bakın. Belki de en iyi çözüm, kod yazmak yerine, bir toplantı odasında doğru soruları sormaktır.
Peki siz ne düşünüyorsunuz? Kariyerinizde, yazılımın sadece teknik bir çözüm olmadığını fark ettiğiniz anlar oldu mu? Hangi “yanlış bildiğiniz” gerçeklerle yüzleştiniz?