Kuinka ratkaiset arkkitehtuurierimielisyydet tiimissäsi?

Question

Accepted Answer

Älykkäät insinöörit ovat eri mieltä arkkitehtuurista, se on terveellistä. TL:n tehtävä on muuttaa erimielisyys **hyviksi päätöksiksi ja sitoutuneeksi tiimiksi**, ei voittaa keskustelua. Useimmat riidat häviävät, kun kaikki sopivat kriteereistä.

## Prosessi sen ratkaisemiseksi

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

## Konkreettinen esimerkki

Kaksi insinööriä väittää microservices vs. monolith. Uudelleenmuotoilette: "Mitä optimoimme ensi vuonna?" Vastaus, nopea toimitus pienellä tiimillä, tekee monolithista selvän valinnan. Väittely oli todella piilotettujen tavoitteiden vuoksi.

## Milloin päättää vs. lykätä

Palautettavissa oleville päätöksille valitse yksi nopeasti ja etene eteenpäin, väärän päätöksen kustannus on pieni. Yhdensuuntaisille päätöksille hidasta ja kerää tietoja. Harkinnan sovittaminen palautettavuuteen välttää sekä aikahukkaa että huolimattomia päätöksiä.

## Yksi sudenkuoppa

Älä anna senioriteettisi sulkea keskustelua, eikä anna keskustelun jatkua ikuisesti. Molemmat tappavat tiimejä: yksi herättää katkeruutta, toinen aiheuttaa halvaantumista.

## Miksi se on tärkeää

Ratkaisemattomat arkkitehtuurikiistat hautautuvat ja jakavat tiimit leireiksi.

TL, joka helpottaa reilusti ja päättää sitten, saa sekä vakaan suunnittelun että tiimin, joka omistaa sen yhdessä, jopa ne, jotka väittivät toisella puolella.