Sjekklisten før dere lanserer webapplikasjonen

En lansering som føles udramatisk, er nesten alltid resultatet av en sjekkliste som ble krysset av i ro og mak ukene før. Det som skaper panikk på go-live-dagen, er sjelden vanskelig teknologi, men enkle punkter som ingen hadde ansvaret for: sertifikatet som gikk ut, backupen som aldri ble testet, skjemaet som sendte e-post ingen leste. Her er avkrysningslisten, sortert i fire områder og skrevet for deg som bestiller tjenesten, ikke for den som bygger den.

Teknikk: det som må være på plass

Grunnlaget er driftssikkerheten. Uten den spiller resten ingen rolle.

• Domene og DNS peker riktig, og du eier domenet selv, ikke byrået.
• TLS-sertifikatet er installert og fornyes automatisk slik at nettsiden aldri plutselig viser en sikkerhetsadvarsel.
• Backup tas automatisk, og en gjenoppretting er testet. En backup du aldri har prøvd å gjenopprette, er en gjetning, ikke en trygghet.
• Overvåking varsler dere ved driftsstans og fanger opp programfeil, så dere vet om problemer før brukerne gjør det.
• Ytelsen holder under last, og løsningen bør være belastningstestet hvis dere venter mange samtidige brukere ved lanseringen.
• E-post fra tjenesten (kvitteringer, tilbakestilling av passord) kommer frem og havner ikke i søppelposten.

Hvorfor akkurat disse? Fordi de tre vanligste grunnene til at en ny tjeneste svikter på lanseringsdagen, er et utløpt sertifikat, en backup uten fungerende gjenoppretting og e-post som i det stille havnet i søppelposten. Alle tre er usynlige til de inntreffer, og alle tre kan krysses av på forhånd.

Innhold og SEO

En teknisk perfekt tjeneste med brutte lenker og feil i teksten føles likevel uferdig.

• Korrekturlest innhold uten plassholdertekst igjen fra utviklingen.
• Riktige sidetitler og metabeskrivelser, samt et sitemap som søkemotorene finner.
• Bilder i riktig størrelse med alt-tekster, for både ytelse og universell utforming.
• En 404-side som hjelper den besøkende videre, og riktige omdirigeringer hvis dere erstatter en eldre nettside.
• Sporing (analyse) er på plass, men konfigurert slik at den respekterer samtykke.

Juss og etterlevelse

Dette området er lettest å glemme og samtidig det som kan bli dyrest i etterkant.

• Brukervilkår og personvernerklæring finnes, er oppdaterte og er enkle å finne.
• Personopplysninger behandles i tråd med personvernforordningen (GDPR): behandlingsgrunnlag, et tydelig formål og databehandleravtale med leverandørene som behandler personopplysninger på vegne av dere.
• Cookiehåndtering der det er like enkelt å avvise som å godta cookies som ikke er nødvendige.
• Universell utforming er ivaretatt. For mange virksomheter er det et krav, ikke en bonus.

Beredskapsplan for lanseringsdagen

Dette er punktet som skiller en kontrollert lansering fra en uryddig. En kort plan er nok, men den skal finnes skriftlig og være gjennomgått med alle involverte på forhånd.

Utpek en lanseringsansvarlig som tar beslutningene. Skriv ned hvem som gjør hva, hvem som kan nås i lanseringsvinduet, og hvordan dere når hverandre raskt. En felles kanal er bedre enn e-poster på kryss og tvers. Bestem på forhånd terskelen for å rulle tilbake: Hva må gå galt for at dere setter lanseringen på pause, og hvordan går dere i så fall tilbake til den gamle løsningen? Uten en forhåndsbestemt terskel blir teamet lett sittende fast i diskusjoner midt i en kritisk situasjon der hvert minutt teller. Lanser tidlig i uken og tidlig på dagen, aldri rett før en helg. Da er teamet på plass hvis noe må rettes.

La noen som ikke har bygget tjenesten, klikke seg gjennom den en siste gang rett før go-live. Utvikleren som har skrevet koden, overser lett det åpenbare, mens et par friske øyne fanger opp den brutte lenken eller den forvirrende feilmeldingen med en gang. Ha også en kort plan for hvordan dere kommuniserer med brukerne hvis noe går galt. En kort melding om at dere er klare over feilen, skaper mer tillit enn taushet.

Et lite, konkret scenario: Dere går live klokken ni en tirsdag. Overvåkingen varsler etter tjue minutter om at kontaktskjemaet ikke sender. Siden det er utpekt en lanseringsansvarlig, utvikleren kan nås og rollene er klare, er feilen rettet før lunsj i stedet for å bli oppdaget av en misfornøyd kunde dagen etter. Det er hele poenget med planen.

Slik bruker dere listen

Gå gjennom punktene som et team, ikke som én persons ansvar, og noter hvem som har ansvaret for hvert punkt. Er dere usikre på om grunnlaget holder før en større lansering? Tjenestene våre dekker alt fra kravene til produksjonssetting. Vil dere drøfte akkurat deres lansering, er det bare å ta kontakt.