Ekibinizde mimari anlaşmazlıkları nasıl çözersiniz?

Question

Accepted Answer

Akıllı mühendisler mimari konusunda anlaşmayacak, bu sağlıklıdır. TL'nin görevi anlaşmazlığı **iyi bir karar ve taahhüt eden bir ekibe** dönüştürmek, tartışmayı kazanmak değildir. Çoğu anlaşmazlık, herkes kriterler konusunda anlaştığında ortadan kalkar.

## Bunu çözmek için bir süreç

```text
1. AGREE on the criteria first — what are we optimizing for?
   (scale, simplicity, time-to-ship, team familiarity)
2. Let each side make its STRONGEST case — steelman, don't strawman
3. Look for DATA — spike it, benchmark it, prototype it
4. If still tied — the TL decides, and explains why
5. DISAGREE AND COMMIT — once decided, everyone rows together
```

## Somut bir örnek

İki mühendis microservices vs. monolith tartışıyor. Siz yeniden şekillendirir: "Gelecek yılda neyi optimize ediyoruz?" Cevap, küçük bir ekipple hızlı sevkiyat, monolithi açık seçim haline getirir. Tartışma aslında belirtilmemiş hedeflerydi.

## Karar vermek vs. Ertelemek zamanı

Tersinir kararlar için hızlı birini seçin ve devam edin, yanlış karar vermenin maliyeti küçüktür. Tek yönlü kapılar için yavaşlayın ve veri toplayın. Düşünceyi reversibiliteyle eşleştirmek hem bikeshedding hem de dikkatsiz aramaları önler.

## Bir tuzak

Kıdemliliğinizin tartışmayı kapatmasına izin vermeyin veya tartışmanın sonsuza kadar devam etmesine izin vermeyin. Her ikisi de ekipleri öldürür: biri husumet besler, diğeri felç yaratır.

## Neden önemli

Çözülmemiş mimari mücadeleler festerlenir ve ekipleri kamplara bölerler.

Adilce kolaylaştırıp sonra karar veren bir TL, hem sağlıklı bir tasarım hem de onu birlikte sahiplenen bir ekip elde eder; hatta diğer tarafı savunanlar bile.