Alle endringer er i praksis en feilkilde. Både våre kunder og Gurusoft er tjent med å redusere risiko og tidsbruk ved endringshåndtering, og her finner dere våre anbefalinger for å sikre det. Hvor stor risiko det er for feil, kommer an på flere ting, og her finner du beskrevet Gurusofts beste praksis for å redusere risiko for feil ved endringer.
- Endringsønsket må varsles / bestilles hos Gurusoft i god tid.
- Målbildet må være detaljert beskrevet før arbeidet med løsning starter.
- Løsning må være detaljert beskrevet før arbeidet med implementering starter.
- Kunde og Gurusoft må godkjenne beskrivelsen av behov og løsning.
- Løsning implementeres iht. bestilling
- Kunden tester og godkjenner levert løsning opp mot bestilling i testmiljø.
- Ny løsning produksjonssettes.
- Kunden tester produksjonssatt løsning.
NB! Vår erfaring er at det vil lønne seg å bruke tid på god planlegging før implementering. Hvor viktig disse punktene er, og hvor mye tid man vil bruke på det enkelte punkt, vil være avhengig av størrelsen på endringen, kompleksiteten i systemet, vurdering av kritikalitet ved feil i implementert løsning etc.
Nedenfor er noe mer utdypning av de enkelte punktene:
1. Varsles i god tid
Jo større endring, jo tidligere ønsker vi å bli varslet for å kunne sette av riktig person til rett tid for å jobbe med endringen. Normalt er de fleste av våre konsulenter alltid fullbooket inneværende uke og kommende uke. Deretter er man mindre låst til avtalte leveranser de kommende ukene. Derfor er det mye enklere å bestille våre konsulenter til å sette av tid om fire uker, enn i morgen.
Jo bedre frist vi får på oss, jo bedre utgangspunkt har vi for å gjøre oppgaven riktig.
Ut fra et økonomisk perspektiv vil vi anbefale å samle opp flere endringer i en bestilling / leveranse, som vi da gjennomfører som et felles prosjekt.
2. Detaljert og låst målbilde
Vår erfaring er at vi dessverre får for mange bestillinger / endringsønsker som ikke er helt gjennomtenkt og / eller der målet endres underveis. Dette gjør det veldig vanskelig å få løsningen til å treffe kundes forventning.
I de tilfellene der kunden kan fortelle, dvs. beskrive, konkret mål og forventninger til løsningen, er vår erfaring at vi i de aller fleste tilfellene leverer iht. forventninger.
I denne fasen er det kun ønsker og behov det er fokus på, dvs. det er ikke fokus på teknisk løsning. Det kommer i senere faser.
3. Løsning må være detaljert beskrevet
Før vi setter i gang med å utvikle og implementere en løsning, skal løsningen være detaljert beskrevet. Dette kan enten gjøres i et eget løsningsdokument, og/eller i et oppdatert integrasjonsdokument, eller i saksverktøyet vi benytter. Poenget er at løsningen må være planlagt og beskrevet i detalj før vi starter utvikling.
NB! Gurusoft anbefaler alltid at det utarbeides testhendelser ved bestilling av kundetilpasninger.
4. Godkjennelse av bestilling
Etter at løsningen er beskrevet, både ønsket og planlagt leveranse, er det ønskelig å få en godkjenning, ikke bare av eventuelle estimater, men faktisk av planlagt løsning.
Her må begge parter ta en intern vurdering av planlagt løsning og sikre at man forstår den, og godkjenner den. I mange tilfeller er det lurt å ta et felles løsningsmøte med alle involverte parter.
Hvis noe er uklart må man gå tilbake til vurdering og beskrivelse av løsningen. Først når løsningsforslaget er forstått og godkjent går man videre.
5. Løsning implementeres
Løsningen skal være så godt beskrevet i punktene ovenfor, at den kan gis til en hvilken som helst konsulent, med kompetanse på det aktuelle området, hos Gurusoft for implementering. Det er ofte en fordel at den samme personen som beskriver løsningen gjennomfører den, men av og til kan det faktisk være en fordel at en annen konsulent utfører endringen.
Gurusoft gjør kun en intern funksjonsspesifikk testing direkte knyttet til kravene og / eller testhendelsene som er beskrevet, dersom ikke annet er avtalt spesifikt. Dette er kun en kravspesifikk test og ikke en fullverdig akseptansetest.
6. Kunden tester og godkjenner på testmiljø
Alle løsninger anbefales å testes godt på testmiljø før man setter noe i produksjon. Vi anbefaler at det i denne fasen utføres testing basert på tidligere utarbeidete krav og testhendelser.
I tillegg anbefaler vi en generell akseptansetest av hele nettstedet, så vel som eksisterende kundetilpasninger.
7. Produksjonssetting
Når dere har testet og godkjent løsningen vil den produksjonssettes.
For fastpris-leveranser regnes løsningen som godkjent idet den produksjonssettes. Det betyr at eventuelle justeringer i ettertid vil i tilfelle faktureres på timesbasis.
Det anbefales å samle flere saker i en produksjonssetting for å redusere risiko og kostnader.
8. Test av produksjonsmiljø
Nå når vi har produksjonssatt ny endring anbefaler vi at kunde så raskt som mulig tester det samme som i punkt 6.
Siden det er gjort en endring / ny utrulling av nettbutikken, anbefaler vi i tillegg at dere tester deres kritiske prosesser, som f.eks. ordrelegging og registrering, for å kvalitetssikre at ikke endringen har påvirket dette.
Jo tidligere etter en produksjonssetting man avdekker eventuelle feil, jo bedre er det for dere og deres kunder, og jo enklere er det for Gurusoft å finne og rette feilen.