Ένα website λειτουργεί, μια εφαρμογή εξυπηρετεί τους πελάτες και τα βασικά συστήματα μιας επιχείρησης κάνουν τη δουλειά τους. Εξωτερικά, όλα μπορεί να φαίνονται απολύτως φυσιολογικά. Πίσω από την οθόνη, όμως, μπορεί να έχει αρχίσει να συσσωρεύεται ένα κόστος που δεν εμφανίζεται άμεσα σε κανένα τιμολόγιο: το technical debt.
Ο όρος περιγράφει τις τεχνικές εκκρεμότητες που δημιουργούνται όταν μια γρήγορη λύση επιλέγεται αντί για μια πιο ολοκληρωμένη προσέγγιση. Μπορεί να είναι ένας παλιός κώδικας, ένα plugin που έπρεπε να έχει αντικατασταθεί, μια προσωρινή σύνδεση ανάμεσα σε δύο συστήματα ή μια διαδικασία που λειτουργεί μόνο επειδή κάποιος γνωρίζει ένα συγκεκριμένο workaround.
Στην αρχή, όλα αυτά συχνά φαίνονται λογικά. Υπάρχει deadline, πρέπει να γίνει ένα launch ή ένας πελάτης χρειάζεται άμεσα μια νέα λειτουργία. Η ομάδα επιλέγει τη γρηγορότερη λύση και συνεχίζει. Το πρόβλημα ξεκινά όταν το «προσωρινό» παραμένει για χρόνια.
Το technical debt μοιάζει αρκετά με ένα οικονομικό χρέος. Η αρχική επιλογή μπορεί να προσφέρει χρόνο σήμερα, αλλά δημιουργεί ένα είδος τόκου που πληρώνεται αργότερα. Κάθε νέα αλλαγή χρειάζεται περισσότερη δουλειά, κάθε update γίνεται πιο δύσκολο και ένα μικρό πρόβλημα μπορεί να επηρεάσει περισσότερα σημεία του συστήματος.
Ένα συνηθισμένο παράδειγμα είναι ένα εταιρικό website που έχει περάσει από πολλούς developers και αρκετές διαφορετικές φάσεις. Προστίθενται plugins, custom κώδικας, integrations και προσωρινές διορθώσεις. Μετά από κάποια χρόνια, ακόμη και μια απλή αλλαγή μπορεί να απαιτεί ιδιαίτερη προσοχή επειδή κανείς δεν γνωρίζει ακριβώς τι εξαρτάται από τι.
Σε αυτό το σημείο, το technical debt παύει να είναι αποκλειστικά τεχνικό πρόβλημα. Γίνεται επιχειρηματικό.
Αν μια νέα λειτουργία χρειάζεται τρεις εβδομάδες αντί για τρεις ημέρες επειδή το υπάρχον σύστημα είναι δύσκολο να τροποποιηθεί, η επιχείρηση χάνει ταχύτητα. Αν μια αναβάθμιση αναβάλλεται επειδή υπάρχει φόβος ότι θα «σπάσει» κάτι άλλο, αυξάνεται και ο λειτουργικός κίνδυνος.
Το ίδιο συμβαίνει με παλιά λογισμικά που παραμένουν σε χρήση επειδή η αντικατάστασή τους φαίνεται πολύ δύσκολη. Στην αρχή, η επιχείρηση αποφεύγει το κόστος μιας αλλαγής. Με τον χρόνο, όμως, αρχίζει να πληρώνει μέσα από περισσότερη υποστήριξη, χειροκίνητες διαδικασίες και περιορισμένες δυνατότητες.
Η ασφάλεια είναι ακόμη ένας σημαντικός παράγοντας. Παλιές εκδόσεις λογισμικού, ξεχασμένα integrations και συστήματα που δεν ενημερώνονται σωστά μπορούν να δημιουργήσουν κενά. Όσο πιο περίπλοκη γίνεται η τεχνική υποδομή, τόσο δυσκολότερο είναι να γνωρίζει μια ομάδα αν όλα τα σημεία παραμένουν πραγματικά προστατευμένα.
Δεν σημαίνει φυσικά ότι κάθε επιχείρηση πρέπει να ξαναχτίζει συνεχώς τα συστήματά της από την αρχή. Αυτό θα ήταν εξίσου ακριβό και αναποτελεσματικό. Το technical debt είναι σε έναν βαθμό φυσιολογικό, ιδιαίτερα σε περιβάλλοντα όπου χρειάζεται γρήγορη ανάπτυξη.
Το σημαντικό είναι να γνωρίζουμε ότι υπάρχει.
Αν μια ομάδα επιλέξει συνειδητά μια προσωρινή λύση για να προλάβει ένα σημαντικό deadline, μπορεί να είναι απολύτως σωστή απόφαση. Χρειάζεται όμως να καταγραφεί τι πρέπει να διορθωθεί αργότερα και να υπάρχει πραγματικό πλάνο για αυτό.
Το πρόβλημα δημιουργείται όταν οι προσωρινές λύσεις ξεχνιούνται. Μετά από έξι μήνες, κανείς δεν θυμάται γιατί σχεδιάστηκε κάτι με συγκεκριμένο τρόπο. Μετά από δύο χρόνια, η εταιρεία μπορεί να φοβάται να το αλλάξει επειδή δεν γνωρίζει ποιες συνέπειες θα έχει.
Η τεκμηρίωση μπορεί να περιορίσει σημαντικά αυτή την κατάσταση. Δεν χρειάζεται κάθε τεχνική απόφαση να συνοδεύεται από δεκάδες σελίδες εγγράφων. Χρειάζεται όμως να υπάρχουν βασικές πληροφορίες για τα κρίσιμα συστήματα, τις εξαρτήσεις τους και τους λόγους πίσω από σημαντικές επιλογές.
Παράλληλα, χρήσιμο είναι να υπάρχει τακτικός χρόνος για συντήρηση. Οι ομάδες συχνά πιέζονται να δημιουργούν συνεχώς νέες λειτουργίες, επειδή αυτές είναι πιο εύκολο να παρουσιαστούν ως πρόοδος. Η αναβάθμιση μιας παλιάς βάσης δεδομένων ή η αφαίρεση ξεπερασμένου κώδικα δεν φαίνεται εξίσου εντυπωσιακή, αλλά μπορεί να είναι πολύ πιο σημαντική μακροπρόθεσμα.
Εδώ χρειάζεται συνεργασία ανάμεσα στην τεχνική ομάδα και στη διοίκηση. Αν το technical debt παρουσιάζεται μόνο ως «πρέπει να καθαρίσουμε τον κώδικα», δύσκολα θα αποκτήσει προτεραιότητα. Αν όμως εξηγηθεί ότι μια συγκεκριμένη τεχνική εκκρεμότητα αυξάνει τον χρόνο ανάπτυξης, δημιουργεί κίνδυνο ή περιορίζει μια νέα υπηρεσία, το επιχειρηματικό όφελος γίνεται πιο ξεκάθαρο.
Δεν χρειάζεται επίσης να διορθωθούν όλα ταυτόχρονα. Όπως και σε κάθε άλλη μορφή χρέους, προτεραιότητα έχουν τα σημεία με τη μεγαλύτερη επίδραση. Ένα παλιό σύστημα που λειτουργεί σταθερά και σπάνια αλλάζει μπορεί να είναι λιγότερο επείγον από μια πλατφόρμα που δημιουργεί προβλήματα κάθε εβδομάδα.
Η σωστή ερώτηση δεν είναι επομένως «έχουμε technical debt;». Σχεδόν κάθε ψηφιακή επιχείρηση έχει σε κάποιο βαθμό. Η πιο χρήσιμη ερώτηση είναι ποιο μέρος του αρχίζει να περιορίζει την ανάπτυξη.
Η ταχύτητα είναι σημαντική στην τεχνολογία. Μια επιχείρηση δεν μπορεί να περιμένει την τέλεια λύση πριν κάνει κάθε κίνηση. Χρειάζεται όμως να γνωρίζει πότε η συνεχής επιλογή του γρήγορου δρόμου αρχίζει να κάνει κάθε επόμενο βήμα πιο δύσκολο.
Γιατί το technical debt σπάνια δημιουργεί ένα μεγάλο πρόβλημα από τη μια μέρα στην άλλη. Συνήθως μεγαλώνει σιωπηλά, μέσα από δεκάδες μικρές αποφάσεις.
Και κάποια στιγμή, η επιχείρηση ανακαλύπτει ότι δεν πληρώνει πλέον μόνο για να αναπτύξει το επόμενο ψηφιακό της βήμα. Πληρώνει και για όλα όσα άφησε πίσω της.
