Yaptığımız işler, doğası gereği üzerinde derinlemesine kafa patlatılması gereken, yüksek ehemmiyetli süreçler. Ancak iş dünyasının hızı, kültür farklılıkları bazen planlarla gerçekleri karşı karşıya getirebiliyor ve bazen de ipin ucu kaçıp işler pek planlandığı gibi gitmeyebiliyor. Bu gerilimlerden yıllar içinde öğrendiğim ve içselleştirdiğim bir yapıyı paylaşmak istiyorum.
Bir işi bir şekilde yapmak ile onu ölçeklenebilir bir mimari içinde yapmak arasında ciddi bir fark vardır. Bu fark genellikle teknik değil, organizasyonel bir meseledir.
Birçok kurumda hız baskısı, projeleri “hemen olsun” refleksiyle şekillendirir. Bu yaklaşım kısa vadede ilerleme hissi yaratır; ancak orta ve uzun vadede ürün karmaşıklığını, teknik borcu ve iletişim problemlerini artırır.
Biz ürün geliştirme süreçlerinde Domain Driven Development yaklaşımını bu nedenle tercih ediyoruz.
DDD, yüzeyde daha fazla toplantı ve daha fazla tartışma gibi görünse de, aslında şunu sağlar:
· Ortak dil: Tüm paydaşların yani Ceo’dan yazılımcıya aynı dili konuşmasını
· Berraklık: Ürünün zihinsel modelinin netleşmesi
· Stratejik hizalanma:Teknik kararların doğrudan iş hedefleriyle eşleşmesi
Bu yaklaşım, daha yavaş değil; daha az sürprizli bir geliştirme süreci üretir.
Domain Driven Development yaklaşımının en kritik kazanımlarından biri, sadece teknik mimari değil; sorumluluk ve zaman yönetiminin de ortak bir dilde ele alınmasıdır.
Bu yaklaşımda, proje girdilerinin zamanında iletilmesi yalnızca operasyonel bir detay değil, ürün kalitesini doğrudan etkileyen bir yapı taşıdır. Geciken dokümanlar ya da içerikler, defalarca hatırlatılmış olsa bile, ürün akışını sekteye uğratabilir.
Olgun ürün organizasyonları, geciken asset’ler ya da taskler hakkında “daha fazla hatırlatılmalıydı” diyerek sorumluluğu üstünden atmak yerine, sürecin kendi kendini taşıdığı sistemler kurmayı hedefler.
Bazı organizasyonlar bu düşünce yapısına doğal olarak sahiptir. Bazılarında ise bu, bilinçli olarak inşa edilmesi gereken bir kasdır.
Burada asıl mesele metodolojinin adı değil (Agile, Waterfall vb.), kurumun ortak karar alma dili oluşturup oluşturamadığıdır.
Gerçek anlamda ölçeklenebilir ürünler; süreçlere ezbere uyan değil, kendi bağlamına uygun bir geliştirme mimarisi kurabilen organizasyonlarda ortaya çıkar.
Yani özetleyecek olursam: Sağlıklı ürün süreçleri, sürekli hatırlatma gerektiren reflekslerle değil; zamanında teslim edilen girdiler ve ortak sorumluluk bilinciyle çalışır. Bu bilinç için bütün paydaşlar yapıcı bir şekilde gelişmeye ve değişmeye açık olmalıdır. Konu kod, tasarım, kişiler, şirketler değil konu sürdürülebilir, güçlü mimariye sahip, ölçeklenebilir, paydaşlarla birlikte değer yaratma sanatıdır.
... Diye düşünüyorum.
