Bakgrund
Kungliga Operan är Sveriges nationalscen för opera och balett och det har den varit sedan 18 januari 1773. Verksamheten har i dag ca 552 anställda och bedrivs i Operahuset i Stockholm samt i Gäddviken där man har alla verkstäder.
Det är en stor och komplex operation att planera verksamheten på Operan med mycket information som ska hanteras över lång tid – en planeringshorisont på 5 år med många inblandade i flera steg av planerings- och produktionsprocessen.
När Operan hade fattat beslutet att gå över från manuella och spridda planeringsverktyg utan gemensamma lagringsutrymmen som såg olika ut på olika avdelningar till ett standardsystem så tog Camilla Högström, IT chef på Operan rodret som projektledare för upphandlingen av det nya systemet. Camilla kontaktade mig under sportlovet för att höra om jag trodde att det var möjligt att kravställa utifrån verksamhetens -och användarnas behov och vara klara med kravställningen innan semestern. “Självklart!” svarade jag och undrade lite varför det skulle behöva ta så lång tid.
Effekter och KPIer
Vi startade med att tillsammans med styrgruppen sätta vilka effekter man ville uppnå med implementeringen av det nya systemet. Det resulterade i ett antal effektmål med mätbara KPIer. Därefter tog vi gemensamt fram vilka de olika målgrupperna för planeringssystemet är och en hypotes om vilka deras största behov skulle kunna vara. När allt detta var prioriterat och klart fick vi ett godkännande av styrelsen och kunde fortsätta vårt kravarbete.
Tillsammans planerade vi in ett antal stora och mindre workshops där alla delar av verksamheten skulle finnas representerad för att vi inte skulle missa några perspektiv. På dessa workshops ville vi få fram nuläget, vilka är de största hindren i dag – för att sedan gå över till hur skulle man vilja att ett nytt system skulle fungera för att ge stöd i det dagliga arbetet.
För mig som UX-konsult var det här ett annorlunda och roligt uppdrag, vi använde bra snabba lean UX-metoder vilket jag tycker var fantastiskt modigt och bra av Operan. Men det var inte bara det som gjorde det så annorlunda, utan vart vi gjorde det och med vilka människor. Det var väldigt roligt att få träffa dessa kreatörer, artister och administratörer på Operan och upplevelsen att få hålla workshop med 35 personer i stora balsalen, med stretchande ballerinor i korridoren utanför. Det är något jag kommer att minnas.
Kravställning tillsammans med användarna
Tillsammans med användarna skapade vi enkla personas där de fick specificera vilka de grundläggande behoven och användarmålen var. En av målgrupperna var en blandning av artister och hantverkare vilket visade sig vara en ganska spretig grupp utifrån behoven vilket snabbt resulterade i två personas. Allt detta gjordes gemensamt i en stor workshop.
Kontextuellt och typiskt användande
En av grundstenarna i det arbete vi gjorde var User Story Mapping. Deltagarna som var indelade i målgrupper fick först tillsammans skapa sin bild av vilka problem var i dag, för att sedan gå över till vilka användarmål de har i systemet. De fick sedan gå över till att tänka kontextuellt och intervjua varandra två och två, där dom fick berätta hur de använde systemet i en typisk situation för att uppfylla respektive användarmål. Den ena personen berättade för den andra som skrev ner scenariot och ställde följdfrågor. Varje målgrupp täckte upp alla sina prioriterade användarmål med scenarios. Detta gjordes i en workshop där vi hade tid att gå igenom och verifiera scenarios som var osäkra, men vi fick också gå igenom dessa i efterhand för att säkerställa att scenariot låg på rätt nivå och inte var för detaljerat i tex gränssnittsdetaljer. Det är ju alltid svårt att säga hur man kommer att använda ett system som inte finns och det är lätt att gå ner lite för djupt i detaljer.
Alla har fått bidra och ta fram kravspecen
Nästa steg var att plocka ut alla interaktioner med systemet från respektive scenario och skapa User Story Mapen. Detta kräver förståelse för vad en interaktion är och vad som är viktigt att ta med för att sedan kunna skriva bra user stories. Det var i vissa fall lite svårt för användarna att göra detta, vilket krävde flera iterationer av genomgångar för att få det bra. Men vinsten är stor – alla har fått bidra och ta fram kravspecen, den är väl förankrad i användarnas behov och processer.
Bra diskussioner vid prioritering
För att hålla isär respektive personas i User Story Mappen så använde vi strikt färgkodning för respektive persona, vilket skapade en tydlig bild av vilka användare som använde vilka funktioner och innehåll mest. Användarna fick tillsammans skapa kartan med kluster av aktiviteter och prioritera och sortera bort dubbletter. Bra diskussioner uppstod där man kunde diskutera vilket behov som egentligen låg bakom viss funktionalitet “Behöver vi verkligen ha en utskriftsfunktion, export till Word och Excell när vi redan har standardfunktionen för utskrift och skapa PDF i browsern – vad är grundbehovet egentligen?”. Mycket kunde rensas bort och prioiteras ner. En prioriterad karta började ta form där skall-krav ligger överst med sådant som måste finnas på plats för att kunna leverera värde kopplat till effektmålen – och resterande som behövs men inte är lika viktigt längre ner som bör-krav.
Själva skapandet av kartan (User Story Mapp) går ofta ganska fort och är ett moment man nästan enklast gör under tystnad, men sedan behöver man rensa och prioritera vilket är ett mycket givande arbete att göra tillsammans både med användarna, produktägare och ur ett tekniskt perspektiv. Kartan kräver dock mycket plats, vår karta var ca 7 meter lång, på den stora User Story Mapping-workshopen hade snickarna byggt ett jättefint långbord som den fick ligga på, men det var lite svårare att få in i de små mötesrum som finns på Operan för senare prioriteringsarbete 🙂
Leverabler
Leverabler från mitt arbete var en prioriterad effektkarta med effektmål, KPIer, personas och behov. Personas för respektive målgrupp, scenarios för de viktigaste användarmålen från respektive personas samt en prioriterad backlog med skall- och bör-nivå i excellformat.
Den stora vinsten i det här arbetssättet är det gemensamma arbete med slutanvändarna som skapar validerade och prioriterade krav och samtidigt en djup förankring i verksamheten. Inget är viktigare än att systemet uppfyller behoven och stödjer processen för att skapa ett system som ger önskvärda effekter.
Vad roligt. Det här vill jag lära mig av. Finns mycket att vinna om vi kan bli bättre på offentliga upphandlingar. Lyckades de löpa linan ut till en färdig FFU i den här formen?
Har du tips om böcker i ämnet?
/Jacob
Tack så mycket Jacob! Det är ett väldigt roligt sätt att jobba på iom det gemensamma arbetet, snabba iterationer med löpande feedback från användare och tydliga prioriteringar. Upphandlingen har gått ut för ett par veckor sedan. Camilla på Operan har fått hjälp i sluttampen av Frontit med omvandlingen till skall- och börkrav samt som stöd för de specifika upphandlingstekniska frågorna. Feedbacken har varit positiv både från andra nationalscener som har genomgått samma typ av upphandling som Operan och nu även från leverantörerna som var positiva angående det gedigna underlaget.
Tyvärr vet jag faktiskt ingen bok där man jobbar exakt så här. Jag har dock med dessa delar bland annat i min kurs i Agil UX här på Crisp. User Story Mapping kommer från Jeff Patton som även han håller Certified Passionate Product Owvner-kurser här på Crisp ett par gånger om året. Lean UX- kan man läsa om i Jeff Goethelfs bok med samma namn, men han jobbar inte så mycket direkt med användare och inte heller med User Story Mapping.
Briljant! Ett föredöme. Gillar speciellt att ni satte effektmålen tidigt och det höga interaktionen. Hoppas på en follow up post där ni berättar om hur ni följde upp dem.
/Mattias
Tack Mattias! Du sätter självklart fingret på ett ofta återkommande problem. Att man sätter effektmål som sedan inte följs upp. I det här fallet hoppas jag att vi har sett till att de måste följas upp, de är satta både kvalitativt och kvantitativt samt både mot verksamheten och slutanvändarna. Så under implementationen ska det tex göras användbarhetstester som ska ge ett visst utfall för att leveransen ska godkännas. Jag hoppas innerligen och tror att Camilla och Operan kommer att följa upp dessa.
Hej Mia!
Du nämner att ni ska göra användbarhetstester under implementationen. Varför inte göra dessa tester i samband med att ni väljer standardverktyg?
Några tips som kanske är helt givna:
– säg till beställaren att redan nu börja med arbetet med uppföljning av effektmålen, d v s att börja samla in benchmark-material.
– lägg in testkrav(!) i avtalet med leverantören.
– skriv en bok när du är klar. 🙂
Låter otroligt spännande att få jobba på Operan. Lycka till!
//Ewa
Hejsan Ewa! Tack för kommentaren, det är du som är min idol i det här ämnet (testledning under implementationer av standardsystem) bara så att du vet 🙂 Jag är bättre på att lyfta på lite stenar innan och sen hålla tummarna 😉
Det är helt klart en djungel det här med offentlig upphandling i sig, och att sedan ha torrt på fötterna och kunna ställa bra krav som säkerställer nytta är ju en stor del i sig. Implementationen kommer att vara ett gediget arbete. Det är som du säger bra att redan i utvärderingen av leverantören testa med användare, och det är det (är jag nästan helt säker på) tänkt att dom ska göra också, där har Frontit varit en bra rådgivare. Jag är dock inte med i själva utvärderingsprocessen.
Dom har också på sin agenda som du nämner att redan nu ta fram grundvärdet för vissa KPIer för att ha som benchmark. Och testkraven ligger med i avtalet. Så det borde gå rätt bra hoppas jag 🙂
Kanske kan det bli en bok tillslut, men jag är tyvärr osäker på om jag kan hjälpa till med implementationen, vilket gör slutet på boken lite tomt kanske 😉 Men någon bra bok på ämnet verkar det ju dock inte finnas, så vem vet 🙂
Hej Mia!
Tack för dina värmande ord! 🙂
Kram!