Kravspesifikasjon

Det er viktig å bruke et prosjektstyringsverktøy. Kanskje har utviklingsselskapet et system de bruker internt, men det kan være komplisert eller ikke gi nok detaljer. 

​

Det viktigste er at dere får en nettbaserte løsning for å dele oppgaver og  kommunisere med IT-utviklerne og andre i prosjektet.

​

System dere velger eller får servert bør brukes til:

• Utviklerselskapet legger inn hovedfasene i prosjektet og deloppgavene, blant annet det som står i kravspesfikasjonen.

• Lagre og dele alle designsskisser og justeringer/endringer man blir enige om.

• Litt mer avanserte systemer kan vise forløp i prosenter/timeforbruk, men det er ikke så viktig.

• Etterhvert vil man ønske å legge inn mindre oppgaver, justeringer, feil som må rettes og kommentere i systemet underveis i prosessen.

 

Velg bare ett system og bruk det til så mye av kommunikasjonen som mulig. Da får dere ikke “men vi har laget X basert på skissen/beskrivelsen som lå på Dropbox, epost, Facebook-chat....” ​

​

Noen systemer 

• Atlassian Jira: Veldig funksjonsrikt (brukes av Nasa) og komplekst.

• Basecamp: Litt mer orientert mot dokumentdeling

• Teamwork: Enkelt og intuitivt

• Asana: Enkelt, populært system

• Slack eller Microsoft Teams: Startet ut som gruppechat, populært i IT-bransjen.

• Trello: Har blitt veldig populært. Lar dere dele oppgavetavler med rader med oppgaver som har ulike farger/statuser. 

• Google regneark: Enkelt og effektivt. Del et regneark med rader for hver oppgave. Bruk fargekoder for feil, klar til test, rettet osv 

​

Videomøte: Bruk videomøter og gjerne del skjerm for å vise feil og forklare hvordan funksjoner skal fungere. Et godt alternativ er gratis-tjenesten http://appear.in.

​

Fremdrift

Prosjektet er et samarbeid der både dere som kunde og utviklerselskapet må gi hverandre litt rom til å manøvrere. Kunsten er å kjenne når prosessen begynner å skurre og da å si fra så fort som mulig:

​

• Når det dukker opp ikke-varslede forsinkelser eller utblivelser av fremdrift

• Når svarene på spørsmål blir unnvikene eller i verste fall ikke så høflige

• Når eposter og telefoner ikke besvares i løpet av dagen 

• Hvis sykdom blir mer enn noen dager

• Hvis det dukker opp diskusjoner der man ikke blir enige 

 

I Norge er vi opplært til å tro det beste og være høflige, men i slike situasjoner gjelder det å gi tilbakemeldinger fort, både til utvikler og leder/den som undertegnet kontrakten med dere. Da er det enkelt å rette opp og forbedre. Ikke vent til stemningen har gått skikkelig sur eller det blir dyrt å rygge/rette opp. Derfor:

​

• Sørg for at dere i kontrakten har avtalt en avsjekk med leder enten hver uke eller annenhver uke og at dere setter leder på kopi på statusrapporter.

• Ta gjerne opp ting på telefonen med utvikler og/eller leder, men oppsummer alltid med en epost etterpå.

 
Testing av konvertert innhold
Har dere komplisert innhold som skal importeres fra den gamle siten, så start tidlig for å sikre at denne eksporten blir riktig. Sørg først for at det som skal flyttes faktisk kommer over. Det gjelder alle bilder, brukerdata, tabeller, PDFer, alle tekstbiter og annet som skal med faktisk er kommet over. 

​

Dersom dere fortsatt skal få innhold fra et bakenforliggende system: Husk å avtale forskjellen mellom hvordan data skal sendes/hentes under konvertering og hvordan det skal skje når sidene kommer i drift. Det kan være forskjeller som den ene parten tror er kommunisert. Så handler det om å få vist data på riktig måte på den nye nettsiden. 

​

Dere må gjøre en hovedimport og så en ny påfyllingsimport på lansering for å få med det siste innhold.

​

Redirects:

Å sette opp redirects er en viktig og ofte glemt del av et nettprosjekt. 

Redirects løser problemet med at mange brukere og Google har tatt vare på gamle nettadresser. Setter man opp redirects, sendes brukere videre til ny, riktig nettside. Dette gjelder både hvis dere bytter domene (fra x.no til y.no) eller legger om noen/alle nettadresser. En redirect vil automatisk sende besøkende som ber om den gamle kontaktsiden fks. www.gamleside.no/34585 videre til www.nyside.no/kontakt-oss. 

Den tekniske siden av redirects gjør utviklerselskapet for dere, men dere må få det med i planen og hjelpe til. 

​

Her er dere bør gjøre:

• Lag en liste over alle hovedsider. Det enkleste er når en gammel side bare bytter adresse.

• Det er litt mer komplisert hvis fks “bedrift.no/produkter” nå skal splittes opp i tre kategorisider. Da må man enten sende brukerne som ber om den gamle adressen til den nye forsiden eller til en enkel spesialside som lar dem velge en av de tre kategorisidene.

• Hvis dere har mange sider på samme nivå, fks 500 produkter, be om hjelp til å få flyttet innhold og automatisk opprettet nye sider. Da kan utviklerselskapet lage en automatisk redirect-liste som sender bruker til riktig side.

• Noen nettsider blir borte, men sett opp en redirect til en hjelpsom side, fks forsiden eller søkesiden. Alternativet er at brukeren møter en “404 - Nettsiden finnes ikke” og går sin vei.

​​

Gjøres redirects riktig, opprettholder man posisjonen sin hos Google.
 

​

​