Starterite ja ettevõtlustarkvara jaoks MVP-de loomine (meie kogemus)

Viimase aasta jooksul on mul olnud õnn osaleda meie ettevõttes kahe mobiilirakenduse arendamisel kahele erinevale kliendile.

Ehkki olemuselt sarnased, erinesid igaühe väljakutsed ja lähenemisviis üksteisest drastiliselt ning tahtsin jagada teiega oma õppimiskogemusi ning seda, mida ma leidsin, kus on mõned seigad ja erinevused Startupi MVP ja suure FinTechi ettevõtte vahel.

Käivitamine

StartUp - väljakutse

Meie esimene väljakutse, mis mulle ja mu kolleegidele anti, oli ülesanne ehitada üsna keerukas MVP LATAMi ühe suurima lennujaama jaoks, kus oli palju liikuvaid detaile, alates reaalajas lendude andmete kogumisest, kaubamajade visuaalsetest kuvadest ja isikupärastatud soovituste mootorist. paljude teiste seas.

Selle eesmärk oli kapseldada tõeline täielikult digitaalne kogemus ja kaasata reisijad ühe mobiilirakenduse kaudu ning välistada kasutaja vajadus alla laadida mitu rakendust ja vähendada hajutatud kaubamärgi seotust.

Suurettevõte

ISV - väljakutse

Teine väljakutse, mis meile heideti - ja ma mõtlen seda parimal viisil - oli suure FinTechi ettevõtte jaoks. See on finantsrakendus, see hõlmab inimeste raha teenimiseks palju funktsioone. See oli ka asi, mida mitu panka kavatses kasutada, nii et nagu võite ette kujutada, oli kõik kogu aeg väga tõsine ja keeruline.

Täna soovin võtta aega, et jagada teiega oma kogemusi, kuid peamiselt erinevust alustamiseks mõeldud MVP ja Enterprise Software ™ ehitamise vahel.

Jagame selle erinevatesse kategooriatesse:

Selle taga olevad tehnoloogiad

Tech Stack

Kahtlemata oli käivitamine selles osas paindlikum, nad olid avatud ettepanekutele ja proovisid innukalt tipptehnoloogiaid ka siis, kui sellega kaasnes risk nagu näiteks toodete tootmiseks BETA versioonis . Näiteks soovisid nad kasutada Cloud Firestore'i, isegi kui see oli toona tähistatud kui BETA.

Fintechi ettevõte oli arusaadavalt suletum tehnoloogiapakkumise osas, mida me kasutaksime. Isegi meie installitud paketid pidid läbima põhjaliku läbivaatusprotsessi nii nende tehnilise meeskonna kui ka turvameeskonna poolt. Rääkimata sellest, et miski, mis neil 100-protsendiliselt kuuluda ei saaks, oli välistatud.

Meeskonnatöö

Meeskonna suurus

Ma ei ole ikka veel kindel, kas seda mõjutab toote tüüp, kaldun arvama, et see on pigem ulatuse tõttu, kuid MVP jaoks oli meil meeskond, kuhu kuulus 1 projektijuht, 2 arendajat ja 1 QA. UX-i inimesi meeskonnas ei olnud, kuna kliendil olid juba oma kujundused.

Ettevõtluse projekti meeskond oli palju suurem, meil oli 1 projektijuht, 6 arendajat, 2 kvaliteedi tagamise ja 2 UX eksperti.

Nagu ma ütlesin, puudutab see rohkem ulatust, MVP oli 2-kuuline projekt, ettevõtte tarkvara oli aasta pikkune töövõtt.

Kiirus

Arengukiirus

See on aspekt, kus leidsime palju erinevusi, ASAP-i turule pääsemiseks oli vaja käivitust, nii et olime keskendunud iga nädala uute funktsioonide juurutamisele.

Enterprise Software ™ puhul on asjad erinevad, meil oli koodi vabastamiseks mitmeosaline protsess:

  • Alustasime teekaardisessiooniga, kus analüüsisime kogu projekti ja määratlesime funktsioonid, mida igas versioonis ehitada.
  • Seadsime sisse igakuise väljalaske, kus igas väljalaskes on 2 sprinti.
  • Pärast iga sprinti läksid omadused meie QA meeskonnale.
  • Pärast QA sertifitseerimist lõime kliendi QA meeskonna jaoks paigaldaja.
  • Pärast kliendi kvaliteedikontrolli sertifitseerimist kinnitati ja integreeriti funktsioonid projekti. Või saadeti nad parandusteks tagasi.
QA

Kvaliteedianalüütikud

Rääkisin sellest eelmises punktis pisut, kuid kvaliteedi tagamisel oli ka mõningaid erinevusi. Näiteks Startup projekti puhul oli meie QA-l rohkem sõnaõigust selles osas, kuidas asjad toimisid ja mida ta pidas täidetud ootuseks.

Ettevõtluskliendi jaoks sertifitseeris meie kvaliteedikontrolli meeskond funktsioone, kuid pärast seda pidi nende enda kvaliteedikontrolli meeskond selle enne projekti alustamiseks integreerima, enne kui asus minema.

Kujundus

UX / UI

See on veel üks osa, kus protsess oli PALJU erinev, stardikliendiga andsid nad meile kavandid meile nende rakendamiseks ja see oli vähem range protsess.

Meie ettevõtte kliendi juures oli disain ka mitmeastmeline protsess:

  • Meie UX-meeskond lõi funktsiooni kavandid järgmiseks sprindiks.
  • Kliendi disainiosakond kiitis kavandid heaks.
  • Klient saatis kasutaja testimiseks kinnitatud kavandid.
  • Klient saatis disainilahendused kasutaja muudatuste põhjal muudatuste tegemiseks tagasi.
  • Meie UX-i meeskond tegi muudatused / parandused ja saadab kujunduse seejärel kliendile tagasi.
Kasutuselevõtt

Kasutuselevõtt

Arvan, et see peab olema rohkem seotud kliendi tüübi kui projekti tüübiga, kuid seda tasub mainida, sest asjad olid väga erinevad.

Oma käivituskliendi jaoks seadistasime juurutuse Firebase'i ja Wordpressi abil (rakenduse sisuosa jaoks).

Ettevõttekliendil olid erinevad nõuded, see kõik tehti sisemiste tööriistade / platvormidega, mis meil olid, ja VSTS-i kontol oli lähtekood, kuid ainult siis, kui me olime arendamisel.

Kui kliendi poolt oli kinnitatud väljaanne, kolisime lähtekoodi nende enda hoidlatesse, kus nad käitusid kõigega.

Rahajutt

Kulud

Nagu võite ette kujutada, oli raha jutt mõlema kliendi jaoks väga erinev.

Alustava kliendi meeskond oli umbes 1/3 ettevõtte kliendi suurusest, mis mõjutab kulusid palju, ka protsessid ja ulatus olid erinevad.

Õppetunnid

Ettevõttena arvan, et suurim õppetund, mille mõlemast projektist õppisime, on see, kui erinev peaks olema meie lähenemisviis sõltuvalt kliendi tüübist. Tööriistad, kommunikatsioon, metoodika jne.

Isiklikumaks märkuseks õppisin klientidega pidevamat ja sujuvamat suhtlust. Oli palju hetki, kui koos räägitud asjad aitasid meil suuremate takistuste poole.

Mis te arvate, kas olete Startup, kes soovib kiiresti turule jõuda? Või asutatud ettevõte, kes otsib tehnilist partnerit?

Ärge kõhelge kõndimast, vaid tahaksime rääkida sellest, kuidas saaksime teid turule tuua ja projekti ellu viia.

Pöörduge minu või Yuxi Globaalse poole - [email protected] - kui olete oma organisatsioonis läbimas sarnaseid väljakutseid ja otsite abi oma järgmise MVP või digitaalse toote loomisel. Armastame head väljakutset ja otsime alati võimalusi, kuidas teiega uuendusi teha.