De fleste gode appideer dør ikke fordi ideen var dårlig. De dør fordi prosjektet ble for stort, tok for lang tid, og mistet oppslutning internt før noe kom ut til brukerne.
Veien fra idé til en første fungerende versjon handler derfor mindre om å planlegge alt, og mer om å avklare de få tingene som faktisk bestemmer hva som skal bygges. Her er stegene, i den rekkefølgen de gir mening.
Start med problemet, ikke løsningen
Det første steget er å beskrive hva som er galt i dag, uten å nevne en app.
Det høres ut som en akademisk øvelse, men det er den mest verdifulle halvtimen i hele prosjektet. Hvis problemet er at selgerne bruker to timer i uka på å føre timer manuelt, så er det problemet. En app er én mulig løsning. Et bedre skjema i systemet dere allerede har, kan være en annen, og den er billigere.
Still tre spørsmål og vær ærlig om svarene. Hva gjør folk i dag for å løse dette? Hvorfor er det ikke godt nok? Og hva koster det dem, i tid, penger eller irritasjon? Kan dere ikke svare konkret på det siste, er det et tegn på at problemet ikke er stort nok til å forsvare et utviklingsprosjekt ennå.
Bli konkret om hvem appen er for
En app for "alle ansatte" eller "kunder generelt" blir sjelden god for noen.
Velg én type bruker og beskriv en vanlig dag for dem. Hvor er de når de skal bruke appen? Har de begge hendene ledige? Er de på nett? Hvor mye tid har de? En app som brukes av en montør ute i felt med hansker på, skal se helt annerledes ut enn en som brukes av en saksbehandler ved skrivebordet, selv om funksjonaliteten er den samme.
Dette er også stedet å snakke med noen faktiske brukere. Fem samtaler på tjue minutter hver gir mer enn tre interne møter, og de avdekker nesten alltid at folk jobber litt annerledes enn ledelsen tror.
Skill det nødvendige fra det ønskede
Nå kommer den delen som avgjør om prosjektet blir håndterbart.
Skriv ned alt appen kunne gjort. Gå så gjennom lista med ett spørsmål for hvert punkt: kan den første brukeren få gjort jobben sin uten dette? Er svaret ja, skal det ut av første versjon. Ikke slettet, bare flyttet til en liste over ting som vurderes senere.
De fleste blir overrasket over hvor lite som står igjen, og det er hele poenget. En MVP er ikke en halvferdig app. Det er en komplett løsning på et lite avgrenset problem. Forskjellen er viktig: brukeren skal kunne gjøre noe nyttig fra start til slutt, ikke oppleve en app der halvparten av knappene ikke virker ennå.
Vi har skrevet mer om hvorfor dette lønner seg i MVP-apputvikling.
Tegn det opp før noen koder
Med omfanget avklart lager dere en klikkbar prototype. Den ser ut som den ferdige appen og kan navigeres, men har ingenting bak seg.
Dette er det billigste stedet å ta feil. En endring i prototypen tar minutter. Den samme endringen etter at databasen er satt opp og skjermbildene er bygget, tar dager. Vis prototypen til de samme brukerne dere snakket med, gi dem en oppgave, og la dem prøve uten hjelp. Det de sliter med her, ville de slitt med i den ferdige appen.
Prototypen fungerer også som spesifikasjon når utviklingen starter. Utviklerne slipper å gjette hva som var ment, fordi de kan klikke seg gjennom det selv.
Velg teknologi etter behovet, ikke omvendt
Først nå gir teknologivalget mening, fordi dere vet hva løsningen skal gjøre.
For de fleste forretningsapper er kryssplattform riktig, fordi du får både iOS og Android fra én kodebase. Skal løsningen brukes ved en skjerm i arbeidstiden, er en webapplikasjon ofte både raskere og rimeligere. Native er riktig når appen har reelle ytelseskrav eller skal ligge tett på maskinvaren.
Avveiningen er gjennomgått i native, hybrid eller webapp.
Planlegg utviklingen slik at dere ser noe hele veien
Del arbeidet opp i korte perioder der det leveres noe som faktisk virker ved slutten av hver. To uker er en vanlig lengde og fungerer bra.
Det viktige er ikke metodikken, men at dere ser løsningen underveis framfor å lese statusrapporter. Å klikke på noe utløser reaksjoner som en beskrivelse aldri gjør. Kunder ser jevnlig noe vi har bygget nøyaktig etter spesifikasjonen og sier at det ikke var det de mente. Det er en god ting når det skjer i uke tre.
Sørg også for at én person hos dere kan ta beslutninger raskt. Ventetid på avklaringer er den vanligste enkeltårsaken til forsinkelse, og den er gratis å fjerne.
Tenk gjennom lanseringen før dere trenger den
App-butikkene tar tid, og de tar mer tid første gang. Utviklerkontoer skal opprettes, butikkoppføringer med tekst og skjermbilder skal lages, og Apple gjennomgår hver innsending.
Trenger appen BankID eller Vipps, må de avtalene startes tidlig. De går ikke raskere av at koden er ferdig, og vi har sett prosjekter vente flere uker på noe som kunne vært bestilt i måned én.
Regn med at arbeidet fortsetter
Lansering er ikke målstreken. Det er første gang dere får vite hva brukerne faktisk gjør, framfor hva dere trodde de ville gjøre.
Sett av kapasitet til månedene etter, og bestem på forhånd hvordan dere måler om appen brukes. Ett tall dere følger med på er mer verdt enn en rapport ingen åpner. Sett også av budsjett til vedlikehold, typisk 10 til 20 prosent av utviklingskostnaden i året, fordi operativsystemene endrer seg enten dere gjør det eller ikke.
Vil du ha hjelp til å gå gjennom dette for din egen idé? Se hvordan vi jobber med apputvikling, regn på omfanget i priskalkulatoren, eller ta kontakt for en uforpliktende prat.