Kaip išsprendžiate architektūros nesutarimus savo komandoje?

Question

Accepted Answer

Protingi inžinieriai nesutarims dėl architektūros, tai yra sveika. TL darbas yra nesutarimą paversti **gera sprendimu ir įsipareigojusia komanda**, o ne laimėti ginčą. Dauguma nesutarimų išnyksta, kai visi sutaria dėl kriterijų.

## Kodėl tai svarbu

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

## Konkretus pavyzdys

Du inžinieriai ginčijasi dėl mikrotarnybų ir monolito. Jūs perkategorijuojate: "Ką mes optimizuojame kitais metais?" Atsakymas – greitai siųsti su maža komanda – daro monolitą akivaizdžiu pasirinkimu. Ginčas iš tikrųjų buvo apie nenurodytus tikslus.

## Kada spręsti, o kada atidėti

Dėl grįžtamų sprendimų pasirinkite greitai ir judėkite, klaidos kaina yra maža. Dėl vienpusių sprendimų sulėtinkite ir rinkite duomenis. Atitikimas deliberaciją grįžtamumui išvengia tiek dviračio šėdo, tiek neatsargių sprendimų.

## Paboga

Neleiskite savo senumui sustabdyti ginčo arba leiskite ginčui tęstis amžinai. Ir vienas, ir kitas žudo komandas: vienas sukeuria nepasitenkinimą, kitas – paraližių.

## Kodėl tai svarbu

Neišspręsti architektūros konfliktymai užkrečia ir skaido komandas.

TL, kuris sąžiningai palengvina, o tada nusprendžia, gauna ir tvirtą dizainą, ir komandą, kuri jį savina kartu, net ir tuos, kurie ginčijosi kitai pusei.