Det är nu tredje året jag är på SVT vilket innebär att jag kan börja se förändringar ifrån tidigare mönster. Första året händer allt för första gången, andra året är några saker desamma och andra har förändrat sig och det tredje året går det att vara riktigt aktivt delaktig i att förändra det som inte fungerar så bra som man vet att det kan vara.
Det har varit en hel del stökiga beställnings- och projektprocesser på svt’s interaktivavdelning. Vi har i varje team minst två inflöden av uppgifter att göra – ett flöde av nyutveckling – projekt där vi tillsammans utformar och producerar, och ett flöde av redaktionellt behovsorienterade uppgifter – t ex leveransmottagning från externa produktioner och konfigurationer av lite större programsidor. På det har vi underhåll att sköta… och buggar att fixa. Och ibland mer övergripande tekniska strukturella uppgifter som teknikchefen lägger ut på teamen. Länge har det här varit väldigt rörigt. Under de tidigare två och ett halv åren har vi varit frustrerade, stressade och känt oss underbemannade och inte kunnat leverera enligt förväntningar.
Tack vare de stora förändringar som har skett på flera nivåer under hösten har åtminstone jag haft ett riktigt roligt och lugnt jobb med teamet som bygger på barnkanalen.se. Vad har hänt då?
Definierad tid för olika flöden
Varje team har fått en tydlig fördelning av den totala tiden, där hälften av tiden ska gå till nyutveckling, 25% till tekniskt underhåll och 25% till underhåll i form av löpande uppdateringar utifrån användarbehov. De externa leveranserna och konfigurationerna har släpat kvar på teamet under hösten men ska hanteras av ett separat team. Med hjälp av trello är det lätt att få överblick över hur mycket tid som läggs på vilken del över tid.
Målstyrd beställning
Vi har haft ett utvecklingsprojekt som sträcker sig från augusti till april. Det projektet beställdes från vår ledning som en målbild utan några detaljer alls i hur det skulle lösas. Jag som utvecklingsansvarig kunde sedan definiera en något mer konkret bild av var vi skulle börja för att bäst uppnå det målet och formulerade fyra ingångsvärden. Dessa ingångsvärden är mitt styrmedel för hela den produkt som teamet sedan bygger. I höstens projekt löd de ingångsvärden som jag upplevde som avgörande för slutleveransen
- Barn kan hitta och navigera själva
- Det finns direktvägar tillgängliga från de enheter barnen själva behärskar och har tillgång till
- Föräldrar kan lämna barnen utan risk för att de ska gå in i olämpligt innehåll
- Det är lätt för var och en att hitta ett utbud som är relevant
Inga detaljer alltså. Bara checkpunkter – Kan barn navigera själva? Då är vi klara. Check. I och med beställningen i form av ett mål behövs inga beslut tas på diverse nivåer, utan teamet kan ta alla beslut själva och därmed jobba på utan mellantider. Det är också direkt moraliserande att själva ta ansvar för det man producerar.
Pedagogisk projektöversikt
Konceptutvecklaren/projektledaren i nyutvecklingsprojektet visualiserade projektet i olika detaljerade format – en lök för den stakeholder som inte behöver/kan/vill sätta sig in i några detaljer alls men
som ändå vill förstå vad man tror ska ingå i projektet för eller senare, en fasindelning med epic-stories insorterade per fas (lökring) och ytterligare en detaljerad prioriteringssortering per fas för att teamet ska veta vad som räknas som fluff och vad som är krav.
Löken visar vi för vår ledning, fasindelningen är för att jag som utvecklingsansvarig ska få en uppfattning om vad vi kommer att hinna på ett ungefär och den detaljerade priosorteringen är för att få balans i teamets detaljarbete.
Regelbunden och strukturerad planning
Varje gång som planningen av någon anledning uteblir eller inte får tillräckligt med fokus eller tid uppstår trassel. Så snart det är otydligt vad som ska göras tappar vi både fart och tid. Balansen i hur mycket eller lite information en story ska innehålla är också svår – utvecklarna hittar lösningen bäst själva, men vill också ha tydlig information om vad som ska lösas – inte alltid självklart. Mest fokus fick vi när vi satte upp ett visst antal saker som var tvungna att bli klara till ett närliggande datum för att vi skulle kunna releasa offentligt – och samtidigt tjatar vi alltid om att det inte går att jobba med scrum mot deadlines…
Lovar bara kärnan, allt annat är bonus
Den typen av deadlines som vi inte vill jobba mot är mer löften till stakeholders av leverans ett visst datum. Det försöker vi komma runt med två metoder. Redan från början när vi visar ’löken’ förklarar vi att vi bara lovar att leverera den innersta kärnan. Den kärnan ska bestå av det absolut mest väsentliga och avgörande för att användaren ska få en förbättrad upplevelse – det förhöjda värde som jobbar mot det mål som är beställt. Allt annat är bonus. Vi måste se till att arbetet med den kärnan ligger långt innanför den tidsram vi har fått – och sedan kan vi bara överleverera.
När vi någon gång under tiden får fram skisser på vårt arbete visar vi aldrig färdig tilltänkt design eftersom det är omöjligt att veta hur det kommer att se ut på riktigt till slut. Färdig form skapar lätt förväntningar. Istället får stakeholders titta på halvfärdigt arbete och så snart det går förstås på det som går ut i produktion. På så sätt bli de liksom användarna gladare ju längre vi får förbättra och addera i en iterativ process.
Jag har gjort många roliga projekt tidigare, men det här är det projekt som har flutit bäst av alla jag har deltagit i, och det är en viktig erfarenhet. Jag hoppas förstås att det inte var för bara en period utan att vi har hittat ett sätt gemensamt som fungerar.