Et web-prosjekt har noen særpreg: Det inkluderer teknisk utvikling av maler, flytting/utvikling av innhold og de blir ofte ledet av personer som ikke har programmering som kjernekompetanse. Tipsene mine under er mest relevante for prosjekter av denne typen, selv om noen av dem også er relevante for andre typer prosjekter.
1. Vær kritisk til hva du lager maler for
Når du endelig kan gjøre noe med alle de utfordringene dere har diskutert lenge, er det fristende å løse alt i utviklingen av malene. Stå i mot den fristelsen. Vurder om ikke en mal kan løse flere utfordringer. Er det et behov som kun gjelder for en eller noen få sider, kan du løse det med html-kode eller en app.
Gå gjennom designet og spør deg selv om det ville være mulig å kutte en hel mal eller funksjonalitet. Om du ikke gjør det selv, må du ha noen under designfasen som stiller kritiske spørsmål til omfanget av utviklingen av malene.
Dette er viktig av to grunner: 1) Flere og mer kompliserte maler betyr dyrere utvikling 2) Mer funksjonalitet betyr høyere risiko og mer å teste.
Jeg er svært godt fornøyd med at visma.no, som er en ganske komplisert side, kun har 4 maler. Det vil nok bli utvidet med en til i løpet av våren, men testing og utvikling blir svært oversiktlig med så få maler.
2. Ta kommunikasjonen med utviklerne på alvor
Å lage gode spesifikasjoner er den mest kritiske jobben for å holde kontroll med et web-prosjekt. Bruk mye tid og ressurser på dette. Grundige spesifikasjoner er godt investert tid. Alt for ofte har jeg oppdaget at forsinkelser eller dårlig kvalitet fra utvikler skyldes at jeg har levert for dårlig beskrivelse av hva jeg ønsker meg.
Du bør ta mål av deg å lage grafiske skisser og en god beskrivelse av funksjonaliteten av hver mal og hvert designelement på siden. Det siste vil typisk være en tekst om hvordan siden fungerer for brukeren og den som redigerer siden. Formen på dette avtaler du med utviklerne på forhånd. Husk at det du ikke beskriver, overlater du til utviklerne.
For å forsikre deg om en felles forståelse med utviklerne er et debrief-møte nødvendig hvor dere går gjennom alt. Regn med mange spørsmål som du oppfatter som opplagte eller dumme. Men de er helt nødvendig for å rydde usikkerhet av veien.
Et dårlig arbeid med spesifikasjoner kan føre prosjektet på ville veier. Svært mange skrekk-eksempler på prosjekter har sitt utspring i uklare spesifikasjoner.
3. Planlegg med risiko, ikke legg 20 % buffer på alle estimater
Å legge til litt ekstra tid på estimatene for å være på den sikre siden har jeg selv gjort i mange prosjekter. Dessverre fører det til at slingringsmonnet som skal ta hensyn til usikkerhet blir normalen. Mer alvorlig, det skjuler potensielle tidsbomber.
Forsinkelser skyldes alltid spesifikke problemer. I prosjektplanen er det derfor mer effektivt å tenke gjennom hvor det er størst sjanser for at det oppstår problemer. Eksempler kan være bruk av et verktøy ingen har brukt før eller en oppgave som må være ferdig før en annen kan starte.
Så hva kan du gjøre med en slik oppgave? Gjør den så tidlig som mulig. En variant av dette, er å lage en test eller prototype for å finne mer ut av hvor vanskelig oppgaven er. I verste fall får du lage en reserve-plan for hva du gjør hvis en oppgave blir forsinket.
For å gjenspeile risiko estimerer mange med en maksimum og minimum tid. Forutsatt at dette gjenspeiler risikoen på hver oppgave kan det være en god idé. Hvis spennet mellom max og min er lik på hver oppgave, har du ikke tenkt grundig nok på risiko.
4. Ha en metode for å håndtere forslag du ikke rekker
Det er ikke til å unngå at ambisjoner, budsjett og tidsplan på et eller annet tidspunkt brytes mot hverandre. Da er det viktig å ha en klar idé om hva som er viktigst. Er virkelig den funksjonaliteten du brenner for viktig for brukeren? «Kill your darlings», er ofte et bra motto for å skape den beste brukeropplevelsen.
Feil i funksjonalitet er uakseptabelt, men hva du har kuttet av funksjonalitet er det kun deltagerne i prosjektet som trenger å kjenne til. Kanskje oppdager du til og med at det ikke var så viktig for brukeren likevel.
En prioritert liste med hva som skal med i neste runde er et godt verktøy når du rydder i oppgavene dine. Det forutsetter selvsagt at dere har planer og budsjetter for videreutvikling. Hvis ikke er det bedre å være ærlig på at oppgaver som blir kuttet sannsynligvis ikke blir gjort.
5. Legg en grundig plan for produksjon av innhold
Det er lett å undervurdere arbeidsmengden knyttet til innhold. Lag derfor en minst like god plan for dette som den tekniske utviklingen. Et godt utgangspunkt er en kartlegging av innholdet på nettsidene i dag og hvordan du vil at de nye sidene skal fungere. Da har du en liste med tekst, grafikk og multimedia som skal produseres.
Hvor mye tid du trenger for å skrive en tekst eller lage et bilde vil være forskjellig fra side til side. Legg likevel et omtrentlig tall for tiden du forventer å bruke inn i et regneark med alt innholdet. Det gir ofte et lite sjokk å summere grovestimater på innholdsarbeidet. Det er bedre å få overraskelsen tidlig i prosjektet enn når dere står midt oppe i jobben.
Legg også en plan som gjør det mulig å bli ferdig med oppgaver. Ofte er det tiden fra nesten ferdig til helt ferdig som tar lengst tid. En måte å gjøre det på er å dele hver innholdsoppgave inn i flere faser som kan krysses av i planen: Enig om innhold, ferdig produsert, lagt inn i CMS, godkjent. Det vil klargjøre hvorfor alt virker så halvferdig.
6. Jobb med innhold parallelt med utviklingen av maler
Det er vanskelig å vite akkurat hvordan tekst og bilde vil se ut på sidene før malene er ferdig, men det er ikke en god nok unnskylding for å starte arbeidet med innhold. Å utsette jobben med innhold skjuler ofte omfanget av denne delen av prosjektet.
Unntaket er et web-prosjekt hvor det ikke spiller noen rolle at du leverer raskt. Men hvor ofte er det tilfelle? Hvis endringene dere jobber for er smarte og gir bedre resultater, er det ingen grunn til å vente med å lansere.
Planlegg derfor å jobbe med innhold mens utviklerne steller med sitt. Har du laget en god plan er du et godt stykke på vei.
7. Planlegg testing som en egen fase av prosjektet
Testing skal være en egen fase i prosjektet, med sin egen milepæl. Den kommer etter at all utvikling og innholdsarbeidet er over. Her sjekker du om malene fungerer som spesifisert, at innholdet er riktig og at brukerne finner informasjonen de leter etter.
I test-fasen går web-prosjektet fra å være ferdig til å bli virkelig bra. Kvaliteten bestemmes av hvor mye tid som brukes på testing. Ofte er ikke dette med i prosjekt-planen. Selv når det er med, blir det brukt som buffer for forsinkelser. Da vil nettsiden føles halvferdig ved lansering.
8. Legg en egen plan for forankring
Alle som har myndighet til å stoppe prosjektet eller forlange endringer må informeres tidlig og grundig. Når utviklerne begynner å programmere og innhold er produsert, begynner det å bli dyrt å gjøre endringer. Unngå dette ved å ha en gjennomtenkt prosess for forankring av beslutninger. Jeg vil si det så sterkt som at du bør ha en plan for forankring som er samkjørt med utviklingen og innholdsproduksjonen.
Forankring tar ikke utgangspunkt i forslag. Sørg for å presentere anbefalinger du kan forklare og stå for. Planen din henger forhåpentligvis sammen. Når noen ønsker å forandre noe må du vite hvordan det påvirker andre deler av prosjektet. Endringer vil det bli, men sørg for de som tar beslutninger ser helheten.
9. Ha en oppdatert og realistisk tidsplan
Selvsagt skal du motivere prosjektmedlemmene til å stå på. Det oppstår alltid tvil i innspurten. Da må noen trykke på og løfte deltakerne over kneiken.
All motivasjon må imidlertid bygge på et felles og realistisk bilde av prosjektplanen. Folk reagerer på tvil på forskjellige måter. Noen står på til de får blodsmak i munnen uten tanke på liv og helse. Andre blir passive og snakker hånlig i krokene om ledere som lever i la-la-land.
Begge deler er like ille. I beste fall halter framdriften. I verste fall blir folk sykemeldt. Jeg snakker av bitter og dyrekjøpt erfaring, både som prosjektleder og –deltaker.
10. Ta tyren ved hornene når problemer oppstår
En kollega jeg jobbet med i Funcom oppsummerte sin erfaring av å jobbe i prosjekter i en kort setning: «Stol alltid på magefølelsen».
Det er ikke noe mystisk. Magefølelsen bygger på erfaringer du har gjort, men har problemer med å sette ord på. Selv en fersk prosjektleder vil skjønne når noe er i ferd med å gå skeis. Da er det på tide å grave i hvor følelsen kommer fra.
Si i fra tidlig og tydelig. Det er greit å kunne dokumentere problemet, men ta tak i problemene. Og spør de du rapporterer til for å være sikker på at de har forstått hva du sier.
Min erfaring er at forsinkelser blir verre jo senere de blir rapportert.
Oppsummering
Selv små web-prosjekter er kompliserte affærer som ofte involverer mange bidragsytere. En god prosjektplan er det beste utgangspunktet for å improvisere når uventede problemer oppstår. Målet er å levere nettsider med høy kvalitet på avtalt tid. Jeg håper disse tipsene vil bidra til at ditt neste web-prosjekt blir perfekt.