Decision Drift

Çoğu karar bozulmaz.

Kayarak değişir.

Biri geri aldığı için değil. Ekip fikrini değiştirdiği için değil.

Gerçeklik ilerlediği halde karar tekrar ele alınmadığı için.

Decision Drift, bir kararın niyeti ile sistemin yaşanan gerçekliği arasındaki sessiz ayrışmadır.

---

Drift Bir “Hata Anı” Değildir

Ekipler genelde tek bir kırılma noktası arar.

Bir release. Bir commit. Bir değişiklik.

Ama drift’in net bir zaman damgası yoktur.

Küçük ve makul adımlarla olur:

• “güvenlik için” bir koruma eklenir
• bir istisna tanımlanır
• “geçici” workaround kalıcı olur
• yeni bir kısıt sessizce davranışı şekillendirir

Her adım savunulabilir.

Sonuç ise çoğu zaman savunulamaz.

---

En Yaygın Akış

Bir karar verilir.

Niyet nettir:

• hangi problem çözülüyor
• neden bu bedel kabul ediliyor
• karar doğruysa hangi sinyalin değişmesi bekleniyor

Sonra karar yayına alınır.

Ve kodun, ayarların, alışkanlıkların içine gömülür.

Haftalar sonra sistem vardır.

Karar yoktur.

Geriye sadece sonuç kalır.

Dashboard hareketi gösterir.

Ama anlamı değil.

---

Basit Bir Örnek

Karar: Onboarding sürtünmesini azalt.

Beklenti: Time-to-value düşsün.

Sonra zamanla:

• “güvenlik için” yeni bir doğrulama adımı eklenir
• “açıklamak için” bir modal eklenir
• “segmentasyon için” yeni bir alan zorunlu olur
• bir edge-case için fallback akış eklenir

Kimse “kararı geri aldık” demez.

Ama onboarding artık ağırlaşmıştır.

Metriklere bakınca sadece sonuç görünür:

• drop-off artmıştır
• tamamlanma süresi uzamıştır

Görünmeyen şey drift’tir:

• sistem artık orijinal kararı yansıtmıyordur

---

Drift Neden Bu Kadar Zor Fark Edilir

Decision Drift iyi niyetin içine saklanır.

Kötü niyetten doğmaz.

Şunlardan doğar:

• lokal optimizasyonlar
• farklı ekiplerin farklı kısıtları çözmesi
• istisnaların büyümesi
• ortak karar hafızasının olmaması

Her değişiklik küçüktür.

Ama drift bileşik etki yaratır.

Ve bir noktadan sonra politikleşir:

• “Biz bunu hiç kararlaştırmadık.”
• “Zaten hep böyleydi.”
• “X yüzünden mecburduk.”

Hepsi doğru olabilir.

Sorun da budur.

---

Drift: Bug Değil, Debt Değil

Drift bug değildir.

Bug, tanımlı davranıştan sapmadır.

Drift, niyetin muhakemesinden sapmadır.

Teknik borç da değildir.

Teknik borç kod maliyetidir.

Drift karar maliyetidir.

Drift birikirse sonunda Decision Debt olur:

• daha çok istisna
• daha çok workaround
• daha çok “sonra düzeltiriz”

Sistem faiz öder.

Ama ekip ana parayı nerede kaybettiğini bulamaz.

---

Silent Revert Drift’in Akrabasıdır

Bazen drift sert bir noktada biter:

Karar fiilen geri alınır.

Ama kimse söylemez.

Not yok. Zaman damgası yok. Öğrenme yok.

Bu Silent Reverttir.

Decision Drift çoğu zaman Silent Revert’in zeminini hazırlar.

Çünkü niyet zaten çözülmüştür.

---

Asıl Bedel: Öğrenme Kırılır

Drift’in en büyük bedeli sonuç değildir.

Öğrenmenin kaybıdır.

Ekip tahmin etmek zorunda kalır:

• ne olmasını bekliyorduk
• neden bu yolu seçtik
• hangi varsayımlar doğruydu

Bağlam yoksa:

• başarı yanlış sebeplere bağlanır
• başarısızlık ahlakileştirilir
• retro “hikâye anlatımı”na döner

Ve aynı tartışmalar geri gelir.

Karar artık bir nesne olarak yoktur.

---

Drift’i Ne Durdurur

Daha fazla dashboard drift’i durdurmaz.

Dashboard aşağıda çalışır.

Drift yukarıda başlar.

Drift’i durduran şey kararları kalıcı varlıklar olarak ele almaktır:

• karar açık yazılır
• beklenti açık yazılır
• sinyal tanımlanır
• gerçeklik sinyalle kıyaslanır
• tekrar ele almak normalleşir

Yani:

Karar Odaklı Geliştirme.

---

Pratik Test

Her önemli değişiklik için şunu sor:

“90 gün sonra geri dönersek, ne olmasını beklediğimizi hâlâ biliyor olacak mıyız?”

Cevap “muhtemelen hayır” ise drift risk değildir.

Drift çoktan takvime yazılmıştır.

---

Sonuç

Decision Drift, kararlar ‘an’ gibi ele alındığında olur.

Ama kararlar an değildir.

Doğruluğu zaman içinde test edilen yaşayan varlıklardır.

Ekipler hareket değil öğrenme istiyorsa, drift görünür olmalıdır.

Suçlamak için değil.

Hatırlamak için.