2012 har varit ett mycket händelserikt år när det gäller sättet vi jobbar med produktutveckling på IT-utveckling. Det finns framför allt två orsaker till detta:

– Mängden utvecklingsarbete har ökat drastiskt under året och i och med detta har antalet personer involverade i utvecklingen fördubblats
– Aftonbladet har omorganiserats och det har inneburit ett tydligare fokus på produktutveckling online med ökade krav på time to market

Vad har då detta inneburit för vårt arbetssätt?

Produktutvecklingens faser
I slutet av 2011 tillsattes en grupp på Aftonbladet vars uppdrag var att agera innovationskatalysator både för externa och interna produkt- och affärsutvecklingsmöjligheter. Resultatet blev ett antal nya satsningar, tex Tipsa och Appguiden mm. Vår avdelning blev viktigare än någonsin men kraven ökade också. Under en omorganisation blev vi en del av en ny avdelning inom Aftonbladet, produkt- och affärsutveckling och i och med detta formulerades visionen att dubbla utvecklingstakten utan att dubbla kostnaderna. Vi tolkade om formuleringen till att halvera time to market. Efter att ha granskat några större projekt kom vi fram till att vi lägger på tok för mycket tid på förstudier innan utvecklingsarbetet drar igång i projekt.

IT-utveckling har jobbat med Scrum sedan 2005 men med fokus på själva utvecklingsarbetet. Vi kom fram till att själva utvecklingsarbetet ibland är den kortare delen i projekt. Det läggs mer tid på att fundera ut vad och hur vi ska göra och ofta med för stor detaljnivå. Detta sätt att jobba, “design up front”, har sina nackdelar:
– Tvingar oss tillbaks i en vattenfallsmodell
– Idéer blir gamla innan de realiseras av lösningar vilket innebär att lösningarna också blir “gamla”. Vi riskerar att andra gör samma eller bättre lösningar
– Användarbeteenden och omvärlden förändras men vi låser oss vid en lösning

Inspirerade av metoder som product discovery och innovationsmetoder som What If kom vi fram till att själva genomförandet (utveckling/implementation) bör föregås av två kortare faser: idéfas och konceptfas. Genom att dessa faser timeboxas borde det innebära att vi löser problemet med för långa förstudier  samtidigt som vi undviker design up front i stor utsträckning. I product discovery rekommenderas en konceptfas på en vecka men med tanke på att vi haft konceptfaser på ett halvår så satte vi gränsen till en månad, dvs idéfas får vara en månad och konceptfas en månad lång, max. Går det fortare så gör det inget.

En nyckelfaktor i detta är att vi tagit in User Experience (UX) som kompetens på avdelningen. UX genomför avgörande moment i dessa tidiga faser (mål/effektmål, målgrupp/personas, skisser, tester). Arbetet med UX följer sedan med i genomförandefasen men är intensiv i de två första faserna.

Idéfas
Denna fas handlar om att skapa en tilltro till en idé. Genom idéförädling tas en idébrief fram där målet med idén är tydligt. Roller i denna fas: PO, UX

Konceptfas
Konceptfasen handlar om att ta en förädlad idé med mätbart mål till en plan för vad som ingår i en första release av produkten. Med andra ord en product backlog som är estimerad i någon form. Roller i denna fas: PO, UX, Utvecklare

Mellan faserna finns beslutspunkter. Ska denna idé tas vidare till konceptfas? Måste idén jobbas om? Ska den förkastas så vi kan jobba med en annan idé? Ska konceptet realiseras i en genomförandefas eller ska vi bygga ett annat koncept? Dessa beslut tas oftast av Aftonbladets onlineledning där många produktägare deltar.

En ny innebörd av PO-rollen
Under 2010/2011 tog vi fram en modell där det fanns två produktägare som synkade utvecklingsarbetet på hela Aftonbladet. Detta innebar att PO ägnade mycket tid att kommunicera med beställare och övriga intressenter för att definiera vad som ska göras och vad som ska prioriteras. En nackdel med detta upplägg är att produktägarna har svårt att känna ägarskap över produkter när de hela tiden bollar runt “andras” produkter.

Under 2012 ökade antalet utvecklingsprojekt och därför ökade även antalet produktägare. Just nu har vi 7 produktägare och det ser ut att bli fler. Vi har också utbildat våra produktägare i Scrum och produktägarskap. I rollen finns nu i många fall ett affärsansvar för produkten samtidigt som man är PO enligt Scrum. Vi tror att detta är rätt väg att gå och testar oss fram.