Hvis du aldri har vært med på å lage en app før, er det vanskelig å vite hva prosessen faktisk består av. Du vet hva du vil ha, men ikke hvilke beslutninger som venter, hvem du trenger, eller hvor pengene går.
Denne artikkelen går gjennom hele veien, i den rekkefølgen tingene faktisk skjer.
Begynn med problemet, ikke appen
Det første du trenger er ikke en idé til en app. Det er en tydelig beskrivelse av hva som er galt i dag.
Dette høres ut som en formalitet, men det er den halvtimen som sparer mest penger. Hvis problemet er at kundene ringer for å bestille time utenom åpningstid, så er det problemet. En app er én mulig løsning, en bookingside er en annen, og den er billigere.
Still tre spørsmål. 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 frustrasjon? Klarer du ikke å svare konkret på det siste, er det et tegn på at du bør vente.
Bestem hvem appen er for, helt konkret
En app for "kunder" eller "ansatte" 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 hender ledige? Er de på nett? Hvor mye tid har de? En app for en montør ute i felt skal se helt annerledes ut enn en for en saksbehandler ved skrivebordet, selv om de gjør det samme.
Dette er også stedet å faktisk snakke med noen. Fem samtaler på tjue minutter hver gir mer enn tre interne møter, og de avdekker nesten alltid at folk jobber litt annerledes enn du trodde.
Skill det nødvendige fra det ønskede
Nå kommer beslutningen som avgjør om prosjektet blir håndterbart.
Skriv ned alt appen kunne gjort. Gå så gjennom lista med ett spørsmål per punkt: kan den første brukeren få gjort jobben sin uten dette? Er svaret ja, skal det ut av første versjon.
De fleste blir overrasket over hvor lite som står igjen. Det er meningen. En første versjon skal løse ett problem helt, ikke ti problemer halvveis. Vi har skrevet mer om hvorfor i MVP-apputvikling.
Velg plattform etter hvordan den skal brukes
Nå gir det tekniske valget mening, fordi du vet hva appen skal gjøre.
Skal den brukes på mobil av folk som er på farten, og trenger den varsler, kamera eller å fungere uten nett, trenger du en app. For de aller fleste bygges den best som kryssplattform, altså én kodebase som dekker både iPhone og Android.
Skal den brukes ved en skjerm i arbeidstiden, er en webapplikasjon som regel raskere og rimeligere, og du slipper app-butikkene helt.
Native, altså to separate apper, er riktig når det er reelle ytelseskrav i bildet. Vi har gått gjennom avveiningen i native, hybrid eller webapp.
Hva som skjer bak appen
Nesten alle apper trenger noe på serversiden. Det er der data lagres, brukere autentiseres, og logikk som ikke hører hjemme på telefonen kjøres.
Du trenger ikke ha en mening om hvilken teknologi som brukes her, men du bør vite at valget påvirker to ting: hva det koster å drifte hver måned, og hvor lett det er å flytte løsningen til noen andre senere. Spør leverandøren om begge deler.
Det du bør ha en mening om, er hvor dataene lagres. Behandler appen personopplysninger, bør du vite hvilken region serverne står i og hva avtalen sier. Det er enkelt å avklare nå og tungt å endre senere.
Tegn det opp før noen koder
Med omfang og teknologi på plass lages 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 her tar minutter, mot dager i ferdig kode. Vis den til de samme personene du snakket med i starten, 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. Utviklerne slipper å gjette hva som var ment.
Under utviklingen
Be om å se noe som faktisk virker minst annenhver uke. Ikke statusrapporter. Det er først når du klikker på noe at du oppdager om det ble som du tenkte.
Sørg også for at én person hos dere kan ta beslutninger raskt. Ventetid på avklaringer er den vanligste enkeltårsaken til forsinkelse i prosjekter, og den koster ingenting å fjerne.
Skal appen bruke BankID eller Vipps, start de avtalene med én gang. De går ikke raskere av at koden er ferdig, og de har veltet flere tidsplaner enn tekniske problemer har.
Lansering
Appen skal inn i App Store og Google Play. Det krever utviklerkontoer, butikkoppføringer med tekst og skjermbilder, og for Apple en vurderingsprosess der hver innsending gjennomgås.
De vanligste grunnene til avvisning er mangelfull informasjon om hvilke data appen samler inn, og funksjonalitet som ikke lar seg teste uten en demokonto. Begge kan forebygges, men regn med at første innsending kan ta noen runder.
Tenk også gjennom hvordan folk skal finne appen. En app ingen laster ned, har samme verdi som ingen app. En nettside som forklarer hva appen gjør, er det vanligste og rimeligste tiltaket, og den kan i tillegg rangere i søk, noe innhold inne i en app aldri gjør.
Hva du trenger av folk
Fra din side trenger du én person som eier prosjektet og kan bestemme. Det er det viktigste enkeltbidraget.
Du trenger også noen som kan svare på hvordan arbeidet faktisk foregår i dag, og noen som kan teste underveis. Dette er reell arbeidstid som bør være med i planen.
Resten, altså design, utvikling, testing og lansering, er det leverandøren som gjør.
Hva det koster og hvor lang tid det tar
En enkel app for både iOS og Android, uten innlogging, ligger på 50 000 til 100 000 kroner med skreddersydd design inkludert. Trenger den innlogging og en backend, er nivået 80 000 til 300 000 avhengig av hvor mye funksjonalitet som skal med. Hver funksjon utover det koster sitt. Du kan sette sammen et anslag i priskalkulatoren, og lese mer i hva koster det å lage en app i Norge.
Regn to til tre måneder for en app med innlogging som skal gjøre noe reelt, og mer hvis den skal ha et web-panel eller snakke med systemer dere allerede har. Mer om det i hvor lang tid tar apputvikling.
Og sett av 10 til 20 prosent av utviklingskostnaden årlig til vedlikehold. Operativsystemene endrer seg hvert år enten du gjør noe eller ikke.
Neste steg
Du trenger ikke en kravspesifikasjon for å ta en første prat. Du trenger å kunne beskrive hvilket problem som skal løses og for hvem.
Har du det, ta kontakt. Vi sier fra hvis vi mener du er bedre tjent med noe enklere enn en app.