Webutvikling
Fra idé til første versjon: Slik avgrenser du en MVP
Skal du bygge app, system eller webtjeneste? Lær å avgrense en MVP med én viktig brukeroppgave, tydelige integrasjoner og kriterier for første lansering.
En MVP er en første, avgrenset versjon av et produkt som lar dere prøve den viktigste verdien i praksis. Den skal være brukbar for oppgaven den lover å løse, selv om mange mulige funksjoner kommer senere.
Hos MA Apps er avklaring av behov og omfang en viktig del av veien til nettsider, apper og systemer. Denne guiden viser hvordan vi anbefaler å tenke når en idé skal bli et konkret utviklingsprosjekt.
Start med oppgaven brukeren skal løse
Skriv ned hvem som skal bruke løsningen, hva personen prøver å oppnå, og hvordan oppgaven blir løst i dag. Et godt problemutsagn er konkret nok til at dere kan undersøke om den nye løsningen hjelper.
Tenk deg en servicebedrift der ansatte sender bilder og notater på e-post etter et kundebesøk. En første versjon kan gjøre det mulig å velge oppdrag, registrere arbeidet og sende en samlet rapport. En omfattende kundeportal kan vente hvis den ikke er nødvendig for å prøve denne arbeidsflyten.
Skill nødvendig funksjonalitet fra gode ideer
Gå gjennom hele brukeroppgaven og marker hvilke steg som må være med. En funksjon hører hjemme i første versjon når oppgaven ikke kan fullføres forsvarlig uten den. Resten kan vurderes når dere har erfaring fra bruk.
Unngå å kutte bort viktige kvaliteter bare for å korte ned listen. Tilgangsstyring, forståelige feilmeldinger og håndtering av data kan være nødvendige deler av den første løsningen. Mindre omfang betyr færre oppgaver å støtte, ikke at de viktigste oppgavene skal fungere dårlig.
Vurder webapp før dere bestemmer dere for mobilapp
Valget mellom nettside, webapp og mobilapp bør følge behovet. Undersøk hvor brukerne jobber, hvilke enheter de bruker, og om oppgaven krever telefonfunksjoner eller bruk uten stabil nettilgang. Avklar også hvordan løsningen skal distribueres og oppdateres.
MA Apps arbeider med både web og mobil. Det gjør det mulig å vurdere alternativene før teknologivalget låses. En kort beskrivelse av brukssituasjonen er et bedre grunnlag for samtalen enn å bestemme plattform bare fordi den er kjent.
Kartlegg dataflyten før dere bestiller integrasjoner
En funksjonsliste sier lite om hvor data kommer fra. Noter hvilke systemer som allerede har kunder, ordre eller produkter, og hvilket system som skal eie informasjonen videre. Avklar tilganger og kontaktpersoner før dere legger tidsplanen.
MA Apps beskriver integrasjoner som koblinger mellom blant annet CRM, økonomi og interne verktøy, med vekt på feilhåndtering og dokumentasjon. I deres prosjekt bør det også være tydelig hva brukeren ser dersom en overføring feiler, og hvem som følger opp avviket.
Kilde: MA Apps: API-integrasjoner
Bestem hva som må være sant før dere lanserer
Lag noen få konkrete akseptansekriterier for hovedoppgaven. I serviceeksempelet kan det være at riktig ansatt får tilgang til oppdraget, kan sende rapporten og får en tydelig bekreftelse. La reelle brukere prøve arbeidsflyten med representative data.
Avklar samtidig hvem som tar imot spørsmål, retter feil og bestiller endringer. Dokumentasjon og drift er del av et brukbart produkt. Det blir enklere å ta løsningen i bruk når ansvar og kontaktveier er tydelige.
Bruk erfaringen før funksjonslisten vokser
Avtal hva dere vil undersøke etter første lansering. Klarer brukeren å fullføre oppgaven? Hvor oppstår det spørsmål? Hvilke manuelle steg gjenstår? Kombiner observasjoner med tilbakemeldinger fra dem som bruker løsningen.
Prioriter neste versjon ut fra den viktigste hindringen dere faktisk har sett. Noen ganger er det en ny funksjon. Andre ganger er det en enklere tekst, bedre opplæring eller en mer pålitelig integrasjon. En god MVP gir et bedre grunnlag for denne beslutningen.
Spørsmål og svar
Er en MVP det samme som en prototype?
En prototype brukes ofte til å utforske og prøve et konsept før full utvikling. En MVP er en avgrenset løsning som kan brukes til den valgte oppgaven. Hva som faktisk leveres, bør beskrives tydelig i avtalen.
Kan vi få fast pris på første versjon?
Et konkret omfang og avklarte avhengigheter gir et bedre grunnlag for prising. Integrasjoner, usikre krav og endringer må være synlige i tilbudet før dere bestemmer leveransemodell.
Kilder og videre lesning
Fra innsikt til noe som virker.
Ta en prat med oss om hva bedriften din trenger, og hvor det er fornuftig å starte.
Utforsk utvikling med MA Apps