Hvordan jobbe smidig når vi lager nytt nettsted? 9

Hvordan få både innholdsfolka, designere og utviklere til å jobbe smidig når du lanserer nytt nettsted? Her er 10 tips som kan hjelpe deg på veien.

Enkelte predikerer Scrum som den eneste riktige måten å kjøre smidige utviklingsprosjekter på. Kjører man Scrum ”etter boka” betyr dette blant annet at:

• alle aktiviteter skal gjennomføres innenfor samme arbeidsblokk (sprint);
• alle på teamet skal være kryssfunksjonelle, og således kunne utføre hverandres arbeidsoppgaver;
• teamet optimalt skal bestå av 5-7 deltakere; og
• teamets medlemmer skal være 100% involvert i prosjektet.

Hva da når prosjektet er web-basert, og utviklingsteamet består av totalt 10-15 personer som inkluderer både utviklere, webskribenter, interaksjonsdesignere og designere?

Min erfaring er at prinsippene bak Scrum er forholdsvis enkle å sette seg inn i. Å  gjennomføre et smidig prosjekt i praksis er mye vanskeligere. Egne erfaringer er den beste veien å gå for finne ut hva som passer i din organisasjon eller prosjekt.

Her er 10 selverfarte tips som kan hjelpe deg på veien.

1. Sørg for at interaksjonsdesign ligger én sprint foran utviklerne

I et web-basert utviklingsprosjekt vil det være vanskelig å gjennomføre alle aktiviteter innenfor samme sprint (iterasjon). Dette skyldes at enkelte aktiviteter avhenger av hverandre. Grunnleggende wireframes og overordnet design bør være klart før utviklerne starter teknisk implementering. Før interaksjonsdesigneren starter arbeidet med innledende skisser, bør forretningssiden ha klare formeninger om hvilke bruksoppgaver og forretningsmål som skal løses. Samtidig bør innholdsteamet kunne si noe om hvor mye og hva slags innhold siden skal inneholde.

Når teknisk sprint starter, vil forretningssiden ha klargjort nok oppgaver i oppgavelisten (backlog) til at teknisk team kan plukke og estimere arbeidsoppgaver til sin sprint. Hvor ”ferdig” wireframes og design skal være er avhengig av utviklernes kompetanse og i hvilken grad de ønsker å involveres.

2. La prosessen være innholdsdrevet

Hvor mye (eller lite) tekst/innhold som skal inn på en gitt webside setter store føringer for utforming av wireframes og innholdsmaler. En innholdsdrevet utviklingsprosess tar utgangspunkt i at innholdet styrer designprosessen. Målet er å unngå pene Photoshop-skisser som ikke dekker webskribentens tekstlige behov, eller innholdsmaler der interaksjonsdesigneren har lagt opp til påkrevde innholdselementer som ikke gir verdi for brukeren.

For å få til dette er det viktig at prosjektet har innholdsressurser som kan ta de nødvendige grep. Hvilket innhold er utdatert, hva må skrives om, og hva kan slettes? Dette fordrer at webskribentene innehar domenekunnskap og kan skrive godt for web. Fordelene er mange: interaksjonsdesigneren får hjelp til å prioritere innholdselementer og plassering av disse, grafisk designer kan forholde seg til reelt innhold fremfor lorum ipsum, og utviklere unngår redesign av datamodeller og feilaktig implementering av input-felt.

3. Sitt samlet og i åpent landskap

Dersom hele teamet sitter samlet unngår prosjektet å bruke unødvendig tid på interne avklaringer og informasjonsdeling. Mange problemstillinger blir løst ved at spørsmål stilles i ”løse lufta”, og prosjektleder slipper å koordinere felles møter eller å innhente svar på e-post. Raske avklaringer er viktig for fremdrift i prosjektet.

Samlokalisering og åpent landskap er også med på å skape en felles teamfølelse, samt større engasjement og individuelt ansvar for det enkelte teammedlem. Bruk av tavle med lapper for kø-visualisering gir god oversikt over hva teamets medlemmer jobber med og hvor ”skoen trykker”. Sammen med vegghengte papirskisser og utskrifter av design-filer har man et godt alternativ til elektroniske delingssystemer.

4. Jobb intensivt med stor involveringsgrad

Det er stor forskjell på å jobbe i et prosjekt hvor team-medlemmene er involvert 80% kontra et 20% engasjement.  Tiden som spares ved å slippe å finne ut hva som har skjedd i prosjektet siden sist, og ikke minst lære nye prosjektdeltakere å kjenne, er uvurderlig. Effekten blir større jo flere i teamet som har tilsvarende stor involveringsgrad i prosjektet.

Det tar tid å finne ut hvordan teamet best kan utnytte sine ressurser. Det samme gjelder utforming av prosjekt-rutiner, arbeidsprosesser og gjennomføringsevne. Jo bedre et team kjenner hverandre og seg selv, jo raskere og mer effektivt blir det. Resultatet er flere oppgaver kan løses innenfor hver arbeidsblokk uten av dette går ut over fremdriften i prosjektet.

5. Ha faste morgenmøter

Et sentralt prinsipp i Scrum er lynkorte daglige møter der alle forteller hva de driver med. Poenget er å informere hvert team-medlem om hva som er gjort siden forrige møte, hva som skal gjøres innen neste møte, og hva som eventuelt er til hinder for planlagte oppgaver.

Min erfaring er at morgenmøtet er svært nyttig for hele teamet. Prosjektleder kan informere om nye krav fra markedsavdelingen i forhold til kampanjer, ønsker knyttet til funksjonalitet og innhold, eller omprioriteringer av allerede planlagte arbeidsoppgaver. For teamet gir møtet en anledning til å koordinere felles arbeidsinnsats eller omprioritere egne oppgaver. Sistnevnte er spesielt viktig dersom team-medlemmer blir syke eller prosjektet må påta seg ekstra oppgaver.

6. Gjør kontinuerlige evalueringer

Tilrettelegg for faste punkter der teamet kan evaluere arbeidet de gjør. I et web-basert utviklingsprosjekt er evalueringen av wireframes, papirskisser, grafisk design og innhold vel så viktig som evalueringen av teknisk implementering. Sørg for å iverksette konkrete tiltak på bakgrunn av evalueringen. Start enkelt, og prøv kun en eller to endringer i hver iterasjon. Dette gjør det mulig å se hva som faktisk fungerer i praksis, og å optimalisere prosessen ytterligere.

7. Spill på lag med utviklerne

Sammenliknet med utviklingsprosjekter for programvare (som ofte består av rene tekniske team), er programmerere ofte i mindretall i web-baserte utviklingsprosjekter. Det er derfor viktig å finne en prosjektmetodikk som også fungerer for forretningssiden og som optimaliserer for helheten.

Det er ingenting i veien med å la utviklerne kjøre Scrum etter boka hvis de ønsker det. Dette krever imidlertid at forretningssiden og teknisk team samarbeider om hvordan backlog skal se ut, og lager klare rutiner for når og hvordan overlevering skal skje. Det bør også være forståelse for at prosjektleder kan omprioritere oppgaver underveis i sprinten. Et midtsprint-planleggingsmøte er et kompromiss som begge parter kan og bør leve med.

8. Bruk en prosjektleder som kjenner kunden og som er 100% involvert

En fraværende prosjektleder resulterer ofte i manglende fremdrift, spesielt hvis prosjektleder også fungerer som kundens produkteier. En god prosjektleder tar ansvar for prioritering av teamets oppgaver, og hjelper til med å booke møter med interessenter for nødvendige avklaringer på forretningssiden.

Prosjektleder er ansvarlig for å holde organisasjonen orientert om  prosjektets fremdrift, og å planlegge kommende lanseringer. Sammen med teamet bør prosjektleder også ta ansvar for å finne ut hvilken arbeidsprosess som fungerer optimalt på bakgrunn av de ressurser som prosjektet har til rådighet. Dette vil vanskelig la seg gjøre dersom prosjektleder ikke er 100% involvert i prosjektet.

9. Bruk kjernemodellen

Kjernemodellen er et tankeverktøy som hjelper kunden med å ta utgangspunkt i nettstedets kjernesider. Hensikten er å definere konkrete brukerbehov og forretningsmål med utgangspunkt i de optimale informasjonsenhetene på nettstedet. Modellen hjelper til med å prioritere krav og sette fokus på hva som er viktig, og fungerer således ypperlig som et diskusjonsgrunnlag med markedsområdene og øvrige interessenter.

I tillegg til selve ”kjernen” inkluderer modellen veier inn (finnbarhet) og veier ut (konvertering). Dette gjør at teamet må tenke bredere enn det som er normalt ved tradisjonell informasjonsarkitektur, og at prosjektet også setter fokus på eksternt markedsmateriell, søkemotoroptimalisering, calls to action, analyse og salg/konvertering.

10. Lanser nettstedet stykkvis fremfor ett ”big bang”

Test og feilretting tar alltid lengre tid enn man tror, og lansering av et nytt nettsted kan raskt bli en smertefull prosess. Dersom det fokuseres på å utvikle og optimalisere deler av et nettsted om gangen, blir risiko mindre samtidig som teamet får mulighet til å gjøre kontinuerlige forbedringer. Ved å gjennomføre brukertester på nylig lanserte sider kan eventuelle problemområder forbedres samtidig med at nye sider lanseres.

Stykkvis lansering av et nettsted vil også gi innholdsarbeidet riktig fokus. Ved å bruke virkelige data er det enklere å se om løsningen dekker reelle behov, og at disse samsvarer med forretningssidens krav. En positiv effekt er at arbeidet med publiseringsrutiner og innholdsproduksjon settes i gang på et tidlig tidspunkt. I tillegg er det enklere å involvere kunden i hele prosessen, fra start til slutt.

___

Lær hva som funker av Norges og verdens fremste eksperter

På årets Webdagene er det satt av en hel dag til diverse workshoper. Her kan du blant annet lære mer om innholdsstrategi og webanalyse. For mer informasjon se www.webdagene.no.