use cases

Use cases: πώς επιλέγουμε τις σωστές περιπτώσεις χρήσης

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

Από την ιδέα στο παρατηρήσιμο αποτέλεσμα

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

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

Πώς γράφεται ένα καλό σενάριο

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

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

Παραδείγματα για διαφορετικά τμήματα

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

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

Πότε δεν χρειάζεται σύνθετο μοντέλο

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

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

Κριτήρια προτεραιοποίησης

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

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

Πίνακας επιλογής για τη διοίκηση

• Υψηλή επανάληψη και επαρκή δεδομένα: καλή υποψήφια περίπτωση για δοκιμή.
• Μεγάλος αντίκτυπος αλλά μη αναστρέψιμη ενέργεια: απαιτείται ανθρώπινη έγκριση.
• Ελλιπής ή αντιφατική γνώση: προηγείται καθαρισμός και υπευθυνότητα πηγών.
• Σπάνια εργασία χωρίς σαφές κέρδος: χαμηλότερη προτεραιότητα.
• Αυστηροί κανόνες και προκαθορισμένες τιμές: εξετάστε απλή αυτοματοποίηση πριν από μοντέλο.
• Αμφίσημα φυσικά αιτήματα: δοκιμάστε ανάκτηση και ελεγχόμενη γλωσσική υποστήριξη.

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

Η σχέση με την εκτέλεση ενεργειών

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

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

Τι δοκιμάζεται πριν από την έγκριση

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

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

Μετρήσεις που συνδέονται με αποτέλεσμα

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

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

Πώς ξεχωρίζει η χρηστική ανάγκη από την εσωτερική επιθυμία

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

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

Από πού να ξεκινήσετε

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