Πώς να ορίσετε το εύρος ενός MVP: Περιορίστε την πρώτη σας υλοποίηση σε ό,τι έχει πραγματικά σημασία

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

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

Έτσι, αυτός είναι ο οδηγός που δίνω στους ανθρώπους πριν γραφτεί ούτε μια γραμμή κώδικα. Δεν αφορά τελετουργικά Agile ή φανταχτερά frameworks. Αφορά μία ειλικρινή ερώτηση — ποιο είναι το μικρότερο πράγμα που μπορούμε να χτίσουμε και που μας λέει αν αυτή η ιδέα είναι αληθινή; — και την πειθαρχία να συνεχίζουμε να την απαντάμε καθώς ο πειρασμός να προσθέσουμε «άλλη μία λειτουργία» επανέρχεται σιγά σιγά. Γιατί πάντα επανέρχεται.

Τι είναι πραγματικά ένα MVP (και τι δεν είναι)

Η φράση έχει φθαρεί από την υπερβολική χρήση, οπότε ας είμαστε ακριβείς. Ένα minimum viable product είναι η μικρότερη εκδοχή της ιδέας σας που προσφέρει πραγματική αξία σε έναν πραγματικό χρήστη και σας διδάσκει κάτι που δεν θα μπορούσατε να μάθετε από μια παρουσίαση διαφανειών. Η λέξη-κλειδί που ξεχνούν όλοι είναι το viable, δηλαδή βιώσιμο. Πρέπει να λειτουργεί πραγματικά για κάποιον, από άκρη σε άκρη, ακόμη κι αν κάνει μόνο ένα πράγμα.

Να τι δεν είναι ένα MVP. Δεν είναι μια μισοτελειωμένη εκδοχή του πλήρους προϊόντος με σπασμένες γωνίες παντού. Δεν είναι ένα πρωτότυπο που πετάς. Και σίγουρα δεν είναι «η φθηνή εκδοχή» — το φθηνό είναι παρενέργεια του καλού ορισμού εύρους, όχι ο στόχος. Ο στόχος είναι η μάθηση. Ξοδεύετε όσο λιγότερα χρήματα γίνεται για να απαντήσετε στην πιο ακριβή ερώτηση που έχετε: θα το χρησιμοποιήσει κανείς, και θα το χρησιμοποιήσει με τον τρόπο που νομίζω;

Αυτή η διάκριση έχει μεγαλύτερη σημασία απ' ό,τι ακούγεται. Η νοοτροπία του «πρώτου 20%» οδηγεί σε κάτι που είναι σπασμένο προς κάθε κατεύθυνση και χρήσιμο σε καμία. Το «ένα πράγμα, σωστά» οδηγεί σε κάτι που ένας άνθρωπος μπορεί να πιάσει, να χρησιμοποιήσει στ' αλήθεια και να έχει γνώμη γι' αυτό. Οι γνώμες είναι όλο το νόημα. Δεν μπορείς να βελτιώσεις τη σιωπή.

Η παγίδα της υπερβολικής υλοποίησης, και γιατί είναι τόσο εύκολο να πέσεις μέσα

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

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

Βρείτε τη μία δουλειά που πρέπει να κάνει το MVP σας

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

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

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

Ταξινομήστε κάθε λειτουργία σε πρέπει, θα έπρεπε και δεν θα

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

• Πρέπει: ο βασικός βρόχος κυριολεκτικά δεν λειτουργεί χωρίς αυτό. Αν το αφαιρέσεις, δεν υπάρχει προϊόν. Κρατήστε αυτή τη λίστα συγκλονιστικά σύντομη — συνήθως τρία έως έξι στοιχεία.
• Θα έπρεπε: κάνει το προϊόν καλύτερο, αλλά ο βρόχος δουλεύει και χωρίς αυτό. Όλα εδώ περιμένουν την έκδοση δύο. Καμία εξαίρεση στην πρώτη υλοποίηση.
• Δεν θα (ακόμη): οι λειτουργίες που συνειδητά επιλέγετε να μην χτίσετε τώρα. Το να τις γράφετε έχει σημασία — έτσι καθησυχάζετε τον εαυτό σας, και την ομάδα σας, ότι η ιδέα δεν εγκαταλείπεται, απλώς μπαίνει σε σειρά.

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

Ορίστε το εύρος με βάση τον χρόνο και τα χρήματα, όχι τη λίστα λειτουργιών

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

Ένα σταθερό κουτί κάνει και κάτι ψυχολογικό. Όταν ο προϋπολογισμός είναι ανοιχτός, κάθε λειτουργία είναι συζητήσιμη και η λίστα μόνο μεγαλώνει. Όταν το κουτί είναι σταθερό — ας πούμε, οκτώ εβδομάδες κι ένα ορισμένο ποσό — η συζήτηση αναποδογυρίζει. Παύει να είναι «να το προσθέσουμε αυτό;» και γίνεται «τι βγαίνει αν μπει αυτό;» Αυτή η δεύτερη ερώτηση είναι που χτίζει καλά MVP. Οι ανταλλαγές γίνονται ορατές αντί για κρυφές, και η ομάδα τις κάνει επίτηδες.

Ένα πραγματικό παράδειγμα: περιορίζοντας μια ιδέα διαχείρισης εργασιών

Ας το κάνω συγκεκριμένο με μια περίπτωση στην οποία δουλέψαμε — ανωνυμοποιημένη, αλλά πιστή στο πώς εξελίσσονται αυτά. Μια μικρή εταιρεία θέρμανσης και υδραυλικών ήρθε σ' εμάς θέλοντας μια εφαρμογή για την ομάδα πεδίου της. Η περιγραφή, στα χαρτιά, ήταν τεράστια: ζωντανός προγραμματισμός εργασιών, παρακολούθηση GPS των φορτηγών, πύλη πελατών, αυτόματη τιμολόγηση, απογραφή ανταλλακτικών σε κάθε όχημα, κατασκευαστής προσφορών, φωτογραφική τεκμηρίωση και μια σουίτα αναφορών για τον ιδιοκτήτη. Ένα πραγματικά χρήσιμο προϊόν, τελικά. Ως πρώτη υλοποίηση, ένας εγγυημένος τρόπος να ξοδέψεις τον προϋπολογισμό ενός χρόνου πριν μάθεις το παραμικρό.

Έτσι κάναμε την άσκηση. Ρωτήσαμε τον ιδιοκτήτη την πρόταση: «Ένας χρήστης έρχεται σ' αυτό για να ______, και είναι ικανοποιημένος αν ______.» Μετά από λίγο πάρε-δώσε, η πραγματική απάντηση αναδύθηκε. Ο μεγαλύτερος καθημερινός πόνος των τεχνικών δεν ήταν ο προγραμματισμός ή η τιμολόγηση — ήταν η γραφειοκρατική παλινδρόμηση. Τελείωναν μια εργασία, σημείωναν ώρες και ανταλλακτικά σε ένα φύλλο, οδηγούσαν πίσω, και κάποιος στο γραφείο τα πληκτρολογούσε ξανά όλα στο λογιστικό σύστημα, συχνά μέρες αργότερα, συχνά με λάθη. Ο βασικός βρόχος ήταν απλά: κατέγραψε τι έγινε στην εργασία, μία φορά, επιτόπου, ώστε κανείς να μην ξαναπληκτρολογεί.

Τι πέρασε το κατώφλι — και τι όχι

Όλα ταξινομήθηκαν. Ο κάδος πρέπει κατέληξε σε τέσσερα πράγματα: μια λίστα με τις σημερινές εργασίες για κάθε τεχνικό, μια απλή φόρμα για καταγραφή ωρών και ανταλλακτικών ανά εργασία, μια επισύναψη φωτογραφίας, και έναν τρόπο για το γραφείο να βλέπει αυτά τα δεδομένα τη στιγμή που υποβάλλονταν. Αυτό ήταν όλο το MVP. Κανένα GPS, καμία πύλη πελατών, κανένας κατασκευαστής προσφορών, καμία φανταχτερή αναφορά — όλα παρκαρισμένα, ρητά, στη λίστα «δεν θα ακόμη» με μια σημείωση ότι έρχονται.

Χτίσαμε αυτόν τον πυρήνα σε λίγες εβδομάδες αντί για το μεγαλύτερο μέρος ενός χρόνου. Και να το μέρος που δικαιολογεί όλη την προσέγγιση: μόλις βγήκε ζωντανά, οι πραγματικές προτεραιότητες της ομάδας αποδείχθηκαν διαφορετικές από την περιγραφή. Ο ιδιοκτήτης είχε υποθέσει ότι η παρακολούθηση GPS θα ήταν το επόμενο· οι τεχνικοί ελάχιστα την ανέφεραν. Αυτό που ήθελαν, με δυνατή φωνή, ήταν να στέλνουν στον πελάτη ένα μήνυμα με το παράθυρο άφιξης μέσα από την εφαρμογή — μια λειτουργία που δεν ήταν καν στην αρχική λίστα. Επειδή το MVP ήταν μικρό και φθηνό, έμενε προϋπολογισμός για να χτιστεί αυτό που πραγματικά ήθελαν, αντί γι' αυτό που είχαν μαντέψει μήνες νωρίτερα.

Τα λάθη που αθόρυβα καταστρέφουν το εύρος ενός MVP

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

• Επιχρύσωση των άκρων: να ξοδεύεις μέρες τελειοποιώντας έναν πίνακα διαχείρισης που μόνο εσύ θα δεις, ενώ ο βασικός βρόχος είναι ακόμη ακατέργαστος. Γυάλισε το πράγμα που αγγίζουν οι χρήστες· άσε το παρασκήνιο άσχημο και λειτουργικό.
• Χτίσιμο για κλίμακα που δεν έχεις: να σχεδιάζεις αρχιτεκτονική για ένα εκατομμύριο χρήστες ενώ χρειάζεται να αποδείξεις ότι οι πρώτοι δέκα θα επιστρέψουν. Λύσε το πρόβλημα της κλίμακας όταν αποκτήσεις το ευχάριστο πρόβλημα της κλίμακας.
• Σύγχυση του «απαραίτητο» με το «πρότυπο του κλάδου»: το ότι κάθε ανταγωνιστής έχει τη λειτουργία Χ δεν σημαίνει ότι το MVP σου τη χρειάζεται για να δοκιμάσει τη βασική σου ιδέα. Δεν κυκλοφορείς ένα τελειωμένο προϊόν, τρέχεις ένα πείραμα.
• Σχεδιασμός κάθε ακραίας περίπτωσης εκ των προτέρων: να χειρίζεσαι τις σπάνιες, παράξενες εισόδους πριν μάθεις αν κάποιος χρησιμοποιεί την κοινή, κανονική διαδρομή. Άσε την πραγματική χρήση να σου πει ποιες ακραίες περιπτώσεις είναι καν αληθινές.
• Κανένας ορισμός του «ολοκληρωμένου»: χωρίς μια γραπτή γραμμή που περιγράφει πώς μοιάζει το «τελειωμένο», η υλοποίηση δεν τελειώνει ποτέ. Η διεύρυνση του εύρους λατρεύει ένα έργο χωρίς γραμμή τερματισμού.

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

Μια απλή διαδικασία για τον ορισμό εύρους του MVP σας

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

1. 1
   Ονομάστε τον βασικό βρόχο

   Ολοκληρώστε την πρόταση: «Ένας χρήστης έρχεται για να κάνει ___, και είναι ικανοποιημένος αν ___.» Αν δεν μπορείτε, δεν είστε έτοιμοι να ορίσετε εύρος — συνεχίστε να μιλάτε μέχρι να αναδυθεί η πραγματική δουλειά.
2. 2
   Καταγράψτε κάθε λειτουργία, μετά ταξινομήστε

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

   Αποφασίστε τον προϋπολογισμό και την προθεσμία πριν οριστικοποιήσετε τη λίστα λειτουργιών. Κάντε τη λίστα να χωρέσει στο κουτί, όχι το αντίστροφο.
4. 4
   Γράψτε τον ορισμό του ολοκληρωμένου

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

   Βγάλτε τον πυρήνα σε πραγματικούς χρήστες. Παρατηρήστε τι κάνουν πραγματικά. Αφήστε τη συμπεριφορά τους — όχι τις προηγούμενες εικασίες σας — να επιλέξει τι έρχεται από τη λίστα «θα έπρεπε» στη συνέχεια.

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

Συχνές ερωτήσεις