„Ένα μικρό λεπτό”
Κάθε άνθρωπος που δουλεύει στη δημιουργία ή τη συντήρηση μιας ιστοσελίδας, εφαρμογής ή συστήματος ξέρει αυτό το μήνυμα.
„Μπορείτε απλά να αλλάξετε αυτό το κουμπί;”
„Είναι πραγματικά μια μικρή διόρθωση.”
„Παρακαλώ, απλώς μετακινήστε αυτό το στοιχείο.”
„Μπορείτε να το κάνετε γρήγορα;”
„Περίπου 5 λεπτά δουλειάς, σωστά;”
Και μερικές φορές όντως είναι.
Κάποιες φορές η αλλαγή χρώματος ενός κουμπιού παίρνει λίγα λεπτά. Κάποιες φορές η διόρθωση ενός ορθογραφικού σφάλματος απαιτεί ένα κλικ. Κάποιες φορές ο προγραμματιστής ανοίγει τον κώδικα, κοιτάζει, αλλάζει μια γραμμή και τελείωσε.
Το πρόβλημα είναι ότι δεν είναι κάθε αλλαγή που φαίνεται μικρή από την οπτική του χρήστη, μικρή και από την οπτική του συστήματος.
Και ένα ακόμα μεγαλύτερο πρόβλημα εμφανίζεται όταν τέτοιες „μικρές αλλαγές” είναι δεκάδες, εκατοντάδες το μήνα. Τότε αρχίζει να συμβαίνει κάτι ενδιαφέρον.
Η εταιρεία μπορεί να έχει την εντύπωση ότι δεν παραγγέλνει τίποτα σημαντικό. Και ταυτόχρονα η ομάδα IT περνάει σημαντικό μέρος του χρόνου της υλοποιώντας ακριβώς αυτές τις μικρές εργασίες.
Και εδώ προκύπτει το ερώτημα: Πόσο κοστίζει πραγματικά ένα κουμπί «Διορθώστε το γρήγορα»;
Ας ξεκινήσουμε με ένα απλό παράδειγμα
Φανταζόμαστε ότι το τμήμα μάρκετινγκ στέλνει στο software house το μήνυμα:
„Είμαστε, πρέπει απλώς να αλλάξουμε το κείμενο σε ένα κουμπί. Αντί για „Δείτε την προσφορά” να γράφει „Γνωρίστε την προσφορά”. Είναι μικρό, παρακαλώ κάντε το γρήγορα.”
Ακούγεται αφελές. Αλλά από την πλευρά της τεχνικής ομάδας μπορεί να φαίνεται εντελώς διαφορετικό.
Ο προγραμματιστής πρέπει:
1. Να αναλύσει το αίτημα
Πού βρίσκεται αυτό το κουμπί;
Είναι μόνο σε ένα σημείο;
Εμφανίζεται σε πολλές εκδόσεις της σελίδας;
Το κείμενο είναι γραμμένο απευθείας στον κώδικα;
Διαχειρίζεται από CMS;
Η αλλαγή αφορά έκδοση για desktop και mobile;
Το κουμπί είναι μέρος ενός component που χρησιμοποιείται και αλλού;
2. Να εφαρμόσει την αλλαγή
Να αλλάξει το κείμενο.
Να ανασχεδιάσει το component.
Να ενημερώσει το περιεχόμενο στο CMS.
Ή να τροποποιήσει τον κώδικα.
3. Να ελέγξει το αποτέλεσμα
Το κουμπί φαίνεται σωστό;
Το κείμενο δεν βγαίνει έξω από την περιοχή του;
Στο κινητό λειτουργεί σωστά;
Η αλλαγή δεν επηρέασε άλλα σημεία;
4. Να κάνει δοκιμές
Μπορεί να κλικάρει κάποιος;
Ο σύνδεσμος οδηγεί εκεί που πρέπει;
Δεν εμφανίστηκε κάποιο σφάλμα;
5. Να αναπτύξει την αλλαγή
Αν η αλλαγή απαιτεί deploy, πρέπει να τοποθετηθεί στο περιβάλλον παραγωγής.
Και ξαφνικά αποδεικνύεται ότι: „Μόνο αλλαγή κειμένου”
δεν σημαίνει απαραίτητα: „Μόνο 5 λεπτά δουλειάς”.
Πόσο μπορεί να κοστίζει μια μικρή αλλαγή;
Ας υποθέσουμε ένα πολύ συντηρητικό σενάριο.
Ο προγραμματιστής αφιερώνει:
- 15 λεπτά στην ανάλυση,
- 20 λεπτά στην υλοποίηση,
- 15 λεπτά στις δοκιμές,
- 10 λεπτά στην προετοιμασία και το deployment.
Σύνολο: 60 λεπτά εργασίας.
Και εδώ φτάνουμε σε ένα σημαντικό σημείο. Αν η ωριαία αμοιβή της ομάδας είναι, για παράδειγμα, 200 ευρώ καθαρά, μια φαινομενικά μικρή αλλαγή κοστίζει περίπου: 200 ευρώ καθαρά.
Αλλά αυτό δεν είναι όλο. Γιατί στην πραγματικότητα μπορεί να εμφανιστούν:
- παραλαβή του αιτήματος από άλλο πρόσωπο,
- διευκρινίσεις του scope,
- ερωτήσεις προς τον πελάτη,
- αναμονή για απάντηση,
- έλεγχος του αποτελέσματος από τον αιτούντα,
- διόρθωση μετά από feedback,
- επανεμφάνιση στο deployment.
Μια ώρα μπορεί πολύ εύκολα να γίνει δύο. Και μια μικρή αλλαγή να μετατραπεί σε πολλές ώρες εργασίας ολόκληρης της ομάδας.
Το πιο ακριβό δεν είναι η υλοποίηση της αλλαγής
Αυτό μπορεί να φαίνεται παράδοξο. Μερικές φορές η ίδια η εκτέλεση μιας εργασίας κρατάει 10 λεπτά. Αλλά η προετοιμασία για αυτήν κρατάει άλλα 20. Μετά έρχονται οι δοκιμές, το deployment, η επικοινωνία και η εναλλαγή συμφραζομένων.
Και αυτό το τελευταίο στοιχείο συχνά υποτιμάται.
Context switching - το κρυφό κόστος των μικρών εργασιών
Ο προγραμματιστής εργάζεται σε μια μεγάλη λειτουργία. Έχει ανοιχτό τον κώδικα. Αναλύει το πρόβλημα. Είναι συγκεντρωμένος.
Ξαφνικά έρχεται ένα μήνυμα: „Ε, μόνο μια μικρή δουλειά. Μπορείς να διορθώσεις το κουμπί;”
Ο προγραμματιστής σταματάει τη δουλειά. Ανοίγει το αίτημα. Ελέγχει τη σελίδα. Ψάχνει το σημείο στον κώδικα. Εισάγει την αλλαγή. Δοκιμάζει. Κάνει deploy. Επιστρέφει στην προηγούμενη εργασία...
Και τότε πρέπει να θυμηθεί: „Τι κάνω ακριβώς;”
Αυτό είναι το context switching, δηλαδή η εναλλαγή συμφραζομένων. Και μπορεί να είναι πολύ δαπανηρό. Όχι επειδή κάθε μεμονωμένη αλλαγή απαιτεί μεγάλη ποσότητα εργασίας, αλλά επειδή κάθε αλλαγή διακόπτει τη διαδικασία σκέψης.
Όσο πιο σύνθετη είναι η εργασία, τόσο μεγαλύτερο είναι το κόστος της επανεισόδου. Γι' αυτό 10 μικρο-εργασίες δεν σημαίνουν πάντα 10 × 10 λεπτά. Στην πράξη μπορεί να σημαίνουν πολύ περισσότερο.
Ένα κουμπί είναι τίποτα. Εκατό κουμπιά είναι μια διαδικασία.
Ας υποθέσουμε ότι η εταιρεία στέλνει στην τεχνική ομάδα:
- 20 μικρές αλλαγές μηνιαίως,
- η κάθε μία διαρκεί κατά μέσο όρο 45 λεπτά.
Αυτό αποδίδει: 15 ώρες εργασίας μηνιαίως.
Με τιμή 200 ευρώ την ώρα: 3000 ευρώ καθαρά μηνιαίως.
Ετησίως: 36.000 ευρώ καθαρά.
Και μιλάμε μόνο για 20 μικρές εργασίες το μήνα. Χωρίς μεγάλες λειτουργικότητες. Χωρίς ανάπτυξη προϊόντος. Χωρίς νέες ενότητες. Χωρίς ενσωματώσεις. Χωρίς σχεδίαση.
Απλώς: „αλλάξτε”, „διορθώστε”, „μετακινήστε”, „προσθέστε”, „διαγράψτε”.
Κι αν φανταστούμε έναν οργανισμό όπου τέτοιων εργασιών υπάρχουν 50 μηνιαίως ή 100, η κλίμακα φαίνεται εντελώς διαφορετική...
Τα μικρο-καθήκοντα έχουν ακόμα ένα κόστος - μπλοκάρουν την ανάπτυξη
Αυτό είναι ένα από τα πιο σημαντικά στοιχεία του παζλ.
Αν η ομάδα ανάπτυξης ξοδεύει 20% του χρόνου της σε μικρές διορθώσεις, δεν μπορεί να αφιερώσει αυτό το 20% στην ανάπτυξη του προϊόντος. Ακούγεται προφανές. Αλλά στην πράξη συχνά δεν φαίνεται.
Η εταιρεία λέει: „Γιατί μια νέα λειτουργία δεν είναι ακόμα έτοιμη;”
Ο προγραμματιστής απαντά: „Επειδή είχαμε πολλά τρέχοντα θέματα.”
„Ποια;”
„Διορθώσεις, μικρές αλλαγές, ενημερώσεις, μικρά tasks.”
Καθένα ήταν μικρό. Αλλά μαζί δημιούργησαν ένα τεράστιο μπλοκ εργασίας. Είναι σαν τις ειδοποιήσεις στο κινητό. Μια ειδοποίηση δεν ενοχλεί. Δέκα κάπως. Εκατό;... Ξαφνικά περνάμε όλη τη μέρα αντιδρώντας.
Με τα μικρο-καθήκοντα συμβαίνει το ίδιο.
„Μικρό task” δεν είναι πάντα μικρό task
Αξίζει επίσης να καταλάβουμε ότι δεν είναι όλες οι αλλαγές ίδιες. Η αλλαγή κειμένου στο CMS μπορεί πραγματικά να πάρει λίγα λεπτά.
Αλλά η αλλαγή κειμένου σε μια εφαρμογή μπορεί να απαιτήσει:
- τον εντοπισμό του component,
- την αλλαγή κώδικα,
- ενημέρωση μεταφράσεων,
- δοκιμές,
- την επανασύνθεση/build της εφαρμογής,
- το deployment.
Η αλλαγή ενός πεδίου μπορεί να απαιτήσει τροποποιήσεις:
- στο front-end,
- στο back-end,
- στη βάση δεδομένων,
- στο API.
Η αλλαγή ενός στοιχείου στο σύστημα μπορεί να επηρεάσει άλλα στοιχεία.
Γι' αυτό το ερώτημα: „Πόσο θα πάρει να αλλάξουμε αυτό το κουμπί;”
χωρίς γνώση της αρχιτεκτονικής του συστήματος συχνά δεν έχει ουσιαστική απάντηση.
Πρέπει πρώτα να ελεγχθεί. Μετά να εκτιμηθεί.
Γιατί ο προγραμματιστής λέει μερικές φορές: „Πρέπει να το ελέγξω”;
Δεν είναι αποφυγή απάντησης. Συχνά είναι ένδειξη επαγγελματισμού.
Ένας καλός προγραμματιστής δεν πρέπει να υπόσχεται: „Ναι, σίγουρα, πέντε λεπτά.”
αν δεν ξέρει τι υπάρχει κάτω από την επιφάνεια.
Πρέπει να πει: „Θα ελέγξω πού χρησιμοποιείται αυτό το στοιχείο και θα σας πω.”
Αυτό μπορεί να πάρει 10 λεπτά. Αλλά αυτά τα 10 λεπτά μπορεί να εξοικονομήσουν πολλές ώρες προβλημάτων. Γιατί η πιο ακριβή αλλαγή είναι συχνά όχι αυτή που παίρνει μια ώρα.
Η πιο ακριβή είναι αυτή που:
- χαλάει άλλη λειτουργία,
- προκαλεί σφάλμα στην παραγωγή,
- απαιτεί επείγουσα rollback,
- γεννάει επόμενα αιτήματα,
- απαιτεί παρέμβαση πολλών ατόμων.
Γι' αυτό η ανάλυση πριν την αλλαγή είναι μέρος της δουλειάς και όχι σπατάλη χρόνου.
Πώς ο πελάτης μπορεί να μειώσει το κόστος των μικρο-καθηκόντων;
Δεν πρόκειται να σταματήσει να στέλνει μικρές αλλαγές. Οι μικρές αλλαγές είναι φυσιολογικό μέρος της εξέλιξης ενός προϊόντος. Πρόκειται όμως για το να τις διαχειρίζεται σωστά.
1. Ομαδοποιήστε τα μικρά tasks
Αντί να στέλνετε:
„Αλλάξτε το κουμπί.”
„Επίσης διορθώστε τον τίτλο.”
„Και προσθέστε αυτόν τον σύνδεσμο.”
„Και μετακινήστε αυτό το στοιχείο.”
Καλύτερα συλλέξτε τα σε ένα πακέτο.
Η ομάδα μπορεί τότε να κάνει πολλές αλλαγές σε έναν κύκλο εργασίας.
Λιγότερο context switching.
Λιγότερη επικοινωνία.
Λιγότερα deployments.
Χαμηλότερο κόστος.
2. Θέστε προτεραιότητες
Δεν είναι όλα επείγοντα.
Αν κάθε αίτημα έχει κατάσταση:
URGENT
τότε κανένα δεν είναι πραγματικά επείγον.
Αξίζει να χωρίσετε τα tasks σε:
- κρίσιμα,
- σημαντικά,
- προγραμματισμένα,
- κοσμητικά.
Έτσι η ομάδα μπορεί να δουλέψει πιο αποτελεσματικά.
3. Αναρωτηθείτε αν χρειάζεται αλλαγή στον κώδικα
Αν η εταιρεία τακτικά αλλάζει:
- κείμενα,
- φωτογραφίες,
- μπάνερς,
- συνδέσμους,
- μηνύματα,
τότε ίσως το πρόβλημα δεν είναι η ταχύτητα του προγραμματιστή.
Ίσως το πρόβλημα είναι η αρχιτεκτονική.
Αν κάθε αλλαγή περιεχομένου απαιτεί προγραμματιστή, αξίζει να σκεφτείτε CMS ή admin panel.
Ένα καλά σχεδιασμένο σύστημα πρέπει να επιτρέπει σε επιχειρηματικά πρόσωπα να διαχειρίζονται τα πράγματα που πραγματικά δεν χρειάζονται τον προγραμματιστή.
Ένα καλό σύστημα πρέπει να απαντά: ποιος πρέπει να κάνει αυτή την αλλαγή;
Αυτή είναι μια πολύ σημαντική αρχή σχεδιασμού. Όχι κάθε αλλαγή πρέπει να πηγαίνει στον προγραμματιστή.
Αν το μάρκετινγκ μπορεί μόνο του:
- να αλλάζει κείμενα,
- να αντικαθιστά εικόνες,
- να προσθέτει άρθρα,
- να αλλάζει τη σειρά των τμημάτων,
τότε δεν έχει νόημα να εμπλέκετε προγραμματιστή.
Ο προγραμματιστής πρέπει να ασχολείται με ό,τι απαιτεί την ειδικότητά του.
Δηλαδή μεταξύ άλλων:
- δημιουργία νέων λειτουργιών,
- ανάπτυξη του συστήματος,
- ενσωματώσεις,
- βελτιστοποίηση,
- ασφάλεια,
- αρχιτεκτονική,
- επίλυση τεχνικών προβλημάτων.
Αλλιώς η εταιρεία αρχίζει να πληρώνει τον προγραμματιστή για δουλειά που θα μπορούσε να κάνει ο χρήστης του συστήματος.
Είναι σαν να προσλάβετε μηχανικό αυτοκινήτου για να γεμίσει το ρεζερβουάρ. Μπορεί να το κάνει. Αλλά πραγματικά το χρειαζόμαστε;
Πότε αξίζει να πούμε: „Ας το κάνουμε αλλιώς”;
Αν το ίδιο αίτημα εμφανίζεται τακτικά, αξίζει να σταματήσετε και να ρωτήσετε:
Γιατί πρέπει κάθε φορά να το κάνουμε χειροκίνητα;
Αν κάθε εβδομάδα ζητάμε αλλαγή του ίδιου στοιχείου, ίσως πρέπει να δημιουργήσουμε:
- ρύθμιση στο CMS,
- διαμόρφωση,
- admin panel,
- αυτοματοποίηση,
- μηχανισμό self-service.
Ένα εφάπαξ κόστος για τη δημιουργία μιας τέτοιας λύσης μπορεί να είναι μεγαλύτερο. Αλλά μετά κάθε επόμενη αλλαγή μπορεί να κοστίζει λίγα δευτερόλεπτα αντί για ώρες.
Αυτή είναι η διαφορά μεταξύ του να πληρώνεις για κάθε αλλαγή και του να επενδύεις σε ένα σύστημα που επιτρέπει τις αλλαγές αυτοπροσώπως.
Μικρο-καθήκοντα και το μοντέλο συνεργασίας με το software house
Αυτό είναι επίσης σημαντικό θέμα για τους πελάτες.
Αν η συνεργασία με το software house βασίζεται αποκλειστικά στο μοντέλο: „στέλνουμε - κοστολογείτε - εγκρίνουμε - υλοποιείτε”, κάθε μικρή αλλαγή μπορεί να δημιουργεί πρόσθετο οργανωτικό overhead.
Γι' αυτό σε διαρκή συνεργασία συχνά δουλεύουν καλύτερα:
- πακέτα ωρών,
- συνδρομή συντήρησης,
- σταθερή ομάδα,
- backlog εργασιών,
- τακτικά sprints,
- προκαθορισμένα παράθυρα για deployments.
Δεν σημαίνει ότι κάθε πελάτης πρέπει να επιλέξει το ίδιο μοντέλο. Πρόκειται για το να ταιριάξετε τον τρόπο συνεργασίας με το είδος του έργου.
Αν μια εταιρεία χρειάζεται μία αλλαγή το μήνα, μια εκτεταμένη διαδικασία μπορεί να είναι περιττή. Αν στέλνει 50 εργασίες το μήνα, η έλλειψη διαδικασίας μπορεί να κοστίσει πολύ.
Αξίζει να μετράμε κάθε αλλαγή;
Εξαρτάται.
Σε κάποια έργα η ακριβής χρέωση κάθε λεπτού βγάζει νόημα. Σε άλλα μπορεί να δημιουργήσει περισσότερη διοίκηση παρά εξοικονόμηση.
Γι' αυτό αξίζει να κοιτάμε τη συνεργασία ευρύτερα.
Το πιο σημαντικό ερώτημα δεν είναι: „Πόσο κόστισε αυτή η αλλαγή;”
Μάλλον: „Πόσο μας κοστίζει ο τρόπος που διαχειριζόμαστε όλες τις αλλαγές;”
Αν μια εταιρεία πληρώνει 200 ευρώ για μια αλλαγή αλλά έτσι αποφεύγει σφάλματα και έχει την ασφάλεια ότι όλα λειτουργούν σωστά, μπορεί να είναι λογικό κόστος.
Αν όμως κάθε μήνα πληρώνει μερικές χιλιάδες ευρώ για δεκάδες παρόμοια μικρο-καθήκοντα, αξίζει να σκεφτεί αν το πρόβλημα μπορεί να λυθεί συστημικά.
Οι πιο ακριβές λέξεις στην πληροφορική;
Ίσως να είναι: „Είναι μόνο μια μικρή αλλαγή.”
Όχι επειδή οι μικρές αλλαγές είναι κακές. Είναι απαραίτητες.
Ένα ψηφιακό προϊόν ζει. Οι ανάγκες των πελατών αλλάζουν. Η αγορά αλλάζει. Το μάρκετινγκ αλλάζει. Η τεχνολογία αλλάζει. Οι αλλαγές είναι φυσιολογικές.
Το πρόβλημα ξεκινά όταν ο οργανισμός δεν βλέπει το σωρευτικό κόστος.
Μια μικρή αλλαγή; - Τίποτα μεγάλο.
Δέκα; - Ακόμα λίγα.
Εκατό; - Είναι ήδη μια διαδικασία.
Και αν τέτοιες διαδικασίες υπάρχουν δεκάδες; Ξαφνικά αποδεικνύεται ότι η εταιρεία δεν ξοδεύει χρήματα για την ανάπτυξη του προϊόντος. Τα ξοδεύει για τη συνεχή διόρθωση λεπτομερειών.
Αντί να μετράμε κουμπιά, ας μετρήσουμε χρόνο
Η καλά διαχειρισμένη ανάπτυξη ενός ψηφιακού προϊόντος δεν σημαίνει να απαγορεύεις στον πελάτη να στέλνει μικρές αλλαγές.
Σημαίνει να γνωρίζεις:
- ποιες αλλαγές πραγματικά χρειάζονται προγραμματιστή,
- ποιες μπορούν να γίνουν εσωτερικά,
- ποιες αξίζει να αυτοματοποιηθούν,
- ποιες να ομαδοποιούνται,
- ποιες είναι πραγματικά επείγουσες,
- ποιες μπορεί να προγραμματιστούν,
- ποιες αξίζει να λυθούν συστημικά.
Γιατί μερικές φορές η καλύτερη απάντηση στο: „Διορθώστε το γρήγορα.”
δεν είναι: „Εντάξει, θα το κάνουμε.”
αλλά: „Ας σκεφτούμε γιατί σε ένα μήνα θα πρέπει πάλι να το διορθώσουμε.”
Εδώ το software house παύει να είναι απλώς εκτελεστής εργασιών. Και γίνεται τεχνολογικός εταίρος. Διότι ένας καλός εταίρος όχι μόνο υλοποιεί τα επόμενα αιτήματα.
Βοηθά επίσης να δει ότι μερικές φορές η φθηνότερη αλλαγή δεν είναι αυτή που θα κάνουμε πιο γρήγορα. Η φθηνότερη είναι αυτή που δεν θα χρειαστεί να κάνουμε για εκατοστή φορά.
Και γι' αυτό ένα κουμπί „Διορθώστε το γρήγορα” μπορεί να κοστίζει μια ώρα.
Αλλά ένα καλά σχεδιασμένο σύστημα μπορεί να κάνει τις επόμενες εκατό τέτοιες αλλαγές να τις κάνετε μόνοι σας σε λίγα λεπτά.
Δεν είναι εξοικονόμηση στους προγραμματιστές. Είναι επένδυση σε μια καλύτερη διαδικασία, καλύτερη αρχιτεκτονική και εξυπνότερη χρήση του χρόνου ολόκληρης της ομάδας.
