Appen er lansert: Hvem tar seg av den nå?

Lanseringsdagen føles som målstreken, men for produktet er den startskuddet. Fra dag én begynner operativsystemer å bli oppdatert, avhengigheter å bli utdatert og brukere å finne ting som burde vært bedre. Spørsmålet er ikke om noen må ta seg av produktet, men hvem som skal gjøre det, hva det bør koste, og hvordan avtalen skal se ut.

Forvaltningens fire bestanddeler

• Feilretting. Feil som oppdages i produksjon, skal finnes, prioriteres og rettes, med tydelige forventninger til hvor raskt.
• Oppdateringer. Nye versjoner av operativsystemer, sikkerhetsoppdateringer, oppdaterte avhengigheter og tredjepartstjenester som endrer grensesnittene sine. Det usynlige arbeidet som holder produktet i live.
• Brukerstøtte. Noen som svarer når noe ser rart ut, tar imot meldinger om feil og kan skille brukerfeil fra faktiske feil.
• Mindre videreutvikling. Små forbedringer og justeringer som ikke rettferdiggjør et eget prosjekt, ofte håndtert via en timebank.

Grensen mellom forvaltning og videreutvikling er den vanligste kilden til misforståelser. En enkel tommelfingerregel: Forvaltning holder produktet i den stand det ble lansert i, videreutvikling gjør det bedre.

Drift er derimot en egen post utenfor forvaltningen: servere, domener og lisenser som koster penger selv om ingen rører produktet. Hold den adskilt fra forvaltningen i budsjettet, for det gjør både tilbud og fakturaer enklere å gå gjennom.

Hva koster forvaltningen per år?

En vanlig tommelfingerregel er 15–25 prosent av den opprinnelige utviklingskostnaden per år for ren forvaltning. Vil dere også utvikle produktet aktivt, kommer et budsjett for videreutvikling i tillegg, ofte 20–40 prosent av byggekostnaden per år. Som månedsavtale lander forvaltning typisk på 12 000–62 000 kr, avhengig av omfang og tjenestenivå.

Et konkret regneeksempel: En app som kostet 1,5 millioner kr å bygge, bør ha et forvaltningsbudsjett på omtrent 220 000–370 000 kr per år, altså 19 000–31 000 kr i måneden. Er appen forretningskritisk, med krav om beredskap utenfor arbeidstid, havner dere i den øvre delen, eller over.

Reaktiv forvaltning eller aktiv produktutvikling?

Reaktiv forvaltning betyr at noen rykker ut når noe går i stykker. Det er billigst på papiret, men produktet står stille, og den tekniske gjelden vokser ubemerket til en oppgradering blir et prosjekt i seg selv.

Aktiv produktutvikling betyr løpende kapasitet hver måned: Feil rettes, avhengigheter holdes oppdatert, og en prioritert backlog arbeides ned. Produktet blir bedre i takt med at dere lærer av brukerne.

Vår anbefaling er aldri å gå under nivået «reaktiv forvaltning med planlagt oppgraderingstakt». Er produktet viktig for forretningen, bør dere regne på den aktive modellen. Forskjellen merkes i hva produktet er verdt om tre år. Det finnes også mellomløsninger: Mange begynner reaktivt med kvartalsvise oppgraderingsvinduer og trapper opp når produktet har bevist verdien sin.

Deres egen rolle i forvaltningen

En forvaltningsavtale styrer seg ikke selv. Utpek en intern eier som prioriterer timebanken, samler tilbakemeldinger fra brukerne og tar beslutninger når leverandøren trenger svar. Uten den rollen går timebanken til det som tilfeldigvis roper høyest, og oppfølgingsmøtene blir en gjennomgang av gamle saker i stedet for en plan fremover. Regn med noen timer i uken. Det er den billigste kvalitetssikringen i hele opplegget.

Slik setter du opp avtalen

• Definer hva som inngår i månedsavgiften, og list opp eksempler på hva som ikke gjør det.
• Fastsett tjenestenivåer for responstid og frist for feilretting per alvorlighetsgrad, og skill nøye mellom de to begrepene.
• Reguler timebanken: størrelse, hva den kan brukes til, og om ubrukte timer overføres.
• Sikre eierskapet løpende: Dere skal eie kontoene, ha tilgang til koden og få dokumentasjonen oppdatert fortløpende, ikke bare ved avslutning.
• Bestem oppsigelsestid og avslutning: hva som overleveres, i hvilket format og til hvilken kostnad.

Bestem forvaltningen før lanseringen

Det beste tidspunktet for å sette opp forvaltningen er før produktet lanseres, mens kunnskapen er fersk og insentivene sunne. Vi i Weapp foretrekker at forvaltningsopplegget utarbeides som en del av utviklingsprosjektet, ikke som en ettertanke når noe allerede har rukket å gå i stykker. Vil dere ha hjelp til å finne et fornuftig nivå for produktet deres? Ta kontakt, så tenker vi gjennom det sammen.