Γιατί ένα έργο λογισμικού διαρκεί περισσότερο απ' όσο εκτιμήθηκε

Σχεδόν κάθε πελάτης έχει μια ιστορία για ένα έργο λογισμικού που υποτίθεται ότι θα διαρκούσε δύο μήνες και διάρκεσε έξι. Η συνήθης εξήγηση είναι «ο πάροχος ήταν αργός» ή «η τεχνολογία ήταν πιο δύσκολη απ’ όσο φαινόταν». Σπάνια είναι αυτό. Τα έργα σχεδόν πάντα καθυστερούν για λόγους που είναι ορατοί από την αρχή, αν κάποιος τους ψάξει.

Η εμβέλεια που δεν γράφτηκε ποτέ κάτω

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

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

Οι εξαρτήσεις που κανείς δεν έλεγξε εγκαίρως

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

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

Πού πραγματικά χάνεται ο χρόνος

Αιτία καθυστέρησης	Γιατί συμβαίνει
Εμβέλεια που δεν γράφτηκε γραπτώς	Κάθε πλευρά υποθέτει διαφορετικό έργο
Εξωτερικό API χωρίς τεκμηρίωση ή πρόσβαση	Ανακαλύπτεται αργά, όχι στο discovery
Απόφαση πελάτη που περιμένει έγκριση	Η ομάδα περιμένει, το ρολόι όχι
Αλλαγή εμβέλειας στη μέση του έργου	Νέα δουλειά προστίθεται χωρίς νέο χρόνο
Δοκιμή μόνο στο τέλος	Προβλήματα βρίσκονται αφού είναι ακριβά να διορθωθούν

Οι αποφάσεις που περιμένουν κάποιον άλλο

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

Η εμβέλεια που αλλάζει στη μέση, χωρίς να το πει κανείς

Μια νέα λειτουργία που φαίνεται μικρή — «μπορούμε απλά να προσθέσουμε και εξαγωγή σε Excel;» — δεν είναι ποτέ τόσο μικρή όσο ακούγεται, γιατί αλλάζει υποθέσεις που ήδη χτίστηκαν. Αυτό δεν σημαίνει ότι οι αλλαγές εμβέλειας είναι κακές — συχνά είναι σωστές αποφάσεις, καθώς το έργο γίνεται πιο συγκεκριμένο στο μυαλό όλων. Σημαίνει ότι πρέπει να αναγνωρίζονται ανοιχτά ως αλλαγή εμβέλειας, με τον χρόνο που προσθέτουν ορατό, όχι να απορροφώνται σιωπηλά στο αρχικό χρονοδιάγραμμα.

Η δοκιμή που γίνεται πολύ αργά

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

Ο ρόλος που κανείς δεν όρισε ρητά

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

Γιατί οι κύκλοι επανάληψης αποκαλύπτουν το πρόβλημα νωρίς

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

Τι κάνουμε εμείς διαφορετικά

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

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

Τα έργα δεν καθυστερούν γιατί η δουλειά είναι δύσκολη. Καθυστερούν γιατί κάτι ήταν αόρατο όταν έπρεπε να είναι ορατό.

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