Πώς εξηγείτε το technical debt σε ένα μη τεχνικό κοινό;

Question

Accepted Answer

**Μεταφράζω το tech debt στη γλώσσα που ήδη χρησιμοποιεί το κοινό: χρήμα, ταχύτητα και ρίσκο.** Έναν μη τεχνικό stakeholder δεν τον νοιάζει το coupling ή το test coverage· τον νοιάζει ότι τα features γίνονται πιο αργά και πιο ακριβά να παραδοθούν. Έτσι πλαισιώνω το debt ως πρόβλημα οικονομικό και παράδοσης, όχι ως πρόβλημα κώδικα.

## Το πλαίσιο που χρησιμοποιώ

- **Η οικονομική μεταφορά, χρησιμοποιημένη προσεκτικά.** "Πήραμε μια συντόμευση για να παραδώσουμε γρήγορα, σαν να πήραμε δάνειο. Δούλεψε, και τώρα πληρώνουμε τόκους πάνω σε αυτό κάθε sprint. Κάθε νέο feature σε αυτή την περιοχή κοστίζει περισσότερο εξαιτίας αυτών των τόκων." Αυτό προσγειώνεται επειδή όλοι καταλαβαίνουν χρέος και τόκους.
- **Κάν' το συγκεκριμένο με τις δικές τους μετρικές.** Όχι "ο κώδικας είναι ακατάστατος" αλλά "αυτό το feature πήρε τρεις εβδομάδες· πριν δύο χρόνια το ίδιο μέγεθος έπαιρνε μία. Η διαφορά είναι το overhead συντήρησης που έχουμε συσσωρεύσει."
- **Σύνδεσέ το με αποτελέσματα που τους νοιάζουν.** Πιο αργή παράδοση, περισσότερα bugs που φτάνουν στους πελάτες, δυσκολότερο onboarding για νέες προσλήψεις, αυξανόμενο ρίσκο outage. Σύνδεσε το debt με έσοδα, φήμη και ταχύτητα roadmap.

## Πώς το κάνω απόφαση, όχι παράπονο

- Παρουσίασέ το ως **trade-off με επιλογές**, όχι ως απαίτηση: "Μπορούμε να συνεχίσουμε να παραδίδουμε features στον τρέχοντα επιβραδυνόμενο ρυθμό, ή να επενδύσουμε δύο sprints τώρα για να μειώσουμε το μελλοντικό κόστος feature κατά περίπου ένα τρίτο."
- Ποσοτικοποίησε όπου μπορώ: χαμένος χρόνος ανά sprint, συχνότητα incident, το ποσοστό της χωρητικότητας που ξοδεύεται σε firefighting.
- Να είσαι ειλικρινής ότι **κάποιο debt είναι εντάξει.** Δεν πρέπει να ξεπληρωθεί όλο το debt· το θέμα είναι να ξεπληρώσεις το debt που ενεργά φορολογεί την παράδοση.

## Παγίδες

- **Χρήση ορολογίας** ("refactor," "coupling," "η αρχιτεκτονική είναι λάθος"). Σε κάνει να ακούγεσαι σαν να θες να κάνεις gold-plating στον κώδικα.
- Πλαισιώνοντάς το ως μηχανικούς που θέλουν καθαρό κώδικα για χάρη του ίδιου του κώδικα· αυτό διαβάζεται ως αυτάρεσκο.
- Κράζοντας λύκο — το να αποκαλείς τα πάντα debt διαβρώνει την αξιοπιστία όταν κάτι πραγματικά επείγον προκύψει.

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

Αν δεν μπορείς να εξηγήσεις το tech debt με επιχειρηματικούς όρους, δεν χρηματοδοτείται ποτέ, και η ομάδα σταδιακά φτάνει σε στασιμότητα ενώ η ηγεσία αναρωτιέται γιατί πέφτει το velocity. Το να το πλαισιώνεις ως κόστος, ταχύτητα και ρίσκο είναι αυτό που σου εξασφαλίζει τον χρόνο να το διορθώσεις πριν γίνει κρίση.