Η πρώτη περιγραφή ενός ψηφιακού προϊόντος συνήθως περιέχει πολλές δυνατότητες: λογαριασμούς, αναζήτηση, κρατήσεις, ειδοποιήσεις, αναφορές και έναν πίνακα διαχείρισης. Είναι φυσικό να βλέπει κανείς από νωρίς τι θα μπορούσε να γίνει. Για να ξεκινήσει όμως η ανάπτυξη, χρειάζεται ένα πιο συγκεκριμένο ερώτημα: ποιος άνθρωπος προσπαθεί να ολοκληρώσει ποια δουλειά και τι τον δυσκολεύει σήμερα; Η απάντηση βοηθά να επιλεγεί μια πρώτη έκδοση που έχει αυτοτελή αξία και ταυτόχρονα επιτρέπει στην ομάδα να μάθει πού αξίζει να επενδύσει στη συνέχεια.
Περιγράψτε το πρόβλημα μέσα σε πραγματικό σενάριο
Ας υποθέσουμε ότι μια μικρή ομάδα οργανώνει εργαστήρια και διαχειρίζεται συμμετοχές μέσα από email και διαφορετικά αρχεία. Μια γενική ιδέα θα ήταν «να φτιάξουμε πλατφόρμα εκδηλώσεων». Μια χρησιμότερη αρχή είναι: ο διοργανωτής θέλει να γνωρίζει ποιοι έχουν δηλώσει συμμετοχή σε κάθε εργαστήριο και ο ενδιαφερόμενος να ξέρει αν η θέση του επιβεβαιώθηκε. Περιγράφουμε πώς γίνεται σήμερα η διαδικασία, πού απαιτείται διπλή καταχώριση και πότε δημιουργείται σύγχυση. Τα παραδείγματα εδώ είναι υποθετικά· αποτελούν τρόπο οργάνωσης της σκέψης, όχι αποτελέσματα κάποιου συγκεκριμένου έργου.
Ορίστε μία ολοκληρωμένη πρώτη διαδρομή
Για αυτό το παράδειγμα, η πρώτη έκδοση μπορεί να επιτρέπει στον διοργανωτή να δημιουργεί ένα εργαστήριο και να βλέπει τις συμμετοχές, ενώ ο επισκέπτης διαβάζει τις πληροφορίες και υποβάλλει αίτημα. Χρειάζονται επίσης επιβεβαίωση, διαχείριση διαθέσιμων θέσεων και σαφής χειρισμός μιας ακύρωσης. Ένα ημερολόγιο με πολλές προβολές ή ένα σύνθετο σύστημα προτάσεων μπορεί να εξεταστεί αργότερα. Το κριτήριο είναι αν ο χρήστης ολοκληρώνει τη βασική δουλειά από την αρχή μέχρι το τέλος και αν η ομάδα μπορεί να υποστηρίξει αυτή τη δουλειά καθημερινά.
Δοκιμάστε την κατανόηση πριν αυξήσετε την πολυπλοκότητα
Ένα απλό πρωτότυπο οθονών βοηθά να ελεγχθούν οι λέξεις, η σειρά των βημάτων και οι προσδοκίες. Ζητήστε από ανθρώπους που μοιάζουν με τους μελλοντικούς χρήστες να βρουν ένα εργαστήριο και να δηλώσουν συμμετοχή. Παρατηρήστε πού σταματούν και τι πιστεύουν ότι θα συμβεί όταν πατήσουν το κουμπί. Αν θεωρούν ότι η αίτηση ισοδυναμεί με επιβεβαιωμένη θέση ενώ χρειάζεται έγκριση, υπάρχει πρόβλημα στη ροή ή στο κείμενο. Αυτό το εύρημα αξίζει να διορθωθεί πριν επενδυθεί περισσότερος χρόνος στην τελική εμφάνιση και στις συνδέσεις συστημάτων.
Συμφωνήστε τι σημαίνουν τα δεδομένα
Ένα προϊόν που εξελίσσεται χρειάζεται συνεπή ονόματα και κανόνες. Στο παράδειγμα, «αίτηση», «επιβεβαιωμένη συμμετοχή» και «ακύρωση» είναι διαφορετικές καταστάσεις. Ποιος μπορεί να αλλάξει καθεμία; Τι συμβαίνει αν το εργαστήριο γεμίσει ενώ κάποιος συμπληρώνει τη φόρμα; Μπορεί το ίδιο άτομο να υποβάλει ξανά αίτηση; Αυτές οι αποφάσεις επηρεάζουν τις οθόνες, τις ειδοποιήσεις και τη διαχείριση. Καταγράψτε τις με σύντομα παραδείγματα που καταλαβαίνει όλη η ομάδα. Οι ξεκάθαροι κανόνες βοηθούν περισσότερο από διαφορετικές ερμηνείες της ίδιας λέξης μέσα στον σχεδιασμό και στον κώδικα.
Κρατήστε τις ευθύνες ευδιάκριτες στην υλοποίηση
Η δυνατότητα εξέλιξης δεν απαιτεί να προβλεφθούν όλες οι μελλοντικές ανάγκες. Απαιτεί να είναι κατανοητό πού αλλάζει κάθε συμπεριφορά. Η εμφάνιση της φόρμας, οι κανόνες συμμετοχής και η αποστολή ειδοποίησης είναι διαφορετικές ευθύνες. Όταν διαχωρίζονται καθαρά, η ομάδα μπορεί να εξετάζει μια αλλαγή με πιο συγκεκριμένο πεδίο. Η επιλογή τεχνολογίας πρέπει να λαμβάνει υπόψη την εμπειρία εκείνων που θα συντηρούν το προϊόν, τις πραγματικές συνδέσεις που χρειάζονται και τις απαιτήσεις λειτουργίας. Δεν υπάρχει μία αρχιτεκτονική που να ταιριάζει εξίσου σε κάθε ιδέα και ομάδα.
Σχεδιάστε και τις ημέρες που κάτι δεν λειτουργεί
Η βασική διαδρομή περιλαμβάνει και αποτυχίες. Αν δεν σταλεί μια ειδοποίηση, παραμένει ορατή η συμμετοχή στον πίνακα διαχείρισης; Αν ένας χρήστης πατήσει δύο φορές την αποστολή, θα δημιουργηθούν δύο εγγραφές; Αν χαθεί η σύνδεση, ποιο μήνυμα θα δει; Προσθέστε αυτά τα σενάρια στα κριτήρια αποδοχής. Ορίστε επίσης ποιος παρακολουθεί τα σφάλματα, ποιος έχει πρόσβαση στη διαχείριση και πώς ελέγχεται η επαναφορά από αντίγραφο ασφαλείας. Πρόκειται για αποφάσεις που στηρίζουν την καθημερινή χρήση και πρέπει να συνδέονται με συγκεκριμένες δοκιμές πριν από τη διάθεση.
Μάθετε από την πρώτη χρήση με συγκεκριμένες ερωτήσεις
Η πρώτη διάθεση χρειάζεται μια μικρή λίστα παρατηρήσεων. Μπορούν οι ενδιαφερόμενοι να ολοκληρώσουν τη συμμετοχή χωρίς βοήθεια; Καταλαβαίνουν την κατάσταση της αίτησής τους; Ο διοργανωτής βρίσκει γρήγορα ποιον πρέπει να ενημερώσει; Καταγράψτε πού εγκαταλείπεται η διαδικασία και συζητήστε με όσους αντιμετώπισαν δυσκολία. Ένας αριθμός μόνος του δεν εξηγεί την αιτία. Αν πολλοί ξεκινούν τη φόρμα και λίγοι ολοκληρώνουν, μπορεί να λείπει μια πληροφορία για το εργαστήριο ή να ζητούνται στοιχεία που δεν έχουν διαθέσιμα. Η επόμενη αλλαγή χρειάζεται να απαντά σε ένα τέτοιο εύρημα.
Εξελιχθείτε με αποφάσεις που έχουν λόγο
Κρατήστε τις επόμενες δυνατότητες σε μια λίστα όπου καθεμία συνδέεται με πρόβλημα, χρήστη και αναμενόμενο όφελος. Όταν αυξάνεται η χρήση, ελέγξτε ποιο συγκεκριμένο σημείο δυσκολεύει την εξυπηρέτηση ή την τεχνική λειτουργία πριν επιλέξετε μεγαλύτερη παρέμβαση. Διατηρήστε σύντομη τεκμηρίωση για τους κανόνες, τις συνδέσεις και τις σημαντικές αποφάσεις, ώστε ένας νέος συνεργάτης να καταλαβαίνει πώς λειτουργεί το προϊόν. Ένα product με δυνατότητα εξέλιξης ξεκινά από καθαρή πρώτη χρησιμότητα, δοκιμασμένη συμπεριφορά και ομάδα που μπορεί να εξηγεί γιατί προσθέτει το επόμενο βήμα. Αυτή είναι μια βάση πάνω στην οποία οι πραγματικές ανάγκες μπορούν να οδηγήσουν την ανάπτυξη.
Συχνές ερωτήσεις
- Πότε μια ιδέα είναι έτοιμη για development;
- Όταν έχει οριστεί το πρόβλημα, το κοινό, η κρίσιμη διαδρομή και ένας ελέγξιμος πρώτος κύκλος λειτουργιών, όχι όταν έχουν αποφασιστεί όλες οι πιθανές δυνατότητες.
- Τι σημαίνει scalable πρώτο release;
- Σημαίνει ότι το πρώτο release είναι μικρό αλλά διαθέτει καθαρά όρια, δεδομένα και τεχνικές αποφάσεις που επιτρέπουν ασφαλή εξέλιξη χωρίς πρόωρη υπερκατασκευή.