«Hva koster en MVP?» er et av de første spørsmålene gründere stiller, og det ærlige svaret er at det avhenger av beslutninger dere ennå ikke har tatt. To produkter som høres like ut, kan skille seg flere ganger i innsats på grunn av plattformer, integrasjoner eller datakrav. I stedet for å oppgi prisintervaller forklarer denne guiden faktorene som driver kostnad, omfang og innsats i MVP-utvikling, slik at dere kan ta valg som holder den første versjonen fokusert, og sammenligne tilbud på et rettferdig grunnlag.
Hva det er
Innsatsen i en MVP drives av hvor mye som må designes, bygges, integreres, testes og overleveres. De viktigste faktorene er: antall ulike brukerroller og kjerneløp; plattformer (web, iOS, Android eller en plattformuavhengig tilnærming); om backend er spesialutviklet eller bruker en administrert tjeneste; integrasjoner med betaling, identitet, meldinger, CRM eller bransjesystemer; databehov som migrering, rapportering eller filhåndtering; krav til sikkerhet og personvern, inkludert autentisering, tillatelser og behandling av personopplysninger; designnivå, fra funksjonelle skjermbilder til en gjennomarbeidet merkevareopplevelse; forventninger til kvalitet og testdekning; utrulling, innsending til appbutikker og oppsett av miljøer; og overleveringen teamet trenger for å drifte og videreutvikle produktet. Usikkerhet er i seg selv en faktor: når kravene er uklare, inneholder estimatene mer reserve, eller omfanget endres under leveransen.
Hvem det er for
Denne guiden hjelper:
- Gründere som forbereder en bestilling eller sammenligner tilbud fra utviklingspartnere
- Produktledere som skal forsvare et fokusert omfang overfor interessenter
- Selskaper som for første gang planlegger et internt verktøy eller en kunderettet app
- Team som har fått estimater som spriker mye, og vil forstå hvorfor
Hva det hjelper med å klarlegge
Å forstå faktorene bidrar til å avklare:
- Hvilke funksjoner som hører hjemme i første versjon, og hvilke som kan vente
- Om én plattform er nok til å lære det dere trenger
- Hvilke integrasjoner som er nødvendige, og hvilke som kan være manuelle inntil videre
- Hvilke antakelser i et tilbud som driver mesteparten av innsatsen
Hva er inkludert
- Skriv produktets kjerneverdi i én setning, og list bare opp løpene som leverer den
- Tell brukerroller; hver av dem legger til skjermbilder, tillatelser og testing
- Velg én plattform først, med mindre brukerne tydelig trenger flere
- List opp integrasjoner og merk hver som nødvendig, utsettbar eller mulig å erstatte med et manuelt steg
- Avgjør om en administrert backend er tilstrekkelig for første versjon
- Identifiser personopplysninger eller sensitive data og beskyttelsen de trenger
- Avtal et designnivå som passer målgruppen og fasen dere er i
- Definer akseptansekriterier og hvilken testing som forventes
- Avklar hvem som eier driftskontoer, kodelagre og oppføringer i appbutikker
- Planlegg overleveringen: dokumentasjon, overføring av tilganger og støtte etter levering
Hva er ikke inkludert
- Budsjettintervaller eller faste tall; innsatsen avhenger av bekreftet omfang
- En påstand om at et mindre omfang sikrer adopsjon eller suksess
- Løpende funksjonsutvikling utover den avtalte første versjonen
- Kostnader til tredjepartslisenser, drift eller transaksjoner, som bekreftes separat
Når skal den velges
Bruk denne guiden før dere ber om tilbud, slik at bestillingen besvarer spørsmålene som driver innsatsen. Den er også nyttig når dere sammenligner tilbud: spør hver leverandør hvilke antakelser de har gjort om plattformer, integrasjoner og data, fordi forskjeller der vanligvis forklarer forskjeller i estimatene. Hvis flere faktorer fortsatt er ukjente, er en kort plan- eller kartleggingsfase ofte en fornuftig investering før dere forplikter dere til en full utvikling.
Vår tilnærming
Den mest pålitelige måten å styre innsatsen på er å redusere usikkerhet og omfang før utviklingen starter. Definer kjerneløpene, det minste nyttige funksjonssettet, de nødvendige integrasjonene og sikkerhetsbaselinen. Be deretter om et skriftlig omfang som angir hva som er inkludert, hva som er utelatt, og hvilke antakelser som gjelder. Tjenesten vår App MVP Sprint leverer en avgrenset første versjon med leveransedokumentasjon og overleveringsmateriell; omfang og kommersielle vilkår bekreftes skriftlig før arbeidet starter. Der backend eller integrasjoner er omfattende, kan Secure Backend & API Engineering avgrenses parallelt. Hvis produktet ennå ikke er tilstrekkelig definert til å estimeres med trygghet, kan et oppdrag av typen Product Blueprint & Scope gi brukerne, flytene, funksjonene og avhengighetene som trengs for et fastere tilbud.
Ofte stilte spørsmål
Beslektede artikler
Kom i gang
Vil dere ha et tydelig, skriftlig MVP-omfang?
Fortell oss om ideen, brukerne, plattformene og integrasjonene. Vi hjelper dere med å definere en fokusert første versjon og bekrefter omfanget skriftlig.
Be om et skriftlig omfang