# Technical Debt: 7 σημάδια ότι σας κοστίζει

Στο προηγούμενο άρθρο είδαμε τι είναι το technical debt και πώς μπορεί σταδιακά να μετατραπεί από τεχνική εκκρεμότητα σε επιχειρηματικό περιορισμό.

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

Σπάνια υπάρχει ένα συγκεκριμένο σημείο όπου μπορούμε να πούμε ότι «από σήμερα έχουμε technical debt». Συνήθως εμφανίζεται μέσα από μικρές καθυστερήσεις, περιορισμούς και προβλήματα που συσσωρεύονται με τον χρόνο.

Ακολουθούν μερικά από τα πιο συνηθισμένα σημάδια.

## 1. Κάθε μικρή αλλαγή χρειάζεται περισσότερο χρόνο από όσο θα έπρεπε

Μία από τις πιο χαρακτηριστικές ενδείξεις είναι όταν απλές αλλαγές αρχίζουν να απαιτούν δυσανάλογα μεγάλο χρόνο ανάπτυξης.

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

Το πρόβλημα δεν είναι απαραίτητα η ίδια η νέα λειτουργία. Είναι ότι η υπάρχουσα αρχιτεκτονική δεν επιτρέπει πλέον εύκολες αλλαγές.

## 2. Οι developers φοβούνται να αλλάξουν συγκεκριμένα σημεία της εφαρμογής

Σε ένα υγιές software project, η ομάδα πρέπει να μπορεί να εξελίσσει το σύστημα με σχετική ασφάλεια.

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

Αυτό μπορεί να οφείλεται σε πολύπλοκο legacy code, έλλειψη automated tests, ελλιπή documentation ή σε λειτουργίες που έχουν συνδεθεί μεταξύ τους με τρόπο που δεν είναι πλέον ξεκάθαρος.

Όσο περισσότερο μεγαλώνει αυτή η αβεβαιότητα, τόσο περισσότερο αυξάνεται και το κόστος κάθε μελλοντικής αλλαγής.

## 3. Οι ομάδες χρησιμοποιούν Excel και χειροκίνητες διαδικασίες γύρω από το σύστημα

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

Οι εργαζόμενοι αρχίζουν να δημιουργούν spreadsheets, να ανταλλάσσουν δεδομένα μέσω email ή να κρατούν πληροφορίες σε διαφορετικά εργαλεία επειδή η βασική εφαρμογή δεν μπορεί πλέον να καλύψει τη διαδικασία.

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

Σε αυτή τη φάση, η ανάπτυξη κατάλληλων internal tools ή η αυτοματοποίηση συγκεκριμένων workflows μπορεί να μειώσει σημαντικά την καθημερινή τριβή.

## 4. Τα συστήματα της επιχείρησης δεν επικοινωνούν μεταξύ τους

Καθώς μια επιχείρηση μεγαλώνει, συνήθως αυξάνεται και ο αριθμός των συστημάτων που χρησιμοποιεί.

CRM, ERP, e-commerce, accounting software, email marketing platforms, warehouse systems και εσωτερικές εφαρμογές χρειάζεται συχνά να ανταλλάσσουν δεδομένα.

Όταν αυτή η ανταλλαγή γίνεται με exports, imports, spreadsheets ή χειροκίνητη αντιγραφή πληροφοριών, δημιουργούνται καθυστερήσεις και λάθη.

Τα σωστά automation workflows και integrations μπορούν να μετατρέψουν αυτές τις αποσπασματικές διαδικασίες σε μια πιο σταθερή υποδομή όπου τα δεδομένα μεταφέρονται αυτόματα μεταξύ των συστημάτων.

## 5. Κάθε νέο feature δημιουργεί νέα bugs

Τα bugs είναι φυσιολογικό μέρος της ανάπτυξης λογισμικού.

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

Η απουσία tests, η επανάληψη κώδικα και οι πολύ στενές εξαρτήσεις μεταξύ διαφορετικών λειτουργιών αυξάνουν τον κίνδυνο regressions.

Σε αυτό το σημείο, το κόστος δεν βρίσκεται μόνο στον χρόνο ανάπτυξης του νέου feature. Βρίσκεται και στον χρόνο που απαιτείται στη συνέχεια για debugging, testing και support.

## 6. Η εφαρμογή εξαρτάται από έναν συγκεκριμένο developer

Ένα software project δεν πρέπει να βασίζεται αποκλειστικά στη γνώση ενός ανθρώπου.

Αν μόνο ένας developer γνωρίζει πώς λειτουργεί ένα κρίσιμο κομμάτι της εφαρμογής ή αν σημαντικές τεχνικές αποφάσεις υπάρχουν μόνο «στο μυαλό» της αρχικής ομάδας ανάπτυξης, δημιουργείται σημαντικός επιχειρηματικός κίνδυνος.

Η σωστή τεκμηρίωση, η καθαρή αρχιτεκτονική και οι κοινές πρακτικές ανάπτυξης επιτρέπουν σε περισσότερους developers να κατανοούν και να εξελίσσουν το σύστημα.

Αυτό είναι ιδιαίτερα σημαντικό για εφαρμογές που αναμένεται να λειτουργούν και να εξελίσσονται για πολλά χρόνια.

## 7. Η τεχνολογία αρχίζει να περιορίζει τις επιχειρηματικές αποφάσεις

Αυτό είναι ίσως το πιο σημαντικό σημάδι.

Όταν μια επιχειρηματική ιδέα απορρίπτεται όχι επειδή δεν έχει αξία, αλλά επειδή «το σύστημα δεν μπορεί να το υποστηρίξει», το technical debt έχει πλέον ξεπεράσει το επίπεδο του development.

Μπορεί να αφορά μια νέα υπηρεσία, ένα integration, ένα νέο workflow, περισσότερους χρήστες ή την ανάγκη να επεκταθεί μια πλατφόρμα σε διαφορετική αγορά.

Όταν η τεχνολογία καθορίζει τι μπορεί και τι δεν μπορεί να κάνει η επιχείρηση, χρειάζεται επανεξέταση της τεχνικής βάσης.

## Refactoring, modernization ή rebuild;

Η ύπαρξη technical debt δεν σημαίνει αυτόματα ότι μια εφαρμογή πρέπει να δημιουργηθεί ξανά από την αρχή.

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

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

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

## Το πρώτο βήμα είναι να γνωρίζετε τι πραγματικά έχετε

Πριν αποφασιστεί οποιαδήποτε τεχνική αλλαγή, χρειάζεται πρώτα να υπάρχει καθαρή εικόνα της υπάρχουσας κατάστασης.

Ποια σημεία δημιουργούν καθυστερήσεις; Ποιες διαδικασίες παραμένουν χειροκίνητες; Πού εμφανίζονται συχνότερα προβλήματα; Ποιες αλλαγές θέλει να κάνει η επιχείρηση τους επόμενους μήνες ή χρόνια;

Η απάντηση δεν είναι πάντα περισσότερο development.

Μερικές φορές χρειάζεται refactoring. Άλλες φορές καλύτερα integrations, automation ή νέα internal tools. Και σε ορισμένες περιπτώσεις, μια νέα πλατφόρμα αποτελεί την πιο βιώσιμη μακροπρόθεσμη λύση.

Το σημαντικό είναι οι τεχνικές αποφάσεις να βασίζονται στις πραγματικές ανάγκες της επιχείρησης και όχι μόνο στους περιορισμούς του υπάρχοντος συστήματος.

Στη Redcase αναλύουμε υπάρχουσες εφαρμογές, workflows και τεχνικές υποδομές και σχεδιάζουμε την επόμενη φάση τους με στόχο ένα software περιβάλλον που μπορεί να εξελίσσεται μαζί με την επιχείρηση.

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

---

Canonical HTML: https://redcase.gr/blog/technical-debt-signs-business