Bilde av artikkelforfatter

Det er flere årsaker til at begrepet er utdatert. Først og fremst fordi det legges ulikt innhold i hva det innebærer. Det skaper problemer både for oss som leverandør og deg som har ansvaret for en nettløsning.

Hva så med begrepet "support?"

I mitt hode er det begrepet mer knyttet til et produkt, og ikke en tjeneste. Support gis av leverandøren av selve CMS-et, det som løsningen bygges på. Tjenesteleverandøren som bruker produktet til å bygge løsningen din, driver derimot med vedlikehold og utvikling.

For oss som jobber med forvaltning i Epinova er det i hovedsak fire oppgavetyper vi jobber med:

  • Feilretting - løpende retting av feil og bugs
  • Endringer - behov som oppdages i etterkant basert på brukeratferd, egne behov, regelverk og standarder mm
  • Ny funksjonalitet - ønsker eller behov som dukker opp i etterkant eller som prosjektet ikke hadde tid/penger til
  • Oppdateringer - nødvendige oppdateringer f.eks. som følge av nye versjoner av moduler, integrasjoner, rammeverk, sikkerhetshull mm

Webutvikling før og nå – grunnen til at begrepet forvaltning er utdatert

Det har skjedd en endring i hvordan vi jobber med webutvikling de 10-20 siste årene. Tidligere satte man av en pott med penger til et prosjekt for å få opp en helt ny nettløsning, men man glemte ofte å sette av penger til arbeid med løsningen etter lansering. De fleste web-prosjekter hadde også en klar begynnelse og slutt. De fleste anså seg som helt ferdig etter lansering og en kort påfølgende stabiliseringsperiode.

Den lille forvaltningen som skjedde, ble ofte utført av de samme ressursene som var i prosjektet. Problemet var at de ofte hadde beveget seg over i et annet prosjekt. Oppfattelsen var at forvaltning i hovedsak var "å rette tekniske feil".

Raskere utvikling krever nye arbeidsmetoder

Utviklingen har de siste årene ført med seg en helt annen type arbeid med nettløsninger. De store nyutviklingsprosjektene har en start, men som regel ikke noen klar slutt. De mest tydelige eksemplene på dette er MVP-er (Minimum Viable Product) og Growth Driven Design-prosesser. I hovedsak bygges da en minimumsløsning som dekker det mest nødvendige behovet. Deretter fortsetter utvikling fortløpende i tråd med ønsker og behov. Det kan være markedet, organisasjonen, tekniske fremskritt eller brukeradferd som styrer retningen og tempo.

En av hovedgrunnene til endringen i måten å jobbe på, er at utviklingen går fryktelig mye fortere i dag enn for 20 år siden. Med de gamle måtene å jobbe frem løsninger er det stor fare for å lansere en allerede utdatert løsning.

Videreutvikling og vedlikehold

Begrepet "forvaltning" er alt for tett knyttet til den gamle verden. Forvaltning som i hovedsak inkluderer bugfix og mindre justeringer får konsekvens at budsjettet blir deretter. Mange glemmer å sette av nok penger til både løpende nyutvikling og andre nødvendige vedlikeholdsoppgaver. Dette fører til både misfornøyde interne bestillere samt etterslep på oppgradering og annet teknisk vedlikehold (også kalt teknisk gjeld).

Jeg tror begrepet "forvaltning" må ta en del av skylden for dette. Forvaltning høres ikke spesielt proaktivt og spennende ut, eller som noe ledelse eller andre involverte ønsker å bruke mye penger på.

Jeg mener derfor at vi heller bør kalle det «Videreutvikling og Vedlikehold». Det er mer dekkende og blir straks mer selvforklarende. Min hypotese er at også at det er mer salgbart internt, når penger skal settes av i budsjettet.

Les mer om vår tjeneste her