En forsmak på "Smidig innhold"-workshop

Ove Dalen

På seminaret 4 steg til suksess på web neste torsdag (27/8) skal jeg holde en workshop om “Smidig innhold”. Vi skal se på hvordan vi ved hjelp av smidige metoder kan sikre at webredaksjonen leverer kvalitetsinnhold – ikke bare i prosjektet, men på en dagtildag-basis.

Mye av min prat kommer til å handle om samhandling, samskriving og hvordan sammen lage godt innhold. Her tror jeg mange tryner i myra ettersom det veldig sjelden eksisterer en kollektiv bevissthet rundt hva som er godt innhold og hvordan jobbe det frem.

Min erfaring er at webredaksjonene sliter med blant annet følgende:

  • Manglende kollektiv bevissthet rundt kvalitet
  • Skriver på hver sin tue – ikke i samme lokale
  • Prater for lite sammen
  • For få dedikerte skriveressurser
  • Lite etterprøving av innhold basert på statistikk og analyse

Her kan smidig, og da Scrum som kjenner best, lære oss mye. Smidig er en utviklingsfilosofi, blant annet brukt i programvareutvikling, som skal løse de samme problemstillingene for de som programmerer.

Men Scrum og smidig er ukjent materie for mange av oss som ikke koder. Jeg tenkte derfor å gi dere en mulighet til å lese dere opp litt på smidig i forkant. Det gjør diskusjonene enklere i workshoppen.

Her er tre lenker som kan hjelpe dere videre:

Smidig og Scrum er såvidt jeg vet ikke brukt i særlig grad systematisk for de som jobber med innhold. Det betyr ikke at det ikke er gjort, men siden ingen har dokumenterte erfaringer driver vi litt nybrottsarbeid.

Egne erfaringer
Jeg har ingen case, men kommer til å prate om erfaring fra egen bedrift. I Origo – den gang vi var et innholdsbyrå – hadde vi en veldig klar kollektiv bevissthet rundt hva som var godt innhold. Det resulterte i at jeg hele tiden kunne levere fra meg en sak til Espen, Kathrine og Pål og forvente at den ble bedre. Hvis det var gjort fem rettelser eller endringer så visste jeg at fire av dem var til det bedre. Ergo så kranglet jeg heller ikke på den siste.

Hvorfor hadde vi denne kollektive bevisstheten? Jo, fordi vi – hvertfall de første årene – kjørte verksteder hver uke der vi diskuterte saker vi hadde skrevet. I tillegg diskuterte vi faglige problemstillinger hver dag i skrivearbeidet. Og vi diskuterte ansikt til ansikt – sendte ikke bare mailer.

Dette er i praksis veldig mye av det samme som smidig forfekter.

Mer informasjon om seminaret:

Vist 2736 ganger. Følges av 1 person.

Kommentarer

Hadde jeg hatt tid, skulle jeg hørt på deg;) Virker veldig bra, Ove!

Ser veldig frem til dette selv, men er også ganske ydmyk i forhold til tema. Blir spennende å se hvordan vi kan bruke Scrum i en mer innholdsfokusert setting.

Utfordringen er vel å etablere samme type lettvekts rammeverk for skriving/skrivesamarbeid som vi benytter for utvikling. Scrum er en prosjektmetodikk laget av utviklere, for utviklere – og det er ikke enkelt å få det til å passe for andre disipliner (selv om jeg har hørt om PR utført ved hjelp av metodikken).

Jeg tror kanskje det er mer å hente i inspirasjon fra enkle, lettforståelige regler med tett, fast kommunikasjon enn i selve metodikken Scrum (hva er for eksempel en sprint i skriveøyemed? En produktbacklog? En sprintbacklog?). Men at det er noe å hente der? Javisst! Spennende tanker dette, Ove.

Inspirasjon er nok det riktige ordet her, Pål. Poenget er ikke å tre Scrum nedover hodet på journalister. Vi skal bruke tankegodset rundt Scrum og annen smidig logikk som et utgangspunkt for diskusjon for å løse innholdsproblemer. Men vi skal også hente inspirasjon fra hvordan redaksjoner med trøkk tenker. Ikke i form av hva de skriver, men i forhold til hvordan de jobber.

Stikkord slik jeg ser det blir teamfølelse, tydelige mål/KPIer, overlappende kompetanse, samskriving, iterasjoner og ikke minst kontinuerlig testing og etterprøving – både visuelt og ved hjelp av stats og korte iterasjoner – ukentlig.

Jeg tror det godt kan gi mening å prate om noe som likner sprinter – altså et sett med saker du leverer innen en iterasjon – ukentlig f.eks – og som du deretter måler, tester med påfølgende evaluering i en kort retrospektiv.

Poenget er vel: Utviklere og webjournalister har veldig mye av de samme utfordringene: De blir lett en avfallsplass for uprioriterte ønsker fra resten av organisasjonen. Og vi vet at alt ikke er like viktig. Ergo kan prioriterte backlogger over innhold være en greie også for de som skriver. Men vi prater da seff om nettsteder som ikke har trøkk på nyheter.

Annonse

Nye bilder