Sammanfattning av utmaningarna som utvecklarmedverkan kan ställas mot

Empiriska fynd hos utvecklarna:

 Utvecklarna ser att utvecklarmedverkan kan möta utmaningar i form av både tid och pengar då det kan bli svårt att motivera den tid och kostnad samarbetet för med sig.

 Utvecklarna ser en utmaning i form av de människor som är involverade, då det kan finnas både en kunskapsskillnad och motvilja hos båda parterna som måste

övervinnas.

 Det kan bli svårt att beräkna utfallet av satsningen då det är beroende av de inblandade.

Empiriska fynd hos användarna:

 Användarna ser att utvecklarmedverkan kan möta utmaningar i form av både tid och pengar då det kan bli svårt att motivera den tid och kostnad samarbetet för med sig.

 Användarna ser en utmaning i form av de människor som är involverade, då det kan finnas både en kunskapsskillnad och motvilja hos båda parterna som måste

övervinnas.

Empiriska fynd hos verksamhetskonsulterna:

 Verksamhetskonsulterna ser att utvecklarmedverkan kan möta utmaningar i form av både tid och pengar då det kan bli svårt att motivera den tid och kostnad samarbetet för med sig.

 Verksamhetskonsulterna ser en utmaning i form av de människor som är involverade, då det kan finnas både en kunskapsskillnad och motvilja hos båda parterna som måste övervinnas.

 Det kan finnas ett motstånd för förändring och nya arbetssätt hos de inblandade, man måste nå en acceptans på något sätt.

45

5 Analys och diskussion

I detta kapitel presenteras en analys och diskussion av studiens resultat. Kapitlet är indelat efter de fem teman från empirin och under dessa teman kopplas empiri och teori mot studiens forskningsfrågor.

5.1 Mottagandet av utvecklarmedverkan som ett nytt koncept

Hur de tilltänkta intressenterna mottar en ny idé kan vara avgörande för dess genomslag och med de tankar som lyftes genom empirin blev detta tema stort nog för att diskuteras

separat. Empirin visar på att både utvecklare och användare tyckte att konceptet lät intressanta, men de lyfte också viss undran över hur det skulle fungera i praktiken och vad de faktiska skillnaderna var. Studiens syfte var inte att undersöka acceptansen av ett nytt koncept utan att undersöka hur man kan involvera utvecklare och vad de skulle kunna leda till men detta tema blir genom teorin och empirin knutet till studiens forskningsfråga ”Vilka

utmaningar kan man möta vid involveringen?”.

Både utvecklarna och användarna i studien har sagt att de uppskattar ett samarbete mellan utvecklare och användare och de menar att någon form av samarbete är nödvändigt för båda parterna. Den åsikten är något som överensstämmer med teorin där exempelvis McKeen och Guimaraes (1997) menar att samarbete är ett måste i många fall och hos Tesch et al. (2009) som lyfter samarbetet som nyckeln till framgångsrika projekt. Dessa åsikter var förväntade då det överensstämmer med den bild jag får av den skandinaviska skolan

(Bansler, 1989; Bansler, 1990; Floyd et al., 1989; Iivari & Lyytinen, 1998), att samarbete och samverkan mellan de olika yrkesrollerna är önskvärt och till viss grad en nödvändighet. He och Sheu (2014) lyfter att de inblandades inställning gentemot ett samarbete är mycket viktigt för att det ska bli meningsfullt. Det här visar på att mottagandet av

utvecklarmedverkan är ett viktigt tema att lyfta och att det är en potentiell källa till flera andra utmaningar som konceptet kan möta.

Som utvecklare D påpekade är utvecklarmedverkan och användarmedverkan något av två ytterligheter som i praktiken kan bli svårt att hålla isär. Det finns redan en allmän

uppfattning om att utvecklare och användare bör samarbeta i någon form och utvecklarmedverkan bidrar då med en lite annorlunda infallsvinkel på samarbetet.

Verksamhetskonsult B ansåg att utvecklarmedverkan innebar att man växlade fokus och gav en ny synvinkel än vad som är det vanliga, detta var något som även utvecklare D påpekade då hen insåg att utvecklarmedverkan innebar nya tankebanor för hen. Ser man däremot till normerna som deltagande design bygger på finner man kriterier som även överensstämmer med tanken bakom utvecklarmedverkan.

Deltagande design ska enligt metoden ske på lika villkor för utvecklare och användare och det fokuseras inte enbart på konstruktionen av system utan ska även förbättra användarens situation (Gulliksen & Göransson, 2002). Det här är två kriterier som försöker lyfta

46

utvecklarmedverkan. Inom användarmedverkan ser jag deltagande design som den metod som ligger närmst utvecklarmedverkan men det finns fortfarande skillnader.

Utvecklarmedverkan ser jag som ett generellt koncept som sker på användarens villkor, inte som en designmetod för system. Utvecklare och användare har, i flera avseenden, olika prioriteringar (Bjorn-Andersen, 2014) och därför är det naturligt att samarbetet kommer att ta olika uttryck beroende på vilken part som dikterar villkoren. Deltagarna i studien har bekräftat min tanke kring att utvecklarmedverkan medför en annorlunda synvinkel på samarbetet mellan utvecklare och användare och även om ingen tillämpning i praktiken har arbetats fram så har ändå konceptet möts av intresse och nyfikenhet.

5.2 Hur utvecklarmedverkan påverkas av utvecklaren och användaren Både teorin (McKeen & Guimaraes, 1997) och empirin tar upp skillnaderna hos användare och utvecklare och hur dessa skillnader påverkar deras förmåga att samarbete eller det utbyte som sker. Tesch et al. (2009) menar att användarnas bristande IT-kunskaper påverkar samarbetet och detta har även empirin lyft fram. Användarna i studien lyfte att

involveringen av utvecklare kan påverkas av kunskapsskillnader hos de två parterna och användares mindre datorvana. Utvecklarna och verksamhetskonsulterna lyfte också att en ovilja att ändras och de inblandades skilda språk kan komma att påverka involveringen. Det är viktigt att bemöta de olika behoven och intressen som finns (Mumford, 2003) vilket både utvecklare och användare har uttryckt som att rätt personer måste medverka för att involveringen ska fungera. Utvecklare B och Verksamhetskonsult A insåg båda att det kunde leda till nya arbetssätt för utvecklarna som med fel introduktion kan bemötas av hårt

motstånd för att de redan är vana och bekväma i dagens arbetssätt. Att intresset hos utvecklare för denna typ av förändring finns kan därmed inte tas för givet. Bjorn-Andersen (2014) talar om ett maktspel mellan utvecklare och användare som grundar sig i olika prioriteringar kring tekniska och sociala mål, vilket påverkar samarbeten mellan parterna. Utvecklarmedverkan innebär ett samarbete mellan människor och det kommer då självklart att påverkas av vilka människor det är som är involverade. Det är en fråga som har fått en stor plats både i teorin och empirin och relateras både till forskningsfrågan ”Vilken nytta kan

man se av involveringen?” och ” Vilka utmaningar kan man möta vid involveringen?”. Både

teorin och empirin visar att den potentiella nytta som involveringen kan ge påverkas av de inblandade, både rätt utvecklare och rätt användare måste involveras för att den fulla nyttan ska uppnås. Som utvecklarsidan av medverkarna i studien uttryckte det så krävs det en vilja för förändring hos de inblandade. Utvecklare B och verksamhetskonsult A befarade att många utvecklare är nöjda med hur det fungerar i dagsläget och att de inte har någon vilja att ta till sig de nya arbetssätt som utvecklarmedverkan skulle innebära. Detta blir således även en utmaning, eftersom involveringen påverkas av de inblandade måste samarbetet ske med personer som passar och är motiverade. På en generell nivå innebär både

47

användare och de har då mycket likheter sinsemellan om hur parterna påverkar koncepten. Det är därför förväntat och högst förståeligt att empirin och teorin presenterar utmaningar och styrkor som grundar sig i de inblandade parterna på ett liknande sätt.

Utvecklarmedverkan och användarmedverkan delar således faktorer som på ett ytligt sätt kan presenteras på samma sätt för de två koncepten men vid en djupare förklaring syns skillnaderna. När verksamhetskonsult A påpekar att motivationen hos de medverkande är viktigt för utvecklarmedverkan så innebär det inte nödvändigvis samma motivation som teorin om användarmedverkan tar upp. Utvecklarmedverkan kräver en motivation hos utvecklaren att vilja ta åt sig ett annorlunda arbetssätt medan i användarmedverkan behöver användaren känna ett intresse och finna motivation till att delta i processen (He & Sheu, 2014).

Som verksamhetskonsult A lyfte fram så kan utvecklarmedverkan möta motstånd hos utvecklare för att det innebär ett helt nytt arbetssätt medan användarmedverkan kan möta motstånd för att det innebär att en användare ska få vara med att ta beslut som utvecklaren anser sig vara mer kompetent att ta själv. Dessa två väldigt skilda scenarier med olika

innebörd, men kan vara exempel på varför motivation eller inställning hos de involverade är viktigt inom koncepten. Vidare när utvecklare D pratar om rätt deltagare för att

utvecklarmedverkan ska fungera behöver denna person nödvändigtvis inte stämma överens med en person som är rätt för användarmedverkan.

Både teorin och empiri har som en gemensam faktor lyft att en persons förkunskaper om teknik och IT påverkar stark hur bra personen i fråga passar för att medverka i samarbetet. Inom användarmedverkan har användarens tidigare förståelse och kunskap om IT en stor roll i hur väl användaren kommer att kunna involveras i arbetet och samarbeta med utvecklaren (He & Sheu, 2014; McKeen & Guimaraes, 1997; Tesch et la., 2009). På samma sätt belyser intervjupersonerna frågan. Användare A lyfte användarens datorvana och det tekniska språket som används vid systemutveckling, kring ramverk och tekniker, som en utmaning och Utvecklare B diskuterade vikten av att hitta en gemensam grund i språket och

kunskapen för att parterna ska kunna förstå varandra. Det här visar på hur viktigt det är att personerna som medverkar passar för uppgifte, att utvecklarna är intresserade av

affärssidan av organisationen och att användarna har ett interesse i den tekniska delen. 5.3 Hur och när utvecklarmedverkan kan användas

Syftet med studien var att undersöka vad en involvering av utvecklare skulle kunna leda till och för att göra detta behöver man reda ut vad involveringen innebär. För detta

formulerades forskningsfrågan ”På vilka sätt kan utvecklare involveras i användarens

verksamhet?” vilket detta avsnitt i sin helhet kopplas mot. Generellt sagt nämnde alla

deltagare i studien att utvecklare kan involveras genom att komma ut till användarna men detta kan ske på många olika sätt och är något godtyckligt. Barki och Hartwick (1989) delar in involveringen som sker inom användarmedverkan till en indirekt eller direkt involvering av

48

den andra parten. Det finns inte mycket stöd i empirin som talar för möjligheter kring en indirekt involvering av utvecklare men man kan fortfarande se en uppdelning.

Empirin visar enligt mig på sätt att involvera utvecklare som utbildare eller coacher och den visar på sätt där utvecklarna har en mer undersökande och utvärderande roll. Det finns flera exempel som talar för den typen av uppdelning, istället för att tala om en indirekt och direkt involvering. Förslag från empirin som innebär att utvecklaren tar rollen som coach var användare Bs tanke om att utvecklare skulle kunna involveras för att introducera och lära användare i hur ny IT fungerar och används. Utvecklarna som deltog i studien hade en ganska samställd bild av hur utvecklare skulle kunna involveras genom en mer vardaglig närvaro, där de kan synas, träffas, tala med och agera bollplank gentemot användarna. Det är bra exempel på hur utvecklarna får ett direkt samarbete med användarna för att sprida sin tekniska kompetens och samtidigt skapa en relation till användarna.

Användarna och verksamhetskonsulterna var de deltagare som såg flest möjligheter för utvecklare att gå in i en mer undersökande och utvärderande roll. Användarna såg att en involvering är möjlig mellan systemprojekt för att skapa relationer där användare A såg fördelar med att kunna utvärdera verksamheten från ett nytt perspektiv.

Verksamhetskonsulterna lyfte möjligheten om involvering som en pågående process där parterna arbetar sida vid sida och därmed får inblick i varandras verksamhet.

Involveringen av utvecklare associeras starkt i empirin till utvecklingsprojekt och skulle då främst ske tidigt i sådana projekt men som har nämnts visar även empirin att involveringen kan användas i andra sammanhang. Då i samband med förändringsarbeten eller för att skapa relationer. Några sätt att involvera utvecklare på enligt empirin är genom träffar och samtal mellan utvecklare och användare, detta föreslog båda verksamhetskonsulterna samt

utvecklare C och utvecklare D. Det här kan ske i grupp eller mellan enskilda individer och blir då främst tillfällen för parterna att dela sina kunskaper med varandra. I teorin (Gulliksen & Göransson, 2002) om användarmedverkan och hur man får en direkt involvering av

användare finner man att dessa sätt även används i det sammanhanget, för att skapa ett samarbete och få med den andra parten i processen.

Ett annat sätt för involvering vid användarmedverkan är genom observationer vilket kommer fram i empirin från deltagare från alla grupperingar. Dessa deltagare föreslår att utvecklare skulle kunna involveras som observatörer där de undersöker nya möjligheter men de skulle också kunna komma ut och jobba sida vid sida med användarna. Empirin och teorin har därmed lyft liknande tillvägagångssätt för hur den ena parten ska kunna komma ut till den andra och involveras i processen. Genom deltagande design är det tänkt att utvecklare och användare ska delta i en utvecklingsprocess på lika villkor och att ett ömsesidigt lärande sker (Gulliksen & Göransson, 2002). Deltagande design är inte vanligt förekommande men så som det är formulerat ovan skulle det kunna innebära en involvering av utvecklare och då målet är att utveckla ett system påverkar det onekligen användarens verksamhet. Som deltagare D

49

nämnde kan utvecklarmedverkan och användarmedverkan ses som två ytterligheter och som deltagande design är förklarat i teorin tror jag att det kan vara svårt att skilja det från en metod för utvecklarmedverkan i praktiken. Grundförutsättning bakom användarmedverkan och utvecklarmedverkan som skiljer dem åt blir mycket otydlig i fallet med deltagande design.

Som empirin och teorin har visat ovan så överlappar området användarmedverkan och den involvering som studien fokuserar på. I vissa sammanhang med användarmedverkan

involveras även utvecklaren i användarens verksamhet och empirin har visat på fler sätt som utvecklare involveras på i dagsläget. Användare A lyfte ett exempel om ett användande av kundbesök där utvecklare besöker användare för att skapa relationer och undersöka nya behov. En annan form av involvering som utvecklare C pratade om är den som konsulter bedriver när de arbetar i kundens verksamhet. De pratar och lyssnar då till medarbetare och försöker finna behov för att förlänga samarbetet genom nya projekt. Det har därmed gått att finna sätt för att involvera utvecklare både i teorin och i empirin.

5.4 Vad utvecklarmedverkan kan leda till

Detta tema är kopplat till forskningsfrågan ”Vilken nytta kan man se av involveringen?” och man kan här se att involveringen kan ge nytta både för utvecklare och användare. För

utvecklarna visar empirin på att involveringen kan ge en större förståelse för användaren och dennes verksamhet, det här är något som hela utvecklarsidan lyfter på något sätt.

Utvecklare B lyfter att utvecklarmedverkan kan leda till en mer direkt kommunikation och feedback och på så sätt även minska missförstånd mellan utvecklare och användare. Utvecklare C tror att det kan leda till minskning av felanvändande av IT-system och processer. Användare A ansåg också att utvecklarmedverkan innebär ett viktigt kunskapsutbyte mellan utvecklare och användare. Det här skulle då kunna leda till att utvecklare fattar snabbare och bättre vardagsbeslut kring systemutveckling, det skulle också leda till en bättre kravförståelse och generellt en effektivare systemutveckling. Teorin har visat på liknande positiva effekter hos användarmedverkan där av McKeen och Guimaraes (1997) många presenterade effekter exempelvis säger att det leder till en komplett och mer exakt definition av användarkrav. Där har de (McKeen & Guimaraes, 1997) visat på att involveringen av användare ger mer kompletta krav, en förståelse för användarens verksamhet, effektivare system, med mera.

Gällande de fördelar som har sitt ursprung i att en bättre förståelse för användarna skapas talar empirin för att utvecklarmedverkan kan leda till samma fördelar som redan är bevisade och vedertagna hos användarmedverkan. Detta då dessa fördelar kommer från den utväxling av kunskap och skapandet av en relation mellan de två parterna som samverkar inom båda koncepten. Oavsett vilken part som är den som blir involverad kan därför ett liknande utbyte förväntas ske. Att utvecklarmedverkan kan leda till en bättre förståelse för den andra parten och ett kunskapsutbyte var de punkter som deltagarna i studien alla var överens om, därför borde involveringen av utvecklare kunna ge flera positiva effekter som finns bevisat hos

50

användarmedverkan. Dessa är de som generellt beror på själva utbytet och samarbetet mellan utvecklare och användare. Som exempelvis färre onödiga systemfunktioner och en bättre systemdesign. I det långa loppet kan involveringen av utvecklare leda till en

effektivare systemutveckling och en närmre relation mellan utvecklare och användare. Utvecklarmedverkan är tänkt att ha användarna i fokus och det går därmed även att se en nytta för användarnas del med involveringen av utvecklare. Empirin visar att involveringen av utvecklare kan leda till att användare får en ökad förståelse för utvecklare och de utmaningar de ställs emot. Att det kan leda till denna typ av förståelse föreslås av alla användare som deltagit i studien men också av flera utvecklare. Kopplat till denna förståelse fortsätter empirin med att det kan leda till mer realistiska förväntningar hos system och en ökad acceptans av dem. Dessa positiva effekter nämner även McKeen och Guimaraes (1997) som en effekt hos användarmedverkan. Användarmedverkan har självfallet andra effekter som exempelvis en känsla av ägandeskap som kanske inte involveringen av utvecklare kan ge, men utvecklarmedverkan kan ge annan nytta som inte täcks av användarmedverkan. Genom involveringen av utvecklare kan användarens verksamhet utvärderas utifrån en ny synvinkel. Utvecklarna i studien menar att verksamheten kan utvärderas för att finna möjligheter för automatisering och effektivisering av verksamheten. Involveringen av utvecklare kan bidra till ett ifrågasättande av nuläget, med utgångspunkt i den tekniska kunskapen som utvecklare har. Utvecklaren har en annan distans till verksamheten och kan värdera både system och processer. Både utvecklare C, utvecklare D och verksamhetskonsult A påpekar att utvecklarmedverkan kan leda till en bättre systemanvändning och effektivare processer. Detta är en potentiell nytta hos utvecklarmedverkan som kan komma att vara den differentierande och komplettera faktorn mot användarmedverkan. Deltagarna i studien såg möjligheter hos utvecklarmedverkan som inte finns hos användarmedverkan och dessa möjligheter kommer från det nya perspektivet. Genom att utvärdera och ifrågasätta användarnas verksamhet kan utvecklarnas kunskaper användas för nya ändamål.

Jag anser att det finns en ny nytta med utvecklarmedverkan som empirin har visat på genom en verksamhetsförbättring hos användarna men konceptet innebär att utvecklare och användare samarbetar vilket kan bidra med många fler generella effekter knutna till att det är olika kompetenser och bakgrunder som samverkar. Dessa effekter är något som är väl utforskat genom användarmedverkan och på grund av utvecklarmedverkans likhet och att det är samma roller som är inblandade kan stora delar av användarmedverkans effekter antas återfinnas även inom utvecklarmedverkan. Involveringen av utvecklare medför att utvecklares tekniska kunskaper appliceras i användarnas verksamhet för att göra den effektivare. Denna involvering medför även att utvecklare och användare lär sig om och av varandra vilket är en central del i deltagande design då deltagande design baseras på ett ömsesidigt lärande (Gulliksen & Göransson, 2002).

51

Ett ömsesidigt lärande borde vara ett mål med all form av samarbete vilket den nytta som teorin och empirin har gemensamt visar på. Likheterna mellan nyttan hos

utvecklarmedverkan och användarmedverkan som har hittats grundar sig i att de kommer från att det är samma parter inblandade som samarbetar. Genom avsnittets resonemang