Cum rezolvi dezacordurile de arhitectură în echipa ta?

Question

Accepted Answer

Inginerii deștepți vor fi în dezacord cu privire la arhitectură, este sănătos. Rolul TL este să transforme dezacordul într-o **decizie bună și o echipă angajată**, nu să câștige argumentul. Majoritatea disputelor se rezolvă odată ce toată lumea este de acord cu criteriile.

## Un proces pentru rezolvarea acesteia

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

## Un exemplu concret

Doi ingineri discută microservicii vs. monolitic. Tu reformulezi: "La ce ne optimizăm în anul următor?" Răspunsul, lansarea rapidă cu o echipă mică, face ca monolitul să fie alegerea evidentă. Argumentul era cu adevărat despre obiective neexprimate.

## Când să decizi vs. când să amâni

Pentru deciziile reversibile, alege una rapid și mergi mai departe, costul deciziei greșite este mic. Pentru ușile cu sens unic, încetinește și strânge date. Potrivirea deliberării cu reversibilitatea evită atât bikeshedding-ul cât și apelurile nechibzuite.

## O capcană

Nu lăsa senioritățile tale să oprească dezbaterea, sau lăsa dezbaterea să dureze pentru totdeauna. Ambele ucid echipele: una generează resentimente, cealaltă generează paralizie.

## De ce este important

Fighturile de arhitectură nerezolvate se agravează și împart echipele în tabere.

Un TL care facilitează corect, apoi decide, obține atât o proiectare solodă cât și o echipă care o deține împreună, chiar și pe cei care au argumentat cealaltă parte.