Etter en del appprosjekter for norske bedrifter har vi sluttet å tro at det er teknologien som avgjør. De prosjektene som går bra og de som går dårlig bruker stort sett de samme verktøyene.
Forskjellen ligger et annet sted, og den er ganske forutsigbar når man har sett den noen ganger.
Det som kjennetegner prosjektene som lykkes
De starter mindre enn de vil. Dette er det tydeligste enkeltkjennetegnet. De som lykkes definerer én arbeidsflyt, bygger den ordentlig, og setter den i drift hos en liten gruppe før de utvider. De som sliter, bygger hele visjonen først og møter brukerne til slutt.
De har én person som kan bestemme. Ikke en styringsgruppe som møtes hver tredje uke, men en navngitt person med nok innsikt og myndighet til å svare på et spørsmål samme dag. Ventetid på avklaringer er den vanligste enkeltårsaken til forsinkelse i prosjektene vi ser, og den koster ingenting å fjerne.
De ser løsningen underveis. Ikke statusrapporter, men noe de kan klikke på annenhver uke. Det er først når folk tar på løsningen at de oppdager at de mente noe annet enn de sa, og det er en billig oppdagelse i uke tre.
Og de har bestemt på forhånd hvordan de skal måle om det virket. Ett tall, fulgt over tid. Uten det blir diskusjonen om videreutvikling en meningsutveksling framfor en beslutning.
De norske forutsetningene som faktisk betyr noe
Et appprosjekt i Norge har noen rammer som endrer både budsjett og tidsplan, og de er verdt å ta stilling til tidlig.
Skal brukerne identifiseres sikkert, forventer mange BankID. Skal de betale, forventer de Vipps. Begge krever avtaler med eksterne parter, begge har en ledetid dere ikke kontrollerer, og begge er småting i kravspesifikasjonen som kan bli det som avgjør når dere faktisk kan lansere. Start de prosessene i måned én, ikke når koden er ferdig.
Personvernreglene håndheves her, og Datatilsynet er en reell instans. Det viktigste grepet er å bestemme tidlig hvilke data dere faktisk trenger, framfor å samle inn alt som er lett tilgjengelig. Skal løsningen brukes av det offentlige, kommer universell utforming i tillegg som et absolutt krav, og en løsning som ikke oppfyller WCAG på nivå AA blir avvist uansett hvor god den ellers er.
Markedet er dessuten lite. Det betyr at inntektsmodeller som krever hundretusener av brukere sjelden er realistiske, og at de mest datatunge funksjonene ofte ikke har nok volum til å fungere. Til gjengjeld kan dere faktisk snakke med en meningsfull andel av målgruppen før dere bygger, og det er den billigste researchen som finnes.
Vi har gått grundigere gjennom disse rammene i slik planlegger du apputvikling i Norge.
Hvorfor prosjekter sporer av
Årsakene går igjen, og de er sjelden tekniske.
Den vanligste er at omfanget vokser uten at noe tas ut. Nye ønsker dukker opp underveis, de er ofte gode, og de legges til. Problemet er ikke ønskene, men at tidsplanen ikke justeres. Da er prosjektet forsinket lenge før noen merker det.
Den nest vanligste er at det bygges på antakelser om hvordan folk jobber. Ledelsen beskriver prosessen slik den er ment å være, og appen bygges etter den beskrivelsen. Så viser det seg at de ansatte har funnet en annen måte fordi den offisielle ikke fungerer i praksis.
Den tredje er at ingen eide prosjektet hos kunden. Når ansvaret er fordelt på flere som alle har det travelt med noe annet, stopper det opp på avklaringer.
Vi har samlet flere av disse i vanlige feil i apputvikling.
Hva du bør gjøre før du kontakter en leverandør
Du trenger ikke en kravspesifikasjon. Du trenger svar på tre ting.
Hvilken konkret oppgave skal løsningen gjøre raskere eller bedre, og hvor mye tid eller penger går med til den i dag? Et tall her gjør hele resten av samtalen enklere, og det avgjør om prosjektet i det hele tatt bærer seg.
Hvem skal bruke den, og hvor ofte? Daglig bruk av en kjent gruppe er det beste utgangspunktet som finnes.
Og hvem hos dere kan ta beslutninger underveis? Er svaret uklart, er det verdt å avklare før prosjektet starter.
Hva du bør spørre leverandøren om
Spør hvem som eier koden når prosjektet er over. Svaret bør være dere. Det er ikke en selvfølge i bransjen, og det er verdt å ha skriftlig.
Spør hvor ofte du får se noe som faktisk virker, og be om at svaret er minst annenhver uke.
Spør hva det koster å drifte og vedlikeholde løsningen i året etter lansering. En leverandør som ikke har tenkt på det, har heller ikke tenkt på hva som skjer med appen deres når operativsystemene endrer seg.
Og spør hva estimatet forutsetter. Ærlige estimater har forbehold knyttet til seg. Et tall uten forbehold betyr enten at noen ikke har tenkt gjennom det, eller at forbeholdene kommer senere, når de er blitt til forsinkelser.
Et realistisk utgangspunkt
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 et web-panel eller snakke med systemer dere allerede har. Budsjetter for utviklingen, og legg til 10 til 20 prosent årlig for vedlikehold.
Du finner et grovt kostnadsanslag for ditt eget prosjekt i priskalkulatoren, og en gjennomgang av hva som driver prisen i hva koster det å lage en app i Norge.
Vil du diskutere prosjektet deres med noen som har sett dette gå både riktig og galt? Se hvordan vi jobber med apputvikling, eller ta kontakt.