MVP: ien luominen aloittaville ja yritysohjelmistoille (kokemuksemme)

Olen viimeisen vuoden aikana ollut onnekas olla mukana kehittämässä kaksi mobiilisovellusta kahdelle erilliselle asiakkaalle yrityksessämme.

Vaikkakin luonteeltaan samanlaiset, haasteet ja lähestymistapa vaihtelivat dramaattisesti toisistaan, ja halusin jakaa oppimiskokemukseni kanssasi ja löysini, missä jotkut omituisuuksista ja erotteluista Startup-yrityksen MVP: n rakentamisen ja suuren FinTech-yrityksen välillä.

Käynnistys

StartUp - haaste

Ensimmäinen haaste, joka annettiin minulle ja kollegoilleni, oli tehtävä rakentaa melko monimutkainen MVP yhdelle LATAMin suurimmista lentokentistä, jolla oli paljon liikkuvia osia reaaliaikaisten lentotietojen vetämisestä, tavaratalojen karttavisioista ja henkilökohtaisen suositusmoottorin avulla. monien muiden joukossa.

Tarkoituksena oli kapseloida todellinen täysin digitaalinen kokemus ja houkutella matkustajia yhden mobiilisovelluksen kautta ja poistaa käyttäjän tarve ladata useita sovelluksia ja vähentää hajallaan olevan tuotemerkin sitoutumista.

Iso yritys

ISV - haaste

Toinen meille heitetty haaste - ja tarkoitan parhaalla mahdollisella tavalla - oli suuri FinTech-yritys. Se on taloudellinen sovellus, johon sisältyy paljon toiminnallisuutta työskentelevä ihmisten rahoilla. Se oli myös jotain, jota useat pankit aikovat käyttää, joten kuten voitte kuvitella, kaikki oli erittäin vakavaa ja monimutkaista koko ajan.

Tänään haluan käyttää hetken aikaa jakaa kanssanne kokemuksemme, mutta lähinnä eron käynnistystä varten tarkoitetun MVP: n ja Enterprise Software ™: n rakentamisen välillä.

Jaamme sen eri luokkiin:

Takana olevat tekniikat

Tekninen pino

Epäilemättä käynnistys oli joustavampaa tässä suhteessa, he olivat avoimia ehdotuksille ja yrittivät innokkaasti kokeilla huipputeknologiaa myös silloin, kun siihen liittyi riski, kuten tuotteiden käyttäminen BETA-versiossa tuotantoon . Esimerkiksi, he halusivat käyttää Cloud Firestorea, vaikka se merkittiin silloin BETA: ksi.

Fintech-yritys oli ymmärrettävästi suljettu tekniikkapinoa varten, jota käyttäisimme. Jopa paketit, jotka meidän oli asennettava, piti käydä läpi perusteellinen tarkistusprosessi, niin heidän teknisen ryhmän kuin turvallisuusryhmänsäkin. Puhumattakaan siitä, että mitään sellaista, jolla heillä ei voisi olla 100-prosenttista omistusta, ei käsitelty.

Ryhmätyö

Joukkueen koko

En vieläkään ole varma siitä, vaikuttaako tuotetyyppi tähän, olen taipuvainen ajattelemaan, että se johtuu enemmän laajuudesta, mutta MVP: llä meillä oli 1 projektipäällikön, 2 kehittäjän ja 1 laadunvarmistajan ryhmä. Tiimissä ei ollut UX-ihmisiä, koska asiakkaalla oli jo mallit.

Enterprise-projektiryhmä oli paljon suurempi, meillä oli 1 projektipäällikkö, 6 kehittäjää, 2 laadunvarmistaja- ja 2 UX-asiantuntijaa.

Kuten sanoin, kyse on enemmän laajuudesta, MVP oli 2 kuukauden projekti, Enterprise Software oli vuoden mittainen sitoutuminen.

Nopeus

Kehitysnopeus

Tämä on näkökohta, jossa löysimme PALJON eroa, käynnistyksen tarvitaan päästäkseen markkinoille ASAP, joten keskityimme ottamaan käyttöön uusia toimintoja joka viikko.

Enterprise Software ™ -sovelluksissa asiat ovat erilaisia, meillä oli moniosainen prosessi koodin julkaisemiseen:

  • Aloitimme tiekarttaistunnolla, jossa analysoimme koko projektia ja määrittelimme ominaisuudet, joita rakentaa jokaisessa julkaisussa.
  • Perustimme kuukausittaisen julkaisun, jossa on 2 sprinttiä jokaisessa julkaisussa.
  • Jokaisen sprintin jälkeen ominaisuudet menivät QA-tiimillemme.
  • QA-sertifioinnin jälkeen loimme asentajan asiakkaan QA-tiimille.
  • Asiakkaan laadunvarmistuksen jälkeen ominaisuudet hyväksyttiin ja integroitiin projektiin. Tai heidät lähetettiin takaisin korjauksia varten.
QA

Laatuanalyytikot

Puhuin tästä vähän edellisessä kohdassa, mutta myös laadunvarmistuksessa oli joitain eroja. Esimerkiksi Startup-projektissa QA: lla oli enemmän sananvaltaa asioiden toimivuuteen ja siihen, mitä hän piti täytetyksi odotukseksi.

Yritysasiakkaalle QA-tiimimme varmensi ominaisuudet, mutta sen jälkeen oman QA-ryhmän oli varmennettava se ennen antamista siirtyäkseen integroimaan se projektin päähaaroon.

Design

UX / UI

Tämä on toinen osa, jossa prosessi oli paljon erilainen, kun käynnistysasiakas antoi heille mallit meille niiden toteuttamiseksi, ja se oli vähemmän tiukka prosessi.

Yritysasiakkaamme kanssa suunnittelu oli myös monivaiheinen prosessi:

  • UX-tiimimme loi ominaisuuden mallit seuraavaa sprinttiä varten.
  • Asiakkaan suunnitteluosasto hyväksyi mallit.
  • Asiakas lähetti hyväksytyt mallit käyttäjätestausta varten.
  • Asiakas lähetti mallit takaisin käyttäjien testeihin perustuvien muutosten toteuttamiseksi.
  • UX-tiimimme teki muutokset / korjaukset ja lähetti sitten mallit takaisin asiakkaalle.
käyttöönotto

käyttöönotto

Mielestäni tämän täytyy olla enemmän asiakastyypin kuin projektityypin suhteen, mutta se on mainitsemisen arvoinen, koska asiat olivat hyvin erilaisia.

Perustimme käynnistysasiakkaamme käyttöön Firebase- ja Wordpress-sovelluksilla (sovelluksen sisältöosaan).

Yritysasiakkaalla oli erilaisia ​​vaatimuksia, kaikki tehtiin sisäisillä työkaluilla / alustoilla, joita meillä oli. Meillä oli lähdekoodi VSTS-tilillämme, mutta vain "kehitystyössä".

Kun asiakas oli hyväksynyt julkaisun, siirrimme lähdekoodin omiin varastoihinsa, joissa he hoitivat kaiken.

Rahatalusta

kustannukset

Kuten voitte kuvitella, rahat -puhe oli hyvin erilaista molemmille asiakkaille.

Startup-asiakkaalla oli joukkue noin 1/3 yritysasiakkaan koosta, joka vaikuttaa paljon kustannuksiin, myös prosessit ja laajuus olivat erilaisia.

Opittua

Yrityksenä mielestäni molemmista hankkeista opittu suurin oppitunti on se, kuinka erilaisen lähestymistavan tulisi olla asiakkaan tyypistä riippuen. Työkalut, viestintä, metodologia jne.

Henkilökohtaisempana huomautuksena olen oppinut pitämään jatkuvampaa ja sujuvampaa viestintää asiakkaiden kanssa. Oli paljon hetkiä, kun asioiden puhuminen yhdessä auttoi meitä innokkaiden tukojen saavuttamisessa.

Mitä luulet, oletko Startup, joka haluaa päästä nopeasti markkinoille? Tai vakiintunut yritys, joka etsii teknistä kumppania?

Älä epäröi tavoittaa tavoitetta, haluaisimme puhua siitä, kuinka voimme auttaa sinua pääsemään markkinoille ja saamaan projektin läpi.

Ota yhteyttä minuun tai Yuxi Globaliin - [email protected] - jos olet kokenut samanlaisia ​​haasteita organisaatiossasi ja etsit apua seuraavan MVP: n tai digitaalisen tuotteen rakentamiseen. Rakastamme hyvää haastetta ja etsimme aina tapoja tehdä innovaatioita kanssasi.