Yazılım ekiplerinde performans problemleri çoğu zaman yanlış yerlerde aranır. Kod kalitesi, teknoloji seçimi ya da mimari kararlar genellikle ilk şüphelilerdir. Oysa pratikte ekiplerin hızını ve etkinliğini belirleyen asıl unsur çok daha temel bir noktada yatıyor: karar alma biçimi.

Bir ekip ne kadar yetenekli olursa olsun, eğer kararlarını doğru hızda ve doğru çerçevede alamıyorsa zamanla yavaşlar. Bu yavaşlama çoğu zaman fark edilmez; çünkü ekip çalışıyordur, toplantılar yapılıyordur, dokümanlar hazırlanıyordur. Ama ilerleme hissedilmez. Bunun temel nedeni, kararların doğasının yanlış değerlendirilmesidir.

Tam da bu noktada Jeff Bezos’un ortaya koyduğu One-Way Door vs Two-Way Door yaklaşımı devreye girer. Bu yaklaşım, kararları geri dönülebilirliklerine göre sınıflandırarak ekiplerin ne zaman hızlı, ne zaman temkinli olması gerektiğini netleştirir.

Bu yazıda konuyu teorik bir çerçevede anlatmak yerine, yazılım ekipleri bağlamında nasıl uygulandığını, nerelerde yanlış yorumlandığını ve ekip performansını nasıl doğrudan etkilediğini ele alacağız.

Karar Vermek Neden Bu Kadar Kritik?

Bir yazılım ekibinin gününün büyük kısmının kod yazarak geçtiğini düşünmek kolaydır. Oysa gerçekte ekipler zamanlarının önemli bir bölümünü karar vermeye çalışarak geçirir.

Yeni bir feature nasıl implemente edilecek? Mevcut sistem refactor edilmeli mi? Yeni bir teknolojiye geçilmeli mi? Bir feature hemen mi release edilmeli yoksa bekletilmeli mi?

Bu soruların her biri teknik gibi görünse de aslında organizasyonel kararlardır. Ve bu kararların nasıl alındığı, doğrudan delivery hızını etkiler.

En tehlikeli durum ise kararların yanlış alınması değil, kararların hiç alınamaması ya da gereğinden fazla gecikmesidir. Çünkü yazılım dünyasında çoğu hatayı telafi edebilirsiniz ama kaybedilen zamanı geri alamazsınız.

One-Way Door vs Two-Way Door Nedir?

Bezos’un yaklaşımı kararları iki kategoriye ayırır. Bu ayrım basit görünür ama etkisi derindir.

Bazı kararlar vardır ki bir kez alındığında geri dönmek oldukça zordur. Bunlar genellikle maliyeti yüksek, etkisi geniş ve geri dönüşü sancılı olan kararlardır. İşte bunlara One-Way Door denir. Yani içeri girdikten sonra çıkmanın kolay olmadığı kapılar.

Örneğin büyük bir veri migrasyonu, sistem mimarisinin kökten değiştirilmesi ya da ürünün iş modelinin değiştirilmesi bu kategoriye girer. Bu tür kararlar dikkatli değerlendirme gerektirir çünkü hata payı düşüktür.

Diğer tarafta ise çok daha esnek kararlar vardır. Deneyebilirsiniz, yanılırsınız, geri alırsınız ve yolunuza devam edersiniz. Bunlar Two-Way Door kararlarıdır. Yani girip çıkabileceğiniz kapılar.

Bir UI değişikliği yapmak, feature flag ile bir özelliği kademeli açmak ya da küçük bir refactor denemek bu kategoriye girer. Bu tür kararlar hızlı alınmalı çünkü asıl değer öğrenme hızındadır.

Ekiplerin Düştüğü Yanılgı

Teoride bu ayrım oldukça nettir ama pratikte ekiplerin yaptığı en büyük hata şudur: Çoğu kararı One-Way Door gibi ele almak.

Bu durum genellikle iyi niyetle başlar. Kimse yanlış karar almak istemez. Kimse sistemin bozulmasına sebep olmak istemez. Ama bu yaklaşım zamanla şu sonuçları doğurur:

Kararlar yavaşlar, toplantılar uzar, herkes daha fazla veri ister, “biraz daha düşünelim” cümlesi standart hale gelir. Sonunda ekipler hareket edemez hale gelir.

Buna “gizli yavaşlama” denebilir. Çünkü dışarıdan bakıldığında herkes çalışıyor gibi görünür ama aslında hiçbir şey ilerlemiyordur.

Örnek Case

Bir ekipte haftalarca süren bir tartışmaya denk gelmiştim. Konu şuydu: REST mi kullanılmalı yoksa GraphQL mi?

Oldukça teknik görünen bu tartışma giderek büyüdü. Dokümanlar yazıldı, farklı ekiplerden görüşler alındı, hatta küçük prototipler geliştirildi. Ama karar bir türlü çıkmadı.

Sonunda ekibe tek bir soru sordum: “Bunu seçtikten sonra değiştirme maliyeti nedir?”

Cevap düşündüğüm gibiydi. Evet, bir maliyet vardı ama imkansız değildi. Yani bu aslında geri dönülebilir bir karardı.

Başka bir deyişle, ekip bu kararı gereksiz yere bir One-Way Door olarak ele almıştı. Oysa bu bir Two-Way Door kararıydı ve hızlıca alınmalıydı.

Bu farkındalıkla karar birkaç gün içinde verildi ve ekip ilerlemeye başladı.

One-Way Door Kararları Nasıl Ele Alınmalı ?

Gerçekten geri dönüşü zor olan kararlar elbette vardır ve bunlar hafife alınmamalıdır. Bu tür durumlarda daha sistematik ilerlemek gerekir.

Bu tip kararlarla karşılaştığımda öncelikle mümkün olduğunca veri toplamaya çalışırım. Sadece teknik analiz değil, benzer problemleri yaşamış ekiplerin deneyimleri de bu noktada çok değerlidir.

Ardından doğru insanları sürece dahil etmek kritik hale gelir. Bu genellikle senior mühendisler, mimarlar ve product tarafının birlikte değerlendirme yaptığı bir süreç olur.

Ama burada dikkat edilmesi gereken önemli bir nokta var: Süreci ağırlaştırmak ama kilitlememek. Çünkü fazla analiz de başka bir problem doğurur: kararın hiç alınamaması.

Bu yüzden mümkün olduğunca bir “geri dönüş planı” da oluştururum. Her ne kadar One-Way Door olarak adlandırılsa da, iyi planlanmış bir sistemde tamamen geri dönülemez karar sayısı aslında oldukça azdır.

Two-Way Door Kararlarının Farkı

Asıl fark yaratan yer burasıdır. Çünkü yazılım ekiplerinin günlük kararlarının büyük çoğunluğu bu kategoridedir.

Bu tür kararlar için yaklaşımım oldukça net: hızlı karar ver, küçük başla, ölç ve gerekiyorsa geri dön.

Örneğin yeni bir feature geliştiriyorsanız, bunu tüm kullanıcıya açmak zorunda değilsiniz. Küçük bir kullanıcı grubunda deneyebilirsiniz. Eğer sorun çıkarsa kapatabilirsiniz.

Feature flag kullanımı sayesinde yeni geliştirmeler kontrollü şekilde açılır. Bu hem riskleri azaltır hem de kararları hızlandırır.

Bu yaklaşım sayesinde ekipler şunu öğrenir: “Yanlış karar almak dünyanın sonu değil.” Asıl problem denememek ve öğrenmemektir.

Yönetici Gözüyle

Bu modelin başarıyla uygulanması büyük ölçüde ekip liderine bağlıdır. Çünkü ekiplerin doğal eğilimi genellikle riskten kaçınmak yönündedir.

İnsanlar yanlış karar almaktan çekinir. Eleştirilmekten korkar. Bu yüzden kararları geciktirmek daha güvenli bir seçenek gibi görünür.

Bu noktada liderin görevi sadece teknik yönlendirme yapmak değil, aynı zamanda doğru karar ortamını oluşturmaktır.

Ekipte psikolojik güven oluşturmak bu işin temelidir. İnsanlar hata yaptığında cezalandırılmayacağını bilmeli. Aksi halde kimse risk almaz.

Ayrıca ekip içinde karar alma framework’ünü netleştirmek de çok önemlidir. Herkesin aynı dili konuşması gerekir. “Bu karar geri alınabilir mi?” sorusu ekip içinde refleks haline gelmelidir.

Over-Engineering

Ekiplerin her kararı kritik görmesi sadece hız problemleri yaratmaz, aynı zamanda over-engineering’e de sebep olur.

Henüz ihtiyaç yokken karmaşık caching mekanizmaları kurmak, gereksiz abstraction katmanları eklemek ya da ileride olabilir diye yapılan optimizasyonlar genellikle bu zihniyetin ürünüdür.

Bunun temelinde şu düşünce yatar: “Sonra değiştiremeyiz.”

Oysa çoğu zaman değiştirebilirsiniz. Ve çoğu zaman değiştirmek, baştan aşırı kompleks bir sistem kurmaktan daha ucuzdur.

Karar Alma Hızı Gerçek Bir Metriktir

Çoğu ekip velocity, deployment frequency gibi metrikleri takip eder ama decision latency neredeyse hiç ölçülmez.

Oysa karar alma süresi uzadıkça delivery süresi de uzar. Bu çok basit ama çoğu zaman gözden kaçan bir ilişkidir.

Hızlı karar almak her zaman doğru karar almak anlamına gelmez ama yavaş karar almak çoğu zaman daha iyi sonuç vermez.

İyi Ekiplerle Ortalama Ekip Arasındaki Fark

Senior ekipler kararların doğasını daha iyi anlar.

Hangi kararın geri dönülemez olduğunu, hangisinin deney yapılabilecek bir alan olduğunu daha hızlı ayırt ederler. Bu da onları hem daha hızlı hem de daha etkili yapar.

Daha junior ekipler ise genellikle her şeyi kritik görür. Bu da onları sürekli daha üst seviyeye danışan, risk almaktan kaçınan ve dolayısıyla yavaşlayan ekipler haline getirir.

Organizasyonel Boyut

Bu model sadece ekip içinde değil, organizasyon genelinde de büyük fark yaratır.

Eğer bir şirkette her karar üst yönetime gidiyorsa, bu genellikle tüm kararların One-Way Door gibi ele alındığını gösterir.

Oysa sağlıklı bir organizasyonda Two-Way Door kararlar ekip seviyesinde alınır. Bu da otonomi ve hız getirir.

Uygulama Şekli

Ekiplerde bu yöntemi uygularken kararları açıkça sınıflandırabiliriz.

Bazı durumlarda bu sınıflandırmayı görünür hale getirmek için kararların başına küçük etiketler koyabiliriz:

• ONE-WAY
• TWO-WAY

Bu bile tek başına ciddi fark yaratır. Çünkü insanlar artık neyi nasıl ele alacaklarını daha net görebilirler.

Ayrıca Two-Way Door kararlar için bilinçli olarak kısa süreler belirleyebiliri. Uzayan tartışmaları bilinçli şekilde kesebiliriz.

Özetleyecek olursak;

Yazılım dünyasında mükemmel karar diye bir şey yok. Ama doğru hızda alınmış, doğru sınıflandırılmış kararlar vardır.

One-Way Door vs Two-Way Door yaklaşımı bana şunu öğretti: Asıl problem yanlış karar almak değil, yanlış türde karar almak ya da doğru kararı yanlış hızda almaktır.

Eğer ekip olarak hangi kararın geri dönülebilir olduğunu doğru anlayabilirseniz, gereksiz korkulardan kurtulursunuz. Bu da sizi daha hızlı, daha cesur ve daha üretken bir ekip haline getirir.