Το πραγματικό χρονοδιάγραμμα ανάπτυξης μιας εφαρμογής: από την ιδέα στην κυκλοφορία

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

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

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

Γιατί η εκτίμηση που σας έδωσαν είναι μάλλον λάθος

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

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

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

Στάδιο 1: Διερεύνηση και οριοθέτηση (1–3 εβδομάδες)

Πριν σχεδιάσει κανείς έστω και μία οθόνη, υπάρχει ένα στάδιο που δεν μοιάζει με πρόοδο αλλά καθορίζει τα πάντα: να καταλάβετε τι ακριβώς φτιάχνετε και, ακόμη πιο σημαντικό, τι δεν φτιάχνετε. Εδώ μια αόριστη ιδέα («μια εφαρμογή για τους πελάτες μου») γίνεται μια συγκεκριμένη, ολοκληρώσιμη λίστα λειτουργιών για την πρώτη έκδοση.

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

Στάδιο 2: Σχεδιασμός και πρωτότυπο (2–4 εβδομάδες)

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

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

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

Στάδιο 3: Κατασκευή (6–12 εβδομάδες)

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

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

Τι τραβάει αθόρυβα σε μάκρος την κατασκευή

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

• Κάθε εξωτερική ενσωμάτωση προσθέτει μέρες, μερικές φορές εβδομάδες — προϋπολογίστε τις ρητά, μην υποθέτετε ότι είναι δωρεάν.
• Το «μόνο μία ακόμη μικρή λειτουργία» είναι η πιο συνηθισμένη αιτία μιας χαμένης ημερομηνίας κυκλοφορίας.
• Τα πραγματικά δεδομένα είναι πιο μπερδεμένα από τα δοκιμαστικά· προβλέψτε χρόνο για να χειριστείτε τις ακραίες περιπτώσεις που το υπολογιστικό σας φύλλο ανεχόταν αθόρυβα.
• Οι λογαριασμοί χρηστών, οι πληρωμές και οι ειδοποιήσεις είναι απατηλά βαθιά — κοστίζουν πάντα περισσότερα απ' όσο φαίνονται.
• Οι εγκρίσεις και το περιεχόμενο που χρωστάτε στην ομάδα (λογότυπα, κείμενα, νομικά κείμενα) μπορούν να κολλήσουν μια κατασκευή τόσο σίγουρα όσο ένα σφάλμα.

Στάδιο 4: Δοκιμές και διορθώσεις (2–4 εβδομάδες)

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

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

Στάδιο 5: Κυκλοφορία και η αναμονή του app store (1–2 εβδομάδες, συν τον έλεγχο)

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

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

1. 1
   Ήπια κυκλοφορία σε μικρή ομάδα

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

   Η Apple και η Google ελέγχουν το ρολόι του ελέγχου, όχι εσείς. Υποβάλετε με ένα περιθώριο ώστε ένας αργός έλεγχος ή μια απόρριψη να μην τινάξει στον αέρα την υποσχεμένη ημερομηνία σας.
3. 3
   Παρακολουθήστε στενά την πρώτη εβδομάδα

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

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

Συνθέτοντας όλο το χρονοδιάγραμμα

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

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

Πώς να την επιταχύνετε πραγματικά (και πώς όχι)

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

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

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

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