Creació de MVP per a startups i programes empresarials (experiència)

Al llarg de l'any passat he tingut la sort de participar en el desenvolupament de dues aplicacions mòbils per a dos clients diferents a la nostra empresa.

Tot i que de naturalesa semblant, els reptes i enfocaments per a cada un van variar dràsticament els uns dels altres i vaig voler compartir les meves experiències d’aprenentatge amb vosaltres i què vaig trobar en què es trobaven algunes de les peculiaritats i diferències entre la creació d’un MVP per a un Startup i una gran empresa FinTech.

L’inici

StartUp: el repte

El nostre primer repte que em van donar a mi i als meus companys va ser la tasca de construir un MVP bastant complicat per a un dels aeroports més grans de LATAM que tenia moltes peces mòbils, des de tirar dades de vols en temps real, visualitzacions de mapes de grans magatzems i un motor de recomanació personalitzada. entre moltes altres.

El propòsit era encapsular una veritable experiència completament digital i involucrar passatgers mitjançant una única aplicació mòbil i eliminar la necessitat que l’usuari descarregués diverses aplicacions i disminuís el compromís d'una marca dispersa.

Big Enterprise

ISV: el repte

El segon repte que ens va llançar –i vull dir que de la millor manera possible– va ser per a una gran empresa FinTech. És una aplicació financera, implica treballar amb molta funcionalitat al voltant dels diners de la gent. Va ser també una cosa que diversos bancs van utilitzar, de manera que, com us podeu imaginar, tot el temps va ser molt seriós i complex.

Avui vull aprofitar un moment per compartir amb vosaltres la nostra experiència, però principalment, la diferència entre crear un MVP per a la creació inicial i crear Enterprise Software ™.

La dividirem en les diferents categories:

Les tecnologies al darrere

Tech Stack

Sens dubte, la posada en marxa era més flexible al respecte, estaven oberts a suggeriments i estaven ansiosos de provar tecnologies d’avantguarda fins i tot quan comportava el risc com utilitzar productes en versió BETA per a la producció . Per exemple, volien utilitzar Cloud Firestore, fins i tot quan es marcava com a BETA en aquell moment.

L’empresa Fintech estava més clarament tancada sobre la pila de tecnologia que faríem servir. Fins i tot els paquets que havíem d’instal·lar havien de passar per un exhaustiu procés de revisió, tant del seu equip tècnic com del seu equip de seguretat. Per no oblidar que qualsevol cosa que no podrien tenir el 100% de propietat quedava fora de dubte.

Treball en equip

Mida de l'equip

Encara no estic segur si això afecta el tipus de producte, però estic inclinat a pensar que és més a causa de l'abast, però per a la MVP teníem un equip de 1 Project Manager, 2 desenvolupadors i 1 QA. A l'equip no hi havia persones UX perquè el client ja tenia els seus dissenys.

L’equip del projecte Enterprise era molt més gran, teníem 1 Project Manager, 6 desenvolupadors, 2 QA i 2 experts UX.

Com he dit, tracta més sobre l’abast, la MVP va ser un projecte de dos mesos, el Enterprise Software va ser un compromís durant un any.

Velocitat

Velocitat de desenvolupament

Aquest és un aspecte on hem trobat moltes diferències, la posada en marxa necessària per arribar al mercat el més ràpid possible, de manera que estàvem concentrats a desplegar una nova funcionalitat cada setmana.

Per a Enterprise Software ™, les coses són diferents, vam tenir un procés multipartit per alliberar el codi:

  • Vam començar amb una sessió de full de ruta on vam analitzar tot el projecte i vam definir les característiques a construir en cada llançament.
  • Establim una publicació mensual amb 2 sprints a cada versió.
  • Després de cada sprint, les funcions es van dirigir al nostre equip de QA.
  • Després de la certificació de QA, hem generat un instal·lador per a l'equip de QA del client.
  • Després de la certificació de QA del client, les funcions es van aprovar i integrar al projecte. O bé van ser enviats de nou per solucionar-los.
QA

Analistes de qualitat

En el punt anterior en parlem una mica, però també hi ha algunes diferències en la garantia de qualitat. Per exemple, per al projecte Startup, la nostra QA va tenir més en compte en què funcionaven les coses i què considerava que era una expectativa satisfeta.

Per al client empresarial, el nostre equip de QA va certificar les funcions, però després, el propi equip de QA va haver de certificar-lo abans de donar-li la sortida per integrar-lo amb la branca mestra del projecte.

Disseny

UX / UI

Aquesta és una altra part en què el procés va ser molt diferent, i amb el client que ens van fer servir ens van fer els dissenys perquè els implementéssim i que va ser un procés menys rigorós.

Amb el nostre client empresarial, el disseny també va ser un procés de diversos passos:

  • El nostre equip d’UX va crear els dissenys de la funció per al proper sprint.
  • El departament de disseny del client va aprovar els dissenys.
  • El client va enviar els dissenys aprovats per a les proves de l’usuari.
  • El client va enviar els dissenys per implementar canvis basats en proves de l'usuari.
  • El nostre equip d’UX va fer els canvis / solucions i després enviar els dissenys al client.
Desplegament

Desplegament

Crec que això té més a veure amb el tipus de client que amb el tipus de projecte, però val la pena esmentar perquè les coses eren molt diferents.

Per al nostre client d'inici, establim un desplegament mitjançant Firebase i Wordpress (per a la part de contingut de l'aplicació).

El client empresarial tenia diferents requisits, tot es feia amb les eines / plataformes internes que tenien, teníem el codi font al nostre compte VSTS, però només mentre estàvem “en desenvolupament”.

Una vegada que vam tenir un llançament aprovat pel client, vam traslladar el codi font als seus propis dipòsits, on es gestionaven tot.

La conversa de diners

Costos

Com podeu imaginar, la conversa de diners va ser molt diferent per a tots dos clients.

El client d’inici tenia un equip aproximadament 1/3 de la mida del client empresarial que afecta molt els costos, a més, els processos i l’abast eren diferents.

Lliçons apreses

Com a empresa, crec que la lliçó més gran que vam aprendre d’aquests dos projectes és la diferència del nostre enfocament segons el tipus de client. Eines, comunicació, metodologia, etc.

Amb una nota més personal, vaig aprendre a mantenir una comunicació més constant i fluida amb els clients, hi va haver molts moments en què parlar coses junts ens van ajudar a bloquejar importants carreteres.

Què en penses, estàs en marxa de startup per arribar al mercat ràpid? O una empresa establerta que busca un soci tècnic?

No dubteu en posar-vos en contacte amb nosaltres, ens agradaria parlar de com podem ajudar-vos a arribar al mercat i fer que aquest projecte es pugui dur a terme.

Assoleix-me a mi o a Yuxi Global - [email protected] - si estàs passant per reptes similars a la teva organització i estàs buscant ajuda per crear el teu proper MVP o producte digital. Ens encanta un bon repte i sempre estem buscant maneres d’innovar amb vosaltres.