Πώς να δημιουργήσετε το κινητό λογισμικό με εστίαση στην ανάπτυξη

Σημείωση από μένα: αυτό το άρθρο συνυπογράφεται από εμένα, τον Benjamin Grol (συνεργάτης και επικεφαλής της ανάπτυξης στο Atomico) και τον Hemant Bhonsle (κινητό μηχανικό της Zenefits). Αν θέλετε περισσότερες αναλύσεις και πληροφορίες όπως αυτό, παραδοθεί μηνιαία (ish) στα εισερχόμενά σας, εγγραφείτε εδώ στο εγχειρίδιο χειριστή (ενημερωτικό δελτίο).

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

Πρόσφατα άρχισα μια συνάντηση ανάπτυξης με τον Joey Kotkins και τον Andy Young για να συγκεντρώσω άλλους επαγγελματίες του κλάδου μας.

Η δημιουργία λογισμικού έχει αλλάξει θεμελιωδώς κατά την τελευταία δεκαετία. Όταν οι κινητές εφαρμογές τρίτου κατασκευαστή ήταν διαθέσιμες για πρώτη φορά μέσω του App Store το 2008, ο τρόπος με τον οποίο χρησιμοποιούμε το λογισμικό άλλαξε για πάντα, κυρίως με καλό τρόπο. Εντούτοις, ορισμένα πράγματα λείπουν δυστυχώς για τις περισσότερες εφαρμογές για κινητά. κύκλους γρήγορης απελευθέρωσης, λειτουργίες που ελέγχονται από το διακομιστή και δοκιμές A / B. Αυτά ήταν αρκετά συνηθισμένα για πολλά προϊόντα ιστού που οδηγούσαν στην κινητή επανάσταση, αλλά γενικά δεν ήταν μέρος του πρώτου κύματος ανάπτυξης κινητών τηλεφώνων και επιστρέφουν μόνο σε πλήρη ισχύ σήμερα. Με κάνει να λυπούμαι που σκέφτομαι όλη την χαμένη παραγωγικότητα και τον αυξημένο πόνο του πελάτη εξαιτίας αυτού.

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

Tenet # 1: (Bi) εβδομαδιαίες κυκλοφορίες σε κινητά και εβδομαδιαία σπριντ εκτέλεσης

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

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

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

  • Κάνετε ένα γρήγορο πέρασμα της (καλά διατηρημένης) ανεκτέλεστα σας με την ομάδα. Πρέπει να διαρκέσει 15 λεπτά το μέγιστο.
  • Εξετάστε τι έχετε μάθει μέχρι στιγμής αυτήν την εβδομάδα. Οποιεσδήποτε διορθώσεις μαθημάτων;
  • Στη συνέχεια η ομάδα συζητάει τι πρέπει να κάνει την επόμενη εβδομάδα.
  • Κάθε εργασία αναλαμβάνεται από έναν μηχανικό που δεσμεύεται να το κάνει την επόμενη εβδομάδα.
  • Υπάρχει συνήθως μια "συνάντηση επίδειξης" καθώς προχωρά η εβδομάδα όπου οι μηχανικοί μπορούν να δείξουν την τελική εργασία (ή ό, τι πρόοδο έχουν κάνει). Αυτό είναι κρίσιμο για να τονωθεί η εστίαση και η υπευθυνότητα.

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

Για να ανακεφαλαιώσουμε, τα θετικά αποτελέσματα ενός ρυθμού γρήγορης απελευθέρωσης και εκτέλεσης:

  • Ταχύτερη πρόοδος - Περισσότερος χρόνος μεταξύ των εκδόσεων μπορεί να οδηγήσει σε περιστατικά με νόμο του Parkinson. Πρόκειται για μια πρόσκληση για ανταλλαγή προόδου για κίνηση.
  • Υψηλότερη ποιότητα προϊόντος - Εάν κυκλοφορείτε δύο φορές την εβδομάδα, ο προσδιορισμός των βασικών αιτιών των ζητημάτων είναι συνήθως πολύ πιο εύκολη. Μπορεί να υπάρχουν εκθετικά περισσότερες αλληλεπιδράσεις λογισμικού σε έναν κύκλο απελευθέρωσης 8 εβδομάδων έναντι ενός κύκλου απελευθέρωσης 2 εβδομάδων
  • Περισσότερη ατομική εστίαση - Εβδομαδιαία σπριντ οδηγούν την εστίαση, την υπευθυνότητα και την ευτυχία
  • Ταχύτερη εκμάθηση - Όπως θα καλύψουμε στο δόγμα # 3, η εκκίνηση τουλάχιστον ενός ουσιαστικού πειράματος την εβδομάδα θα κάνει το προϊόν ή την υπηρεσία σας καλύτερο νωρίτερα.

Σημείωση: κατά την εβδομαδιαία εκτόξευση, είναι κοινό να υπάρχει ένας κατασκευαστής υποψήφιων κυκλοφοριών που χρησιμοποιείται εσωτερικά (ή μια ομάδα beta) για μια εβδομάδα, και * στη συνέχεια * στην πραγματικότητα ξεκίνησε στην άγρια ​​φύση. Καθώς οι απελευθερώσεις συσσωρεύονται, έχετε μια φάση αλλαγής φάσης μία εβδομάδα, αλλά η σταθερή ροή εξακολουθεί να είναι εβδομαδιαία. Η ποιότητα είναι ζωτικής σημασίας για τη διατήρηση, φυσικά.

Tenet # 2: Ελέγξτε τις λειτουργίες του πελάτη για κινητά με στοιχεία ελέγχου διακομιστή

Μια πολύ σημαντική πτυχή της φυσικής ανάπτυξης κινητής τηλεφωνίας σήμερα είναι η διατήρηση του διακομιστή ελέγχου από τα διάφορα χαρακτηριστικά του πελάτη. Αυτό έχει γίνει ένα τέτοιο πρότυπο τα τελευταία χρόνια ότι πολλές επιχειρήσεις έχουν ξεσπάσει γύρω από αυτή την έννοια, επιτρέποντας στους προγραμματιστές να ρυθμίζουν εύκολα τις εφαρμογές τους για να διαβάζουν σημαίες από το διακομιστή και να προσαρμόζουν ανάλογα το UI / UX τους και δείχνουν μόνο τα κατάλληλα χαρακτηριστικά. Πολλές μεγάλες εταιρείες λογισμικού δημιουργούν συστήματα που το κάνουν αυτό από το μηδέν. Το Facebook είχε μερικά συστήματα που το έκαναν, όπως το Gatekeeper (GK) και τα Quick Experiments (QE). Παρόμοια συστήματα έχουν κατασκευαστεί σε Uber, Pinterest, Zenefits, κλπ. Μερικά παραδείγματα διαθέσιμων εργαλείων που το κάνουν περιλαμβάνουν Optimizely, Mixpanel, Apptimize και Firebase.

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

  • Καλύτερη εμπειρία πελατών - Λόγω καθυστερήσεων μεταξύ της υποβολής της εφαρμογής και της διαθεσιμότητας για τους πελάτες σας, τα σφάλματα των υπολογιστών-πελατών και τα σφάλματα ενδέχεται να εμφανιστούν μέχρι να δημοσιευθεί μια επείγουσα επιδιόρθωση. Με χαρακτηριστικά του πελάτη που ελέγχονται από το διακομιστή, αυτά τα είδη αποτυχιών μπορούν να μετριαστούν (π.χ. μια νέα λειτουργία προκαλεί συντριβή στη συσκευή Nexus 6, οπότε η λειτουργία απενεργοποιείται σε επίπεδο διακομιστή για όλους τους χρήστες με αυτήν τη συσκευή και η συντριβή σταματά). Αυτό είναι αναμφισβήτητα λιγότερο θέμα για τις εφαρμογές Android, όμως, μπορεί να υπάρχει ακόμη μερική καθυστέρηση μεταξύ της υποβολής και της απελευθέρωσης. Επίσης, ορισμένοι χρήστες δεν έχουν ενεργοποιημένη την αυτόματη ενημέρωση.
  • Περισσότερες εγκαταστάσεις - Σε έναν κόσμο όπου η εφαρμογή διακόπτεται στην αρχή για μια ημέρα περίπου, η εφαρμογή μπορεί να πάρει πολλές αρνητικές κριτικές. Αυτό μπορεί να οδηγήσει σε χαμηλότερη κατάταξη στο Google Play Store / iOS App Store και χαμηλότερο ποσοστό μετατροπής από τη σελίδα της εφαρμογής στην εγκατάσταση της εφαρμογής (π.χ., είμαι πιο πιθανό να εγκαταστήσω μια εφαρμογή με βαθμολογία 4,5 αστέρων από μια βαθμολογία 3,5 αστέρων) . Αυτό δεν επηρεάζει καν πελάτες στους οποίους έχετε «καεί» που δεν θα επιστρέψουν ποτέ, ούτε αρνητικό τύπο που θα μπορούσε να βλάψει το εμπορικό σήμα σας.
  • Μικρότερη μονολιθική / πιο υγρή ανάπτυξη - Όταν οι μηχανικοί γνωρίζουν ότι ένα ατελές χαρακτηριστικό μπορεί να απενεργοποιηθεί με μια διαμόρφωση διακομιστή, αυτό μειώνει το γενικό κόστος ανάπτυξης.

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

Για παράδειγμα:

  • Μόλις δημιουργήσατε ένα χαρακτηριστικό πληρωμών για πελάτες κινητής τηλεφωνίας
  • Δημιουργήσατε μια αντίστοιχη σημαία διακομιστή που ονομάζεται "payments_v1". Πρόκειται για μια τιμή boolean που μπορεί να οριστεί είτε ως αληθής είτε ως ψευδής
  • Κατά την πρώτη περίοδο λειτουργίας πελάτη, ο υπολογιστής πελάτης παραδίδει αυτήν την τιμή. Εάν η τιμή είναι αληθής, ο πελάτης θα δείξει τη δυνατότητα, αν είναι ψευδής, ο πελάτης δεν θα το κάνει

Είναι κοινή η προπώληση του ονόματος της πλατφόρμας, συνήθως "ios_" ή "android_", και να προστεθεί η ημερομηνία κατά την οποία έγινε η σημαία, έτσι κάτι σαν "_aug_2017". Έτσι, για την πρώτη έκδοση των δυνατοτήτων πληρωμών που κυκλοφορεί στην iOS, μπορεί να δείτε μια σημαία όπως "ios_payments_v1_aug_2017". Η κατοχύρωση της ημερομηνίας βοηθάει ώστε οι ομάδες να μπορούν να διατηρούν ένα μαλακό χρονοδιάγραμμα στον κώδικα κατά το οποίο απελευθερώθηκαν διαφορετικά χαρακτηριστικά. Η κατοχή της πλατφόρμας βοηθάει ώστε η απενεργοποίηση της σημαίας να απενεργοποιείται μόνο για την κατάλληλη πλατφόρμα παρά για όλους τους χρήστες, εάν η συντριβή ή το πρόβλημα είναι μόνο σε ένα και όχι το άλλο.

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

Tenet # 3: Επέκταση των ελέγχων διακομιστών των λειτουργιών για κινητά σε δοκιμές A / B για μεγιστοποίηση της μάθησης

Ο έλεγχος των λειτουργιών μόνο με δυαδικό τρόπο (true == show, false == hide) είναι ωραίο ως διακόπτης για να ενεργοποιήσετε και να απενεργοποιήσετε τα πράγματα για τους χρήστες. Σε πολλές περιπτώσεις, όμως, θέλουμε να αναπτύξουμε διαφορετικές παραλλαγές χαρακτηριστικών για να μάθουμε τι θέλουν οι πελάτες μας με βάση τη χρήση του χαρακτηριστικού.

Το κάνουμε αυτό με δοκιμές A / B σε κινητά. Η ιδέα για το κινητό εδώ είναι ίδια με την δοκιμή A / B οπουδήποτε αλλού - θέλουμε να εκτελέσουμε ένα πείραμα και να δοκιμάσουμε πολλές διαφορετικές παραλλαγές για τα καλύτερα αποτελέσματα. Έτσι, εκτός από τις σημαίες χαρακτηριστικών για να ενεργοποιήσετε και να απενεργοποιήσετε τις συμπεριφορές πελατών, τα ονόματα κλειδιών των παραλλαγών που εμφανίζονται επιστρέφονται από το διακομιστή. Με βάση την παραληφθείσα παραλλαγή, στην αίτησή σας θα εμφανιστεί το αντίστοιχο UI / UX.

Αυτή η διαδικασία μας επιτρέπει:

  • Επιλέξτε τον νικητή - Με την εξερεύνηση και τη δοκιμή των επιλογών, μπορείτε να επιλέξετε το καλύτερο.
  • Ανακόψτε αργά ένα επικίνδυνο / αμφιλεγόμενο χαρακτηριστικό (πιθανώς σε μια ομάδα beta) - Μερικές φορές ξεκινάμε λειτουργίες που ενδέχεται να σπάσουν την υπάρχουσα λειτουργικότητα με άγνωστους τρόπους. Μπορεί να χρησιμοποιεί ένα νέο back-end ή ένα νέο κομμάτι λειτουργικότητας που σε μεγάλο βαθμό δεν έχει δοκιμαστεί. Με την εκτόξευση σε ένα μικρό ποσοστό των χρηστών, μπορείτε συχνά να μετριάσετε τον ευρύτερο πόνο των πελατών. Μια άλλη επιλογή που πρέπει να εξετάσετε είναι να βασιστείτε σε μια ομάδα beta πιστών πελατών. Έχω δει καταστάσεις όπου αυτοί πεθαίνουν σκληροί οπαδοί του προϊόντος, όπως η αποκλειστικότητα της ύπαρξης στις πρώιμες κυκλοφορίες της εφαρμογής σας.
  • Δημιουργήστε μια καλύτερη εμπειρία εφαρμογής - Όταν χρησιμοποιείτε τη συνήθεια μέτρησης δεδομένων χρήσης και πλοήγησης στην εφαρμογή σας για κινητά, οι φυσικές χρήσεις συχνά γίνονται αυτονόητες. Αυτό σας επιτρέπει να βελτιστοποιήσετε την εφαρμογή σας στην πραγματική συμπεριφορά των πελατών.

Επεκτείνοντας το παράδειγμα της δυνατότητας πληρωμών που συζητήσαμε νωρίτερα:

Εκτελέστε τη δοκιμή:

  • Θέλουμε να A / B δοκιμή το χρώμα του κουμπιού πληρωμής για να δούμε αν υπάρχει επίδραση στις αγορές των χρηστών
  • Εκτός από τη σημαία "payments_v1" στέλνουμε τώρα από το διακομιστή ένα πλήκτρο "payments_v1_button_color" με παραλλαγές δηλαδή "μπλε", "πράσινο", "κόκκινο"
  • Περιμένετε έως ότου λάβετε στατιστικά σημαντικά αποτελέσματα από την παρακολούθηση πελατών

Αποφασίστε για ένα αποτέλεσμα:

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

Αφαιρέστε τη δοκιμή A / B όταν είναι ασφαλές να το κάνετε:

  • Καθαρίστε ξανά τον κώδικα διακομιστή μόλις ο λόγος των χρηστών σας σε παλαιότερους πελάτες είναι αμελητέος
  • Καταργήστε πλήρως το πλήκτρο "payments_v1_button_color"
  • Εάν αναπτύξατε με γνώμονα τη συμβατότητα προς τα πίσω (έτσι ώστε αν το κλειδί δεν αποστέλλεται από το διακομιστή), ο πελάτης πέφτει πίσω στην εμφάνιση ορισμένων προεπιλογών - σαν την προεπιλεγμένη περίπτωση μιας εντολής διακόπτη

Συμπέρασμα:

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

TL, έκδοση DR

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

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