Inlägg taggade scrum

Hur man får glada användare, medarbetare och beställare

Efter delaktighet i många olika sorters webbproduktion har jag med tiden sett några återkommande fenomen.

  1. Arga användare. De är arga för att något inte fungerar som det ska, för att de ville att vi skulle ha byggt något annat, för att de är tvungna att betala. Summa summarum har ofta blivit en våldsam upprorsstämning där rösterna skalla ’It’s not fair, it’s not worth it!!!’.
  2. Uppgivna utvecklare och team. Teamen används som en fabrik som får en specifikation som de ska utföra. De vet inte varför och förstår inte vad poängen är. De är inte det minsta varken stolta eller nöjda med det de har byggt. De undrar bara ’Why on earth are we doing this?
  3. Uppgivna utvecklare 2. Halvvägs in i projekt dyker det upp önskningar om lite nya saker som utvecklarna svarar att det är helt omöjligt att producera. Mantrat låter ’Vi måste vara med tidigare i processen’.  När de har varit med tidigare i processen har de ofta suttit tysta och inte kunnat bidra.
  4. Idéer utan effekt. Anställda kommer fyllda med energi och vill visa en idé som de har prototypat på kvällstid – idéer som nästan alltid är helt oanvändbara, som inte kommer att generera ett skit för företaget hur trevliga de än må vara. Idéerna genomförs aldrig och medarbetarna känner sig obesvarade och slutar komma med goda idéer alls.
  5. Pengar kastas i sjön. Enorma satsningar på stora team som producerar nya spännande produkter under lång lång tid och när projekten releasas… om de releasas alls… floppar de. Hur vet man att man gör rätt sak?

När jag backar tillbaka de frågorna till rotorsaken lyder de

Hur ska vi kunna garantera en kvalitetsprodukt i slutändan?
Hur ska vi utnyttja kunskaperna hos varje team-medlem på bästa sätt?
Hur ska vi få alla att fokusera på rätt mål?
Hur vet vi att vi gör rätt sak?

När jag började på Barnkanalen, SVT, för tre år sedan dök jag rakt in i att det väl beprövade och framgångsrika konceptet broadcast stod inför totala beteendeförändringar i och med mobila device. Det behövdes större grepp än att ändra tablåläggningen. Vi fick uppdraget att skapa bästa möjliga barnspelarupplevelse online. En av de stora utmaningarna i detta är att vi i vårt public service-uppdrag jobbar för att vara tillgängliga för just nu 260 olika browserversioner, för iOS, Android och Windows phone på samtliga olika device. Det är svårt att få det bra och hålla standard för samtliga. Dessutom skulle vi nu lägga mycket tid och arbete på en helt ny tjänst, vilket alltid är läskigt. Hur vet vi som sagt, att vi gör rätt sak?

Den här gången har inget av de tidigare mantran och frågetecknen uppstått. Vi

  • lyssnar på och engagerar våra användare

o   börjar med att göra research på och prata med målgrupperna och summerar några insikter att utgå ifrån. Det visade sig t ex att barnspelaren endast skulle erbjuda hela program och inte klipp och att den skulle ligga placerad på barnkanalen.se och inte i svtplay för att det skulle vara möjligt att bygga på bästa sätt för målgrupperna.

o   testar med användare varje vecka. Alla i teamet deltar när de kan och vill för att se hur barn interagerar med det som ska byggas eller har byggts. Vi har även haft testfamiljer som har sänt in sin feedback från hemmiljön, såväl som vi har besökt familjer i deras hem.

o   mäter allt som går att mäta och justera löpande utifrån den faktiska användarresponsen.

o   releasar så snart det går att releasa själva kärnerbjudandet och lägger ut allt löpande därefter. Det blir små kontinuerliga förbättringar av användarens upplevelse och i bästa fall upplever de att vi svarar på deras önskningar.

  • sätter tydliga mätbara mål

o   får en beställning i form av ett mål, t ex ökad timespent eller dubbelt så många återkommande besök per unik besökare. Beställaren önskar sig inga funktioner eller färdiga skisser och teamet löser på egen hand hur målet ska uppnås utifrån alla de detaljkunskaper som krävs för att det ska bli på bästa sätt. På så sätt engageras alla i teamet inte bara tidigare i processen, utan hela tiden, i varje liten detalj. Alla i teamet får också god förståelse varför vi gör det vi gör och kan komma med bästa möjliga idéer som har stor chans att realiseras.

o   gissar nästan aldrig, och när vi gissar följer vi upp och justerar utifrån den mätbara responsen. Tyckande är irrelevant, det är bara vad användartester och statistiken från tjänsten säger som talar om vad vi ska göra. Vi gör små justeringar, releasar och mäter eller testar effekten.

  • levererar en kvalitativ produkt i slutändan

o   Vägen till god kvalitet är förstås i grunden att göra rätt saker, men också att se till att det fungerar bra, att det är buggfritt. Släpper vi kod dagligen låter vi inte bara användarna engageras och delta i produkten, utan vi isolerar buggar som uppstår och kan lätt rulla tillbaka dem utan att stänga ner en hel site. I arbetet med barnplay har ingen behövt jobba nätter och dagar i sträck. Själv åkte jag på semester samma helg som vi skulle lansera appen, sidan har legat ute lajv i flera månader. Den är testad och optimerad och det enda vi väntade på var att Apple skulle få ändan ur vagnen och godkänna den i app store.

Det fina med att jobba mot målbilder istället för färdiga skisser är att vi har lyckats med vår leverans när vi har uppfyllt målbilden, inte när alla features i skissen är på plats. Det tydligaste i arbetet med barnplay var kanske att fler funktioner inte hade levererat mot målet om vi inte hade prioriterat att korta laddnings- och svarstider i interaktionen. Funkar inte det som ska fungera kommer ingen att använda tjänsten.  Då har man valt att göra fel saker, eller rätt fast vid fel tillfälle. Nu kunde vi ägna all av teamets tid till att uppnå de mål som var satta.

Presentation av detta från Handelshögskolan samt Berghs, projektledning av digitala projekt.

 

Annonser

, , , , , , , ,

1 kommentar

Smidiga processer bästa jobberfarenheten i år

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

bild fr fotoakuten.se

bild fr fotoakuten.se

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.

, , , , , , , ,

1 kommentar