Hogyan oldod meg az architekturális nézeteltéréseket a csapatodban?

Question

Accepted Answer

Az okos mérnökök nem értenek egyet az architektúrában, ez egészséges. A TL feladata a nézeteltérést **jó döntésre és elkötelezett csapatra** fordítani, nem pedig az érvet megnyerni. A legtöbb vita feloldódik, amint mindenki egyetért a kritériumokkal.

## A megoldás folyamata

```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
```

## Egy konkrét példa

Két mérnök vitatkozik a mikroszolgáltatások vs. monolitikus megközelítésről. Újrafogalmazza: "Mit optimalizálunk a következő évben?" A válasz az, hogy gyorsan szállítunk egy kis csapattal, ami a monolitikus megoldást nyilvánvalóvá teszi. Az érv valójában az irányított célokról szólt.

## Mikor döntsd el, mikor halaszd el

A visszafordítható döntésekhez választasz egyet gyorsan és mész tovább, a helytelen döntés költsége kicsi. Az egyirányú ajtók esetén lassulj le és gyűjts adatokat. A megfontolás és a visszafordíthatóság egyeztetése elkerüli a bikesheddinget és a gondatlan döntéseket.

## Egy bukta

Ne hagyd, hogy a senioritásod elfojtsa a vitát, vagy hagyj véget vetni a vitának. Mindkettő megöli a csapatokat: az egyik nehezülést szül, a másik bénulást.

## Miért fontos

A megoldatlan architekturális viták megkeserednek és osztózkodásokra osztják a csapatot.

Egy TL, aki méltányosan segít, majd dönt, egyszerre kap egy szilárd tervet és egy olyan csapatot, amely közösen birtokolja azt, még azok is, akik az ellenkező oldalt képviselték.