8 ακριβά λάθη στην ανάπτυξη εφαρμογών που κάνουν συνεχώς οι μικρές επιχειρήσεις

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

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

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

Λάθος 1: Φτιάχνετε πριν αποδείξετε ότι το θέλει κανείς

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

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

Λάθος 2: Διόγκωση αντικειμένου μεταμφιεσμένη σε φιλοδοξία

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

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

Λάθος 3: Κανένα γραπτό brief — μόνο μια κοινή νοητική εικόνα

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

Δεν χρειάζεστε προδιαγραφή εκατό σελίδων. Χρειάζεστε λίγες σελίδες που οποιοσδήποτε νεοφερμένος θα μπορούσε να διαβάσει και να καταλάβει: ποιος χρησιμοποιεί αυτή την εφαρμογή, ποια είναι τα τρία ή τέσσερα πράγματα που χρειάζονται να κάνουν με αυτή, πώς μοιάζει ένα επιτυχημένο αποτέλεσμα. Προσθέστε ένα πρόχειρο σκίτσο των βασικών οθονών. Αυτό είναι όλο. Το νόημα του brief δεν είναι η γραφειοκρατία — είναι μια κοινή αναφορά που μπορείτε και οι δύο να δείχνετε όταν η μνήμη και η πραγματικότητα αρχίζουν να αποκλίνουν, πράγμα που πάντα συμβαίνει.

Λάθος 4: Επιλέγετε τον προγραμματιστή με λάθος τρόπο

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

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

Τι να ελέγξετε στ' αλήθεια

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

Λάθος 5: Υπολογίζετε το κόστος κατασκευής, ξεχνάτε τα υπόλοιπα

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

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

Λάθος 6: Σχεδιάζετε για εσάς αντί για τον χρήστη σας

Ξέρετε την επιχείρησή σας απ' έξω κι ανακατωτά, πράγμα που σας κάνει τον χειρότερο δυνατό κριτή του αν η εφαρμογή σας είναι εύκολη στη χρήση. Πράγματα που είναι προφανή για εσάς — η ορολογία, η σειρά με την οποία κάνετε τις εργασίες, οι συντομεύσεις που παίρνετε χωρίς να το σκέφτεστε — μπερδεύουν έναν πρωτοεμφανιζόμενο χρήστη. Μια εφαρμογή που βγάζει απόλυτο νόημα στον ιδιοκτήτη και μπερδεύει όλους τους άλλους έχει αποτύχει, όσο έξυπνη κι αν είναι.

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

• Δώστε στον δοκιμαστή μια πραγματική εργασία, όχι μια ξενάγηση — «κλείστε ένα ραντεβού για την επόμενη Τρίτη», και μετά μείνετε σιωπηλοί.
• Παρακολουθήστε τα χέρια τους και το πρόσωπό τους, όχι μόνο αν τελικά τα καταφέρνουν.
• Σημειώστε κάθε δισταγμό· μια παύση είναι ένα σχεδιαστικό πρόβλημα που δεν μπορείτε να δείτε από μέσα.
• Αντισταθείτε στην παρόρμηση να εξηγήσετε — αν χρειάζεται να το εξηγήσετε, θα έπρεπε να το είχε κάνει η εφαρμογή.
• Δοκιμάστε με πέντε ανθρώπους, διορθώστε τις προφανείς αποτυχίες, μετά δοκιμάστε ξανά.

Λάθος 7: Χτίζετε native iOS και Android ενώ δεν το χρειαζόσασταν

Υπάρχει ένα αντανακλαστικό να χτίσετε μια «κανονική» εφαρμογή και για iPhone και για Android από την πρώτη μέρα, πλήρως native, όπως το κάνουν οι μεγάλες μάρκες. Για τις περισσότερες μικρές επιχειρήσεις, αυτό είναι δύο με τρεις φορές το κόστος και η πολυπλοκότητα για ένα όφελος που οι χρήστες σας δεν θα παρατηρήσουν ποτέ. Χειρότερα, τώρα συντηρείτε δύο ξεχωριστές βάσεις κώδικα για πάντα, διπλασιάζοντας κάθε μελλοντική διόρθωση.

Συχνά η σωστή πρώτη κίνηση δεν είναι καθόλου μια native εφαρμογή. Μια καλοφτιαγμένη web εφαρμογή που δουλεύει στον browser οποιουδήποτε κινητού, ή μια cross-platform προσέγγιση που παράγει και τις δύο εκδόσεις για τα καταστήματα από μία βάση κώδικα, σας βγάζει στην αγορά πιο γρήγορα και φθηνότερα — και μπορείτε πάντα να πάτε πλήρως native αργότερα αν η πραγματική χρήση αποδείξει ότι αξίζει τον κόπο. Η ερώτηση που πρέπει να κάνετε δεν είναι ποτέ «native ή web» αφηρημένα. Είναι: ποιο είναι το μικρότερο, φθηνότερο πράγμα που επιτρέπει σε πραγματικούς χρήστες να κάνουν τη βασική δουλειά; Χτίστε αυτό, μάθετε από αυτό, και μετά ξοδέψτε τα μεγάλα χρήματα με αποδείξεις αντί για υποθέσεις.

Λάθος 8: Αντιμετωπίζετε την κυκλοφορία ως το τέλος της δουλειάς

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

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

Πώς να μείνετε μακριά και από τα οκτώ ταυτόχρονα

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

1. 1
   Αποδείξτε τη ζήτηση πριν χτίσετε

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

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

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

   Φιλοξενία, συντήρηση, διορθώσεις και υποστήριξη. Η ημέρα κυκλοφορίας είναι η γραμμή εκκίνησης, οπότε χρηματοδοτήστε τη λειτουργία του πράγματος.
5. 5
   Διαλέξτε τη μικρότερη πλατφόρμα που κάνει τη δουλειά

   Web ή cross-platform πρώτα στις περισσότερες περιπτώσεις. Πηγαίνετε πλήρως native αργότερα, με αποδείξεις, μόνο αν το απαιτεί η χρήση.
6. 6
   Δοκιμάστε με πραγματικούς χρήστες, μετά σχεδιάστε την κυκλοφορία

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

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