Το πιο αργό στοιχείο της εφαρμογής σου μπορεί να είναι... ο άνθρωπος.
Όταν μια εταιρεία λέει ότι η εφαρμογή της είναι αργή, η πρώτη αντίδραση είναι συνήθως πολύ τεχνική. Πρέπει να ελεγχθεί ο διακομιστής. Η βάση δεδομένων. Το API. Τα ερωτήματα SQL. Η cache. Η υποδομή. Το μέγεθος των αρχείων. Η JavaScript. Ο χρόνος απόκρισης των επιμέρους υπηρεσιών.
Και σωστά. Η technical performance έχει τεράστια σημασία.
Μόνο που μερικές φορές όλα τα γραφήματα φαίνονται καλά, ο διακομιστής αποκρίνεται γρήγορα, η εφαρμογή φορτώνει σε λογικό χρόνο, και οι χρήστες συνεχίζουν να λένε: "Αυτό αργεί πολύ."
Και τότε προκύπτει ένα πιο ενδιαφέρον ερώτημα. Ίσως η εφαρμογή να μην είναι καθόλου αργή. Ίσως απλώς αναγκάζει τον άνθρωπο να περιμένει.
2 δευτερόλεπτα απόκρισης, 20 λεπτά δουλειάς
Ας φανταστούμε έναν εργαζόμενο που πρέπει να ετοιμάσει μια προσφορά για έναν πελάτη.
Το σύστημα λειτουργεί άψογα. Κάθε οθόνη ανοίγει γρήγορα. Δεν υπάρχουν σφάλματα. Ο διακομιστής αποκρίνεται σχεδόν ακαριαία.
Μόνο που για να ετοιμάσει την προσφορά, ο εργαζόμενος πρέπει να: ανοίξει τον πελάτη, να πάει στην παραγγελία, να αντιγράψει τον αριθμό του προϊόντος, να ανοίξει μια δεύτερη ενότητα, να αναζητήσει το προϊόν, να ξαναγράψει τα δεδομένα, να επιστρέψει στην πρώτη οθόνη, να επιλέξει κατηγορία, να πάει στην επόμενη καρτέλα, να κατεβάσει τις τιμές, να ελέγξει χειροκίνητα την έκπτωση, να αντιγράψει το αποτέλεσμα στο Excel και στη συνέχεια να το ξαναπληκτρολογήσει στο σύστημα.
Κάθε μεμονωμένη ενέργεια μπορεί να διαρκεί λίγα δευτερόλεπτα.
Τεχνικά όλα λειτουργούν άριστα. Μόνο που όλη η διαδικασία παίρνει 20 λεπτά.
Και ακριβώς εδώ η κλασική αντίληψη της απόδοσης παύει να αρκεί.
Γιατί τον χρήστη δεν τον ενδιαφέρει πρωτίστως ο χρόνος απόκρισης του API. Τον ενδιαφέρει ο χρόνος που χρειάζεται για να ολοκληρώσει μια εργασία.
Η technical performance είναι μόνο η αρχή
Η απόδοση ενός συστήματος μπορεί να μετρηθεί με πολλούς τρόπους.
Μπορούμε να αναλύσουμε τον χρόνο απόκρισης του διακομιστή, τον χρόνο φόρτωσης της προβολής, τα ερωτήματα στη βάση, τη χρήση μνήμης, το φορτίο του επεξεργαστή ή τις καθυστερήσεις μεταξύ υπηρεσιών.
Αυτές είναι πολύ σημαντικές μετρήσεις. Αλλά υπάρχει και ένα δεύτερο επίπεδο.
Perceived performance, δηλαδή η απόδοση όπως την αντιλαμβάνεται ο χρήστης.
Και ακόμη ευρύτερα μπορούμε να δούμε την operational performance - δηλαδή πόσο γρήγορα και αποτελεσματικά μπορεί ένας άνθρωπος να ολοκληρώσει μια πραγματική εργασία χρησιμοποιώντας το σύστημα.
Και ακριβώς σε αυτό το τελευταίο επίπεδο οι εταιρείες πολύ συχνά χάνουν τον περισσότερο χρόνο. Γιατί μπορείς να φτιάξεις μια εξαιρετικά γρήγορη εφαρμογή, που όμως εξακολουθεί να είναι ένα αργό εργαλείο εργασίας.
Το πιο αργό σύστημα είναι μερικές φορές επτά οθόνες
Ας υποθέσουμε ότι ένας εργαζόμενος διαχειρίζεται μια καταγγελία.
Το σύστημα απαιτεί επτά βήματα.
Πρώτα το άνοιγμα του πελάτη.
Μετά της παραγγελίας.
Έπειτα του προϊόντος.
Ακολούθως της φόρμας καταγγελίας.
Μετά της κατηγορίας του προβλήματος.
Έπειτα της απόφασης.
Στο τέλος της επιβεβαίωσης.
Κάθε οθόνη φορτώνει σε 0,5 δευτερόλεπτα.
Από την οπτική του developer όλα μπορεί να φαίνονται πολύ καλά. Αλλά ο χρήστης έκανε επτά μεταβάσεις, άλλαξε επτά φορές πλαίσιο και επτά φορές έπρεπε να σκεφτεί τι να κάνει στη συνέχεια.
Αν τέτοιες ενέργειες γίνονται δεκάδες φορές την ημέρα, το πρόβλημα παύει να είναι θέμα ευκολίας. Γίνεται κόστος. Και δεν αφορά μόνο τον χρόνο μπροστά στην οθόνη. Προστίθενται η κόπωση, τα λάθη, η ανάγκη διόρθωσης δεδομένων, οι διακοπές στις εργασίες και η αυξανόμενη επιβάρυνση του εργαζομένου.
Μια φόρμα με 40 πεδία δεν είναι γρήγορη μόνο και μόνο επειδή ανοίγει γρήγορα
Αυτό είναι ένα από τα κλασικά παραδείγματα.
Η φόρμα ανοίγει αστραπιαία. - Υπέροχα.
Μόνο που ο χρήστης πρέπει να συμπληρώσει 40 πεδία.
Ένα μέρος των πληροφοριών η εταιρεία το έχει ήδη.
Ένα μέρος μπορεί να ανακτηθεί από το CRM.
Ένα μέρος μπορεί να υπολογιστεί.
Ένα μέρος εξαρτάται από προηγούμενες απαντήσεις.
Κι όμως το σύστημα ρωτά τον άνθρωπο για όλα ξανά από την αρχή.
Τότε το πρόβλημα δεν είναι το performance της εφαρμογής.
Το πρόβλημα είναι ο σχεδιασμός της διαδικασίας και του interface.
Ένα καλό σύστημα πρέπει να αξιοποιεί τα δεδομένα που ήδη διαθέτει.
Αν ο πελάτης έδωσε τη διεύθυνση παράδοσης σε προηγούμενη παραγγελία, γιατί ο εργαζόμενος να την καταχωρίσει ξανά; Αν το σύστημα γνωρίζει την εταιρεία του πελάτη, γιατί ο χρήστης να ξαναεπιλέξει τα στοιχεία της; Αν η απάντηση στο πρώτο ερώτημα αποκλείει τα μισά από τα επόμενα πεδία, γιατί όλα είναι ορατά από την αρχή;
Μερικές φορές ο καλύτερος τρόπος να επιταχύνεις την εφαρμογή δεν είναι η βελτιστοποίηση του κώδικα. Είναι η αφαίρεση της εργασίας που ο χρήστης δεν θα έπρεπε να κάνει.
Ο πιο ακριβός είναι ο χρόνος του ανθρώπου πολλαπλασιασμένος με την κλίμακα
Ένα επιπλέον λεπτό μπορεί να φαίνεται ασήμαντο.
Ο εργαζόμενος εκτελεί την ενέργεια 5 φορές την ημέρα. - 5 λεπτά.
Σε μηνιαία κλίμακα αυτό γίνεται πάνω από 1,5 ώρα.
Αλλά τι γίνεται αν το κάνουν 20 άτομα; Τι γίνεται αν η ενέργεια συμβαίνει 30 φορές την ημέρα; Τι γίνεται αν αφορά ολόκληρο το τμήμα; Τι γίνεται αν το σύστημα θα χρησιμοποιείται για τα επόμενα πέντε χρόνια;
Τότε το μεμονωμένο λεπτό παύει να είναι λεπτό. Γίνεται λειτουργικό κόστος.
Γι' αυτό, όταν σχεδιάζουμε ένα σύστημα για μια εταιρεία, αξίζει να ρωτάμε όχι μόνο: "Πόσο χρόνο χρειάζεται η απόκριση του διακομιστή;"
αλλά επίσης: "Πόσο χρόνο χρειάζεται ο άνθρωπος για να ολοκληρώσει την εργασία;"
Αυτές είναι δύο εντελώς διαφορετικές ερωτήσεις.
Το σύστημα μπορεί να είναι γρήγορο, αλλά η διαδικασία αργή
Αυτό είναι ένα ακόμη ευρύτερο πρόβλημα.
Ας φανταστούμε μια διαδικασία αγορών σε μια εταιρεία.
- Ο εργαζόμενος υποβάλλει αίτημα.
- Το σύστημα το αποθηκεύει αμέσως.
- Αλλά μετά πρέπει να περιμένει την έγκριση του προϊσταμένου.
- Ο προϊστάμενος λαμβάνει μήνυμα.
- Ανοίγει το σύστημα.
- Ελέγχει το έγγραφο.
- Το προωθεί στα οικονομικά.
- Τα οικονομικά ελέγχουν τον προϋπολογισμό.
- Στη συνέχεια κάποιος πρέπει να εγκρίνει την παραγγελία.
Τεχνικά η εφαρμογή μπορεί να λειτουργεί άψογα. Και η διαδικασία διαρκεί τρεις ημέρες.
Μπορούμε να πούμε ότι η εφαρμογή είναι γρήγορη;
Τεχνικά - ίσως.
Για την επιχείρηση - ο εργαζόμενος περιμένει τρεις ημέρες.
Και ακριβώς γι' αυτό ο σχεδιασμός επιχειρησιακών συστημάτων απαιτεί να βλέπουμε πέρα από το ίδιο το interface. Πρέπει να δούμε ολόκληρη τη ροή εργασίας.
"Παρακαλώ περιμένετε" είναι κι αυτό στοιχείο του UX
Υπάρχει και μία ακόμη ενδιαφέρουσα περίπτωση.
Μερικές φορές το σύστημα όντως εκτελεί μια μεγάλη διαδικασία.
Δημιουργεί αναφορά.
Επεξεργάζεται μεγάλο αρχείο.
Συγχρονίζει δεδομένα.
Στέλνει πολλά records σε εξωτερικό API.
Εκτελεί σύνθετη διαδικασία.
Δεν γίνεται πάντα να το κάνεις να διαρκεί ένα δευτερόλεπτο. Αλλά μπορείς να κάνεις τον χρήστη να ξέρει τι συμβαίνει.
Αυτό είναι τεράστια διαφορά.
Το μήνυμα: "Φόρτωση..."
είναι κάτι εντελώς διαφορετικό από: "Ετοιμάζουμε την αναφορά. Έχει επεξεργαστεί το 72% των δεδομένων. Μπορείς να κλείσεις το παράθυρο - η αναφορά θα είναι έτοιμη στο παρασκήνιο."
Στη δεύτερη περίπτωση ο χρήστης λαμβάνει ενημέρωση, έλεγχο και προβλεψιμότητα.
Αυτό ακριβώς είναι ένα από τα στοιχεία του perceived performance.
Το σύστημα μπορεί να εκτελεί την ίδια λειτουργία για 20 δευτερόλεπτα. Αλλά η εμπειρία του χρήστη είναι εντελώς διαφορετική.
Το χειρότερο είναι η αναμονή χωρίς ενημέρωση
Ο άνθρωπος αντιλαμβάνεται πολύ χειρότερα την αναμονή, όταν δεν ξέρει αν το σύστημα κάνει κάτι καθόλου.
Κάνουμε κλικ. - Τίποτα.
Κάνουμε ξανά κλικ. - Πάλι τίποτα.
Λειτουργεί το σύστημα;
Κόλλησε;
Πρέπει να κάνουμε ανανέωση;
Υποβλήθηκε η φόρμα;
Μπορούμε να κλείσουμε το παράθυρο;
Είναι η στιγμή που ο χρήστης αρχίζει να παλεύει με την εφαρμογή.
Και όταν ο χρήστης αρχίζει να παλεύει με το σύστημα, εμφανίζονται νέα προβλήματα.
Ανανέωση σελίδας.
Εκ νέου αποστολή φόρμας.
Διπλότυπα.
Τηλεφωνήματα στο support.
Σφάλματα.
Περιττές αναφορές.
Και χρόνος εργασίας άλλων ανθρώπων...
Γι' αυτό η ενημέρωση του χρήστη για την κατάσταση της λειτουργίας δεν είναι ένα καλλωπιστικό πρόσθετο. Είναι μέρος του σχεδιασμού ενός αποδοτικού συστήματος.
Και μερικές φορές η εφαρμογή περιμένει για τον άνθρωπο
Αυτό είναι ίσως η πιο ενδιαφέρουσα περίπτωση.
Το σύστημα απαιτεί από τον άνθρωπο να εκτελέσει μια ενέργεια που η τεχνολογία θα μπορούσε να κάνει αυτόματα.
Ο υπάλληλος αντλεί δεδομένα από ένα σύστημα.
Τα μεταφέρει σε ένα άλλο.
Ελέγχει μια συνθήκη.
Αντιγράφει το αποτέλεσμα.
Στέλνει μήνυμα.
Αλλάζει την κατάσταση.
Περιμένει.
Επιβεβαιώνει.
Μεταφέρει τα δεδομένα παρακάτω.
Και το κάνει δεκάδες φορές την ημέρα.
Δεν υπάρχει βλάβη.
Δεν υπάρχει σφάλμα.
Το σύστημα λειτουργεί σύμφωνα με τις παραδοχές.
Μόνο που οι παραδοχές ήταν λάθος.
Ο αυτοματισμός δεν σημαίνει απαραίτητα τεχνητή νοημοσύνη.
Μερικές φορές ο μεγαλύτερος αυτοματισμός είναι απλώς να κάνεις τα συστήματα να σταματήσουν να απαιτούν από τον άνθρωπο τη χειροκίνητη μεταφορά πληροφοριών μεταξύ τους.
Η αρχιτεκτονική έχει άμεση επίδραση στο πόσο περιμένει ο χρήστης
Σε αυτό το στάδιο φτάνουμε στα τεχνικά ζητήματα.
Εάν η εφαρμογή αποτελείται από πολλές υπηρεσίες, κάθε κλήση μπορεί να εισάγει καθυστέρηση. Εάν το σύστημα κάθε φορά ανακτά τα ίδια δεδομένα από ένα εξωτερικό API, μπορεί να εξεταστεί το cache. Εάν η αναφορά κάθε φορά επανυπολογίζει εκατομμύρια εγγραφές από την αρχή, ίσως χρειάζεται άλλη στρατηγική παραγωγής δεδομένων. Εάν ο χρήστης πρέπει να περιμένει για μια λειτουργία που δεν χρειάζεται να εκτελεστεί άμεσα, μπορεί να εξεταστεί η ασύγχρονη επεξεργασία. Εάν πολλές διαδικασίες εκτελούν την ίδια εργασία, ίσως το πρόβλημα βρίσκεται στην αρχιτεκτονική.
Ακριβώς εδώ το UX, το performance και η software architecture αρχίζουν να συνδέονται μεταξύ τους.
Ο σχεδιαστής βλέπει το πρόβλημα του χρήστη.
Ο αναλυτής βλέπει τη διαδικασία.
Ο προγραμματιστής βλέπει τον κώδικα.
Ο αρχιτέκτονας βλέπει τις εξαρτήσεις.
Ένα καλό σύστημα πρέπει να συνδυάζει και τις τέσσερις οπτικές.
Δεν χρειάζεται να επιταχύνεται κάθε λειτουργία
Αυτό είναι επίσης σημαντικό.
Μερικές φορές μια εταιρεία επενδύει πολλά χρήματα στη βελτιστοποίηση μιας λειτουργίας που συμβαίνει μία φορά την ημέρα.
Την ίδια στιγμή μια άλλη ενέργεια, που εκτελείται από 50 άτομα δεκάδες φορές την ημέρα, παραμένει πρακτικά ανέγγιχτη.
Γι' αυτό πριν από τη βελτιστοποίηση αξίζει να ξέρουμε: τι ακριβώς βελτιστοποιούμε και για ποιον;
Δεν πρόκειται να ανοίγει κάθε οθόνη σε 100 χιλιοστά του δευτερολέπτου.
Πρόκειται για το να είναι το σύστημα γρήγορο εκεί όπου η ταχύτητα έχει επιχειρηματική σημασία.
Εάν μια οικονομική αναφορά μπορεί να παράγεται για 15 δευτερόλεπτα μία φορά την ημέρα, ίσως αυτό να μην είναι πρόβλημα. Εάν η αναζήτηση πελατών απαντά σε 4 δευτερόλεπτα σε κάθε ενέργεια ενός πωλητή, η κατάσταση είναι εντελώς διαφορετική.
Το performance πρέπει να αξιολογείται στο πλαίσιο της συχνότητας, της κρισιμότητας και του κόστους της συγκεκριμένης ενέργειας.
Πώς να βρούμε το πραγματικό στενό σημείο;
Αντί να ρωτάτε μόνο τους προγραμματιστές: "Γιατί η εφαρμογή είναι αργή;"
αξίζει να ξεκινήσετε από τους χρήστες: "Δείξε μου πώς εκτελείς τη δουλειά σου."
Όχι: "Τι σε ενοχλεί;"
Μόνο:
"Δείξε μου πώς ετοιμάζεις μια προσφορά."
"Δείξε μου πώς χειρίζεσαι μια καταγγελία."
"Δείξε μου πώς καταχωρείς έναν νέο πελάτη."
"Δείξε μου πώς κλείνεις μια παραγγελία."
Και τότε συχνά αποκαλύπτονται πράγματα που δεν φαίνονται στον κώδικα.
Excel.
Σημειωματάριο.
Δεύτερη οθόνη.
Αντιγραφή δεδομένων.
Χειροκίνητος έλεγχος.
Τηλεφωνήματα.
Άνοιγμα πέντε καρτελών.
Ανανέωση σελίδας.
Αναμονή για email.
Ερώτηση σε συνάδελφο.
Ακριβώς εκεί βρίσκεται συχνά το πραγματικό στενό σημείο.
Μια καλή εφαρμογή δεν απαντά μόνο γρήγορα
Μια καλή εφαρμογή επιτρέπει να εκτελείς τη δουλειά γρήγορα.
Αυτή είναι μια λεπτή, αλλά θεμελιώδης διαφορά.
Μπορεί να έχεις μια τεχνικά πολύ αποδοτική εφαρμογή, που απαιτεί από τον χρήστη δεκάδες κλικ. Μπορεί να έχεις ένα όμορφο interface που κρύβει μια πολύπλοκη διαδικασία. Μπορεί να έχεις εξαιρετική αρχιτεκτονική που δεν λύνει το πραγματικό επιχειρηματικό πρόβλημα. Και μπορεί να έχεις ένα σύστημα που τεχνικά δεν είναι πρωταθλητής απόδοσης, αλλά επιτρέπει στον υπάλληλο να κάνει σε πέντε λεπτά κάτι που πριν έπαιρνε μισή ώρα.
Ακριβώς γι' αυτό ένα software house δεν πρέπει να κοιτάζει την εφαρμογή μόνο μέσα από το πρίσμα του κώδικα.
Ο κώδικας είναι το μέσο. Στόχος είναι μια επιχείρηση που λειτουργεί αποτελεσματικά.
Πριν βελτιστοποιήσεις τον server, μέτρησε τον άνθρωπο
Αυτή η φράση αξίζει να τη θυμάσαι.
Αν οι χρήστες παραπονιούνται ότι η εφαρμογή είναι αργή, μην ξεκινήσεις αυτόματα από την αύξηση της ισχύος του server.
Πρώτα έλεγξε όλη τη διαδικασία.
Πόσο χρόνο απαιτεί η εργασία;
Πόσες οθόνες χρειάζεται να διασχίσεις;
Πόσα δεδομένα εισάγει ο χρήστης χειροκίνητα;
Πόσες φορές ξαναγράφει τις ίδιες πληροφορίες;
Σε πόσα συστήματα πρέπει να αλλάζει;
Πόσες φορές περιμένει;
Σε τι περιμένει;
Ξέρει ότι το σύστημα εξακολουθεί να λειτουργεί;
Μπορεί ένα μέρος της δουλειάς να γίνει αυτόματα;
Τα δεδομένα που ήδη διαθέτουμε, τα ζητάμε ξανά από τον άνθρωπο;
Μόνο τότε αξίζει να κατέβεις ένα επίπεδο και να ελέγξεις το API, τη βάση δεδομένων, την υποδομή, το cache, τις ουρές ή την αρχιτεκτονική της εφαρμογής.
Γιατί μερικές φορές το πρόβλημα πράγματι βρίσκεται στον κώδικα.
Αλλά μερικές φορές βρίσκεται ανάμεσα στην οθόνη και την καρέκλα.
Και τότε η καλύτερη βελτιστοποίηση δεν είναι ένας πιο γρήγορος server.
Είναι ένα καλύτερα σχεδιασμένο σύστημα.
Το πιο αργό στοιχείο της εφαρμογής σου μπορεί να είναι ο άνθρωπος.
Και ο ρόλος ενός καλού software house δεν είναι να κάνει τον άνθρωπο να κάνει κλικ πιο γρήγορα.
Ο ρόλος ενός καλού software house είναι να κάνει έτσι ώστε να χρειάζεται να κάνει λιγότερα κλικ.
