Spørsmålet kommer i nesten hvert første møte, og det fortjener et ærligere svar enn et tall.
En enkel app som lagrer data lokalt og ikke har innlogging, kan være klar på tre til fem uker. En app med innlogging og backend, som er det de fleste bedrifter trenger, tar typisk seks til fjorten uker, avhengig av hvor mye som skal med. Skal appen ha et tilhørende web-panel, dekke flere brukerroller eller integrere mot eksisterende fagsystemer, snakker vi tre til seks måneder, av og til mer.
Disse tallene forutsetter noe som ofte ikke stemmer: at dere vet hva som skal bygges, og at beslutninger tas raskt underveis.
Hvor tiden faktisk går
Folk flest antar at utvikling er den store posten. I praksis fordeler tiden seg jevnere enn som så.
Selve programmeringen utgjør sjelden mer enn halvparten. Før den kommer avklaring og design, som på et prosjekt av normal størrelse tar tre til seks uker. Etter den kommer testing, retting, klargjøring for produksjon og selve lanseringen, som til sammen tar mer tid enn de fleste setter av.
Det er verdt å merke seg at testing ikke er en fase på slutten hos oss, men noe som skjer kontinuerlig. Prosjekter som utsetter all testing til slutten, får en hale av feilretting som er umulig å estimere, fordi ingen vet hva som venter der.
Det som forsinker prosjekter i praksis
Etter en del prosjekter er mønsteret ganske tydelig, og det handler sjelden om utviklingshastighet.
Den vanligste forsinkelsen er ventetid på avklaringer. Utvikleren trenger et svar for å gå videre, spørsmålet sendes, og så tar det fire dager før noen med myndighet svarer. Gjentar det seg ti ganger i løpet av et prosjekt, har dere mistet et par uker uten at noen har gjort noe galt. Det enkleste tiltaket i hele prosjektet er å utpeke én person som kan bestemme, og gi den personen nok innsikt til å gjøre det raskt.
Den nest vanligste er endringer i omfang. Nye ønsker dukker opp underveis, og de er ofte gode. Problemet er når de legges til uten at noe annet tas ut, og uten at tidsplanen justeres. Da er prosjektet forsinket allerede før noen merker det.
Så er det tredjeparter. Skal appen bruke BankID, Vipps eller koble seg mot et eksisterende fagsystem, er dere avhengige av avtaler, tilganger og dokumentasjon dere ikke kontrollerer selv. Vi har sett prosjekter vente flere uker på en testkonto. Start de prosessene først, ikke sist.
Til slutt kommer app-butikkene. Apple gjennomgår hver innsending, og selv om det ofte går raskt, kan en avvisning koste dager. De vanligste grunnene er mangelfull informasjon om personvern og funksjonalitet som ikke lar seg teste uten en demokonto. Begge kan forebygges.
Hva som faktisk gjør prosjekter raskere
Det mest effektive er å redusere hva som skal bygges. Ingen prosessforbedring slår det. En app med halvparten så mange funksjoner tar omtrent halvparten så lang tid, og du finner ut om de resterende faktisk trengs mens den første halvparten er i bruk.
Deretter kommer forarbeidet. En klikkbar prototype fjerner en hel klasse med diskusjoner fra utviklingsfasen, fordi spørsmål som ellers ville dukket opp underveis allerede er avgjort. Det ser ut som tid brukt før prosjektet starter, og er i praksis tid spart.
Og så er det tempo i tilbakemeldinger. Prosjekter der kunden ser noe som virker hver uke og sier fra med én gang, går raskere enn prosjekter med månedlige statusmøter. Ikke fordi det jobbes fortere, men fordi feil oppdages mens de er billige å rette.
Om AI har gjort utvikling raskere
Noe, men mindre enn overskriftene antyder.
Kodeassistenter gjør erfarne utviklere merkbart raskere på rutinearbeid, og det merkes særlig på prosjekter med mye standardfunksjonalitet. Men koding er som nevnt bare en del av løpet. De delene som tar tid, som å bli enige om hva som skal bygges, teste med ekte brukere og få løsningen gjennom app-butikkene, går ikke fortere av bedre verktøy.
Der vi ser reell gevinst, er på testdekning og på det kjedelige arbeidet rundt oppsett. Det er verdifullt, og det er en del av grunnen til at enkle apper leveres raskere enn før, men det flytter ikke et sammensatt prosjekt fra seks måneder til to.
Hva du bør spørre en leverandør om
Be om en tidsplan som viser faser, ikke bare en sluttdato. En dato uten noe imellom gir deg ingen mulighet til å oppdage at prosjektet sklir før det er for sent.
Spør hvor ofte du får se noe som faktisk virker. Svaret bør være minst annenhver uke. Får du bare statusrapporter, vet du ikke hvordan det går.
Spør også hva estimatet forutsetter. Et ærlig estimat har forutsetninger knyttet til seg, som at innholdet leveres til avtalt tid eller at tilgang til et system er på plass innen en gitt dato. En leverandør som oppgir en dato uten forbehold, har enten ikke tenkt gjennom det eller kommer til å presentere forbeholdene senere, når de er blitt til forsinkelser.
Et realistisk utgangspunkt
Hvis du trenger et tall å planlegge etter før du har snakket med noen: regn to til tre måneder for en app med innlogging som skal gjøre noe reelt for en bedrift, og legg til tid hvis den skal ha web-panel eller snakke med systemer dere allerede har.
Vil du ha et konkret anslag for ditt eget prosjekt, får du et grovt estimat i priskalkulatoren, og en gjennomgang av kostnadene i hva koster det å lage en app i Norge. Eller ta kontakt, så gir vi deg en vurdering basert på hva appen faktisk skal gjøre.