Δημιουργία MVPs για Startups vs Enterprise Software (Η εμπειρία μας)

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

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

Η εκκίνηση

StartUp - Η πρόκληση

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

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

Μεγάλη Επιχείρηση

ISV - Η πρόκληση

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

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

Θα το χωρίσουμε στις διάφορες κατηγορίες:

Οι Τεχνολογίες Πίσω από αυτό

Tech Stack

Δεν υπάρχει αμφιβολία ότι η εκκίνηση ήταν πιο ευέλικτη σε αυτό το θέμα, ήταν ανοιχτά σε προτάσεις και ήταν πρόθυμοι να δοκιμάσουν τεχνολογίες αιχμής, ακόμη και όταν συνεπάγονταν κινδύνους όπως τη χρήση προϊόντων στην έκδοση ΒΕΤΑ για παραγωγή . Για παράδειγμα, ήθελαν να χρησιμοποιήσουν το Cloud Firestore ακόμη και ότι χαρακτηρίστηκε ως ΒΕΤΑ την εποχή εκείνη.

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

ΟΜΑΔΙΚΗ ΔΟΥΛΕΙΑ

Μέγεθος ομάδας

Δεν είμαι ακόμα σίγουρος αν αυτό επηρεάζεται από το είδος του προϊόντος, είμαι διατεθειμένος να πιστεύω ότι είναι περισσότερο λόγω του πεδίου εφαρμογής, αλλά για το MVP είχαμε μια ομάδα 1 Project Manager, 2 Developers και 1 QA. Δεν υπήρχαν άτομα UX στην ομάδα, επειδή ο πελάτης είχε ήδη τα σχέδιά τους.

Η ομάδα για το έργο Enterprise ήταν πολύ μεγαλύτερη, είχαμε 1 Project Manager, 6 Developers, 2 QA και 2 UX εμπειρογνώμονες.

Όπως είπα, πρόκειται περισσότερο για το πεδίο εφαρμογής, το MVP ήταν ένα έργο διάρκειας δύο μηνών, το Enterprise Software ήταν μια δέσμευση ενός έτους.

Ταχύτητα

Ταχύτητα ανάπτυξης

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

Για το Enterprise Software ™, τα πράγματα είναι διαφορετικά, είχαμε μια διαδικασία πολλαπλών τμημάτων για την αποδέσμευση κώδικα:

  • Ξεκινήσαμε με μια σύνοδο οδικής χαρτογράφησης όπου αναλύσαμε ολόκληρο το έργο και καθορίσαμε τις δυνατότητες που πρέπει να δημιουργηθούν σε κάθε έκδοση.
  • Δημιουργήσαμε μια μηνιαία έκδοση με 2 σπριντ σε κάθε έκδοση.
  • Μετά από κάθε σπριντ, τα χαρακτηριστικά πήγαν στην ομάδα QA μας.
  • Μετά την πιστοποίηση QA δημιουργήσαμε έναν εγκαταστάτη για την ομάδα QA του πελάτη.
  • Μετά την πιστοποίηση QA του πελάτη, τα χαρακτηριστικά εγκρίθηκαν και ενσωματώθηκαν στο έργο. Ή έχουν σταλεί πίσω για διορθώσεις.
QA

Αναλυτές ποιότητας

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

Για τον πελάτη επιχείρησης, η ομάδα QA πιστοποίησε τα χαρακτηριστικά, αλλά μετά από αυτό, η δική του ομάδα QA έπρεπε να την πιστοποιήσει πριν δώσει το go για να το ενσωματώσει με τον κύριο κλάδο του έργου.

Σχέδιο

UX / UI

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

Με τον πελάτη της επιχείρησής μας, ο σχεδιασμός ήταν επίσης μια διαδικασία πολλαπλών βημάτων:

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

Ανάπτυξη

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

Για τον πελάτη εκκίνησης, δημιουργήσαμε μια εγκατάσταση χρησιμοποιώντας το Firebase και το Wordpress (για το τμήμα περιεχομένου της εφαρμογής).

Ο πελάτης επιχείρησης είχε διαφορετικές απαιτήσεις, όλα έγιναν με εσωτερικά εργαλεία / πλατφόρμες που είχαν, είχαμε τον πηγαίο κώδικα μέσα στο λογαριασμό VSTS, αλλά μόνο όταν ήμασταν "στην ανάπτυξη".

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

Η συζήτηση χρημάτων

Δικαστικά έξοδα

Όπως μπορείτε να φανταστείτε τα χρήματα ομιλία ήταν πολύ διαφορετική και για τους δύο πελάτες.

Ο πελάτης εκκίνησης είχε μια ομάδα περίπου το 1/3 του μεγέθους του πελάτη επιχείρησης που επηρεάζει πολύ το κόστος, επίσης, οι διαδικασίες και το πεδίο εφαρμογής ήταν διαφορετικές.

Διδάγματα

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

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

Τι νομίζετε, είστε ένα Startup ψάχνει να φτάσει στην αγορά γρήγορα; Ή μια εδραιωμένη εταιρεία που αναζητά έναν τεχνικό συνεργάτη;

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

Φτάστε σε εμένα ή στο Yuxi Global - [email protected] - εάν αντιμετωπίζετε παρόμοιες προκλήσεις στον οργανισμό σας και ψάχνετε για βοήθεια στην κατασκευή του επόμενου MVP ή του Ψηφιακού Προϊόντος. Αγαπάμε μια καλή πρόκληση και αναζητούμε πάντα τρόπους να καινοτομούμε μαζί σας.