Come risolvi i disaccordi architetturali nel tuo team?

Question

Accepted Answer

Gli ingegneri intelligenti disaccorderanno sull'architettura, è salutare. Il compito del TL è trasformare il disaccordo in una **buona decisione e un team impegnato**, non vincere l'argomento. La maggior parte delle dispute si dissolve una volta che tutti concordano sui criteri.

## Perché è importante

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

Due ingegneri discutono microservices vs. monolite. Tu riformuli: "Su cosa stiamo ottimizzando nell'anno prossimo?" La risposta, spedire veloce con un piccolo team, rende il monolite la scelta ovvia. L'argomento era davvero su obiettivi non dichiarati.

## Quando decidere vs. rimandare

Per decisioni reversibili, scegline una velocemente e procedi, il costo di decidere male è piccolo. Per porte a senso unico, rallenta e raccogli dati. Far corrispondere la deliberazione alla reversibilità evita sia il bikeshedding che le scelte sconsiderate.

## Un errore

Non lasciare che la tua anzianità arresti il dibattito, o lasciare che il dibattito duri per sempre. Entrambi uccidono i team: uno genera risentimento, l'altro genera paralisi.

## Perché è importante

I conflitti architetturali irrisolti si accumulano e dividono i team in fazioni.

Un TL che facilita equamente, poi decide, ottiene sia un design solido che un team che lo possiede insieme, anche coloro che hanno discusso l'altro lato.