Lanseringen er starten. Hvem tar ansvar etterpå?

Et produkt trenger en eier i hverdagen

Det er lett å legge all energi i datoen produktet skal lanseres. Men etterpå kommer spørsmålene fra brukerne, endringene i integrasjonene og ønskene som ikke sto i den første planen. Hvem samler dette og bestemmer hva som skal skje?

Jeg ville utpekt én person som eier prioriteringene, selv om flere bidrar med faglige vurderinger. Uten en tydelig beslutningstaker kan utviklingen bli styrt av den siste henvendelsen eller den som roper høyest. Det er vanskelig å bygge et sammenhengende produkt på den måten.

Skille feil fra nye ønsker

En innlogging som ikke fungerer og et ønske om en ny rapport trenger ulike vurderinger. Det samme gjelder en hendelse som påvirker alle brukere, og en mindre visningsfeil. Avtal hvordan alvorlighetsgrad vurderes og hvem som varsles.

Skill også mellom tiden til å svare og tiden til å løse. Et raskt svar betyr ikke at en komplisert feil kan rettes umiddelbart. Forventningene til tilgjengelighet, eskalering og arbeid utenfor normal arbeidstid bør være tydelige for begge parter.

Sikkerhetskopier må kunne brukes

Drift handler blant annet om oppdateringer, tilganger, overvåking og mulighet for å gjenopprette data. NSMs grunnprinsipper anbefaler en plan for sikkerhetskopiering og regelmessige gjenopprettingstester. Det er forskjell på å ha en kopi og å vite at tjenesten kan komme tilbake.

Avklar hvem som følger opp dette og hvor dokumentasjonen ligger. En virksomhet bør ikke være avhengig av at én person husker hvordan alt er satt opp. Tilgang til kode, driftskontoer og nødvendige rutiner må inngå i overleveringen.

Kilde: NSM: Grunnprinsipper for IKT-sikkerhet, særlig prinsipp 2.9 om gjenoppretting

Lag en fast rytme for å lære

Et enkelt møte med jevne mellomrom kan samle det viktigste: Hva strever brukerne med? Hvilke feil går igjen? Hva har vi lært siden sist? Hvilken forbedring er viktigst nå? Hold feilretting og produktutvikling synlige, slik at det ene ikke forsvinner i det andre.

Se etter hele brukeroppgaver. At noen åpner en side betyr ikke at de får gjort jobben. Kombiner relevante brukssignaler med samtaler og tilbakemeldinger. Da blir det lettere å forstå om en endring faktisk løser et problem.

En enkel plan for tiden etterpå

Før lansering ville jeg laget en kort drifts- og oppfølgingsplan sammen med dem som skal bruke og utvikle produktet. Den trenger ikke være omfattende, men den må være konkret nok til å brukes når noe skjer.

• Navngitt ansvar for produktprioritering og teknisk drift.
• Kontaktvei og rutine ved feil eller nedetid.
• Plan for oppdateringer, tilgangskontroll og gjenoppretting.
• Avsatt kapasitet og budsjett til oppfølging.
• Et første tidspunkt for å gjennomgå brukerinnsikt og prioritere videre.

Gi produktet et liv etter prosjektet

Jeg mener et utviklingsløp bør vurderes ut fra mer enn om det kom i mål på lanseringsdagen. Det bør også etterlate en løsning som noen kan forstå, ta ansvar for og forbedre. Den overgangen blir enklere når vi planlegger den mens vi fortsatt bygger.