Service blueprint – en inkörsport till tjänstedesign

På senaste tiden har jag jobbat med Service blueprint. En blueprint är kort och gott en visualisering av vad en användare/kund gör steg-för-steg (som en kundresa, alltså). Men man lägger också till vad organisationen gör för att stödja kunden i en och samma piffiga visualisering.

Service blueprint exempel

Här har jag gjort ett (säkert inte helt korrekt) exempel på hur en blueprint skulle kunna se ut för att skaffa ett nytt pass hos Polisen. Den utgår från kundens aktiviteter, sedan har jag lagt till vilka tjänster, system, personer och annat som användaren interagerar med. Både sådant som syns (på scenen) och sådant som inte syns (bakom scenen).

En inkörsport till tjänstedesign

Service blueprints har kallats ”a gateway drug to service design” eftersom folk som är lite mer tekniskt eller processorienterade snabbt kan förstå nyttan. Det här är något jag upplevt själv. Det tog inte lång tid innan vår blueprint fick spridning även hos folk som inte varit med i jobbet eller fått den presenterad. Jag blev extra glad när någon frågade om hen kunde få den i Visio-format för att kunna använda den som mall och göra en egen.

Gemensam förståelse

Jag älskar visualiseringar som kan hjälpa folk att förstå och lösa problem tillsammans. Blueprinten är en bra modell när de som ska samarbeta sitter i olika projekt eller avdelningar som borde prata mer med varandra.

Man kanske till exempel har ett gäng som jobbar med bokningen till passexpeditionen och ett annat som jobbar med att förbättra hur handläggarna jobbar. Det är bra om båda gängen har koll på hur de system och människor som möter kund hänger ihop, hur kunden beter sig och vilka problem kunder och handläggare har. Så de kan jobba mot samma mål och göra det som är bäst för användaren totalt, inte bara för sin lilla del i upplevelsen. Tjänstedesign, alltså.

Lager på lager på lager

Mitt exempel har ”bara” tre lager. En fin grej med blueprinten är att man kan lägga på flera lager av information. Man kan lägga på hur många lager som helst!

I den blueprint jag jobbat med i verkligheten hade jag med kundens problem och möjligheter, plus anställdas problem och möjligheter. Man kan också dela upp interaktionerna i anställda och system. Man kan bryta ner system i sina beståndsdelar och visa vilken data som flödar hit och dit. Man kan visa vilka avdelningar som jobbar med vad. Man kan visualisera hur användaren mår i olika steg.

Men om man vill göra något som folk ska förstå (och det vill man!) får det förstås inte bli för mycket.

Det är inte raketforskning

Tjänstedesign ses ibland som något stort och tungt. Många intervjuer, långa analysfaser och mycket förankring. Jag tror det beror på att man ofta vill ta stora grepp, man vill att kundresor och blueprints ska användas för att styra total prioritering. Det är ju bra. Men det finns också värde i att använda tjänstedesignmetoder i det lilla, bara för att få folk att snacka lite mer med varandra och förstå lite bättre.

Blueprints ska, liksom andra modeller av hur användare beter sig, bygga på kunskap och inte bara gissningar. Men det betyder inte att det behöver ta lång tid eller vara svårt. Det finns ofta en massa kunskap (och olika perspektiv) hos kollegor. Och om man kan lite intervjuteknik och hittar smarta sätt att analysera anteckningar tar det inte mer än några dagar att intervjua några kunder och analysera.

Tack till grymma kollegorna Sanna, Peter och Eric som bidrog till det här!

Mer om Service blueprint

Adaptive Paths Guide to Service Blueprinting

Annonser

Några tips för att söka jobb

För ett tag sedan bestämde jag mig för att bli konsult (igen) och sedan dess har jag träffat sex olika konsultbolag. Alla gånger jag skaffat nytt jobb tidigare har jag glidit in på något sorts bananskal och gått på känsla, har aldrig träffat i närheten av så här många eller tänkt så här rationellt. Det har förstås varit lärorikt som attan.

Skriva en lista

En grej jag gjorde bra var att skriva en lista med saker jag ville ha. Det var bra eftersom det är lätt att hamna i att man har en bra känsla eller personkemi med en person man träffar och glömma bort vad man ville ha hos en ny arbetsgivare. Ungefär så här såg min lista ut:

  • Bra möjligheter till kompetensutveckling
  • Många duktiga att dela erfarenhet med
  • Bra förutsättningar för att jobba användarcentrerat
  • Bra förutsättningar för att jobba agilt/i tvärfunktionella team
  • Fokus på nytta (affärs-/samhällsnytta)
  • Snäll chef som är intresserad av mig och min utveckling
  • Småsaker som gör att man känner sig uppskattad (frukostar, fester, konferenser m.m.)

Inte söka när man har en jobbsvacka

Ibland känner jag mig på topp, att jag är superduktig och kan det mesta. Ibland mindre så. För mig beror det mycket på team och projekt jag jobbar i, är det bra stämning och man känner att man får gehör för sina idéer och sitter i förarsätet så mår man bra och tror på sig själv.

Jag tror man ska undvika att söka jobb när man känner att man är i en svacka. Då blir det mycket svårare att beskriva vad man är bra på och vad man vill på ett självklart sätt.

Ta det lugnt

Jag tror det är lätt att hamna i att vilja få jobbletandet avklarat snabbt. Det är ju rätt jobbigt att söka jobb. Och visst, ibland hittar man helt rätt direkt. Men idag när arbetsmarknaden för UX:are och annat IT-folk är så bra så behöver man verkligen inte ha bråttom.

Att träffa en massa olika bolag gör att man blir bättre på att förstå vad man tycker är viktigt. Dessutom träffar man ju en massa folk som man kan stöta på igen längre fram även om det inte klickar just nu.

Effektkarta och User story map – två modeller för prioritering

Jag älskar modeller. En bra och tydlig modell kan göra kommunikationen i ett projekt så mycket lättare.

Effektkartan är en modell jag jobbat mycket med. Den har hjälpt mig (och andra) att kommunicera och nå delad förståelse. Den har också hjälpt mig i prioritering av lösningar. En annan modell som jag lärt mig på allvar på senare tid (genom att läsa den briljanta boken User Story Mapping av Jeff Patton) är User story map. En Story map kan också underlätta delad förståelse och prioritering. Men på lite andra sätt.

Delad förståelse

Hur håller vi reda på vad som ska utvecklas och ser samtidigt till att alla i teamet vet vad som ska göras? Att mommunicera via många och långa dokument fungerar inte, det vet vi. Teammedlemmarna måste prata med varandra. Men om tjänsten är komplex, vilket den ofta är, behövs det någon form av dokument att kommunicera kring. User stories är ett vanligt sätt, men en User story i en vanlig backlog har ett problem. Den saknar kontext. Hur passar den här storyn in i helheten? Alltså, vilka andra stories hänger den ihop med, och vilka användarbehov löser den? Effektkartor och Story maps är modeller som ger en bättre helhetsbild av vad som ska göras.

Det är viktigt att tänka på att varken Effektkartor eller Story maps (eller andra modeller för den delen) är kompletta kravdokument. De är stöd för konversationer mellan människor. Det innebär att de aldrig kommer innehålla alla detaljer. Du kommer aldrig kunna maila modellen till någon utomstående och förvänta dig att den ska fatta. Du, eller någon annan som varit med om att bygga modellen, måste förklara med hjälp av modellen. Jeff Patton liknar det vid ett semesterfoto. Om du ger någon en av dina foton från en resa kommer den aldrig förstå var bilden är tagen, vad som hände före och efter. Men det blir lättare för dig att förklara om du har ett foto att visa.

Prioritering

Att jobba mot en stor ”big bang”-release av sin tjänst är inget vidare. Tidiga releaser mot riktiga användare är bra på flera sätt. Dels kan vi lära oss om hur tjänsten den möter användarnas behov innan den är klar (vilket boken Lean UX av Jeff Gothelf handlar om). Dels tar pengarna ändå alltid slut innan man hunnit utveckla allt man vill, så det är lika bra att från början öva på att leverera något begränsat.

Men för att kunna släppa något innan hela tjänsten är helt klar måste man prioritera vad som ska släppas. Då krävs koll på helheten. Vilka användarbehov är viktigast? Hur hänger olika stories ihop? Vi vill ju släppa något som är tillräckligt komplett för att användarna ska kunna (och vilja) använda tjänsten.

Effektkartan

Grundidén med effektkartan är att åskådliggöra kopplingen mellan en lösning och verksamhetsnytta. Modellen har tre nivåer:
  • Effekt – vilken nytta ska tjänsten göra för verksamheten? Halvdåligt exempel från kattmatsbranschen: ”Fler som köper kattmat hemifrån”.
  • Användning (beteenden och användningsmål) – hur beter sig människor som påverkas av tjänsten, och vilka mål har de? Beteenden och användningsmål ska förstås bygga på vad man vet om användarna – inte bara vad man tror. Prioritering sker också på denna nivå. Vi kan till exempel göra lite user research och komma fram till att vi har en beteendegrupp ”Finsmakaren” som vill uppleva exklusivitet och gärna får detaljer som kattmatens smak och näringsinnehåll. En annan grupp ”Budgetkatten” vill bara betala så lite som möjligt. Vi väljer att prioritera ”Finsmakaren” eftersom vi tror den gruppen tilltalas mer av vår ganska dyra och fina kattmat.
  • Lösning – vad ska utvecklas för att stödja användningen? Lösningar formuleras på en från början hög nivå (till exempel ”tydligt hur näringsinnehåll skiljer sig mellan produkter” eller ”design som upplevs som exklusiv”) och kopplas till de användningsmål de tillgodoser. En fin princip är att lösningarna ska formuleras som egenskaper som går att mäta. Upplevs designen som exklusiv? Det kan vi ju ta reda på genom att fråga användarna. Om den gör det så kommer vi antagligen lyckas locka ”Finsmakaren” att köpa kattmat och – tada! – nytta för kattmatsbutiken som tjänar deg!

Effektkartan kan hjälpa oss att konversera om nytta och prioritera de lösningar som leder till maximal nytta för verksamhet och användare. Att lösningarna är på en hög nivå gör att modellen går snabbt att förklara utan att gå in alltför mycket på detaljer. En bra modell att använda för att beskriva tjänsten för någon oinsatt eller intressenter utanför teamet (till exempel ledningsgruppen).

User story map

Story maps gör det lättare att jobba med User stories i projekt genom att strukturera upp dem istället för att bara lägga dem i en rad (klassisk ”platt” backlog, alltså).

Kartan beskriver vad användaren gör steg-för-steg. Om vi tar en e-handel för kattmat skulle stegen kunna vara ”Hitta kattmat”, ”Köpa”, ”Betala”, ”Få leverans”, ”Mata katt”. Under varje steg finns sedan saker som ska utvecklas (User stories) av olika prioritet.

För att tjänsten ska fungera för användaren måste varje steg fungera, det duger inte att släppa tjänsten utan att ha med steget ”Få leverans” – det skulle användarna aldrig acceptera. Men av de User stories som hör till varje steg är inte alla kritiska. Till exempel behövs SMS-avisering av leveranser inte i en första version av tjänsten. User storyn ”Få SMS-avisering inför leverans” kommer vara lägre prioriterad än t.ex. ”Få kvitto på leverans”. Det här hjälper oss att välja vad som behöver utvecklas för en tidig release av tjänsten som ändå upplevs som komplett.

En Story map ger en helhetsbild av hur tjänsten fungerar utifrån vad användaren gör steg-för-steg. Det gör det lättare att kommunicera då de User stories vi jobbar med i teamet får struktur och kontext på ett sätt som alla kan förstå. Det blir också mer fokus på användningen jämfört med en vanlig ”platt” backlog.

Effektkartor och User story maps i en härlig harmoni

Man kan förstås kombinera de här två modellerna eftersom de är bra på olika saker. Effektkartor är bra för konversationer om nytta och användning, inom teamet eller med intressenter utanför. Story maps är bra för konversationer om detaljer och i vilken ordning saker behöver levereras, inom teamet.

Nina Boljang höll ett bra blixttal om det här på senaste UX Open (2016). Nina pratade bland annat om att prioritering utifrån användares mål är det viktiga med effektkartan, men en Story map underlättar planering av releaser. Väger man in båda perspektiven får man en riktigt vettig total prioritering.

Lästips

Boken User Story Mapping borde vara obligatorisk läsning för alla som jobbar med digitala tjänster.

Handfast guide med exempel på User story map av Steve Rogalsky

Exempel på effektkarta från Huddinge kommun

Bra färsk artikelserie om Effektkartläggning av skaparen Ingrid Domingues:

 

Gör som Janne, skaffa ett spretigt team

janne_andersson_2008
By  Halmstad at English Wikipedia, CC BY-SA 3.0

I år fick Sveriges herrlandslag i fotboll en ny förbundskapten i Janne Andersson. Janne jobbar inte ensam, det finns en massa roller runt omkring honom. Som assisterande tränare, agenter och mental coach. Det är intressant hur Janne plockade ihop sitt entourage. Han har satsat på olikheter. Janne är själv en resultatinriktad tävlingsmänniska. Hans två scouter Tom Prahl och Jonas Thern verkar vara varandras motsatser. Den ene en noggrann analytiker, den andre en impulsiv och kreativ känslomänniska. Jag rekommenderar Per ”Texas” Johanssons text om detta i senaste Offside.

Jag tror Janne gör helt rätt. De bästa teamen jag jobbat i har bestått av olika personligheter med olika egenskaper. För att inse det måste man, som Janne gjort, inse sina brister men och också förstå vilka egenskaper som är viktiga i ett sammanhang. Här är några personliga egenskaper jag tror är viktiga i utvecklingsteam:

  • Resultatfokuserad – superviktigt. Utan tillräcklig vilja att faktiskt leverera nytta blir själva jobbet ibland ett mål i sig. Man hamnar i evighetslånga diskussioner om detaljer som inte spelar roll men som bara måste redas ut. Bara för att de måste det. Här är det extra viktigt att det finns resultatfokuserade personer som har hög status (ja, det finns alltid en hierarki – formell eller ej) och kan bestämma att ”nej, nu går vi vidare”.
  • Självinsikt – eftersom ett utvecklingsteam består av experter på olika områden behöver man kunna lita på varandras kompetens. Vilket innebär att man själv måste förstå vad man är bättre och sämre på. Det gäller alla i teamet.
  • Glädjespridare – lite positivitet, pepp och skratt kan göra under. Ingen gillar gnällspikar men alla kan inte heller vara Mia Törnblom hela tiden, då blir det inget gjort. Och man behöver inte äta tårta varje vecka. Jag jobbade med en projektledare en gång som var så grym på att peppa. Han var bara väldigt glad och intresserad av hur alla mådde. Vi kände oss sedda och viktiga. Och han skaffade en ny växt åt oss varje sprint så varje leverans blev något konkret i rummet som vi fick ta hand om.
  • Analytisk – sällan en egenskap som det är brist på i utvecklingsteam. Men jag tror att eftersom utvecklare och testare ofta är så pass analytiska måste övriga i teamet också vara hyfsat analytiska för att kunna kommunicera.
  • Kreativ – kreativitet kan appliceras på mycket, inte alls bara design. Jag tycker det handlar om att kunna zooma ut och komma på ett helt annat sätt att angripa ett problem. Det är inte något som ”bara finns” utan kan tränas upp, så både en kompetens och en personlig egenskap. Istället för att komma på en lösning, kom på många. Jämför med andra lösningar eller situationer. Tänk brett, inte bara djupt. Om det saknas kreativitet blir alternativen få och lösningarna helt enkelt inte lika bra.

Insikter om användare är en färskvara – leverera tidigare!

När man ska utveckla en tjänst gör man ofta tidigt researcharbete för att förstå användarnas behov och kunna designa tjänsten rätt. Det är bra. Men vad som är mindre bra är att det ofta går för lång tid från research till leverans och att användarbehoven ”glöms bort”.

Det räcker inte med en powerpoint för att förstå

Visserligen är det så att användares behov förändras över tid. Så kan det ju vara, framför allt om man jobbar med nya och innovativa tjänster som förändras. I min jobbvärld som handlar om bank och ekonomi så händer det dock inte jättemycket, och jag har sett många användargrupper där behoven är mer eller mindre statiska. I kontexten ekonomi vill användarna ha kontroll över sin ekonomi, uppleva ekonomisk trygghet och få en bättre ekonomi. De här sakerna är rätt lätta för folk som jobbar med banktjänster att förstå.

Men det är svårare att se och förstå detaljerna och nyanserna. Vad betyder kontroll för en användare? Vad ger en känsla av kontroll och trygghet? Hur står sig våra tjänster idag – på vilket sätt ger de kontroll och vad är det som gör att användaren inte känner sig trygg?

När man jobbar med att förstå användare lär man sig jättemycket. Men det är svårt att lämna över sin kunskap till någon annan som inte varit med. Vi UX:are är ofta bra på att skapa bra modeller och visualiseringar av användares behov men för att riktigt riktigt förstå de här detaljerna och nyanserna måste man vara med och göra jobbet. Alltså vara med och intervjua, lyssna på användare, analysera och hitta mönster.

Minimera tiden från research till leverans

Vad som händer om man först gör ett insiktsarbete och sedan låter det gå en viss tid innan man levererar en tjänst (eftersom man kanske är upptagen med att göra utredningar, skriva krav eller övertyga företaget om att göra en investering) är att:

  • De som var med i researcharbetet börjar glömma bort de här detaljerna och nyanserna som är så viktiga för att kunna designa en riktigt bra tjänst
  • Folk byter jobb, tar tjänsteledigt eller blir befodrade (oj vad ålderdomligt det låter att bli befodrad men tja, det heter väl så)

De här superbra insikterna försvinner alltså sakta, sakta bort ju längre tid man låter gå. Och till slut är det enda som återstår en stackars powerpoint i en bortglömd mapp i något gemensamt filsystem. Det spelar ingen roll hur bra researchleverabler vi gör (även om bra modeller och visualiseringar är jättebra för de hjälper andra att förstå!). Detaljkunskapen kommer till slut försvinna om vi inte tar oss i kragen och sätter igång att designa och implementera tjänsten.

Om vi dessutom levererar tjänsten tidigt så får vi andra finfina effekter. Tjänsten börjar användas och skapar nytta för användare och affär. Och vi kan utvärdera hur folk använder den på riktigt, så vi kan förstå deras behov ännu bättre.

Så hur gör man?

Vattenfallsprocesser lever tråkigt nog kvar i UX- och affärsutvecklingsvärlden i rätt hög utsträckning. Ibland under täcknamn som ”sprint 0” eller ”vi jobbar agilt, men först måste vi göra research”. Vi börjar med ett researcharbete, sedan kan vi utveckla. Utvecklarna får inte vara med i researchfasen, för i den fasen finns det inget tekniskt jobb att göra, sägs det.

Det är klart att användarresearch behöver göras innan vissa saker kan utvecklas. Men det finns alltid tekniskt jobb som inte är avhängt på att vi gjort en massa research. Vi vet oftast från början vilken typ av tjänst som ska utvecklas och en webbsajt eller en app behöver alltid uppsättning av infrastruktur och tekniska miljöer innan man kan börja utveckla features.

Det bästa är att jobba tillsammans från början och att hela teamet är involverat i både research och utveckling. Och att research görs löpande, parallellt med utveckling och leverans.

Men om man gör tjänstedesign då?

Om man gör ett tjänstedesignjobb så vet man inte från början vilken typ av tjänst jobbet kommer mynna ut i. Ska det bli en app, en webbsida, eller en fysisk butik kanske? Eller allt på samma gång? Här blir det svårare att minimera tiden från research till leverans och att involvera teamet som i slutändan ska realisera tjänsten.

Jag tror ändå man i många lägen från början kan gissa vilka personer som kommer vara med och realisera. Om det finns en digital tjänst och den inte funkar bra så bör det inte behövas månader av research för att inse att den behöver förbättras. Om man ändå inte kan det så bör man en bit in i tjänstedesignjobbet börja ana vilken kanal förbättringarna kommer göras i och i det läget fasa i rätt folk.

Idag jobbar tjänstedesignbyråer ibland vattenfalligt. Fokus är att leverera insikter snarare än att leverera tjänster och skapa nytta för användare och affär. Vilket kan bero på att de inte har kompetens att leverera själva, men också på att kunderna är dåliga beställare. Därför tror jag på att bygga kompetens och jobba med service design in-house. Eller hitta en byrå som inte bara är duktig på tjänstedesign utan även intresserad av leverans.

Förstå varandra – bli effektivare

Nu i sommartider blir det lite peace love and understanding här, av typen som man kan lära sig om i managementböcker som heter saker som ”How to Become Successful in 4 Simple Steps”.

Vi börjar med ett citat av världens kanske mest citerade människa, Martin Luther King, Jr:

Peo­ple fail to get along because they fear each other, they fear each other because they don’t know each other; they don’t know each other because they have not com­mu­ni­cat­ed with each other.
Det är lätt att hamna i känslan av att någon i ens närhet är ignorant, dum eller ond. Känslan är ibland den reflexmässiga när någon tycker annorlunda, men förstås nästan alltid fel. Därför borde vi jobba mer på att förstå varandra och mindre på att bråka (peace!).

Visa känslor på en oljerigg

Jag lyssnade på en fin historia i podcasten Invisibilia (som är jättebra och handlar om hur människor fungerar). Den handlade om män som jobbade på en oljerigg. Det var en rätt farlig miljö och kulturen var klart macho. Man frågade inte frågor och visade inte känslor, jobbade på. När en arbetare dog i en olycka sörjde kollegorna i 15 minuter, jobbet fick inte stanna upp.

I ett försök att få upp effektiviteten anlitade man en ledarskapskonsult som använde rätt ovanliga metoder, med Shells mått mätt. Hennes mål var att få arbetarna att hantera sina rädslor och börja visa känslor. De fick berätta om sina liv för varandra och göra olika övningar i att visa sig sårbara och erkänna sina misstag och brister. Till exempel fick de i par svara på frågan ”Om du fick förändra en sak med mig – vad skulle det vara?”.

Det här blev en rätt omvälvande upplevelse för oljeriggsarbetarna. Det skapade en helt annat sätt att bete sig och samarbeta på arbetsplatsen. Ökad trygghet, mer kommunikation och känslor. Det gav också resultat. Mängden olyckor gick ner med 84 procent och produktiviteten ökade till rekordnivåer.

Vi är alla en färg (eller flera)

På mitt jobb gjorde vi en DISC-analys för ett tag sedan. Man svarar på en massa frågor och får en färg (röd, gul, grön eller blå) som visar ens jobbpersonlighet. Man fick också träna sig i att identifiera vilka färger andra är och lära sig lite om hur de tänker.

Även om jag kanske inte använder färgtänket så mycket har jag har blivit bättre på att tänka att folk kan ha andra perspektiv och andra mål. Det här är en skill som jag tror vi UX:are är rätt bra på generellt, eftersom vi jobbar med att förstå andra människor. Vi borde bara lära oss att använda den mer på kollegor och andra runt omkring oss.

Förstå hur korkade beslut tas

En grupp som väcker speciellt mycket irritation är de som tar ”korkade” beslut. På konferensen From Business to Buttons i våras pratade Simon Bennett om hur beslutsfattare tänker:

Hur kan vi vara mer som Buddha?

Jag kan rätt lite om buddhism men tänker att en Buddha aldrig blir irriterad på en medmänniska. För att bli mer som Buddha behöver vi förstå varandra genom att kommunicera på ett ärligt och öppet sätt. Berätta vad du är bra på, men erkänn också dina fel och brister. Då blir det blir lättare för andra att förstå ditt perspektiv när ni tycker olika.

Så här kommer det – How to Become Sucessful in 4 Simple Steps:

  1. Inför parterapi i dina agila team
  2. Maila alla kollegor på företaget och berätta varje gång du begår ett misstag
  3. Bjud en kollega på tårta och berätta om din livshistoria varje dag
  4. Gör en DISC-analys och klä dig helt i rött, gult, grönt eller blått

Om stegen känns svåra så kan du börja med att öva dig på att förstå andras perspektiv. Inför ett möte – vilka mål har deltagarna? Och när någon tycker annorlunda – varför tycker hen så?

Trygga grupper presterar bättre

När människor i en grupp vågar visa våra svagheter och brister, känner varandra och kommunicerar så blir vi mer trygga. Och det har visat sig att trygghet är en viktig faktor för att team ska prestera.

Google studerade 180 arbetsgrupper för att förstå vad som fick vissa team att prestera bättre än andra. Deras hypotes var att det handlade om kompetens och att få till den ultimata kombinationen av olika kompetenser. Men man hittade inget sådant samband. Förmågan att prestera hängde snarare ihop med mjuka faktorer, alltså hur teamet samarbetade. Och den allra viktigaste faktorn för att teamet skulle prestera var känslan av trygghet. Alltså om medlemmarna i teamet kunde riskera att ha fel utan att känna sig bortgjorda.

Jag tycker det här visar att vi borde satsa mer på gruppdynamik när vi skapar och jobbar i team. Speciellt om teamet ska jobba under en längre tid och läget är pressat, teamet ”måste” prestera. Det är förresten i de tillfällena vi ofta struntar i saker som kick-offer, fikor och after work. Det finns inte tid.

Innovation genom goda idéer från olika håll

Innovation. Känn på det. För min egen del mår jag lite illa när jag hör ordet. Lite på samma sätt som jag kräks lite i munnen när jag hör ordet brainstorming. Det låter som att man bara ska samlas ett gäng sköna personer och komma på ett gäng sköna idéer. Gärna utan mål, utan att veta vad användarna behöver eller vad som är möjligt att realisera.

Samtidigt är förstås nya goda idéer (som uppfyller verksamhetens mål och dessutom är realiserbara) bra och inte alltid lätta att komma på. Det är lätt att bli miljöskadad. Om man jobbar med att anlägga tulpanrabatter hela dagarna och dessutom har en lång och gedigen utbildning i tulpaner är det svårt att inse när något annat skulle passa bättre. Som pelargoner. Eller kanske till och med en fräsig buske.

Vissa har patent på nya idéer

Som en smart kollega sa när vi snackade innovation igår; det svåra är inte att komma på nya idéer utan att få ta dem vidare. I de allra flesta företag gör man skillnad på de som får komma på idéer (affärsfolk, produktägare, designers m.fl.) och de som realiserar idéer (utvecklare, arkitekter, testare m.fl.). Vissa företag har till och med delat upp sig i grupper som ”creatives” (usch!) och ”tech”.

Det här är förstås dåligt eftersom nya goda idéer kan komma från olika håll. Från en utvecklare som har koll på användarbehoven, från någon på supporten eller t.o.m. från användarna själva.

Innovationstävlingar och hackathons

I veckan var jag på ett frukostseminarie på KnowIt där Björn Lindqvist (accedo.tv, tidigare Avanza) snackade om innovation.   Han organiserade innovationstävlingar för att få fram nya idéer. Alla på företaget fick möjlighet att vara med. Det enda som krävdes var en god idé och ett team som kunde realisera idén hela vägen till produktionsfärdig kod på en vecka.

De som ville vara med fick samla ihop ett team och skicka in sin idé till tävlingen. Sedan röstade företaget på idéerna. Teamen som vann fick en veckas ostörd arbetstid för att realisera idén som pris.

Tävlingen blev en succé. På Avanza skapade man till exempel ett nytt sätt att visualisera innehav, och på accedo.tv ett nytt sätt att generera leads från sin webb. De flesta idéerna från tävlingarna sattes faktiskt i produktion, så bra var de.

Tvärfunktionella team (på riktigt)

Det här med tävlingar och hackathons låter ju kul och bra men uppdelningen mellan idéskapare och implementerare finns kvar. Hur ofta orkar man köra såna här events? Det blir rätt mycket administration eller ”waste”. Och som en annan smart kollega sa, man kan inte styra över när goda idéer kommer.

Bästa lösningen är förstås att ha team som inte jobbar med en idé som någon annan utanför teamet kommer på. Team där inte bara utveckling utan även affär och design ingår, där teamets uppdrag är att uppfylla ett verksamhetsmål eller tillgodose ett behov hos en målgrupp. Resten är upp till teamet och alla är med i alla faser, inklusive idégenerering och design.

Är det här innovation?

Men har det här något med innovation att göra egentligen? Ja, typ. Om man involverar fler personer i att komma på idéer, som dessutom samarbetar tvärfunktionellt, kommer det dyka upp fler olika (och goda) idéer. Det löser inte tulpankillens grundproblem. Även om han början samarbeta med pelargontjejen kommer det inte bli några buskar. Men det är ett bra steg på vägen.