Πώς επιλύετε διαφωνίες αρχιτεκτονικής στην ομάδα σας;

Question

Accepted Answer

Οι έξυπνοι μηχανικοί θα διαφωνούν για την αρχιτεκτονική, αυτό είναι υγιές. Το καθήκον του TL είναι να μετατρέψει τη διαφωνία σε **μια καλή απόφαση και μια δεσμευμένη ομάδα**, όχι να κερδίσει το επιχείρημα. Οι περισσότερες διαφορές διαλύονται μόλις όλοι συμφωνήσουν στα κριτήρια.

## Μια διαδικασία για την επίλυσή της

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

## Ένα συγκεκριμένο παράδειγμα

Δύο μηχανικοί υποστηρίζουν microservices vs. monolith. Επαναδιατυπώνετε: "Τι βελτιστοποιούμε το επόμενο έτος;" Η απάντηση, γρήγορη αποστολή με μια μικρή ομάδα, κάνει το monolith την προφανή επιλογή. Το επιχείρημα ήταν πραγματικά σχετικά με ανεκφώνητους στόχους.

## Πότε να αποφασίσετε έναντι αναβολής

Για αναστρέψιμες αποφάσεις, επιλέξτε μια γρήγορα και προχωρήστε, το κόστος της λανθασμένης απόφασης είναι μικρό. Για απόφασεις μονής κατεύθυνσης, επιβραδύνετε και συγκεντρώνετε δεδομένα. Η αντιστοίχιση της διακριτικής ευχέρειας με την αναστρεψιμότητα αποφεύγει τόσο τη σπατάλη όσο και τις απερίσκεπτες αποφάσεις.

## Μια παγίδα

Μην αφήνετε τη διοικητική ικανότητά σας να σταματήσει τη συζήτηση, ή αφήνετε τη συζήτηση να συνεχιστεί για πάντα. Και τα δύο σκοτώνουν τις ομάδες: το ένα δημιουργεί κατάχρηση, το άλλο παράλυση.

## Γιατί έχει σημασία

Οι άλυτες αρχιτεκτονικές διαμάχες ζυμώνονται και χωρίζουν τις ομάδες σε στρατόπεδα.

Ένας TL που διευκολύνει δίκαια, και στη συνέχεια αποφασίζει, παίρνει τόσο έναν ορθό σχεδιασμό όσο και μια ομάδα που το κατέχει μαζί, ακόμη και αυτοί που υποστήριξαν την άλλη πλευρά.