Appprosjekter feiler sjelden fordi teknologien ikke holdt mål. De feiler fordi det ble bygget feil ting, fordi beslutninger ble tatt for sent, eller fordi ingen hadde tenkt gjennom hva som skulle skje etter lansering.
Vi har sett de samme mønstrene gjenta seg hos både oppstartsselskaper og etablerte bedrifter. Her er de som koster mest.
Å bygge alt i første versjon
Dette er den dyreste feilen, og den vanligste. Prosjektet starter med en liste over alt appen skal kunne, lista godkjennes, og så bygges den i sin helhet før noen utenfor prosjektet får se noe.
Problemet er ikke at lista er feil. Problemet er at ingen vet om den er riktig før appen møter ekte brukere, og da har dere allerede brukt et år og hele budsjettet. Vi har sett prosjekter med førti funksjoner der brukerne endte opp med å bruke seks av dem regelmessig. De seks kunne vært bygget på tre måneder.
Det som virker i stedet, er å definere hva én bruker skal få gjort fra start til slutt, bygge akkurat det, og la resten vente til dere vet om det trengs. Det føles utilstrekkelig når dere planlegger, og det er nesten alltid riktig. Vi har skrevet mer om tankegangen i MVP-apputvikling.
Å hoppe over planleggingen fordi det haster
Den nest dyreste feilen ser ut som det motsatte av den første, men har samme rot. Når noe haster, føles det riktig å komme i gang med koding med én gang.
Konsekvensen er at beslutninger som burde vært tatt på et møte, tas underveis av den som tilfeldigvis står i det. Noen antar én ting, noen antar noe annet, og forskjellen oppdages når delene skal snakke sammen. Da bygges det om, og ombyggingen koster mer enn planleggingen ville gjort.
Det trengs ikke et tykt dokument. Det trengs at dere er enige om hvem appen er for, hva den skal løse, og hva som ikke er med i første versjon. Den siste er den viktigste og den som oftest mangler.
Å velge teknologi av prestisje
Native velges ofte fordi det oppfattes som det profesjonelle valget, ikke fordi prosjektet trenger det. Motsatt velges noen ganger den billigste løsningen uten at noen har vurdert om den holder.
Begge deler er samme feil: teknologien ble valgt før behovet var forstått. For en app som viser data, tar imot innspill og sender varsler, betyr valget mellom native og kryssplattform lite for brukeren og mye for budsjettet. For en app som behandler video i sanntid, er det motsatt.
Vi har gått gjennom avveiningen i detalj i native, hybrid eller webapp.
Å ikke snakke med dem som skal bruke appen
Mange appprosjekter baseres på hva ledelsen tror de ansatte eller kundene gjør. Det er sjelden helt feil, men det er nesten aldri helt riktig heller.
Den billigste korreksjonen finnes: vis en klikkbar prototype til fem personer fra målgruppen og be dem gjøre en oppgave uten hjelp. Tjue minutter per person avdekker som regel mer enn tre planleggingsmøter. Det som kommer fram er sjelden at konseptet er feil. Det er at et viktig valg ligger gjemt, at knappen heter noe folk ikke leter etter, eller at to steg står i motsatt rekkefølge av hvordan folk faktisk jobber.
Å glemme hva det koster å eie appen
Budsjettet settes for utviklingen, og så er det ikke satt av noe til året etterpå. Dette er den feilen som gir de ubehageligste overraskelsene, fordi den dukker opp når prosjektet er avsluttet og ingen føler eierskap til regningen.
Apple og Google gir ut nye versjoner av operativsystemene hvert år og krever jevnlig at apper bygges mot nyere versjoner for å bli værende i butikkene. Biblioteker må oppdateres av sikkerhetshensyn. Regn med 10 til 20 prosent av utviklingskostnaden årlig, pluss løpende driftskostnader for servere og databaser.
En app som ikke vedlikeholdes, forsvinner til slutt fra butikken. Da står dere med valget mellom en uforutsett regning og å miste produktet.
Å behandle personvern som en sjekkliste til slutt
Når appen er ferdig og noen spør hvor dataene lagres, er det for sent å svare elegant. Behandler løsningen personopplysninger, må det være tenkt inn i arkitekturen fra start.
I praksis er det tre spørsmål som må besvares tidlig: hvilke data trenger vi faktisk, hvor lagres de, og hvem har tilgang. Den vanligste feilen er å samle inn alt som er lett tilgjengelig fordi det kan bli nyttig senere. Det gir dere en forpliktelse uten tilsvarende verdi.
Bruker appen en ekstern AI-tjeneste, kommer spørsmålet om hvor den behandlingen skjer i tillegg. Det er raskt å avklare i planleggingen og tungt å rydde opp i etterpå.
Å tro at lansering er målstreken
Mange prosjekter er organisert som om lansering er slutten. Teamet oppløses, budsjettet er brukt opp, og så begynner brukerne å si hva de mener.
Det er nettopp da arbeidet blir verdifullt, fordi dere endelig endrer basert på hva folk gjør framfor hva dere trodde de ville gjøre. Sett av kapasitet til de første månedene etter lansering, og bestem på forhånd hvordan dere skal måle om appen faktisk brukes. Et tall dere følger med på er mer verdt enn en rapport ingen leser.
Det de vellykkede prosjektene har til felles
De starter mindre enn de vil, de viser noe som virker tidlig og ofte, og de har noen som har myndighet til å ta beslutninger raskt.
Det siste er undervurdert. Prosjekter der hver avklaring må gjennom flere ledd, taper uker på ting som kunne vært avgjort på en telefonsamtale. Utpek én person som kan bestemme, og gi den personen nok innsikt til å gjøre det.
Vil du diskutere et prosjekt med noen som har sett hvordan dette går både riktig og galt? Se hvordan vi jobber med apputvikling, få et grovt estimat i priskalkulatoren, eller ta kontakt.