Når du jobber på spreng for å få noe lansert, er det lett å overse den ene tingen som kan avgjøre om prosjektet ditt lykkes eller mislykkes. Og nei, jeg snakker ikke om noe som har med selve produktutviklingen å gjøre.
Jeg snakker om det som skjer etter lansering – support.
70 % av programvareprosjekter mislykkes fordi ingen tar vare på dem etter lansering.
Hvorfor betyr dette så mye? Og hvordan gjør man det egentlig riktig?
«Etter go-live? Nå går det vel av seg selv.» (Spoiler: det gjør det ikke.)
Teamet ditt har vært dypt inne i koden i uker eller måneder.
Dere lanserte. Ingenting krasjet. Kunden er fornøyd. Tid for å feire.
Men her er poenget. I mange tilfeller starter den mest risikable fasen nå. Og det handler ikke bare om bugs.
Det er nå ekte brukere begynner å danne seg en mening om hele løsningen. Det folk flest bryr seg om innen IT-support er ikke fancy design eller en lang liste med funksjoner. Det er enkelt: Når noe går galt, hjelper noen meg raskt og tydelig?
De første 30 dagene = test i virkeligheten
Alt fungerte i test. Nå har du ekte data, ekte brukere og ekte edge cases.
Noe vil gå galt. Det gjør det alltid. Noen problemer er små. Andre kan utslette hele verdien av prosjektet.
Så hvordan unngår du å ødelegge lanseringen? Her er 5 ting du bør ha på plass før du trykker «deploy»:
Hvem er første respons?
Det høres åpenbart ut, men dette snubler mange team i.
Du trenger én person eller ett team som eier innkommende saker. PM, lead dev, support – det spiller ingen rolle. Det som betyr noe er at noen vet at de har ansvaret når noe går galt.
Den første måneden bør dette være deres høyeste prioritet. I stedet for «send en e-post og vent», får brukerne rask respons.
Hva hvis noe stort går galt?
Du trenger ikke en formell playbook. Du trenger en plan.
Hvem kan rulle tilbake en release?
Hvem forklarer hva som skjer til brukerne?
Hvem sjekker om feilen ligger i koden vår eller i infrastrukturen?
Ellers prøver alle å hjelpe samtidig, og det er ikke bra. Derfor utgjør det hele forskjellen at én person eier prosessen.
Hvor raskt svarer dere?
Som jeg nevnte tidligere, trenger ikke folk alltid en umiddelbar løsning. Men de trenger å vite at de ikke blir ignorert.
Selv en rask melding som «Vi har sett det, vi sjekker nå og oppdaterer deg senere i dag» gjør en stor forskjell.
Hvordan håndterer dere tilbakemeldinger?
I kaoset de første dagene er det lett å behandle saker som noe man bare fikser og glemmer. Men de er mer enn det. De forteller deg hva brukerne forventet – og ikke fikk. Merk dem tydelig. Bug, feature request, UX-problem, dokumentasjonsmangel. Og følg med på om de samme tingene dukker opp flere ganger.
Tre separate brukere som rapporterer det samme? Det er ikke et edge case.
Når er vi ferdige?
Det høres rart ut, men dere trenger en målstrekk. Ellers tar «lanseringssupport» aldri egentlig slutt.
Velg en regel – 30 problemfrie dager, brukerens godkjenning, eller en fast dato. Bare sørg for at alle vet når prosjektet går fra lanseringsmodus til normal support. Hvis du får alt dette på plass før go-live, unngår du mye stress senere, og tiden etter lansering vil faktisk føles som en suksess.
Vil du vite mer om dette temaet?
Nysgjerrig på å lære mer? Les hva vår IT-support Sue skriver om de syv prinsippene for programvaretesting. Hun bryter det ned med praktiske tips og råd fra virkeligheten.
Trenger du hjelp til å tenke gjennom prosessen etter lansering? Ta kontakt! Vi deler gjerne det som har fungert for oss.
