Low code-utveckling
- En studie av utvecklares motivation
och förändring av yrkesrollen
Elin Borg 870209 Agnes Skogfors 961210 Emma Wall 910109
HT20
Informatik med systemvetenskaplig inriktning, kandidatkurs Kandidatuppsats, 15 hp
Ämne: Informatik
Handelshögskolan vid Örebro Universitet Handledare: Kai Wistrand
Förord
Vi vill börja med att tacka våra respondenter som har hjälpt till att göra denna uppsats möjlig. Vi vill även tacka vår handledare Kai Wistrand och alla som på något vis bidragit med råd och feedback under processens gång.
Sammanfattning
Low code spås kunna effektivisera systemutvecklingsbranschen och möjligen råda bot på den brist på systemutvecklare som råder idag. Inom low code-plattformar sker utvecklingen via drag-and-drop funktioner. Studien har som syfte att undersöka hur systemutvecklarens roll förändras vid övergång till low code-utveckling. Detta undersöks utifrån en specifik motivationsteori där fokus läggs på uppmärksamhet, relevans, självförtroende och tillfredsställelse. Studien har även utökat teorin med ett omvärldsförhållande.
Studien har utförts i form av intervjuer med utvecklare som har erfarenhet av traditionell programmering men idag arbetar med low code. Resultatet påvisar att traditionell
programmering fortfarande är en viktig del av utvecklingsarbetet. Resultatet visar även att utvecklarnas produktivitet har ökat då low code gör att systemutvecklingen går snabbare. Vidare framkommer att utvecklarnas kommunikation med användarna underlättas genom low code. Utifrån dessa aspekter kan studien visa en ökning av utvecklarnas motivation. Dagens low code-plattformar påstås dock vara för tekniska för att användare utan
programmeringskunskaper själva ska kunna utveckla system i dem. Även om plattformarna spås bli lättare i framtiden framhålls risker med användarutveckling kopplade till
systemstruktur och säkerhet där behov av granskning från utvecklare kommer att finnas kvar. Studien landar slutligen i att förändringar av systemutvecklarrollen kan påvisas, då rollen inom low code-utveckling blivit mer kommunikativ. I framtiden kan rollen även komma att bli mer granskande.
Nyckelord: Systemutvecklare, Low code, Low code-utveckling, Low code-plattformar, Motivation, Kellers motivationsmodell, Användarutveckling, Anveckling
Centrala begrepp
Low code - Ett sätt att utveckla mjukvara snabbt och utan att behöva skriva så mycket traditionell kod (Revell, 2020, 16 januari).
Low code-plattform - Det verktyg inom vilket low code-utveckling utförs, tillhandahåller bland annat drag-and-drop-funktioner och visuella flöden (Revell, 2020, 16 januari).
Systemutveckling - Utveckling av informationssystem, omfattar allt från beställning till test och leverans av systemet (ComputerSweden From IDG, 2020).
Systemutvecklare - En person som arbetar med att skapa och designa informationssystem utifrån de behov som till exempel en verksamhet har (“Arbetsförmedlingen”, u.å.).
Traditionell programmering – Ett sätt att utveckla mjukvara som bygger på källkod inom ett tekniskt programmeringsspråk (Piteira & Costas, 2013).
Traditionell utveckling – Systemutveckling som sker med traditionell programmering (ComputerSweden From IDG, 2020; Piteira & Costas, 2013).
Anveckling/Användarutveckling - Systemutveckling som utförs av de som är användare av systemet (Avdic, 1997).
Motivation - Psykologisk term som handlar om de faktorer hos en person som väcker, formar och riktar dennes beteende mot olika mål (“Motivation”, u.å.).
Kellers motivationsmodell - Teoretisk modell för motivation, innehållandes förhållanden och strategier för att skapa och upprätthålla motivation (Keller, 1987).
Innehållsförteckning
1. Inledning ... 1
1.1 Forskningsfråga ... 2
1.2 Syfte ... 2
1.3 Avgränsning och Målgrupp ... 2
1.4 Förförståelse ... 3 2. Tidigare forskning ... 4 2.1. Historik systemutveckling ... 4 2.1.1 Problematik ... 5 2.2 Anveckling ... 6 2.3 Low code ... 6
2.4 Utvecklares motivation till low code-utveckling... 8
3. Motivationsteori ... 10 3.1 Kellers motivationsmodell ... 10 4. Metod ... 12 4.1 Metodansats ... 12 4.2 Litteraturstudie ... 13 4.3 Datainsamlingsmetod ... 14 4.3.1 Alternativa datainsamlingsmetoder ... 15 4.4 Urval av respondenter ... 15 4.5 Tillvägagångssätt ... 16 4.6 Teoretisk utgångspunkt ... 16 4.7 Intervjudesign ... 17 4.8 Analysmetod ... 20 4.9 Etik ... 21 5. Resultat ... 22 5.1 Attention ... 22 5.2 Relevance ... 23 5.3 Confidence... 25 5.4 Satisfaction ... 26 5.5 Omvärlden ... 28 6. Analys ... 30 6.1 Analys av motivationsförhållanden ... 30 6.2. Analys av omvärldsförhållandet ... 32 7. Diskussion ... 34
8.1 Förslag till fortsatta studier ... 37 Källförteckning ... 38 Bilaga 1 - Intervjufrågor ... 42
1
1. Inledning
Systemutveckling är extra aktuellt idag då det råder en kraftig brist på utvecklare, vilket under en längre tid målats ut i media (SvD Näringsliv, 2018, 23 april). I branschorganisationen IT&Telekomföretagens prognos (2017) spåddes 70 000 utvecklare saknas år 2022. IDG (2020) skriver på sin hemsida att när allt mer digitaliseras sätter det större press på
utvecklarna eftersom det är de som måste lösa problemen och komma på de nya lösningarna i praktiken.
Definitionen av en systemutvecklare är en person som arbetar med att skapa och designa informationssystem utifrån de behov som till exempel en verksamhet har
(“Arbetsförmedlingen”, u.å.). Utvecklarens yrkesroll kan sträcka sig från allt mellan programmering och teknisk expertis till testning och projektledning. Rollens innehåll kan även variera mycket mellan olika verksamheter och gränsen mellan just systemutveckling och programmering är många gånger flytande (Saco, u.å.). Traditionell programmering som bygger på källkod inom ett tekniskt programmeringsspråk anses tidskrävande och svårt att lära sig (Piteira & Costas, 2013). Det krävs därför många år av träning och praktisering för bli en bra utvecklare. Samtidigt tar det lång tid, även för erfarna utvecklare, att skriva bra
program (Shu, 1986; Hedlund, 2017, 13 augusti).
Under de senaste åren har dock begrepp som low code och no code uppstått, som ett möjligt svar på behovet av effektivisering inom systemutveckling. Idag finns ett flertal aktörer som erbjuder plattformar för att bygga applikationer utan teknisk kunskap inom något
programmeringsspråk (Nunes Alonso et al., 2020; Waszkowski, 2019). Dessa plattformar spås enligt Gartner (refererad i Koksal, 2020) kunna effektivisera marknaden på ett drastiskt sätt. Gartner (refererad i Koksal, 2020) menar även att år 2024 kommer 65 % av all
systemutveckling att ske genom low code. Fördelar med low code är, enligt low
code-aktörerna själva, bland annat snabb utveckling och minskade kostnader, vilket kan ses som ett svar på den brist på systemutvecklare som råder idag (Appian, u.å.; Lowcode.se, u.å.;
OutSystems, u.å.). Via low code-plattformar är det även möjligt för användare själva att utforma och utveckla system som passar deras tänkta användning (Jolanki, u.å.). Med anledning av ovan väcktes våra tankar kring hur low code kommer att påverka systemutvecklarens roll och det är inom detta område studien kommer att ha sitt fokus. En
2 aspekt av low code-plattformar är att branschfolk, som till exempel säljare, kommer kunna bygga sina egna system. Funderingar som uppstår kring detta är hur systemutvecklarens roll och motivation kommer förändras. Kommer dessa aspekter att omformas? Utifrån detta har studien tagit ansats i motivationsteori för att, med utgångspunkt i utvecklarnas motivation till sin yrkesroll, kartlägga vilka förändringar som low code innebär för systemutvecklarrollen i stort. Detta då motivation kan förklaras som själva anledningen till handling. Motivation definieras som en psykologisk term som handlar om de faktorer hos en person som väcker, formar och riktar dennes beteende mot olika mål. Teorier om motivation förklarar varför människor handlar på ett visst sätt och varför de utför vissa handlingar snarare än andra (“Motivation”, u.å.).
Den motivationsteori som vi valt att arbeta utifrån är Kellers motivationsmodell och denna bryter upp motivationsfaktorer i fyra förhållanden: Attention, Relevance, Confidence och Satisfaction (Keller, 1987). Inom studien använder vi dessa förhållanden för att undersöka hur systemutvecklarrollen förändrats vid övergången till low code. Studien har även utökat teorin med ett omvärldsförhållande för att studera utvecklarnas relation till den verksamhet hen utvecklar till.
1.1 Forskningsfråga
• Hur har systemutvecklares motivation till sitt yrke förändrats vid övergång till low
code-utveckling?
1.2 Syfte
Syftet är att utifrån forskningsfrågan undersöka systemutvecklarens roll genom motivation samt hur denna har förändrats vid övergång till low code. Detta för att kartlägga eventuella skillnader i rollen vid low code-utveckling jämfört med traditionell utveckling.
1.3 Avgränsning och Målgrupp
Studien avgränsar sig till att undersöka utvecklare som arbetar med low code i Sverige. Studien riktar sig till flera olika målgrupper:
• Utvecklare som arbetar med traditionell programmering idag och funderar på att börja
3
• Studenter som funderar på hur deras kunskaper inom programmering kommer att stå
sig på den framtida arbetsmarknaden.
• Organisationer som vill gå över till low code-utveckling och har funderingar kring
rekrytering och personaltillgång.
1.4 Förförståelse
Om Gartners (refererad i Koksal, 2020) framtidsspaning stämmer, och low code blir det ledande arbetssättet, tror vi att systemutvecklarrollen kommer att förändras och att andra kvaliteter än tidigare kommer att efterfrågas hos utvecklarna. Detta då de kommer att lägga mer fokus på att effektivisera och verksamhetsanpassa system och mindre fokus kommer att läggas på att skriva den faktiska programkoden. Vidare tror vi, att om utvecklarna sökt sig till yrket för att få skriva kod, kommer deras motivation antagligen att minska vid övergång till low code-utveckling.
4
2. Tidigare forskning
Under detta kapitel behandlas tidigare forskning som gjorts på utvecklingen av systemutvecklarrollen. Här lyfts även den problematik som finns kopplad till
kommunikationen mellan utvecklare och användare samt forskning som gjorts på anveckling - det vill säga användares utveckling av system. Sedan behandlas low code-plattformar och dess funktionalitet samt den tidigare forskning som finns kring utvecklares motivation till att arbeta med dessa.
2.1. Historik systemutveckling
Från att utvecklingen av elektroniska datorer startade, på 1940 talet, har målet hela tiden varit att de ska utvecklas och bli mer effektiva (Flodén, 2018; Yousfi, 2016). Även
systemutvecklarrollen har utvecklats genom åren, i takt med att nya tekniska lösningar uppkommit (IDG, 2020).
Benämningen systemutvecklare uppkom först i början av 1960-talet. Då innefattade rollen främst att programmera efter sina egna behov, och med sig själva som användare. Rollen utvecklades sedan till att skapa mer komplexa system åt andra. När utvecklarna behövde utveckla större, mer komplexa system resulterade det i mjukvaruproblem som efter en konferens i Garmish, Tyskland, 1968, kom att benämnas som “software crisis”. Det vill säga att när utvecklare fick hårdare krav att arbeta snabbt och inom en tight budget gjorde det att de var tvungna att ändra sitt arbetssätt för att kunna skapa effektiva program inom en rimlig tid (Fitzgerald, 2002).
Från början, under 1960-talet, fanns heller inga allmänna standarder eller utbildningar för personer som ville lära sig programmera, vilket ledde till att programmen ofta blev komplexa med olika, individuella lösningar. Detta gjorde även programmen svåra att underhålla
eftersom personen som hade skrivit koden inte alltid fanns tillgänglig för att underhålla eller förklara den (Fitzgerald, 2002).
Under 1980-talet introducerades mikrodatorn som kom att ändra sättet företagen arbetade på. Användarna av systemen fick då mer ansvar och större kontroll över systemutvecklingen i organisationen. Nu var de inte längre beroende av att ha en avdelning som skötte allt,
5 mer användarvänlig och kraftfull och användarna kunde därför skapa och anpassa systemen efter sina egna behov (Gauch, 1992).
Nästa steg i utvecklingen var persondatorer, vilket innebar att datorer inte längre enbart ägdes av organisationer utan även av privatpersoner för privat bruk. Detta möjliggjordes även av billigare och mer lättillgänglig hård- och mjukvara (Moldoveanu, 2003). Teknikutvecklingen fortsatte i samma riktning och personer fick tillgång till flera datoriserade föremål i sin vardag. I samband med detta blev begreppet Ubiquitous computing aktuellt, vilket innebär att användandet av teknik kan ske överallt och var som helst, genom att göra vardagliga föremål till smarta föremål (Yousfi et al., 2016).
Parallellt med övergången till att datorer även började användas för privat bruk skiftade fokus på mjukvaran från att enbart tillhandahålla funktion till att dessutom behöva vara mer
användarvänlig. Denna utveckling har fortsatt och mer och mer fokus har lagts på att göra applikationer användarvänliga i samband med att teknikanvändandet brett ut sig och att smarta föremål blivit en del av vår vardag (Arvola, 2019).
2.1.1 Problematik
Systemutvecklingsprojekt har en historik av att misslyckas. Enligt Charette (2005) överges 5– 15 % av alla projekt före eller kort efter driftsättning, då de inte uppfyller verksamhetens krav. Många projekt driftsätts även med signifikant reducerad funktionalitet alternativt att projektet markant överskrider budget (Verner et al., 2008).
Forskning har visat vissa ledande faktorer och anledningar till att systemutvecklingsprojekt misslyckas samt även påvisat att det sällan är en enda faktor som stjälper projekten. Exempel på vanliga faktorer hos misslyckade projekt är orealistiska och opreciserade mål, otydligt definierad kravspecifikation, dålig eller bristande kommunikation mellan utvecklare, kund och slutanvändare, orealistisk budget samt felaktig bedömning av tidsgång (Verner et al., 2008). Det poängteras även att långtgående fel är dyra och resurskrävande att åtgärda och att det därför är av stor vikt att upptäcka fel tidigt i projekten (Charette, 2005). Som en lösning på ovanstående problematik förespråkas kontinuerlig inblandning av användarna i
6 2.2 Anveckling
Begreppet anveckling handlar om en typ av systemutveckling som utförs av de som på något sätt är användare av systemet. Dessa användare kallas även för anvecklare. En stor anledning till anvecklingens uppkomst är de problem med kunskapsöverföring som sker vid traditionell systemutveckling. Där utvecklas ett system till en verksamhet, av externa utvecklare, baserat på de behov som de framtida användarna av systemet gett uttryck för. Att det uppstår problem med kunskapsöverföring beror på att det är svårt för användarna att beskriva verksamheten och vilka behov den har av ett informationssystem, på ett sätt som gör att utvecklarna verkligen förstår. Det är därför också svårt för utvecklarna att skapa ett system som faktiskt motsvarar de krav verksamheten har (Avdic, 1997).
Anveckling beskrivs som en potentiell lösning på ovan nämnd problematik. En nackdel med anveckling är dock att anvecklarna kanske inte förstår grundproblematiken bakom problemet de försöker lösa med ett system och att deras lösning därför inte heller blir optimal. En aspekt av detta kan vara att anvecklarna utvecklar system som inte håller särskilt hög kvalitet och därför ej heller är särskilt hållbara över tid (Avdic, 1997).
2.3 Low code
Utveckling av system genom low code innebär en snabbare form av utveckling som kräver en mindre mängd programmeringskod, jämfört med traditionell utveckling. Det möjliggör att applikationer kan utvecklas snabbare (Nunes Alonso et al., 2020). Eftersom low code inte kräver lika stora kunskaper inom programmering möjliggör det att fler än bara
systemutvecklare kan arbeta med att utveckla applikationer på dessa typer av plattformar. Detta i sin tur möjliggör en lösning på problemet med bristen på utvecklare som existerar idag (Silva et al., 2020).
För att arbeta med low code används särskilda plattformar. Flera aktörer på marknaden erbjuder detta, till exempel OutSystems, Mendix och Appian (Silva et al., 2020; Woo, 2020). Low code-plattformar är uppbyggda med några förvalda mallar för basapplikationer,
gränssnitt och funktionalitet, som utvecklaren sedan kan anpassa. Det är även möjligt att själv skriva kod för att få just de funktioner som önskas (Silva et al., 2020). Utöver low code-plattformar finns även no code-code-plattformar som fungerar på nästan samma sätt, men med skillnaden att där behövs ingen kod skrivas (Woo, 2020).
7 Ett steg i ledet från traditionell programmering till low code är visual programming language (VPL). VPL är en typ av mjukvara som gör det möjligt för utvecklaren att grafiskt ändra i färdiga funktioner istället för att skriva dem med traditionell kod. Det krävs dock
programmeringskod för att addera funktionalitet (Lau-Kee et al., 1991; Revell, 2019, 2 augusti).
Low code-plattformar är baserade på tekniken bakom VPL (Waszkowski, 2019), eftersom applikationen även här designas genom ett grafiskt användargränssnitt. Den stora skillnaden är dock att low code låter användaren skapa applikationer och program utan att till varje funktion behöva programmera hur den ska fungera (Sanchis et al., 2019). Dessa funktioner är redan inbyggda i plattformen och användaren väljer vilka funktioner som ska finnas med och drar sedan dem dit de ska vara i den färdiga applikationen (Silva et al., 2020). Detta gäller dels för gränssnitt, se den första bilden, dels för logiklagret, se bild 2, där affärslogiken sätts ihop med hjälp av visuella flöden.
Bild 1. Ovan bild visar hur ett gränssnitt för registreringsformulär kan skapas i low code med
hjälp av drag-and-drop. Se valbar funktionalitet på bildens vänstra sida. Källa: OutSystems Service Studio 11.
8
Bild 2. Ovan bild visar hur logiklagret kan sättas ihop med drag-and-drop och flöden i OutSystems. Hämtad 2020-12-27, från https://www.outsystems.com/ai/. Använd med tillåtelse.
2.4 Utvecklares motivation till low code-utveckling
Dahlbergs studie (2020) har undersökt systemutvecklares upplevelser av att arbeta med low code. Studien utgår ifrån att det finns forskning kring low codes påverkan på
systemutvecklingen i sig men ej på utvecklares upplevelser av low code-arbete. I studien påvisas övervägande positiva aspekter kopplade till utvecklares upplevelser av att arbeta med low code istället för traditionell programmering. Bland annat känner sig utvecklarna mer produktiva, detta utifrån att de med hjälp av low code-plattformarna kan få mer jobb gjort på kortare tid. Dahlberg (2020) kopplar även detta till utvecklarnas motivation och menar att en ökning av produktivitet också leder till ökad motivation. Vidare lyfts andra
motivationshöjande faktorer, ur tidigare motivationsforskning, kopplade till bland annat, problemlösning, att hjälpa andra, utmanande arbete, variation, utnyttjande av kunskap, kreativitet och kommunikation. Positiv påverkan på flera av dessa faktorer hittas i Dahlbergs egen studie (2020) av utvecklarnas upplevelser av low code-plattformar.
Vidare anger de utvecklare som intervjuats i Dahlbergs studie (2020) att low code-verktygen möjliggör förbättrade kundrelationer. Detta baseras delvis på snabbare utveckling men även på att low code-plattformarna öppnar upp möjligheten att göra snabba ändringar, till exempel
9 i ett möte direkt med kunden närvarande i rummet. Denna förenkling av kommunikationen uppges leda till att utvecklarna bättre förstår användarnas krav på systemet. Även detta framhålls som positivt för utvecklarnas upplevelser av att arbeta med low code-plattformar och deras motivation till arbetet. Utvecklarna uppger även att de vid arbete inom low code har möjlighet att lägga mer fokus på objektet, det vill säga det aktuella projektet, detta då mindre fokus behöver läggas på programmering och teknik. Vidare uppger utvecklarna att arbetet blivit roligare då monotona och uttråkande moment minskat.
Dahlbergs studie (2020) påvisar även en del negativa upplevelser av low code-arbete. Där lyfts begränsad arbetsfrihet och kreativitet, kopplat till de begränsade valmöjligheterna som finns inom low code-plattformar. Studien pekar även ut otillräckligt dokumentation och osäkerhet kring gruppsamarbeten som negativa aspekter med low code-utveckling.
Anledningar till detta är att low code-plattformarna inte gör det möjligt att backa tillbaka och titta på tidigare lösningar, i samma utsträckning som inom traditionell programmering. Det är även svårt att se vem som skrivit vilken kod samt att dela kod mellan varandra.
10
3. Motivationsteori
I detta kapitel presenteras motivationsteori. Först presenteras begreppet motivation och dess definition samt avsikten med att studera detta. Sedan presenteras två välkända
motivationsteorier. Därefter behandlas den teori som vi valt att utgå ifrån för att studera utvecklares motivation till att arbeta med low code.
Motivation är en psykologisk term som handlar om de faktorer hos en person som väcker, formar och riktar dennes beteende mot olika mål Teorier om motivation förklarar varför människor agerar över huvud taget och varför de utför vissa handlingar snarare än andra. Motivation kan brytas ner i primär och sekundär motivation, där den primära motivationen antas vara biologiskt betingad medan den sekundära anses vara formad ur sociala och kulturella förhållanden (“Motivation”, u.å.).
Motivation har studerats av ett flertal forskare och ur många olika synvinklar. En välkänd modell för motivationsstudier är Maslows behovstrappa från 1943. Där behoven rangordnas och de grundläggande behoven som till exempel mat och sömn kommer först följt av behov av trygghet, behov av gemenskap, behov av uppskattning och sist behov av
självförverkligande. Enligt modellen behöver behoven uppfyllas i tur och ordning (“Behovshierarki”, u.å.).
Ytterligare en välkänd teori inom motivation är Herzbergs tvåfaktorteori från 1959, vilken kan ses som en utbyggnad av Maslows behovstrappa. Tvåfaktorteorin studerar människors
motivation till arbete. Inom denna teori skiljs hygienfaktorer, som ses som grundläggande och ej motivationshöjande, från de motivationshöjande faktorerna (Herzberg,1959).
Den specifika motivationsteori vi valt att använda i vår studie, Kellers motivationsmodell, är ursprungligen uppkommen för att studera motivation till inlärning och redogörs för nedan.
3.1 Kellers motivationsmodell
Inom Kellers teori om motivation beskrivs motivation som oförutsägbar, föränderlig och svår att kontrollera, vilket i sin tur har lett fram till att Kellers motivationsmodell utvecklades. Syftet med modellen är att bryta ner och konkretisera de komplexa aspekterna som ligger bakom motivation. Grundtanken är att människor kommer att involvera sig i aktiviteter som
11 de tror att de kommer lyckas med och som kommer att tillfredsställa deras personliga behov. Vidare består modellen av fyra förhållanden till vilka strategier för att skapa och upprätthålla motivation utformas. Förhållandena är Attention, Relevance, Confidence och Satisfaction, dessa kommer beskrivas mer detaljerat nedan. Utifrån dessa kallas modellen även för ARCS-modellen (Keller, 1987).
Attention - Att fånga och hålla kvar uppmärksamhet. Bygger på människors behov av
stimulans och variation. Arbetsuppgifter ska uppfattas som roliga. Variation inom uppgifterna gör att dessa uppfattas roligare och leder till att bibehålla uppmärksamheten. Även begrepp som nyfikenhet, uttråkning och upphetsning behandlas här (Keller, 1987).
Relevance - Kan kopplas till tidigare kunskaper och erfarenheter, men även till framtida mål. Relevansen för en uppgift är högre om uppgiften går att relatera till och bygger vidare på tidigare kunskaper samt om kopplingar kan göras mellan uppgiften och framtida användning av kunskapen som uppgiften ger. Erfarenheter, nutida värde och framtida användbarhet framhålls som viktigt begrepp när relevansen studeras (Keller, 1987).
Confidence - Handlar om människors strävan att kännas sig kompetenta och inneha kontroll. Här behandlas svårighetsgrad och förväntningar som viktiga begrepp. En hög nivå av
confidence gör att framgång kopplas till förmågor istället för tur. Mål nås genom handling (Keller, 1987).
Satisfaction - Behandlar strävan att känna sig nöjd med sig själv och sin egen insats, samt att bli bekräftade för sitt arbete. Väldefinierade arbetsuppgifter som kopplas till tydlig belöning är viktiga faktorer. Även kontroll genom möjligheten att själv kunna bestämma över sitt arbete framhålls som en viktig faktor under denna kategori (Keller, 1987).
12
4. Metod
I detta kapitel beskrivs och motiveras de metoder som har använts för att genomföra studien. Kapitlet inleds med en metodansats. Därefter behandlas metod för föreliggande
litteraturstudie, vilken utfördes för att på ett strukturerat sätt sätta oss in i ämnet. Därefter behandlas metod och metodval för insamling och analys av data.
4.1 Metodansats
Studien har som avsikt att kartlägga utvecklarnas motivation till sitt yrke samt förändring av motivationen vid övergång till utveckling inom low code-plattformar. Syftet med studien är att genom motivationsförändringarna, utläsa eventuella förändringar av systemutvecklarens roll som uppstått vid övergången. Studien utförs med en deduktiv ansats, vilket innebär att vi som utfört studien gått in i arbetet med vissa förkunskaper och åsikter inom ämnet som vi prövat med hjälp av en specifik teori (Bryman, 2011). I vårt fall hade vi bland annat en bild av att systemutvecklarrollen skulle komma att förändras vid övergången till low code och att utvecklarnas motivation till yrket skulle komma att minska, kopplat till att mindre kod behöver skivas i low code och att utvecklarna skulle sakna detta arbetsmoment.
Vidare har studien genomförts i form av en djupgående studie som skulle kunna liknas med hur Oates (2006) beskriver fallstudier, vilket innebär att studera en specifik instans av något genom att använda flera olika datainsamlingsmetoder. I vår studie har dock endast intervjuer använts som datainsamlingsmetod. Vi har intervjuat sex low code-utvecklare från två olika företag, vilka i sin tur arbetar inom två olika low code-plattformar. Empirin kan tyckas begränsad i antalet respondenter. Val av omfång grundas i att studien behövt utföras på ett djupgående plan för att fånga upp motivationsförändringar enligt den valda teorin. Low code-plattformar har än så länge begränsad utbredd i Sverige, och problematiken kring att få low code-utvecklare att ställa upp i studien spelar också in och ligger till grund för valet av studiens djupgående inriktning. Denna problematik var känd redan vid studiens uppstartsfas och vi har valt att utforma studien utifrån de respondenter som varit tillgängliga för oss. Att våra utvecklare har erfarenhet från olika low code-plattformar ser vi dock som en tyngd i studien, vilket ger relevans och gör att studien kan kopplas mot low code-utveckling på ett bredare plan.
13 Vidare är studien utförd som en kvalitativ studie, med fokus på icke-numerisk data, och semistrukturerade intervjuer har genomförts. Mer om innebörden av detta och motivering för dessa metodval återfinns under 4.3 Datainsamlingsmetod.
Studien har dock inletts genom att genomföra en litteraturstudie som är tänkt att ligga till grund för studien. Inom denna behandlas low code-plattformar, dess funktionalitet och utvecklares motivation till low code. Även systemutvecklingens historik kopplat till
utvecklingen av rollen, systemutvecklingsproblematik samt användarutveckling inkluderas i litteraturstudien.
4.2 Litteraturstudie
Vid vår litteraturstudie av low code-plattformar har vi använt databaser som rekommenderas för informatik: Web of Science, Scopus samt IEEE. Detta då de är lämpade för ämnesområdet samt innehåller artiklar som är peer reviewed, vilket innebär att de är granskade av experter inom ämnet (Oates, 2006). Inom ovan nämnda databaser har vi använt sökbegreppen “low code” och “low-code” samt sorterat på relevans och sedan valt att endast visa artiklar som är peer reviewed. Sedan har vi läst rubriker och abstracts på de artiklar som presenterats på första sidan. Därefter har vi valt ut och läst de artiklar som vi uppfattat behandlar low code på en generell och beskrivande nivå. Eftersom low code är ett relativt nytt fenomen har vi inte tagit hänsyn till äldre eller eventuellt utdaterade källor vid litteratursökningen. Alla källor som har kommit upp i sökningarna och behandlats i studien är max två år gamla.
Initialt gjordes även sökningar mot vårt huvudområde, det vill säga low code och motivation. Inom dessa hittades dock inga vetenskapliga källor. På grund av bristen på vetenskapliga artiklar inom vårt huvudområde, har vi valt att lyfta en studie som vi hittat i Diva-portalen. Detta är en masteruppsats i informatik från 2020, där sex low code-utvecklare intervjuats om deras upplevelser av att arbeta med low code. Studien har slående likheter med vår studie. Huvudkritiken mot denna, förutom att den inte är vetenskaplig, är att antalet intervjuade utvecklare är lågt, vilket gör det svårt att dra generella slutsatser.
Vi har även upplevt det relevant för vår studie att studera litteratur med koppling till systemutvecklingens historik, hur rollen utvecklats samt vilken problematik som finns kopplad till systemutveckling. Även här har vi använt de tidigare nämnda databaserna: Web
14 of Science, Scopus samt IEEE, med olika sökkombinationer av orden “software developer”, “development”, “history”, “evolution”, “platforms” och “failed software projects”. Genom dessa sökningar har vi hittat artiklar som beskriver den generella utvecklingen inom
systemutveckling sedan 1960-talet fram till idag, samt problematik inom området. Även dessa artiklar filtrerades så att endast artiklar som var peer-reviewed visades. De sorterades via relevans och valdes med hänseende till titel och abstract. Vad gäller ålder på källorna har detta bedömts olika med hänseende till vilken information källan bidrar med. Eftersom det är historisk utveckling som skildras har vi inte haft något fokus på att enbart ta med nya källor. Alla källor som använts i studien är dock inte kopplade till forskning eller studier på
universitetsnivå. På vissa områden har vi haft svårt att hitta denna typ av källor, eller inte sett behovet av detta. Det gäller främst den statistik och de tekniska framtidsspaningar som lyfts i inledningen för att väcka läsarens intresse. Här har vi istället haft som utgångspunkt att källorna ska betraktas som välkända medier. Andra källor som finns med i studien, och som används med samma syfte, är low code-aktörernas egna hemsidor. När fakta från dessa lyfts i studien är vi extra noga med att påvisa deras roll som intresseorganisationer. Detta görs främst i inledningen där vi påvisar att informationen kommer från “low code-aktörerna själva”.
4.3 Datainsamlingsmetod
Vi har, som tidigare nämnts, valt att göra en kvalitativ studie där vi har samlat in data genom intervjuer. Detta val gjordes tidigt under studiens uppstartsfas och grundar sig i karaktären på vår forskningsfråga, vilken inte har som avsikt att generera direkt mätbara resultat och därför blir kvantitativa insamlingsmetoder olämpliga för vår studie (Oates, 2006). Enligt Bryman (2011) möjliggör kvalitativa intervjuer detaljerade och breda svar, vilket är vad vi är ute efter i vår studie.
Vidare upplevde vi det mest lämpligt för vår studie att genomföra intervjuer av
semistrukturerad karaktär, eftersom vi ville ha breda svar på ett antal i förhand specificerade frågor. Semistrukturerade intervjuer beskrivs som öppna frågor där respondenterna fritt kan prata om frågans ämne och lägga tonvikt på det eller de områden som hen upplever mest relevanta (Oates, 2006). Vi upplevde detta som viktigt för vår studie eftersom vi hade som avsikt att spegla respondenternas inställning och motivation till yrket och att dessa faktorer kan yttra sig på olika sätt för olika respondenter. En respondent kanske brinner mer för en
15 specifik fråga och vi vill då att hen ska få utrymme för att redogöra det. En ostrukturerad intervju beskrivs som ett öppet samtal kring ett ämne, utan specificerade frågor, och en strukturerad intervju beskrivs ha utgångspunkt i att få svar på kvantitativa frågor (Oates, 2006).
4.3.1 Alternativa datainsamlingsmetoder
En alternativ datainsamlingsmetod för vår studie hade kunnat vara en enkätundersökning. Oates (2006) beskriver dock enkätundersökningar som bäst lämpade för insamling av
kvantitativ och mätbar data. Vi bedömer vår frågeställning vara av en bredare karaktär. Vi ser därför ett behov av att, utöver de faktiska svaren, även fånga upp attityder och känslor hos utvecklarna. Vi gjorde därmed bedömningen, att trots intervjuer kräver mer tid och ger mindre insamlad data, är detta en mer lämplig insamlingsmetod för vår frågeställning.
Ytterligare en alternativ insamlingsmetod är att genomföra observationer, då vi är intresserade av att se hur arbetsförhållanden och förutsättningar ändrat sig. Oates (2006) definierar en observation som att iaktta vad andra gör, vilket i sin tur kan utföras på olika sätt beroende på fokusområde. Här har vi dock en begränsning i den pågående covid-19-pandemin. Vi tror även att det skulle vara svårt att hitta liknande projekt att följa för att jämföra low code-utveckling med traditionell code-utveckling, utan att andra utomstående faktorer och skillnader skulle spela in.
4.4 Urval av respondenter
Vi har arbetat med ett målstyrt urval i vår studie. Målstyrt urval innebär att respondenter som bedöms besitta specifik kunskap inom det aktuella forskningsområdet väljs ut för att delta i studien (Bryman, 2011). I vår studie har vi valt att intervjua systemutvecklare som tidigare arbetat med traditionell utveckling och gått över till att arbeta med low code-utveckling. Valet av respondenter baseras på att dessa personer sett båda sidorna och därmed bedöms besitta erfarenheter som är relevanta att fånga upp och koppla till vår forskningsfråga.
Vid intervjuerna har det senare visat sig att två av respondenterna enbart kommit i kontakt med traditionell utveckling under studietiden, ej inom arbetslivet. Denna miss har troligtvis uppstått då vi inte specificerat vikten av tidigare arbetslivserfarenheter då vi beskrivit behovet av respondenter till vår initiala kontaktperson (mer om etablering av kontakt finns under 4.5
16
Tillvägagångssätt). I studien har dessa två respondenter fått jämföra low code med traditionell utveckling genom att utgå från sina studieerfarenheter.
4.5 Tillvägagångssätt
Kontakt med respondenterna togs via en tidigare arbetsgivare. Utifrån denna kunde även fler kontakter på ytterligare en arbetsplats etableras. Detta möjliggjorde en större spridning av erfarenheter hos respondenterna, bland annat tack vare att företagen använder olika low code-plattformar. Respondenterna kontaktades via mejl och vi bad dem att återkoppla till oss med lämpliga tider för intervjuer. Initialt kontaktades sex respondenter på företag X, den tidigare arbetsplatsen, och två på företag Y. Företag X är ett logistikföretag med en egen
utvecklingsavdelning, varav de flesta anställda är konsulter från IT-konsultbolag. Företag Y är ett IT-konsultbolag. Totalt ställde sex respondenter upp på att intervjuas, fyra från företag X och två från företag Y. Intervjuerna tog mellan 25 - 45 minuter och genomfördes via Google Meet samt var spridda över ungefär en veckas tid.
Vi valde att spela in intervjuerna och att sedan transkribera dem eftersom vi utgick ifrån att detta skulle vara en fördel vid analysen. Oates (2006) menar att det förenklar genomsökning och analys av insamlad data om denna finns i textform. Eftersom intervjuerna var förlagda spritt under en cirka en vecka har vi transkriberat dem löpande och delat upp arbetet inom uppsatsgruppen.
4.6 Teoretisk utgångspunkt
Under teorikapitlet har vi gått igenom att Kellers motivationsmodell kan användas för att studera motivation. Modellen bygger på fyra viktiga förhållanden för att skapa och behålla motivation. Dessa är Attention, Relevance, Confidence och Satisfaction. De kan som nämnts kopplas till motivation vid inlärning men vi ser även en koppling till den motivation som vi vill studera, det vill säga motivation till en yrkesroll. Vi upplever att förhållandena är relevanta för vår studie, då vi har som syfte att påvisa förändringar i systemutvecklaryrket. Här ser vi utvecklarnas motivation som en viktig del, kopplat till hur de tar sig an övergången till att utveckla via low code-plattformar. Vi har därför valt att använda denna modell som en grund för att samla in och analysera data genom att utforma våra frågor utifrån den.
Vi upplever dock inte att Kellers teori är tillräcklig för att utforma och analysera alla frågor och svar utifrån forskningsfrågan. Det vi upplever saknas i modellen är en koppling till
17 omvärlden. Vi har därför kontextualiserat modellen genom att placera den i ett sammanhang då vi även känt ett behov att studera utvecklarnas roll inom den verksamhet de utvecklar till. Hit kopplas tidigare forskning om anveckling, systemutvecklingens historik och misslyckade systemutvecklingsprojekt.
Bild 4. Kontextualisering av Kellers motivationsmodell. Den gröna cirkeln symboliserar omvärlden, vilket i vårt fall är verksamheten som utvecklaren utvecklar till. Källa till ursprunglig modell: IS Theory, u.å.
4.7 Intervjudesign
Vid utformning av intervjufrågor har fokus legat på att skapa frågor som bidrar till att analysera och besvara forskningsfrågan. Målet med intervjuerna är att kartlägga eventuella skillnader i motivationen hos utvecklarna efter övergången till low code och utifrån dessa kunna dra en slutsats om huruvida en förändring av systemutvecklarrollen skett. För att grunda och strukturera arbetet har kontextualiseringen av Kellers modell använts vid utformningen av intervjufrågorna samt vid analys av svaren på dessa.
Vid utformningen av intervjufrågorna, se Bilaga 1, har vi utgått ifrån att alla frågor ska vara relevanta och kunna kopplas till minst en av de fyra ursprungliga förhållandena i Kellers modell, alternativt till omvärldsförhållandet. På detta sätt har teorin brutits ner utifrån de fyra motivationsförhållandena, och omvärlden har vid intervjutillfället fått utgöra ett eget
förhållande. Frågorna har dock inte ställts i ordning där de är uppdelade efter förhållande, utan i den ordning som vi upplevde skulle passa intervjuflödet bäst.
18 Många av våra frågor handlar om att respondenterna ska jämföra olika faktorer i sin
nuvarande yrkesroll inom low code med tidigare erfarenheter där de arbetat med traditionell programmering. Att frågorna är ställda på detta sätt grundar sig i vårt syfte att kartlägga förändringar i yrkesrollen vid övergången till low code. Nedan redogörs för utformningen av intervjufrågorna under respektive förhållande.
Attention - Frågor kopplade till att fånga och behålla uppmärksamhet.
Under detta förhållande formuleras frågor om respondenternas bakgrund, intressen samt studie- och yrkesbakgrund. Här återfinns frågor som inte är direkt kopplade till low code utan istället med fokus på anledningar till att utvecklarna har valt sitt yrkesområde. Svaren är tänkta att kopplas tillbaka till i analysen och om dessa anledningar fortfarande är aktuella inom low code-utveckling. Här behandlas vilka delar av arbetet som utvecklarna tycker är roligast och vad de själva tror gör dem till bra utvecklare. Även dessa svar har tänkt att
användas i analysen med fokus på om low code-utveckling fortfarande tillhandahåller de delar och moment som utvecklarna framhåller som roliga. Enligt Keller (1987) är det viktigt för uppmärksamheten att uppgifter upplevs som roliga. Vidare har attention-förhållandet behandlat variation i arbetet då detta bidrar till att uppgifter upplevs som just roliga och inte uttråkande och därmed bedöms ha en positiv inverkan på uppmärksamheten.
Relevance - Frågor kopplade till arbetsuppgifternas relevans.
För att kunna analysera relevansen av arbete inom low code-plattformar kopplas detta till utvecklarnas tidigare arbetslivserfarenheter samt utbildningsbakgrund. Frågor som formuleras och ställs här har som avsikt att fånga upp hur utvecklarnas tidigare erfarenheter från arbeten och studier bedöms användbara vid arbete inom low code-utveckling. Enligt Keller (1987) upplevs relevansen för uppgifter högre om de går att relatera till och bygger vidare på tidigare kunskaper. Här har vi även valt att fråga hur länge utvecklarna arbetat med traditionell
utveckling respektive low code för att få en tydligare bild av vad de har för tidigare kunskaper och bättre kunna analysera relevansen.
Keller (1987) menar också att kopplingen mellan en uppgift och framtida användning av kunskapen denna ger påverkar hur relevant uppgiften uppfattas. Utifrån detta har vi valt att fråga respondenterna om hur de anser att sina erfarenheter av low code-plattformar är meriterade på arbetsmarknaden.
19
Confidence - Frågor kopplade till strävan att kännas sig kompetent och i kontroll. Enligt Keller (1987) är det viktigt att veta vad som förväntas av en och hur man förhåller sig till det. Teorin tar även upp vikten av svårighetsgrad och att denna förhåller sig på en lagom nivå. Här har vi frågat utvecklarna om vilka moment som de upplever är de svåraste inom sitt yrke och hur dessa påverkats av övergången till low code. Denna fråga ställdes för att analysera eventuell förändring i svårighetsgraden.
Under confidence-förhållandet har vi även ställt frågor om ifall utvecklarna upplever sitt arbete mer eller mindre utmanande och personligt utvecklande nu än vid utveckling med traditionell kod. Frågor har även ställts om huruvida de skulle föredra att gå tillbaka till traditionell kodning. Dessa frågor är tänkta att verka på en mer övergripande nivå. Tanken är att de ska ge indikationer, dels på svårighetsgraden i arbetet, dels på utvecklarnas upplevda känsla av kompetens och kontroll.
Satisfaction - Frågor kopplade till strävan att känna sig nöjd med sig själv och sin egen insats. Vi vill här ta reda på hur nöjda utvecklarna är med sin arbetssituation idag när de arbetar med low code jämfört med tidigare arbete inom traditionell utveckling. Keller (1987) påvisar att det är viktigt att känna sig nöjd med sina åstadkommanden. För att nå detta framhålls specifikt vikten av att arbetsuppgifterna ska vara väldefinierade och tydligt kunna knytas till belöning och bekräftelse. Inom detta förhållande har vi därför formulerat frågor kring respondentens arbetsbelastning och upplevd produktivitet för att se hur nöjda de är med sin arbetssituation. Här har vi även frågat respondenterna hur de fördelar sin arbetstid mellan olika moment samt vilka arbetsmoment som de upplever som mest tidsbesparande inom low code-utveckling jämfört med traditionell utveckling.
Vidare menar Keller (1987) att ovan faktorer kopplade till tydliga uppgifter och belöningar inte alltid är tillräckliga för att kunna känna sig nöjd med sin arbetsinsats. I dessa fall påvisas självbestämmande och kontroll över sin arbetssituation som viktigt, då för stor utomstående kontroll kan ta ner känslan av nöjdhet. Utifrån detta har vi även frågat respondenterna om hur de upplever frihet och självbestämmande i sitt yrke idag jämfört med tidigare. Här behandlas även om utvecklarna själva sökt sig till low code eller kommit in i det mer slumpmässigt.
Omvärld - Frågor kopplade till utvecklarnas plats i verksamheten. Dessa frågor är inte
20 Vid formulering av omvärldsfrågorna har vi utgått från att de ska fånga upp utvecklarnas relation till den verksamhet som de utvecklar till. Här ställs därför frågor om vilka andra yrkesgrupper respondenterna har kontakt med i sitt arbete och om en eventuell förändring av kontakten skett vid övergången till low code. Även mer specifika frågor om användare, användarutveckling och eventuella risker med användarutveckling tas upp. Tanken är att svaren ska kunna analyseras i förhållande till tidigare forskning om
systemutvecklingsproblematik och anveckling.
4.8 Analysmetod
Analysen har utförts utifrån studiens syfte och forskningsfråga. Utgångspunkten har varit att utifrån teori och tidigare forskning, analysera systemutvecklarens roll och motivation samt hur dessa förändrats vid övergången till low code. Vid genomförandet har analysen brutits upp i flera delar. Dels har Kellers ursprungliga motivationsförhållanden analyserats var för sig, för att se hur de har förändrats sedan övergången till low code. Sedan har respondenternas roll inom organisationen de utvecklar till analyserats som en egen del, inom vilken
förändringar av rollen även lyfts med koppling till motivation. Slutligen har en sammanfattning av analysen gjorts för att koppla samman delarna.
Vid analys av enskilda motivationsförhållanden har vi utgått från de intervjusvar vi fått under respektive förhållande och analyserat dem separat. Detta gjordes i syfte att kartlägga ökad, minskad eller oförändrad motivation vid övergången till utveckling inom low code. Att varje förhållande analyseras separat baseras på att fokus även legat på att lyfta bakomliggande faktorer till eventuella motivationsförändringar. Även motivationsförhållandena har brutits isär vid analysen eftersom de underliggande frågorna har visats påverka motivationen på olika sätt.
Studien har utöver de fyra ursprungliga motivationsförhållanden även haft ett uttalat fokus på utvecklarnas omvärld. Detta då det initialt fanns frågor om utvecklarnas kontakter och plats i organisationen som Kellers motivationsmodell inte gav något självklart utrymme för. Vid analys av omvärldsförhållandet har vi därför använt vår egen kontextualisering av Kellers modell, som beskrivs under 4.6 Teoretisk utgångspunkt, och inom vilken vi lagt kopplingar till tidigare forskning kring systemutvecklingens historik, systemutvecklingsproblematik och anveckling.
21 Studien använder den kontextualiserade motivationsmodellen för att specifikt analysera utvecklarens plats inom organisationen och deras relation till andra yrkesgrupper samt hur dessa förhållanden förändrats vid övergången till low code. Detta gjordes genom att utgå från intervjusvaren och tidigare forskning. Vissa delar som framkommit under denna del av arbetet har, i analysen, även kunnat kopplas mot ett eller flera att de tidigare nämnda
motivationsförhållandena.
4.9 Etik
Respondenterna kontaktades initialt via mejl, i detta skede fick de information om studiens syfte samt att deras deltagande var frivilligt. De fick själva återkoppla med lämpligt datum och tid för intervju och vi försökte även informera om ungefärlig tidsåtgång.
Vid inledningen av varje enskild intervju fick respondenterna ge sitt medgivande till eventuell inspelning av intervjun. De fick då även information om att studien efterföljer GDPR,
Dataskyddsförordningen, eftersom inga personuppgifter kommer att sparas samt att de inte kommer att nämnas vid namn i uppsatsen. Vidare har vi haft som utgångspunkt att bemöta respondenterna med respekt och intresse. Respondenterna fick även i slutet på intervjun möjlighet att komma med egna tankar och frågor ifall de kände att de vill lägga till något. Detta rekommenderas av Oates (2006) för att fånga upp eventuella oklarheter eller svar som respondenten vill ändra.
22
5. Resultat
5.1 Attention
Under attention behandlas varför respondenterna valde utvecklaryrket, utbildnings- och arbetslivsbakgrund samt vad de upplever som roligt och minst roligt med sina arbeten. Vidare behandlas vilka egenskaper hos dem själva som de tycker gör dem till bra utvecklare och om de uppfattar arbete inom low code som mer eller mindre monotont än tidigare arbete inom traditionell programmering.
Systemutvecklingsyrket har fångat respondenternas uppmärksamhet och intresse av olika individuella anledningar. Det är inte någon av respondenterna som beskriver
systemutveckling som ett självklart val från till exempel uppväxten. Samtliga respondenterna har testat andra yrkesbanor eller utbildningar tidigare och letat sig fram till yrket.
Respondenterna nämner dock kreativitet och problemlösning som huvudsakliga faktorer till att de valde sitt yrke. Hälften av respondenterna menar att de hållit på med datorer på fritiden och haft detta som ett intresse. Två av respondenterna nämner även att de ville satsa på ett yrke inom vilket de visste att det skulle finnas arbete.
Respondenterna har även tagit sig till yrket på olika sätt och deras utbildningsbakgrund kopplad till systemutveckling är spridd. Fyra av de sex respondenterna har
universitetsutbildning, varav tre läst informatik och en studerat dataspelsutveckling. De två övriga har intensivutbildningar inom programmeringen. Flera av respondenterna besitter även andra utbildningar inom olika områden. Även sett till arbetslivserfarenhet råder spridning hos de utvecklare vi intervjuat. Den respondent som jobbat längst inom systemutvecklaryrket har arbetat cirka 11 år, följt av en som arbetat i nio år. Två av respondenterna har arbetat i åtta år och de två nyaste har arbetat cirka två år inom yrket.
På frågan om vad som gör respondenterna till bra utvecklare har hälften av dem referat till sitt intresse för problemlösning. Andra respondenter är inne på samma spår men benämner detta som kreativitet och logiskt tänkande. Två av respondenterna nämner kommunikation och en följsamhet. Huvuddelen av resonemanget handlar om att nå den bästa lösningen och faktiskt anpassa lösningen till de som ska använda den. Att inte bara lösa problemet utan att lösa det på rätt sätt, kopplat till verksamhetsförståelse och förståelse för vilka följdverkningar olika lösningsalternativ har.
23 Med koppling till ovan nämner samtliga respondenter kreativitet, problemlösning och
skapandet som det roliga inom utvecklaryrket. Hälften av dem framhåller även sin del i kedjan och kontakten med dem som ska använda systemet. Att de bygger något som någon ska använda och att de får se till helheten och lösa någons problem. Detta benämns även som ett ansvar och som extra motiverande. Det som respondenterna uppger som minst roligt med arbetet är saker runt omkring själva systemutvecklandet och skapandet. Här nämns bland annat möten och dokumentation.
På frågan huruvida respondenterna upplever sitt arbete mer monotont eller varierade vid utveckling inom low code-plattformar jämfört med traditionell utveckling har fyra av sex respondenter svarat att arbetet är mindre monotont inom low code. Detta förklaras med att det redan finns färdiga lösningar i low code-plattformarna för att starta upp och sätta ihop
applikationer. Detta beskrivs annars som en av de mest monotona och tidskrävande
arbetsuppgifterna. En av respondenterna nämner även att low code-plattformarna underlättar de monotona arbetsuppgifter som kopplas till felsökning. En annan nämner att low code underlättar för att hen ska kunna arbeta i ett bredare spektrum från front end till back end. En respondent har dock svarat att hen inte märker någon skillnad alls vad gäller variation av arbetsuppgifter och en annan har svarat att hens arbete är betydligt mer monotont nu inom low code än tidigare. Hen kopplar dock detta till andra faktorer såsom arbete inom projekt
respektive arbete inom förvaltning.
5.2 Relevance
Under relevance behandlas huruvida respondenterna upplever sina low code-kunskaper meriterande på arbetsmarknaden samt hur de upplever sina tidigare arbetslivserfarenheter och utbildningar relevanta vid low code-utveckling. Till detta förhållande har vi även kopplat hur länge respondenterna arbetat med low code respektive traditionell utbildning, vilket först avhandlas kort.
Arbetslivserfarenhet inom traditionell utveckling skiljer sig väldigt mycket mellan respondenterna och kan delas upp i två läger. De som arbetat längst med detta har arbetat cirka åtta till nio år medan de som arbetat kortast i princip inte har någon arbetslivserfarenhet alls, utan har enbart erfarenhet av projekt med traditionell utveckling från utbildningen,
24 alternativt några månaders arbete ute på företag. När det kommer till arbetslivserfarenhet inom low code är svaren mer likartade då samtliga utvecklare har arbetat cirka ett till två år med detta.
Ett par av respondenterna tyckte att frågan om huruvida low code är meriterade på arbetsmarknaden var svår att besvara och menade att detta har att göra med vilken typ av arbete som sökes. Vi riktade i dessa fall om frågan, mot utbud och efterfrågan av low tjänster. Det övergripande svaret här är att det inte finns något överflöd av varken low code-utvecklare eller lediga low code-tjänster på den svenska arbetsmarknaden idag. En av respondenterna pekar utomlands mot USA och övriga Europa och menar att där är low code betydligt mer utbrett och erfarenhet av detta är därför mer eftertraktat där. Flera av
respondenterna menar att det kommer att bli meriterande på den svenska arbetsmarknaden inom kort. Detta baserar de dels på rapporter inom branschtidningar och liknande, dels på egna erfarenheter av hur low code ökat produktiviteten i utvecklingsarbetet. En av
respondenterna påpekar dock att erfarenhet av traditionell programmering är mer meriterande än av low code även vid low code-utveckling. Hen menar att det är viktigt att förstå grunderna men påpekar att hen själv inte arbetat så länge med low code än.
Samtliga respondenter uppger att utbildningar eller arbetslivserfarenhet inom traditionell programmering fortfarande är relevant eller till och med avgörande vid utveckling inom low code-plattformar. Förklaringarna till relevansen av erfarenhet av traditionell programmering är att saker och ting fortfarande heter och byggs upp på samma sätt som tidigare. Utvecklaren behöver därför känna till begrepp som loopar, if-satser, listor och iterationer samt hur dessa används. Hen behöver alltså fortfarande veta att “här behövs en loop”, skillnaden är bara att den kan dras dit istället för att den ska skrivas med kod.
Vidare nämns att low code-utveckling fortfarande är en form av systemutveckling och att planeringen bakom hur applikationer sätts ihop fortfarande är densamma. Respondenterna benämner detta lite olika men syftar alla till strukturen bakom applikationen. En respondent påpekar att det även går att bygga dåliga applikationer i low code och att det därför behövs bra systemutvecklare och bra analytiker. En annan respondent menar att low code är som vilken systemutveckling som helst, bara lite finare paketerad samt att en del kommer på köpet. Just planering och systemutformning är dock återkommande begrepp som nämns för att förklara relevansen av tidigare erfarenheter inom traditionell utveckling. En respondent
25 nämner även felsökning vid eventuella buggar. En annan diskuterar utbildning inom
kravhantering och test och att dessa delar av systemutveckling inte skiljer sig åt vid low code-utveckling.
Vidare nämns att low code-utveckling heller inte utesluter traditionell programmering och att de flesta utvecklare som arbetar med low code idag faktiskt arbetar med en blandning.
5.3 Confidence
Under confidence behandlas om respondenterna skulle föredra att gå tillbaka till att arbeta med traditionell kod istället för low code. Här behandlas även om arbetet upplevs som mer eller mindre utmanande och personligt utvecklande än tidigare samt vilka de svåraste arbetsuppgifterna är, och om dessa har förändrats sedan övergången till low code. Ingen av respondenterna förespråkar ett alternativ där de endast arbetar med low code-plattformar, utan menar att det finns fördelar med både traditionell kod och low code, och de kan tänka sig att arbeta med båda. Två av de sex respondenterna tar upp att de fortfarande arbetar både med traditionell kod och low code i low code-plattformen, eftersom plattformen de arbetar i är väldigt kodnära. En respondent tar även upp att low code inte ersätter all kodning, utan att det fortfarande finns viss kodning kvar i arbetet.
Hälften av respondenterna anser att arbetet de utför är ungefär lika utmanande nu som tidigare, när de inte arbetade med low code. En respondent uppger att arbetet är mer utmanande nu, men denne menar att detta även beror på att uppgifterna hen utför har förändrats, och inte på plattformen i sig. Ytterligare en respondent menar att skillnaden i utmaningsgrad beror på arbetsuppgifterna och inte plattformen.
Flera respondenter tar upp att de svåraste momenten inom systemutveckling är kravhantering och kommunikation med kund, vilka beskrivs varit de svåraste momenten även före
övergången till low code. Respondenterna nämner även att det är de enklare delarna av systemutveckling som har blivit ännu enklare med low code, och att de svåraste delarna är oförändrade. Detta förklaras med att det är att bygga rätt system med rätt funktionalitet anpassat till verksamhetens och användarnas behov som är det svåra. Dessa delar hjälper inte low code till med, utan de förblir svåra oavsett plattform, förklarar en av respondenterna.
26 Det är blandade uppfattningar mellan respondenterna kring huruvida de upplever sitt arbete mer eller mindre personligt utvecklande nu när de arbetar med low code. Fyra av sex respondenter märker ingen direkt skillnad utan uppfattar situationen likvärdig med tidigare. De andra respondenterna svarar att det är upp och ner, och att det beror mer på vilket projekt de arbetar i och vilken roll de har i det, än på utvecklingsplattformen.
5.4 Satisfaction
Under satisfaction behandlas hur respondenterna upplever möjlighet till självbestämmande i sitt arbetet, produktivitet och arbetsbelastning. Här behandlas även hur respondenterna fördelar sin arbetstid mellan olika moment och vilka arbetsuppgifter som respondenterna upplever är mest tidsbesparande efter övergången till low code. Sedan behandlas
anledningen till att de idag arbetar med low code, och om detta är självvalt eller inte. Angående hur respondenterna uppfattar möjligheten till självbestämmande skiljer sig deras åsikter åt. Hälften av dem anser att det inte blivit någon skillnad sedan övergången till low code utan anser att deras arbete som utvecklare innebär frihet under ansvar oavsett vilken plattform systemutvecklingen sker på. Två av sex respondenter anser att de har mer frihet i sitt arbete nu på grund av att systemutvecklingen går fortare och att det är lätt att göra ändringar i designen för applikationer. De upplever därför att de har en större frihet kring att göra dessa ändringar och även att anpassa dem efter kunden. En respondent menar att det också beror på vilken typ av uppdrag hen är involverad i och även hur uppdragsgivaren är. Alla respondenter är överens om att systemutvecklingen genom low code är snabbare jämfört med traditionell utveckling. Åsikterna kring om de själva blivit mer produktiva sedan de började arbeta med low code går isär. Hälften av respondenterna anser definitivt att de blivit mer produktiva, då low code-plattformarna hjälper till att effektivisera moment som tidigare var mycket tidskrävande. Det är även möjligt att återanvända tidigare lösningar, vilket också innebär att systemutvecklingen går fortare. En respondent är tudelad i sin åsikt angående produktivitet men beskriver istället att värdet till kund är högre nu, eftersom det går snabbare att ta fram lösningsförslag på de behov verksamheten gett uttryck för. Två respondenter upplever dock ingen ökad produktivitet i sitt eget arbete men menar att det beror på dem själva. Att de inte arbetat med low code tillräckligt länge eller har lika stor kunskap kring det, för att vara lika effektiva som när de arbetade med traditionell programmering.
27 Åsikterna kring respondenternas arbetsbelastning varierar något. En respondent upplever något högre arbetsbelastning eftersom det går så fort att visa på resultat med low code och att det då skapas en större efterfrågan på produkter från kunderna, vilket i sin tur leder till ett högre tempo. En annan respondent menar att även om de producerar i ett högre tempo nu så anpassar de sin arbetsbelastning kring det för att inte stressa för mycket och upplever därför ingen större skillnad. De övriga respondenterna anser inte heller att det är någon skillnad i arbetsbelastningen, beroende på om de arbetar med low code eller traditionell programmering. De upplever istället att arbetsbelastningen är kopplad till vilket typ av projekt de är
involverade i för tillfället och vilken roll de har i det.
På frågan om hur respondenternas arbetstid är fördelad mellan olika moment skiljer sig svaren en del mellan respondenterna. En respondent tar upp att tack vare de snabba förändringarna som kan göras med low code har hen nu mer kontakt med kunden, eftersom nya funktioner kan visas och diskuteras oftare. En annan respondent tar upp att det nu går åt mindre tid till att faktiskt utveckla systemen och att mer tid istället går till att tänka ut bra lösningar. Fyra av sex respondenter menar dock att vad de behöver lägga sin tid på inte är beroende av
utvecklingsplattform utan varierar mellan olika projekt och vilken fas av projektet de är i. På frågan om vilka arbetsuppgifter som är mest tidsbesparande med low code tar
respondenterna upp några olika arbetsuppgifter. En respondent menar att de flesta
arbetsuppgifterna är tidsbesparande men tar specifikt upp att hen sparar mycket tid på att inte gå för långt åt fel håll, eller skapa system som inte stämmer överens med vad kunden
efterfrågar. Detta eftersom hen oftare kan visa upp vad som gjorts och kan stämma av det med kunden. En annan respondent tar upp att det är just utvecklingsfasen som är mest
tidsbesparande, kravhanteringen och kommunikationen med verksamheten tar ungefär lika lång tid som innan. Flera av respondenterna menar att i princip allt med low code är
tidsbesparande, men framförallt vid utveckling av mindre komplexa applikationer, eftersom det då kommer många delar med på köpet, och att dessa inte behövs läggas in manuellt. Vid utveckling av mer komplexa applikationer kan low code-plattformarna upplevas begränsande då de inte tillhandahåller färdiga lösningar för det. Det blir då mer invecklat att anpassa standardlösningen från low code-plattformen än att skapa en egen lösning från grunden.
28 Fyra av sex respondenter uppger att det till stor del är en slump att de arbetar med low code. Att de inte hade någon direkt koll innan på vad detta innebar utan att de istället sökt sig till företag som de velat arbeta hos och då hamnat inom low code-utveckling. Två av utvecklarna uppger att de mer aktivt sökt arbete inom low code. En av dessa menade att hen tyckte att det var intressant att hoppa på något nytt, medan det fortfarande var i sin linda. Den andra uppgav att hen sökt ett low code-arbete då hen utifrån uppfattat detta som ett smidigare och mer friktionslöst sätt att utveckla system på.
5.5 Omvärlden
Under omvärlden behandlas vilka kollegor och yrkesgrupper som respondenterna har mest kontakt med i sina arbeten och hur kontakten förändrats sedan övergången till low code. Här lyfts även respondenternas syn på användarutveckling och eventuella risker med detta tas upp.
På frågan om vilka kollegor och yrkesgrupper respondenterna har kontakt med i sina arbeten har svaren innefattat alla som kan tänkas vara delaktiga i det projektet, det vill säga allt från chefer och projektledare till slutanvändare. Storleken på projektet och utvecklarens egen roll inom projektet uppges ha stor betydelse för vilka kontakter som behövs upprätthållas. Om utvecklingen sker via traditionell programmering eller low code uppges dock inte ha någon speciell betydelse för vilka yrkesgrupper som utvecklarna har kontakt med.
Hälften av respondenterna har svarat att de arbetar närmare användarna vid low code-utveckling, att mötena blir tätare och att användarna har kommit närmare
utvecklingsprocessen. Detta baseras på att det med hjälp av low code är enklare att kontinuerligt visa användarna vad som utvecklats, eftersom low code är mer visuellt och lättare för användarna att ta till sig. Respondenterna nämner även att de till exempel suttit tillsammans med användarna och gjort ändringar direkt i programmet, vilket tidigare inte varit möjligt. Tre respondenter ser inte någon skillnad i hur nära de arbetar med användarna. En av dem menar dock att detta beror på att även hens tidigare arbete innefattade mycket
kundkontakt och det har därför inte förändrats sedan hen började med low code.
Respondenternas synpunkter på användarutveckling och huruvida användare skulle kunna utveckla system själva skiljer sig åt. En respondent menar att bara för att low code är lätt att använda innebär inte det att användare, utan någon förståelse för systemutveckling, kan
29 utveckla bra system. De kanske kan utveckla mer simpla delar av en applikation, men utan tänket som en utvecklare har blir det svårt att bygga något mer avancerat. En annan
respondent tror att dagens low code-plattformar fortfarande är för avancerade att förstå för en användare utan programmeringskunskap, men att de säkert kommer bli lättare i framtiden. Två respondenter berättar även om projekt inom vilka vanliga användare får utveckla
applikationer genom low code. De har då en mentor med utvecklarbakgrund som hjälper dem att kontrollera att applikationerna fungerar som de ska. Respondenterna upplever att dessa projekt verkar fungera bra. En av respondenterna påpekar att det inte alltid är lätt att förstå precis vad en verksamhet vill ha. Om då användarna kan utveckla vissa enklare delar av applikationen själva och därmed påvisa vad de vill ha, är detta mycket positiv för
slutprodukten. En annan respondent menar att, även om low code-plattformarna troligtvis inte kommer kräva någon programmeringskunskap i framtiden, kommer det alltid finnas behov av utvecklare med programmeringskunskaper, bland annat för att utveckla själva plattformarna. Behovet av utvecklare kommer därför inte att försvinna helt.
Alla respondenter är överens om att det finns risker med att användare själva utvecklar system. Två respondenter nämner att det är en risk ifall det byggs system utan förståelse för vad det är som byggs och utan logiskt tänk bakom. Detta kan bland annat leda till att
systemen blir ineffektiva. En respondent menar att det är lätt att bygga system, men att det är svårare att tänka på att få med alla aspekter som gör ett system bra. Användarutveckling utan övervakning påpekas även kunna leda till att liknande funktioner utvecklas inom samma företag, utan att den funktionalitet som redan finns återanvänds. Ytterligare en risk, som tas upp, är att det kan bli väldigt tidskrävande att försöka rätta till de fel som kan uppstå när ett system byggs utan logisk struktur. En annan respondent menar även att det kan vara en risk om det byggs system av användare som inte vet hur de ska lösa säkerheten i systemet.
30
6. Analys
I ovan kapitel har vi presenterat resultatet utifrån vårt teoretiska ramverk, där sker dock ingen analys av motivationsförhållanden eller utvecklarnas omvärld. Dessa delar återfinns istället här. Inom detta kapitel analyseras det resultat som presenterats med koppling till motivationsförhållandena var för sig. Sedan analyseras utvecklarnas omvärld mer flytande med koppling till motivation samt förändringar i relationen till användarna. Kapitlet avslutas med en sammanfattande analys av hur övergången till low code påverkar och förändrar motivationen samt systemutvecklarrollen.
6.1 Analys av motivationsförhållanden
Attention
Studiens resultat visar att utvecklarnas uppmärksamhet är ungefär densamma som tidigare. Detta baseras mestadels på att respondenterna sökt sig till yrket för att få utlopp för sin kreativitet och problemlösningsförmåga, vilket även uppges vara det roligaste med yrket. Utifrån vad som framgått i resultatet har de roliga momenten inte förändrats av övergången till low code, respondenterna får således fortfarande utlopp för dessa på en likvärdig nivå. Enligt Keller (1987) är stimulans och att uppgifter upplevs roliga viktigt för att fånga och behålla uppmärksamhet. En viss ökning av motivationen kan även urskönjas då
respondenterna menar att de får mer tid för de roligaste momenten. Samma fenomen påvisas även i Dahlbergs studie (2020), eftersom utvecklarna inom low code slipper mycket av de monotona arbetsmomenten. Även detta kan kopplas tillbaka till teorin, då Keller (1987) menar att variation i arbete gör att arbetsuppgifter upplevs roligare, vilket i sin tur leder till ökad uppmärksamhet.
Relevance
Utifrån studiens resultat har de flesta respondenter liknande användning för sina tidigare arbetslivserfarenheter och utbildningar vid arbete inom low code. Deras tidigare kunskaper inom traditionell utveckling ses absolut inte som onödiga eller bortkastade. Enligt Keller (1987) är en viktig del av relevansen att uppgifter ska kunna kopplas till tidigare erfarenheter. Utifrån detta förblir relevansen densamma eftersom respondenterna inte ser någon direkt skillnad i användningen av sina tidigare kunskaper.
