Systemutvecklares syn på användarmedverkanvesterdahl.se/c-uppsats/C-Uppsats.pdf · MÄLARDALENS HÖGSKOLA Ekonomihögskolan C-uppsats i informatik, 10 p, VT2004 Eskilstuna, 2004-06-09

MÄLARDALENS HÖGSKOLA Ekonomihögskolan C-uppsats i informatik, 10 p, VT2004 Eskilstuna, 2004-06-09 Handledare: Theresia Olsson Neve

Författare: Christian Bleckert 771119 Karin Sundin 770131 Calle Vesterdahl 790319

Systemutvecklares syn på användarmedverkan

Sammanfattning

Behovet av användare, som en central och viktig del i utvecklingen av datorsystem, är idag allmänt accepterat. Systemutvecklingsprojekt har tidigare fokuserat på vilka funktioner som skall levereras med ett system. Idag är kraven högre från användarna och ledningen, då företag inriktar sig mer och mer på att lösa komplicerade affärsproblem och strävar efter att bli mer flexibla i sin organisation. Trots att tidigare studier och undersökningar som uppsatsförfattarna tagit del av pekar på att användarmedverkan är bra och bidrar till att systemet blir en tillfredställande slutprodukt, finns det ändå indikationer på att det inte alltid är bra med användarmedverkan. Med anledning av ovanstående har uppsatsförfattarna valt att undersöka systemutvecklares syn på användarmedverkan. Syftet med uppsatsen är att undersöka om systemutvecklare på företag upplever att användarmedverkan ses som ett negativt tillskott i systemutvecklingen och i sådana fall i vilka utvecklingsfaser samt på vilket sätt. Uppsatsens teori bygger på åtta vetenskapligt granskade artiklar och en populärvetenskaplig bok som alla tar upp användarmedverkan i någon form. Litteraturen tar även upp nackdelar med användarmedverkan. I materialet, utifrån vilken undersökningsmodellen har skapats, har olika faktorer påträffats vilka kan bidra till att användarmedverkan kan försämra utvecklingsarbetet. Dessa faktorer är Organisation och ledningens support, Typ av inblandning, Nivå i utvecklingen, Grad av inflytande, Kommunikation, Terminologi, Attityd och Systemkomplexitet . Undersökningen är en kvalitativ studie med åtta halvstrukturerade öppna intervjuer. Respondenterna arbetade på företag som alla ligger inom Mälardalen av varierande storlek. Respondenterna hade alla goda erfarenheter av användare och resultatet visar att användarmedverkan trots allt ses som någonting positivt i systemutvecklings-arbetet. Resultatet visade även att uppfattningen om hur skadligt och överflödig användarmedverkan kan vara i olika faser är individuellt. Trots detta svarande nästan alla respondenter att programmeringsfasen var den fas där användarmedverkan ses som mest överflödig. Alla hade dock olika syn på hur det kan vara överflödigt.

INNEHÅLLSFÖRTECKNING SAMMANFATTNING..................................................................................................................................1 1 INLEDNING.................................................................................................................................................4 1.1 BAKGRUND.......................................................................................................................................... 4 1.2 ANVÄNDARMEDVERKAN................................................................................................................... 4 1.3 PROBLEMATISERING.......................................................................................................................... 6 1.4 PROBLEMFORMULERING................................................................................................................... 6 1.5 SYFTE................................................................................................................................................... 6 1.6 AVGRÄNSNING.................................................................................................................................... 6 2 TEORI............................................................................................................................................................7 2.1 GENERELLT ......................................................................................................................................... 7 2.2 GULLIKSEN OCH GÖRANSSON, ANVÄNDARCENTRERAD SYSTEMDESIGN.................................. 7 2.3 MCKEEN OCH GUIMARES, SUCCESSFUL STRATEGIES FOR USER PARTICIPATION

IN SYSTEMS DEVELOPMENT ............................................................................................................. 8 2.4 MOTIVERING AV TEORI.................................................................................................................... 10 3 METOD........................................................................................................................................................13 3.1 INSAMLING AV SEKUNDÄRDATA.................................................................................................... 13 3.2 INSAMLING AV PRIMÄRDATA.......................................................................................................... 13 3.3 VAL AV METOD................................................................................................................................. 13 3.4 URVAL ............................................................................................................................................... 13 3.4.1 Intervjuundersökning..........................................................................................................................14 3.5 METODKRITIK................................................................................................................................... 14 3.6 KÄLLKRITIK...................................................................................................................................... 15 3.6.1 Primära källor......................................................................................................................................15 3.6.2 Sekundära källor..................................................................................................................................15 3.7 UNDERSÖKNINGENS RELIABILITET OCH VALIDITET.................................................................... 15 4 RESULTAT ................................................................................................................................................17 4.1 RESPONDENTERNA........................................................................................................................... 17 4.2 GENERELLT OM ANVÄNDARMEDVERKAN..................................................................................... 18 4.3 ORGANISATION OCH LEDNINGENS SUPPORT ................................................................................ 21 4.4 TYP AV INBLANDNING..................................................................................................................... 22 4.5 UTVECKLINGSFAS ............................................................................................................................ 23 4.6 GRAD AV INFLYTANDE .................................................................................................................... 25 4.7 KOMMUNIKATION............................................................................................................................ 27 4.8 TERMINOLOGI ................................................................................................................................... 29 4.9 ATTITYD ............................................................................................................................................ 30 4.10 SYSTEMKOMPLEXITET..................................................................................................................... 32 5 ANALYS ......................................................................................................................................................34 5.1 GENERELLT OM ANVÄNDARMEDVERKAN..................................................................................... 34 5.2 ORGANISATION OCH LEDNINGENS SUPPORT ................................................................................ 35 5.3 TYP AV INBLANDNING..................................................................................................................... 35 5.4 UTVECKLINGSFAS ............................................................................................................................ 36 5.5 GRAD AV INFLYTANDE .................................................................................................................... 37 5.6 KOMMUNIKATION............................................................................................................................ 37 5.7 TERMINOLOGI ................................................................................................................................... 38 5.8 ATTITYD ............................................................................................................................................ 38 5.9 SYSTEMKOMPLEXITET..................................................................................................................... 39 6 SLUTSATSER ...........................................................................................................................................40 6.1 ANVÄNDARMEDVERKAN SOM ETT NEGATIVT TILLSKOTT.......................................................... 40 6.2 UTVECKLINGSFAS ............................................................................................................................ 41 6.3 HUR ANVÄNDARMEDVERKAN UPPLEVS AV SYSTEMUT VECKLARNA........................................ 41 7 FORTSATT FORSKNING....................................................................................................................43

KÄLLFÖRTECKNING BILAGA 1 -INTERVJUFRÅGOR

BILAGA 2 - INTERVJU 1








MÄLARDALENS HÖGSKOLA Ekonomihögskolan - Inledning -

4

1 Inledning

Många företag använder idag någon form av informationssystem (IS) 1 i sin verksamhet, t.ex. affärssystem för att sköta order och fakturering. Förr eller senare hamnar företaget i ett läge när de står inför beslutet att antingen vidareutveckla det befintliga systemet eller införa ett helt nytt system. Idag är behovet av användare, som en central och viktig del i utveck lingen av datorsystem, allmänt accepterat. I början av 1980-talet gavs behovet av användarmedverkan låg prioritet. En vanlig anledning till denna försummelse är att det var på slutet av 1970-talet som användandet av datorsystem verkligen började sprida sig till större grupper av befolkningen. En annan anledning är det faktum att de flesta stora företagen som arbetade med systemutveckling hade skapat en lämplig struktur för organisationen långt innan behovet av användare var satt i fokus. (Ljung, Allwood, 1999)

1.1 Bakgrund

Systemutvecklingsprojekt har tidigare fokuserat på vilka funktioner som skall levereras med ett system. Idag är det högre krav från användarna och ledningen, då de beställande företagen inriktar sig mer och mer på att lösa komplicerade affärsproblem och strävar efter att bli mer flexibla i sin organisation. Historiskt sett har informationstekniken koncentrerats mot enskilda användare eller enheter och deras behov. Utvecklingen inriktade sig då på vad systemet ska klara av, inte vad systemet ska bidra till, dvs. användarnas mål med arbetet. Tidigare studier inom området har visat att de flesta slutanvändare önskar medverka i utvecklingen mer än de verkligen har tillåtelse till. (Doll, Xiaodong, 2001) Trots att tidigare studier och undersökningar inom området som uppsatsförfattarna tagit del av, pekar på att användarmedverkan är bra och är en viktig orsak till att systemet blir en tillfredställande slutprodukt, finns det ändå antydningar på att användarmedverkan inte alltid är bra. McKeen och Guimares (1997) skriver ”Trots de potentiella fördelarna är användarmedverkan ingen universallösning. Det finns många situationer där användarmedverkan till och med kan vara kontraproduktivt” (s. 134, egen översättning).

1.2 Användarmedverkan

Det finns olika definitioner av användarmedverkan. McKeen (1994) definierar användarmedverkan på följande sätt: ”… de olika designrelaterade rollerna och aktiviteter som slutanvändarna, eller de som representerar dem, utför under systemutvecklingsprocessen.” (s. 428, egen översättning). Hartwick och Barki (2001) definierar istället användarmedverkan på detta sätt: ”… användarmedverkan inkluderar alla utvecklingsrelaterade aktiviteter utförda av användarna under utvecklingsarbetet.” (s. 22, egen översättning) 1 Informationssystem är ett datorprogram eller kombination av datorprogram och databaser som används för att lagra, söka eller på annat sätt bearbeta data. Informationssystem existerar för att stödja en organisation i deras affärsprocesser. (http://www.susning.nu/Informationssystem)


5

Uppsatsen kommer tillämpa Hartwick och Barki´s definition av användarmedverkan, då uppsatsförfattarna anser att den inte bara finns i designrelaterade roller, utan även i övriga faser i systemutvecklingsarbetet. McKeen´s definition är äldre och utvecklingen har medfört att användaren idag spelar en större roll i hela utvecklingsprocessen. Vid systemutveckling ingår normalt följande faser: förstudie, analys, design, utveckling, implementation, förvaltning och avveckling. Vanligtvis sker utvecklingen antingen med vattenfalls- eller livscykelmodellen. Vattenfalls-modellen innebär att varje fas är helt klar innan nästa påbörjas. Tanken är att arbetet skall ske som ett vattenfall, när en fas är passerad skall man inte behöva gå tillbaka till något av de föregående stegen. Livscykelmodellen innebär att de olika faserna upprepas gång på gång tills man uppnår önskat resultat. (Beekman, 2002, Avison & Fitzgerald, 1995) Enligt Ljung och Allwood (1999) finns nedanstående fem typer av användarmedverkan.

• Användare i projektgrupp relaterar till huruvida användarna är medlemmar i projektgruppen eller inte. Hur projektgruppen sätts samman beror på typ och storlek på utvecklingsprojektet.

• Seminarium/möten avser informationsmöten där systemutvecklare möter

alla eller vissa av de tilltänkta användarna. Dessa seminarier är konstruerade för att kunna fungera som informationskanaler där utvecklare och användare får möjlighet att både kommunicera och bli informerade.

• Referensgrupper formas av användarrepresentanter som ska bidra med

förslag och viktiga synpunkter på systemet som ska utvecklas. Även här beror sammansättningen av gruppen på det aktuella projektet.

• Användartestning är i många projekt en ovärderlig källa för information.

Testning av system kan ske på ett flertal olika sätt, allt i från att bedöma skärmbilder på ett papper till att testa avancerade prototyper. Testning kan även utföras genom frågeformulär, intervjuer eller genom att observera användare när de använder systemet.

• Frågelådor ger användarna möjlighet att skicka sina synpunkter och frågor

till dem som är ansvariga för projektet via papper eller e-post. Denna typ av användarmedverkan ger tillgång till lättåtkomlig information om användarnas åsikter och är lätt för utvecklarna att använda.

Enligt den undersökning som Ljung och Allwoods genomförde anser systemutvecklarna att användarmedverkan i seminarium, projektgrupper och referensgrupper är relativt eller helt oviktig. Den enda typ användarmedverkan som ansågs viktig var användartester. Hur relevanta systemutvecklarna tycker att frågelådor är presenteras inte.


6

Uppsatsen berör samtliga typer av användarmedverkan. Uppsatsförfattarna ställer sig dock något frågande till huruvida frågelådor ses som användarmedverkan men finner det intressant att undersöka systemutvecklares syn på detta.

1.3 Problematisering

Systemutvecklingen har mer och mer inriktat sig på att utveckla samarbetsvänliga system2 där användarna utgör en central del i designen och funktionaliteten i ett system. Det har dock visat sig att en användares medverkan i systemutvecklingen på en del områden i utvecklingsfasen är mer eller mindre bra för utvecklingsarbetet. (Hartwick, Barki, 2001). Tidigare forskning kring användarmedverkan vid systemutveckling har visat på olika relationer mellan användarmedverkan och användartillfredställelse med systemutvecklingsprojekt. Forskningarna presenterar inte vilka dessa relationer är, men de tyder på att användarmedverkan inte alltid är lika effektiv i alla situationer. (McKeen, Guimares, 1997, s. 133 egen översättning)

1.4 Problemformulering

Vissa författare (Hartwick, Barki, 2001 och McKeen, Guimares, 1997) skriver i sina artiklar att användarmedverkan inte alltid är passande vid systemutveckling. Därför frågar sig uppsatsförfattarna om systemutvecklarna anser att användarmedverkan i systemutvecklingen kan vara negativ och i sådana fall i vilka faser av utvecklingen samt på vilket sätt det kan yttra sig?

1.5 Syfte

Syftet med denna uppsats är att söka svar på huruvida systemutvecklare på företag upplever att användarmedverkan kan ses som ett negativt tillskott i systemutvecklingen och i sådana fall i vilka utvecklingsfaser samt på vilket sätt.

1.6 Avgränsning

Uppsatsen behandlar inte hur användarmedverkan upplevs ur vare sig användar-perspektiv eller ur företagsledningens perspektiv. Undersökningen är inte rikstäckande utan behandlar endast synpunkter från systemutvecklare i Mälardalsregionen.

2 System som möjliggör hög nivå av samarbete i t.ex. projekt, där filer och dokument delas mellan projektmedlemmarna och där medlemmarna kan arbeta på samma filer och dokument samtidigt.

MÄLARDALENS HÖGSKOLA Ekonomihögskolan - Teori -

7

2 Teori

I följande avsnitt presenteras den teori som ligger till grund för undersökningen, vilken sammanställts utifrån vetenskapligt granskade artiklar samt annan relevant litteratur. I ett flertal tidigare studier och undersökningar kring problemområdet, ses ofta användarmedverkan som ett positivt tillskott i utvecklingsarbetet. Det har dock framkommit att dessa undersökningar oftast ses ur användarperspektiv. Huruvida användarna är nöjda med systemet efter implementationen är ofta i fokus.

2.1 Generellt

Användarmedverkan i utformning av systemkrav, testning och implementation av ett datorsystem har länge erkänts som bra. Aktiv medverkan från användare i dessa delar av systemutvecklingen anses ge många fördelar, däribland en mer precis och komplett definition av informationskrav för användaren. (McKeen, Guimares, 1997) I en tidigare artikel menar McKeen (1994) att ”… deltagande vid arbetsledning i designfasen, formellt samtycke av specifikationen och kontinuerlig granskning av systemet var direkt relaterat till användartillfredställelse” (s. 432, egen översättning). Trots att användarmedverkan vid systemutveckling oftast sägs ge hög användartillfredställelse finns belägg för att användare, mer eller mindre, är det största hotet för ett projekt. McKeen och Guimares (1997) skriver i sin artikel att användarmedverkan inte är någon universallösning trots de potentiella fördelarna. Det finns många situationer där användarmedverkan till och med kan vara kontraproduktiv. Äldre forskningar inom området visar på att användarmedverkan inte är effektiv i alla situationer.

2.2 Gulliksen och Göransson, Användarcentrerad systemdesign

Gulliksen och Göransson (2002) presenterar i sin bok hur utvecklingsarbetet kan bedrivas på ett användarcentrerat3 sätt. Det vill säga att fokus ligger på den användarcentrerade utvecklingsprocessen. Gulliksen och Göransson presenterar många positiva effekter, men berör även de problem som kan uppstå vid systemutvecklingsarbete med användarcentrering samt förslag på hur dessa kan hanteras. Nedan presenteras några av de problem som anses relevanta för uppsatsens frågeställning.

• Organisation Olämpligt ledningsinflytande, makt och konfliktsituationer mellan projektdeltagare, fördröjning och gruppindelning är alla exempel på organisationsproblem vid systemutveckling. För att kunna göra system användbara är en förutsättning att utvecklaren får stöd och uppmuntran från den berörda organisationen.

3 Den process som fokuserar på användare och användbarhet genom hela utvecklingsprocessen och vidare genom hela livscykeln.(Gulliksen och Göransson, 2002)


8

• Attityd Något som starkt kan påverka utvecklingsresultatet är systemutvecklarnas attityd till utvecklingsarbetet. De kan ha svårt att se sin yrkesroll i ett servicesammanhang.

• Kommunikation Något som även påverkar utvecklingen är bristande förmåga, tid eller intresse av att förstå samt tolka de traditioner och kulturer som de olika deltagarna representerar. Detta kan då bli ett kommunikationsproblem mellan utvecklaren och användaren.

• Terminologi Ett problem som kan uppstå vid användarmedverkan är att utvecklare och användare talar olika ”språk” Det är viktigt att användarna får kommunicera med bekanta begrepp och inte huvudsakligen med tekniska termer.

2.3 McKeen och Guimares, Successful Strategies for User Participation in Systems Development

Även McKeen och Guimares (1997) presenterar, i sin artikel, faktorer som mycket väl kan försämra utvecklingsprocessen. Några av dessa faktorer behandlas även av Gulliksen och Göransson (2002), men då med en annan förklaring. Då Gulliksen och Göransson presenterar sitt material i en mer populärvetenskaplig bok, med fokus på användarcentrerad systemdesign, finner uppsatsförfattarna det lämpligt att komplettera och i vissa fall stärka dessa punkter med en vetenskapligt granskad artikel. Några av de för undersökningen relevanta faktorer som presenteras av McKeen och Guimares är: ledningens support, typ av inblandning, utvecklingsfas, grad av inflytande, kommunikation och systemkomplexitet. Då en definition av ovan nämnda punkter saknas i McKeen och Guimares artikel har dessa valts att förklaras dels med andra vetenskapligt granskade artiklar, dels Gulliksen och Göranssons bok som källa. Boken och dessa artiklar har valts då de berör en eller flera av punkterna och även haft en, för uppsatsen, lämplig förklaring till dessa.

• Ledningens support Kweku och Zbigniew (1994) presenterar i sin artikel ett antal faktorer som kan leda till nerläggning av ett utvecklingsprojekt. Det har visat sig att konflikter mellan användare, ledning och utvecklare är eller kan vara förödande. Kweku och Zbigniew har funnit att nästan alla misslyckade utvecklingsprojekt snarare beror på företagsledningen och personalen, som systemet utvecklas för, än på teknologin. Av de tolv största faktorerna för misslyckande, som Kweku och Zbigniew kartlade, fann de att hälften av dem handlade om organisationella frågor från den högre ledningen till slutanvändarmedverkan i projektutvecklings processen. En av faktorerna är brist på lämplig teknisk infrastruktur och expertis inom organisationen och utgör den näst största bidragande delen till att utvecklingsprojekt läggs ned.


9

• Typ av inblandning Enligt Barki och Hartwick (1989) kan användarinblandningen variera mellan indirekt och direkt. Med indirekt inblandning menas att en representant för användarna deltar i utvecklingsprocessen. Direkt inblandning innebär att användarna själva deltar i utvecklingsprocessen. Ljung och Allwood (1999) skriver att det finns fem olika typer av användarmedverkan vilka är: Användare i projektgrupp, seminarium/möte, referensgrupp, användartest samt frågelåda. De fyra första av dessa fem typer kan ha både direkt och indirekt inblandning.

• Utvecklingsfas

Med detta avses i vilken utvecklingsfas som användarmedverkan är lämplig eller inte. Gulliksen och Göransson (2002) skriver att användarmedverkan i faser där det inte är lämpligt kan medföra att användarna får mindre inflytande i de faser där användarna verkligen kan göra nytta. Vilka de olämpliga faserna är framgår inte av boken.

• Grad av inflytande Enligt Guimares, Staples och McKeen (2003) är grad av inflytande den omfattning en användare kan påverka beslut som berör slutprodukten, dvs. systemet. Med stort inflytande blir användare mer aktiva beslutsfattare. Får inte användare ett tillräckligt stort inflytande kan konflikter uppstå och utvecklingen försämras. Guimares et al. (2003) skriver ”Utan tillräcklig inverkan att ändra saker och påverka resultat, kommer troligen användare se deras medverkan som slöseri med tid…” (s. 43, egen översättning).

• Kommunikation Kommunikation har en nyckelroll i utvecklingsprocessen. Det är viktigt att kommunikationen fungerar åt båda hållen, från användaren till utvecklaren och vice versa. Effektiv kommunikation mellan användare och utvecklare kan medföra att användarmedverkan bli mer meningsfull då båda parter kan få klarhet i vad som ska göras. Där kommunikationen brister finns det risk för att konflikter skapas och att nyttan med användarmedverkan minskas. (Guimares, et al. 2003)

• Systemkomplexitet Med systemkomplexitet menas komplexiteten på systemet som utvecklas. (McKeen D. James, Guimares Tor, 1997) McKeen (1994) diskuterar i en tidigare artikel om användarnas grad av medverkan och inblandning i olika systemutvecklingsprojekt. Vid stora system med hög komplexitet och uppgiftskomplexitet krävs högre grad av användardeltagande. McKeen menar att ”För att hantera risken för systemmisslyckande, föreslås att användarnas medverkan ska ökas i proportion till projektets komplexitet” (s. 434, egen översättning). I situationer när uppgiftskomplexiteten är låg (dvs. uppgiften är väl strukturerad med direkta krav), kan utvecklaren fortsätta sitt arbete nästan oberoende av användaren. Med andra ord - vid utveckling av system med låg komplexitet är behovet av att involvera användare aktivt antagligen mindre viktigt.


10

2.4 Motivering av teori

Trots den allmänna uppfattningen att användarmedverkan är ett bra stöd för utvecklingen och att det oftast leder till tillfredställelse hos användaren och företaget i stort, finner uppsatsförfattarna att det finns för många stora faktorer som kan stjälpa ett utvecklingsprojekt för att uttala sig om att användarmedverkan är bra. McKeen (1994) skriver: ”Argumentationen för användarmedverkan är obekräftad då forskningsbevisen oftast är befläckade av resultat som är obekräftade och ofta motsägelsefulla” (s. 428, egen översättning) Den teori som utarbetats, med ovan presenterat material som grund, är att systemutvecklarna inte har något inflytande när det gäller grad av användarmedverkan i utvecklingen. De tros inte heller ha något inflytande över vilka användare som skall involveras i utvecklingsarbetet. Det är oftast företagsledningen och användarna som insisterar på användarmedverkan i projekten. Gulliksen & Göransson (2002) skriver att några av de organisationer de samarbetat med har haft som tradition att involvera användare i utvecklingsarbeten, men utan någon som helst struktur i urvalet av detta. Vidare skriver Gulliksen och Göransson att de observerat ett flertal problem i involveringen av användare. Ett exempel är att hög grad av användarmedverkan i olämpliga faser i utvecklingen kan leda till mindre inflytande i de faser där användaren kan göra mer nytta. Uppsatsförfattarna anser att detta tyder på att användarmedverkan kanske enbart är uppmuntrad från ledningen och dess organisation, vilket i många situationer kan leda till att det blir ett negativt tillskott för systemutvecklarna. Med ovanstående teori som utgångspunkt finner uppsatsförfattarna det intressant att undersöka om nedanstående faktorer kan bidra till att användarmedverkan kan försämra utvecklingsarbetet. Dessa faktorer kommer dels från Gulliksen och Göranssons (2002) bok och dels från McKeen och Guimares (1997) artikel. Utifrån dessa punkter anser uppsatsförfattarna att de kan undersöka om, när och varför systemutvecklarna kan se användarmedverkan som en negativ resurs i utvecklingsarbetet. Nedan presenteras varför uppsatsförfattarna anser att dessa punkter är intressanta i undersökningen med resonemang baserat på definitionerna ovan.


11

• Organisation och ledningens support Faktorerna organisation (Gulliksen & Göransson 2002) och ledningens support (McKeen & Guimares, 1997) anser uppsatsförfattarna gå in i varandra och behandlas därför som en punkt. Att utvecklingsprojektet är väl förankrat både hos ledningen och i hela organisationen anser uppsatsförfattarna vara en viktig del för att utvecklingsarbetet skall lyckas. Vidare anses att utvecklarna tillsammans med ledningen skall avgöra vem eller vilka användare som skall vara delaktiga i utvecklingsarbetet. Det är också viktigt att användarna inte bara är med för att ledningen anser att det är bra med användarmedverkan utan för att fylla en funktion och vara till hjälp i utvecklingsarbetet, inte en börda.

• Typ av inblandning Enligt Ljung och Allwood (1999) finns det olika sätt att involvera användare i utvecklingsarbetet. Uppsatsförfattarna anser att det även här måste vara systemutvecklaren som får avgöra vilken typ av inblandning som användarna skall ha i arbetet och inte användarna eller ledningen, då det är systemutvecklarna som skall arbeta med användarna.

• Utvecklingsfas Med fas i utvecklingen avses i vilken fas av utvecklingsprocessen man befinner sig i. Detta kan vara avgörande för huruvida användarmedverkan är lämplig eller inte. I ett flertal av artiklarna, som nämns tidigare, sägs att det i vissa faser kan vara rent av skadligt med användarmedverkan. Därför ämnar undersökningen söka svar på varför och i vilka av faserna som systemutvecklarna kan anse användarmedverkan som negativ.

• Grad av inflytande Vid användarmedverkan kan användarna ha olika grad av inflytande. Uppsatsförfattarna menar att det är viktigt att systemutvecklarna själva får vara med och avgöra hur mycket inflytande användarna skall ha innan utvecklingsarbetet startar. Utvecklaren kan eventuellt hämmas i sitt arbete om graden av användarmedverkan är för hög. En annan viktig del är att det nya systemet kanske inte blir så ”nytt”, då användarna i allt för hög grad kan vara påverkade av det gamla systemet. Systemutvecklarna vill ha ett gott samarbete med användarna under utformningen av kravspecifikationen för att sedan minska graden av användarmedverkan.

• Kommunikation

Guimares, et al. (2003) hävdar att om kommunikationen brister kan konflikter uppstå vilket minskar nyttan med användarmedverkan. Därför anser uppsatsförfa ttarna att en viktig del i användarmedverkan måste vara att innan utvecklingsarbetet påbörjas klargöra på vilket sätt kommunikation mellan de eventuella användarna och utvecklarna skall ske. Detta för att underlätta kommunikationen och förebygga konflikter.


12

• Terminologi Uppsatsförfattarna anser att terminologin kan försvåra utvecklingsarbetet avsevärt då utvecklaren tvingas lägga sin tid på att omformulera sig för att användaren ska förstå. Detta kan då vara något som bidrar till att systemutvecklaren upplever användaren mer som en börda än en resurs i utvecklingsarbetet.

• Attityd Enligt Gulliksen och Göransson (2002) kan systemutvecklarnas attityd till utvecklingsarbetet påverka resultaten av utvecklingsarbetet. Uppsats-författarna anser att även användarnas attityd kan ha stor påverkan. Om användaren är ovillig att vara med i utvecklingsarbetet kan denne vara oengagerad och motsträvig och om användaren har en positiv attityd och är för engagerad kan det medföra att denne försöker bli involverad i delar i utvecklingsarbetet som inte är relevanta.

• Systemkomplexitet Då McKeen (1994) hävdar att system med hög komplexitet kräver högre användarmedverkan undrar uppsatsförfattarna om även systemutvecklarna anser detta. Kan det inte vara så att ju mer komplext ett system är desto högre teknisk kompetens krävs av deltagarna i utvecklingsarbetet. Då användarna vanligtvis inte har den kompetensen som krävs kan det då vara olämpligt att ha en hög grad av användarmedverkan i utvecklingsarbetet.

MÄLARDALENS HÖGSKOLA Ekonomihögskolan - Metod -

13

3 Metod

Följande avsnitt behandlar den vetenskapliga metod som användes i undersökningen. Även kritiska förhållningssätt till de metoder som valdes redogörs för samt förhållningssätt till de källor som användes presenteras.

3.1 Insamling av sekundärdata

De sekundärdata som insamlades för undersökningen består av ett antal vetenskapliga artiklar och böcker. Artiklar söktes fram i högskolans databaser med sökorden: participation, user, involvement och systemdevelopment. Böckerna som användes är dels tidigare kurslitteratur dels böcker som har lånats på Högskolebiblioteket. Även några Internetkällor har använts för mindre, kompletterande uppgifter.

3.2 Insamling av primärdata

Undersökningen som genomfördes var en intervjuundersökning med åtta respondenter för insamling av primärdata. Samtliga respondenter arbetade som systemutvecklare. De arbetade både som konsulter och utvecklade på de företag de var anställda på.

3.3 Val av metod

Enligt Holme och Solvang (2001) ska valet av metod ske utifrån den problemformulering undersökningen har. Då uppsatsen behandlar system-utvecklares syn på användarmedverkan vid utvecklingsarbetet innebär det att uppsatsförfattarna måste söka mer djupgående information om detta varför en kvalitativ undersökning valdes. Med andra ord söktes svar på om systemutvecklarna upplever användarmedverkan som negativ och i sådana fall varför och på vilket sätt Därmed utfördes undersökningen i en hermeneutisk anda. Detta då absoluta sanningar inte eftersöks inom hermeneutiken, eftersom sådana inte finns enligt detta synsätt. Istället är hermeneutiken en kvalitativ och förståelseinriktade forskningsansats där målet är att förstå varför ett fenomen är på ett visst sätt.

3.4 Urval

Vid urvalet till intervjuundersökningen tillämpades närhetsprincipen då uppsatsförfattarna ansåg att det var för kostsamt och tidskrävande att utföra intervjuer med stor geografisk spridning. För att komma i kontakt med yrkesverksamma systemutvecklare i Mälardalen utnyttjades befintliga kontakter. Med andledning av metodvalet valdes åtta personer ut vilka alla var villiga att delta i undersökningen. Antalet respondenter valdes med anledning av att avsikten med undersökningen var att genomföra en djupgående studie, vilket medför att sammanställning av data är mer tidskrävande än vid kvantitativa undersökningar.


14

3.4.1 Intervjuundersökning

Intervjuerna som genomfördes var halvstrukturerade med 24 fördefinierade frågor som ställdes i en bestämd ordning med öppna svar. Dessa intervjufrågor hade, innan intervjuerna utfördes, granskats och godkänts av uppsatsens handledare. Undersökningen genomfördes med åtta respondenter, vilka arbetade på fem olika företag verksamma i Mälardalsregionen. Den initiala kontakten togs via e-post där författarna presenterade sig själva och uppsatsen samt gjorde en förfrågan om respondenterna var villiga att delta i undersökningen. Samtliga tillfrågade var positiva till detta. Respondenterna erbjöds att vara anonyma, vilket sju av åtta respondenter valde. Med vissa respondenter bestämdes tid och plats för intervju via e-post och med de andra upprättades en telefonkontakt för att bestämma tid och plats. En av intervjuerna utfördes hemma hos en av författarna och de resterande sju intervjuer genomfördes på respektive respondents arbetsplats. Intervjuerna tog från tjugofem till fyrtiofem minuter att genomföra. På de sex första intervjuerna var samtliga tre författare närvarande, på de två sista var två av författarna närvarande vilket inte upplevdes som negativt för undersökningen. Samtliga intervjuer spelades in på band för att kunna återges korrekt. Intervjuerna skrevs sedan ner ordagrant (se bilaga 1-9) för att underlätta sammanställningen av resultatet. De nedskrivna intervjuerna sändes via e-post, innan sammanställningen, till respektive respondent för att ge denne möjlighet att kontrollera att intervjun återgetts korrekt. Resultatet från intervjuerna har sammanställts och presenteras enligt punkterna i teorin och inte i den följd som frågorna ställts.

3.5 Metodkritik

Den metod som valdes till undersökningen var en intervjuundersökning. Ejvegård (2003) menar att en bandspelare vid intervjun kan vara hämmande för respondenten då det kan upplevas som en obekvämt av respondenterna. Uppsats-författarna ansåg dock att ljudupptagning skulle vara tills stor hjälp och upplevde inte att respondenterna verkade hämmade av detta. Anledningen till att en halvstrukturerad intervju valdes, trots att Patel och Davidsson (1994) förespråkar en låg grad av struktur vid kvalitativa undersökningar, var den tidsbegränsning under vilken undersökningen skulle genomföras som förelåg. Då uppsatsförfattarna var medvetna om att det är ett tidskrävande arbete att sammanställa resultatet från en öppen intervju valde de istället att genomföra en halvstrukturerad intervju.


15

3.6 Källkritik

I källkritiken tas två punkter upp, primära och sekundära källor. För att bedöma källorna, användes det som Eriksson och Wiederheim-Paul (2001) kallar källkritiska kriterier vilka är samtidskrav, tendenskritik och beroendekritik. Dessa behandlas i följande underkapitel.

3.6.1 Primära källor

De intervjuer som genomförts är undersökningens primära källor. Då samtliga som intervjuades var systemutvecklare borde inte samtidskravet vara ett problem i den meningen att alla har samma yrke samt att intervjuerna genomfördes under en tvåveckorsperiod. Respondenterna hade varierande erfarenhet av användarmedverkan, vilket dock inte upplevdes som ett problem. Några av respondenterna var anställda på samma företag men uppsatsförfattarna upplevde inte att det fanns en tendens till att de svarade från ett gemensamt material för att uttrycka den allmänna uppfattningen på företaget. Uppsatsförfattarna upplevdes inte att det verkade finnas något beroende mellan respondenterna.

3.6.2 Sekundära källor

Uppsatsens sekundära källor är det artiklar, böcker och Internetkällor som använts. Då vissa av artiklarna och böckerna är publicerade med relativt stora mellanrum, kan samtidskravet inte uppfyllas. Vissa artiklar belyser frågor och slutsatser som sedan har motbevisats eller understrukits ännu mer. Beroendet mellan artiklarna ansågs vara starkt. Flera av artiklarna hade samma referenser och en del var skrivna av samma författare. Det material som användes ansågs inte innebära problem för undersökningens reliabilitet. Med andra ord konstaterades, att även om det fanns ett visst samband mellan sekundärkällorna belyste de inte varandra på ett partiskt synsätt.

3.7 Undersökningens reliabilitet och validitet

Enligt Patel och Davidsson (1994) avser reliabilitet ett mätinstruments tillförlitlighet. Det innebär bland annat att det inte ska ge några slumpmässiga fel. Med hög reliabilitet menas således att två undersökningar som utgår från samma material men utförs oberoende av varandra skall ge samma eller snarlikt resultat. Trots valet att utföra undersökningen i hermeneutisk anda anses undersökningen har en hög reliabilitet då undersökningen har utformats på ett sätt att den skall vara möjlig att replikera. Vidare anses att en tillförlitlig metod valdes då intervjuerna genomfördes på systemutvecklare som har olika lång yrkeslivserfarenhet inom området. För att undvika att intervjufrågorna skulle missuppfattas av respondenterna granskades de av uppsatsens handledare samt kurskamrater till uppsatsförfattarna innan intervjuerna genomfördes. Enligt Bell (1995) är validitet ett mått på om en viss fråga mäter det man vill att den ska mäta. En fråga som saknar reliabilitet kommer även att sakna validitet. Då undersökningen anses ha en hög reliabilitet ses inte reliabiliteten som ett hinder för


16

att undersökningen inte skall ha någon validitet. Då frågorna utformats så att man fick in det material som behövdes för att kunna undersöka om systemutvecklare ser användarmedverkan som ett negativt tillskott i utvecklingen, i vilka faser och på vilket sätt, anses denna undersökning ha hög validitet.

MÄLARDALENS HÖGSKOLA Ekonomihögskolan - Resultat -

17

4 Resultat

I detta avsnitt presenteras resultatet av undersökningen i sammanställd form. Intervjuundersökningen genomfördes med åtta respondenter i Mälardalsregionen, två kvinnor och sex män.

4.1 Respondenterna

De åtta respondenterna som deltog i undersökningen hade arbetat med systemutveckling under olika lång tid och på olika sätt. I diagram 1 visas hur många år respondenterna varit yrkesverksamma inom systemutveckling.

Respondent A arbetar på ett företag som säljer och implementerar affärssystem till företag. Respondentens huvudsakliga arbetsuppgifter är att agera som säljstöd till säljaren, systemera och presentera lösningar till kunden och om kunden har några frågor kan de vända sig till denne. Respondent B arbetar på IT avdelningen på ett företag som levererar energi, vatten och kringtjänster. Denne arbetar huvudsakligen med systemutveckling och förvaltning av vissa system. Respondent C arbetar som systemutvecklare på ett administrativt center på ett matvaruföretag. Främst arbetar respondenten med att ta fram prototyper inom de administrativa systemen. Respondent D, E och F arbetar på ett internbolag på ett företag i stålbranschen. Internbolagets huvudsakliga arbetsuppgift är att ta fram systemlösningar åt företaget. De utvecklar endast internt inom koncernen och utvecklar inget för externa bolag. Respondent D arbetar med att utveckla webbapplikationer. Respondent E arbetar huvudsakligen med att programmera och bygga system. Respondent F har, på grund av sin långa erfarenhet, varierande arbetsuppgifter och arbetar just nu med integrering av system i företaget.

Antal Yrkesverksamma År

0

5

10

15

20

25

30

A B C D E F G H Responden t

År

Diagram 1 - Respondenternas yrkesverksamma år som systemutvecklare Egen bearbetning.


18

Respondent G och H arbetar på ett företag inom konsultbranschen vilket inriktar sig på att utveckla webbapplikationer. Respondenterna genomför oftast utvecklingen hos kunden. Respondents G:s huvudsakliga arbetsuppgifter varierar då denne är konsult och ibland arbetar som en resurs i projekt och ibland helt självständigt. Respondent H är relativt nyanställd på företaget men skall ha som huvudsaklig uppgift att utveckla koden i applikationerna och inte att arbeta med användargränssnitt.

4.2 Generellt om användarmedverkan

Vad anser Du användarmedverkan innebär? Respondent A anser att användarmedverkan innebär att användarna får komma med sina synpunkter och krav på funktionalitet och information som är viktig för att bedriva deras dagliga verksamhet och för att företaget ska fungera. För respondent B, D och F innebär användarmedverkan att användarna involveras i hela utvecklingen och är med och tar fram systemet. Respondent C vill gärna ha med användarna för att utveckla system. Denne anser att det blir bättre system om användaren är involverad från början. Detta för att utvecklaren skall kunna fånga upp behoven redan i inledningsfasen. Enligt respondent E börjar det med att användarna formulerar ett slags önskemål kring vad de vill. Sedan skall utvecklarna gemensamt med användarna komma fram till vad som skall utvecklas. Respondent G anser att användarmedverkan är när utvecklarna försöker ta in synpunkter på användargränssnittet. Innan och under tiden det utvecklas låter utvecklaren andra titta på applikationen för att det ska bli tydligt, även för icketekniker. Respondent H har en liknande bild av användarmedverkan och anser att det innebär att användarna tas med i utvecklingsprocessen.

Har du erfarenhet av användarmedverkan? Samtliga respondenter, förutom D, ansåg att de hade erfarenhet av användarmedverkan vid utvecklingsarbeten. Responden D ansåg sig däremot ha begränsad erfarenhet av användarmedverkan. Hur vanligt förekommande är det med användarmedverkan vid systemutveckling? Respondent A, C, E och F anser att användarmedverkan är vanligt förekommande. Respondent A menar att på det ena eller andra sättet kommer systemet slutligen till användaren och han eller hon alltid har en åsikt. Har man gjort någonting där användaren inte har fått vara med från början kommer det oftast tillbaka för justeringar. Respondent C har aldrig utvecklat något system där användarna inte har varit delaktiga vid utvecklingsarbetet såvida det inte handlar om ett system som bara skall kommunicera med ett annat system.


19

Respondent B anser att det är långt ifrån den grad av användarmedverkan denne egentligen vill ha för att få system som verkligen accepteras och fungerar. Denne anser att det är så speciellt inom mindre företag där programmeringstimmar köps rakt av utan någon större användarmedverkan. Respondent H tror att det är ovanlig med användarmedverkan. Denne anser även att vissa företag har med det bara för sakens skull. Respondent D anser att användarmedverkan är begränsad vid utveckling av applikationer då denne utvecklar mycket efter eget tycke samt utifrån en kravspecifikation och befintliga mallar. Respondent G anser att det varierar. Vid arbete med webb är det fler okända användare av systemet och därför läggs mer tid på användarmedverkan eftersom målgruppen är mer flyktig. Men ju närmre industrin man kommer desto mindre tar man hänsyn till användarmedverkan. Vad är enligt din mening det bästa/sämsta som användaren kan bidra med? Respondent A anser att det bästa en användare kan bidra med är att ge en förståelse för vad det är för resultat som önskas. Det sämsta en användare kan bidra med anser respondent A och B är när de blir för detaljerat eller bara ser till sin rutin och inte till helheten. Respondent B anser att det bästa är när en användare bidrar med kunskap och kompetens som inte finns hos den som skall utveckla systemet t.ex. det som inte finns dokumenterat. Det sämsta är, enligt respondent B, om det inte finns någon modell för hur man skall ha användarmedverkan. Det kan då bli ostrukturerat och användarmedverkan kommer in lite här och där i processen, vilket tar onödigt mycket tid. Enligt respondent C är det bästa när användarna på ett tydligt och bra sätt specificerar vad det är de vill ha med redan vid kravställandet. Det sämsta som en användare kan bidra med är när de lägger sig i hur applikationen utvecklas rent tekniskt. Att användarna bidrar med vad de vill ha ut av applikationen funktionellt och även hur den skall utformas är, enligt respondent D, det bästa en användare kan bidra med. Respondent D anser att det sämsta är när det är många användare som alla har olika idéer som de vill driva igenom eller när de har petitesskrav. Respondent E anser inte att det finns något som är det sämsta en användare kan bidra med och tycker att det bästa är när användaren bidrar med kunskap om verksamheten och idéer om layouter. Enligt respondent F kommer arbetet fortare igång när användarna är med så utvecklarna kan intervjua dem om hur de vill ha det vilket upplevs som positivt. Respondent F anser att det sämsta är att vissa användare vill alldeles för mycket, särkilt när de kräver nya funktioner efter det att kravspecifikationen är fastställd.


20

Respondent G anser att det bästa med användarmedverkan är att användarna ser systemet med andra ögon än utvecklaren. De kan berätta för utvecklaren hur man ska arbeta med systemet och därmed underlättas utvecklingsarbetet. Respondent G anser att det sämsta med användarmedverkan är när de kommer med synpunkter av bagatellartad natur t.ex. synpunkter på utseendet. Kreativa idéer, så att det som utvecklas blir bättre är enligt respondent H det bästa en användare kan bidra med. Men användare som aldrig blir riktigt nöjda utan vill ha förändring på förändring trots att ingenting egentligen blir bättre, är det sämsta med användarmedverkan. Vad är din generella uppfattning om användarmedverkan? Respondent A anser att användarmedverkan kan vara både bra och dålig. Respondenten är mycket glad om det finns användare som har systemförståelse och kan se den röda tråden. Det gäller helt enkelt, enligt respondenten, att få tag på rätt användare. Respondent B anser att användarmedverkan är bra om det finns ett strukturerat arbetssätt där det är väl genomtänkt hur användarna skall involveras. Om det inte finns tror respondenten att det kan bli svårt med användarmedverkan då det kan komma in i oönskade faser. Respondenten tror inte heller att användarmedverkan blir bra om man samlas i stora möten för att gå igenom allt. Respondent C anser att användarmedverkan är bra för annars vet inte respondenten vad denne skall utveckla för system. Respondenten påpekar även att det är för användarna som systemen görs. Respondent D ser användarmedverkan som nödvändigt för ett utvecklingsprojekt. Respondenten tror däremot att vissa utvecklare inte alltid är så noga med att involvera användare. Respondent E anser att användarmedverkan är bra, inte bara i förstudier och vid framtagning av kravspecifikationer utan även i utvecklingsarbetet och i testfasen. Respondenten menar det inte skulle gå att arbeta utan användarnas medverkan.

För respondent F är användarmedverkan A och O vid systemutveckling. Respondenten tycker att användarmedverkan är en förutsättning för att lyckas i sitt utvecklingsarbete. Respondenten menar att det finns ingen anledning att bygga ett system som sedan stoppas i handen på användare som inte trivs med systemet. Respondent G anser att användarmedverkan är bra och tycker att det är synd att inte fler kunder förstår att det kan avgöra hur ett system blir mottaget. För användarna spelar det ingen roll vad som finns bakom skalet, det viktiga är att systemet skall vara lätt att använda. Man ska absolut inte räkna med att det som en tekniker anser är lätt, är lätt för en icke-tekniker dvs. användarna. Respondent H anser att användarmedverkan är viktig, inte bara för den utvecklande organisationen utan även för den organisationen som är beställare.


21

4.3 Organisation och ledningens support

Hur upplever Du uppdragsgivarens syn på användarmedverkan? Respondent A anser att uppdragsgivarens syn beror på det beställande bolagets storlek. Minde bolag tar mer hänsyn till användarna än större där det kanske finns en IT-avdelning som är mer drivande och tar mera egna beslut då de vet vad användarna har för behov. Respondent B tror att uppdragsgivaren vill ha en hög grad av användarmedverkan men att de inte alltid är beredda att betala för vad det kostar att ha med användarna. Enligt respondent C vill kunden alltid vara med och bestämma. Respondent D är däremot osäker på vad uppdragsgivaren har för syn på användarmedverkan. Respondent E tror inte att uppdragsgivaren har räknat med att det tar så mycket tid för användaren att vara med som det verkligen gör. Respondent F anser att uppdragsgivaren helst vill ha med användarna. Respondenten hoppas att uppdragsgivaren vet vilka som är nyckelpersoner och har förståelse för hur processen fungerar för att utse rätt personer. Respondent G anser att det är en mognadsprocess. Anser uppdragsgivaren att användarmedverkan är viktig blir det oftast ett bättre resultat när man involverar slutanvändarna tidigt. Denne tror även att när det gäller webb är troligen uppdragsgivaren extra intresserad av att ha med användare eftersom så många som möjligt ska kunna ta del av applikationen då de inte riktigt vet vilken målgruppen är. Enligt respondent H, som anser att han inte har så stor erfarenhet av användarmedverkan, försöker man ta med användarna eller någon representant för dem för att få synpunkter på tidiga prototyper. Vem bestämmer om man ska ha användarmedverkan med i utvecklingsprojektet? Enligt respondent A är det kundens egna projektledare som tillsammans med ledningen bestämmer vilka som skall ingå i projektet. Respondent B menar också att det är projektledaren som bestämmer detta. Även beställaren kan ha ett intresse, men respondent B tror inte att de beställande företagen ännu riktig har förstått nyttan med användarmedverkan. På det företag som respondent C arbetar nu, är det respondenten själv som bestämmer om användarmedverkan men när denne tidigare arbetade som IT-konsult var det kunden som bestämde. Respondet D säger att det bör vara uppdragsgivaren som bestämmer om användarmedverkan skall finnas i projektet eller inte. Men denne tror att om man som utvecklare vill ha med användare skulle det inte vara något problem.


22

Enligt respondent E är det de som drar upp riktlinjer för projektet som bestämmer om man skall ha med användarmedverkan i projektet, denne undrar även om det går att bedriva ett utvecklingsprojekt utan användarmedverkan. Enligt respondent F är det uppdragsgivaren som bestämmer om användarna skall vara med eller inte. Men har man valt att inte ha med några ser respondenten till att få med användare. Enligt respondent G är det kunden som bestämmer. Enligt respondent H är det den som är projekt- eller utvecklingsansvarig som bestämmer om användarna skall delta eller inte. Denne tror även att de flesta har till uppgift att ta med användarna på något sätt men att många av olika skäl hoppar över det.

4.4 Typ av inblandning

Vilken typ av inblandning är vanligast vid användarmedverkan (dvs. seminariegrupper, referensgrupper, testgrupper, frågelåda)? Respondent A går igenom varje funktion med användarna i en projektgrupp och systemerar sedan de funktionerna. När utvecklingsarbetet är igång är det mera vanligt att programmeraren sitter hos kunden för att själv lyssna av vad man vill och då används kunden som en referens. Enligt respondent B är den vanligaste typen av inblandning referensgrupper även om det kanske inte generellt upplevs som användarmedverkan. Den typen av inblandning som respondent C arbetar med är främst referensgrupper men respondenten använder sig även av seminarium/möten och testgrupper. Testgrupper och referensgrupper är enligt respondent D och E den typ av inblandning som är vanligast vid användarmedverkan Möten och testgrupper är den typ av inblandning som respondent F vanligtvis har med sina användare. Respondent G har arbetat med referensgrupper där man har involverat personalen som ska vara mottagare, men även med testgrupper. Den första funktionella insamlingen brukar respondent H vanligtvis göra i intervjuform med användargrupper men denne använder sig även av användarmöten där de får se olika prototyper.


23

Vem bestämmer vilken typ av inblandning användarna skall ha? Enligt respondent A bestämmer projektledaren tillsammans med kundens projektledare, vilken arbetsform det ska vara. Oftast blir det en form av större eller mindre projektgrupp. Helst så liten som möjligt bestående av beslutsfattande personer som är väl insatta i verksamheten. Respondent B anser att det kan vara olika. Men är de olika stegen i utvecklingsprocessen väl definierade tror respondenten att ansvaret kan ligga på de olika områdena. Det är respondent C som själv bestämmer vilken typ av inblandning som användarna skall ha. Respondent E är osäker på vem det är som bestämmer vilken typ av inblandning användarna skall ha, men tror att projektledaren gör det. Enligt respondent F bestäms typen av inblandning under utvecklingsarbetet. Det är oftast uppdragsgivaren som utser användare men även utvecklarna kan begära att få användare utsedda. Enligt respondent G bestämmer kunden vilken typ av inblandning användarna skall ha i projektet. I de projekten som respondent H har varit med, är det huvudprojektledaren som är ansvarig och alltså bestämmer det.

4.5 Utvecklingsfas

Vilka faser har ni med i det utvecklingsarbetet som du brukar arbeta med? Respondent A arbetar med följande steg i sitt utvecklingsarbete. Inledningsvis utbildar de användarna i systemets standardfunktione r för att visa hur systemet fungerar idag. Sedan inleds designfasen, eller produktgenomgång, med en genomgång av anpassningarna för att sedan samla in information. Därefter sker systemeringen för att sedan börja med programmeringen. Därefter sker testning på vilket man skall ha ett godkännande, innan system- och användardokumentation utformas. Utvecklingsarbetet som respondent B arbetar med inleds med att en funktionell kravspecifikation utformas av någon som inte behöver ha teknisk kompetens. Därefter dokumenteras vad systemet skall göra och vad som skall hända. Därpå utformas en prototyp på vilken någon instans godkänner designen. För större projekt finns även en integratör med som blir en kommunikationskanal mellan specifikationerna som har tagits fram med hjälp av användarna och det färdiga gränssnittet för programmering.


24

Respondent C börjar sitt utvecklingsarbete med att fånga upp behov hos användarna för att sedan specificera det på papper och kontrollera det med användarna. Efter godkännande från användarna inleds utvecklingsfasen och därefter påbörjas testfasen. Utvecklingsfasen och testfasen itereras, användarna utbildas vid behov och sedan sätts systemet i drift. Därefter förvaltas systemet. De steg som respondent D arbetar med är förstudie, analys, utveckling, testning och implementation. Men enligt respondenten skall de idag arbeta enligt en egenutvecklad metod som heter PMM, ”Project Management Method”. I denna metod beskrivs alla stegen. Respondent E och F har med förstudie, analys, utveckling och implementation i sin utvecklingsprocess. Respondent E har även en testfas, men enligt respondenten genomförs den inte alltid. Enligt respondent G, som arbetar som konsult, varierar utvecklingsarbetet ganska mycket. Det beror på i vilken fas man kommer in i arbetet och som konsult är det alltid kundens modell som styr och utvecklaren får anpassa sig. Respondent H inleder sin utvecklingsprocess med en kundundersökning där kundens förväntningar och vilka nya saker som de önskar få in i systemet tas upp. Sedan följer andra faser där behovet från kundundersökningen har fångats upp och prototyper utvecklas. Sedan visas prototyperna för samma användargrupp som deltog i kundundersökningen. Därefter får användarna säga sitt och ändringar genomförs för att man till sist skall komma fram till fas 1 och 2 då det stora arbetet med kodning och utveckling startar. I vilka utvecklingsfaser och på vilket sätt anser Du att användarmedverkan kan vara överflödig/negativ? Respondent A anser att det är just vid själva programmeringsarbetet som användarmedverkan kan vara överflödig för då sköter sig programmeraren helt och hållet själv. Då måste man hålla sig till det som bestämts och arbeta efter det. Projektets tidsramar är planerade efter det som bestämts i tidigare faser och efter det som kunden har beställt. Om användaren då har en dialog direkt med programmeraren och kommer med nya direktiv tar hela projektet längre tid. I de initiala skedena när utvecklingen, dvs. programmeringen, av själva lösningen sker anser respondent B att användarmedverkan är överflödig eller negativ. Man kan även få med oönskad användarmedverkan i vissa faser om det brister i planeringen i tidigare faser. Även respondent C anser att det kan vara negativt med användarmedverkan vid utvecklingen, då vill denne endast ha med dem i en referensgrupp. Enligt respondent D har man ingen större nytta av användarna vid uppstarten i den första fasen då man analyserar.


25

Respondent E anser att det inte finns någon fas då användarmedverkan kan vara överflödig eller negativ. Ibland är det lite krångligt att ha med dem men det är ännu värre om de inte skulle vara med alls. Enligt respondent F är användarmedverkan överflödig eller negativ i när denne gör den grova kodningen, då behövs dom inte för då vill respondenten vara ifred. Under implementationsfasen anser respondent G att användarmedverkan kan vara negativ eller överflödig för då är kraven redan satta och det är alltid jobbig om de förändras under tiden. Respondent H tror att användarmedverkan är minst önskvärd eller har minst att tillföra under utvecklingsfasen och under testfasen. Nedan, i diagram 2, visas i vilka faser respondenterna anser att användarmedverkan kan vara överflödig eller negativ. Sju av respondenterna svarade endast en fas och en respondent svarade två faser. Därav räknas personen som svarade två faser som 0.5 på varje fas.

Faser då användarmedverkan kan varanegativ eller överflödig.

Ingen fas 1

Analysfasen 1

Programmering, utveckling

4.5

Testning 0.5

Implementation 1

Diagram 3 - Faser då respondenterna anser att användarmedverkan kan vara negativ eller överflödig. Egen bearbetning.

4.6 Grad av inflytande

Vilken grad av inflytande har användaren haft under utvecklingsarbetet?

Enligt respondent A får användarna vara med och ge sin syn och ställa sina krav på vad de behöver i systemet. Användarna brukar i hög grad vara med vid kravställandet och det användarna säger filtreras sedan via projektledaren eller den som är beställare av det som ska utvecklas.


26

Respondent B anser att inflytandet på arbetet generellt brukar vara ganska lågt förutom när det gäller att granska prototyper eller liknande. Enligt respondent C är användarnas ord lag i vissa delar. Detta gäller speciellt när det är ett system som respondenten inte kan eller förstår, som t ex ekonomiska system eller när det är reglerat av lagar. Respondent D tycker att det är svårt att säga vilken grad av inflytande som användarna har under utvecklingsarbetet. Respondenten lyssnar på vad styrgruppen eller projektledaren som sköter kommunikationen med användaren säger. Enligt respondent E finns det vissa användare som har mer inflytande än andra. Detta beror oftast på användarens kunskap men även på att de ibland är påstridiga. Respondent F säger att användarna ibland kan framföra många irrelevanta åsikter, men att är ovanligt. Användarna brukar kunna tala om att det här fungerar inte, eller att det är så här systemet är konstruerat. Respondent G anser att användarna har ganska stort inflytande i början eftersom de är kravställare. Det är de som vet hur dom vill att systemet ska fungera. Enligt respondent H är användarnas grad av inflytande olika från projekt till projekt. Respondenten tror att användarna har inflytande så länge de är inbjudna, därefter har de litet eller inget inflytande alls. Hur mycket har Du haft möjlighet att påverka användarens grad av inflytande?

Enligt respondent A kan denne påverka användarens grad av inflytande genom att ta kontakt med den person som besitter de kunskaper som efterfrågas. Denne kan även välja att lyssna på någon eller inte. Om det är någon förändring som respondenten önskar få igenom kan man försöka sälja in det behovet till kundens projektledare eller processägaren. Men det är ändå kunden som bestämmer om förändringen ska genomföras. Respondent B menar att om man är systemutvecklare i hela kedjan, dvs. inte bara har ett steg, har man större möjlighet att påverka användarens grad av inflytande. Respondenten tror även att i större projekt så har utvecklaren mindre möjlighet att påverka än i mindre projekt. Enligt respondent C har man stor möjlighet att påverka användarnas grad av inflytande då det är respondenten som säger avgör. Respondent D har inte sett något behov av eller gjort någonting för att påverka användarens grad av inflytande. Om respondenten har några synpunkter går de via projektledaren. Respondent E bestämmer själv när denne vill fråga någon och påverkar därigenom användarnas grad av inflytande.


27

Respondent F menar att det inte handlar om att någon måste bestämma mer än någon annan utan om att få ett bra system. Respondent G anser att om man ser direkta tankefel eller att det som användaren säger inte kommer att fungera i praktiken kan man som utvecklare påpeka att det kan göras på ett annat och bättre. Men det är alltid kunden som bestämmer och vi gör det dom vill att vi ska göra. Respondent H kan påverka graden av användarnas inflytande genom att kontakta dem i utvecklingsfasen för att påverka dem att beställa en förändring i systemet. På vilket sätt har Du haft möjlighet att påverka användarens grad av inflytande?

Om respondent A vill ha med en användare så har denne stor frihet att bestämma det. Men naturligtvis kan kunden säga ifrån och då löses frågan i samförstånd direkt med kunden. Enligt respondent B är det lättare att påverka ju tidigare i systemutvecklingskedjan man befinner sig. Responden har också möjlighet att påverka om man har god kunskap om verksamheten. Respondenten vet då vem för då vet denne vem som skall tillfrågas. Genom att kalla till möten eller ringa upp användarna kan respondent C påverka användarnas grad av inflytande. Desamma gäller respondent E som själv väljer när användarna skall konsulteras. Respondent F kan, om denne tycker att systemet är designat på ett mindre bra sätt, påverka användarnas grad av inflytande genom att prata med dem och framföra sina förändringsförslag Att framföra rent tekniska argument är enligt respondent G det bästa när man vill påverka användarna. På så sätt kan respondenten påverka användarna.

Respondent H menar att man i egenskap av utvecklare och genom kontakt med utvecklingsprocessens användarna kan påverka graden av inflytande.

4.7 Kommunikation

Hur sköts vanligen kommunikationen mellan er och användarna? Redan vid projektstarten bestäms alla kända mötesdagar enligt respondent A. Under projektets gång sköts merparten av kommunikationen via telefon och finns kunden nära kan även besök förekomma. Den kommunikation respondent B har med användarna sköts ganska direkt. Men i större projekt brukar de ha en person som är utsedd till att kommunicera med användarna.


28

Respondent C tycker att de ultimata är att träffas men det är inte alltid möjligt på grund av tid och pengar. Då sköts kommunikationen med användarna via e-post och telefon. Enligt respondent D sköts kommunikationen med användarna via deras representant och projektledaren. Respondenten har normalt sett inte kontakt med användarna. Respondent E har en relativt informell kommunikation med användarna som vanligtvis sköts via e-post och per telefon. Det finns grupper som träffas då och då men respondenten är sällan med de utan får information om vad som har avhandlats. Respondent F har både formell och informell kontakt med sina användare, dels över telefon och dels genom workshops. Respondent G:s kommunikation med användarna sker genom dokument. Respondenten kommunicerar oftast med en representant för användarna och ibland sitter de även med på samma projektmöten. Enligt respondent H är kommunikationen med användarna oftast obefintlig. Den går oftast en genom andra personerna som är inblandade i projektet. Anser Du att kommunikationen brukar fungera bra? Respondent A, B, C, D, F och G anser alla att kommunikationen med användarna brukar fungera bra och har inte upplevt det som något problem. Respondent E anser att kommunikationen brukar fungera sådär ibland fungerar den bra och ibland mindre bra. Respondent H anser att antingen fungerar kommunikationen dåligt eller också är den obefintlig och vet inte hur man skulle kunna göra det på ett annat sätt. Respondenternas syn på hur kommunikationen brukar fungera med användarna visas i diagram 3 nedan.


29

Hur kommunikationen mellan respondenterna och användarna fungerar

Brukar fungera bra 6

Brukar fungera sådär

1

Dåligt eller obefintlig

1

Diagram 3 - Respondenternas uppfattning om hur kommunikationen fungerar.Egen bearbetning.

4.8 Terminologi

Hur vanligt är det att det förekommer terminologiska problem mellan er och användarna?

Enligt respondent A pratar utvecklaren och användaren ofta helt olika språk. Därför fungerar respondenten som ett filter som förstår både programmerarens och slutanvändarens språk. Respondenten är en internbeställare till programmeraren och kundens kontaktperson som förstår kundens och slutanvändarens behov. Respondenten förstår även hur programmeraren reagerar efter ett behov eller ett krav från en kund. Respondent B anser att det ganska ofta förekommer terminologiska problem mellan utvecklarna och användarna och att det egentligen beror på att man inte förstår varandra. När systemutvecklaren försöker beskriva någonting som är avancerat på ett enklare sätt, får man inte med den komplexitet som kanske krävs för att användaren skall till fullo förstå det hela. Respondent C anser att det största problemet med användarmedverkan är att utvecklaren och användaren pratar olika språk. Respondent D, som normalt sett inte har någon direktkontakt med användarna, anser inte att det brukar förekomma några terminologiska problem. Responden E anser att det kan uppstå terminologiska problem i kommunikationen med användarna men inte att det brukar förekomma i någon större utsträckning. Respondenten anser att de gånger det uppstår kan det vara från båda hållen dvs. att användaren inte förstår utvecklaren eller tvärt om.


30

Enligt respondent F kan det förekomma terminologiska problem mellan användarna och att det oftast beror på att de missförstår varandra, men respondenten upplever inte att det sker speciellt ofta. Enligt respondent G är det vanligt att terminologiska problem uppstår. Respondenten anser att det gäller att lära sig användarnas språk. De terminologiska problemen skiljer sig från företag till företag och med vem utvecklaren pratar. Respondent H, som inte anser sig ha så mycket erfarenhet av användarmedverkan, tror inte att det, idag, är så vanligt att det uppstår terminologiska problem som det gjorde för ett till två årtionden sedan. Nu har de flesta en persondator i hemmet vilket gör att datorvanan är betydligt större

4.9 Attityd

Anser Du att användarnas inställning till att bli delaktiga i projektet påverkar deras attityd till utvecklingsarbetet? Enligt A sätts projektgruppen samman så att den består av kreativa medarbetare som har god kunskap om verksamheten i bolaget och kan se helheten. De är ofta positiva till förändringar vilket gör att de finns en positiv attityd till projektet. Respondent B anser att användarnas attityd till att vara delaktiga i projektet helt klart påverkar attityden till utvecklingsarbetet. Respondenten menar att om en användare tvingas vara med i ett projekt eller är oengagerad innebär det svårigheter. Men en användare med för stort engagemang är egentligen ett större problem då de gärna går in på för mycket detaljer och det blir en användarpåverkan under hela tiden, även i de faser som det icke är önskat. Enligt C kan de användare som inte vill vara delaktiga i projektet vara väldigt kritiska och anse att det var bättre i det gamla systemet eller som det var förr. Respondent D anser att det normalt sett inte är så att inställningen påverkar, men många gånger säger användarna att det är ont om tid. Samtidigt har respondent D svårt att tro att användarna inte är villiga för det är de som ska använda applikationen. Respondent E anser att inställningen kan vara olika från person till person. Enligt respondent F blir de användare som är delaktiga mycket positiva till det nya systemet. Respondenten menar även att om en användare har en negativ inställning är det viktigt att ta reda på orsaken till det. Ofta kan det vara att man är orolig för att inte förstå det nya systemet och är därför negativ till det. Respondent G anser att de flesta av användarna tycker om att bli engagerade tid igt för det ger dem möjlighet att påverka. Inställningen till systemet när det är klart, brukar bli bättre för de användare som varit engagerade från början än för de som får det färdigt på skrivbordet. Dessa användare brukar säga att det förra systemet fungerade bättre och vet inte alls hur de skall arbeta med det nya.


31

Respondent H har varit med några gånger när användare uppenbarligen inte har velat vara med. Dessa användare har bara sagt ja eller nej på vilka frågor som helst bara för att bli av med det. Då har användargruppen omformats efter att tag och andra personer som vill vara med har tillkommit Hur villiga är användarna till att medverka i utvecklingsarbetet? Enligt respondent A kan slutanvändaren bli lite trött på utvecklaren om utvecklaren återkommer gång på gång med ytterligare kompletteringar. Respondent B anser att när det är saker som rör användarna i hög grad är de mycket villiga att delta. Men om det när något som användaren inte kan se någon nytta med är det svårare med deltagande. Respondent C upplever användarna som oerhört samarbetsvilliga för det respondenten gör innebär hjälp i deras arbete. Enligt respondent E är användarna oftast positiva till att delta i utvecklingsarbetet men menar även att det alltid finns undantag. Enligt respondent F är det blandat hur villiga användarna är på att medverka i utvecklingsarbetet. Respondenten anser att detta beror på att många företag drar ner på antalet anställda och då delas arbetsuppgifterna upp på de som är kvar. Användarna skall sedan utöver detta hinna med att medverka i utvecklingsarbetet vilket lätt kan göra att de blir negativa till att delta och tycka det är jobbigt på grund av tidsbrist. Enligt G är det väldigt varierande hur villiga användarna är att medverka. De flesta tycker hellre till när det är klart istället för att medverka vid specifikationen. Respondent H anser att användarna vill vara med så mycket de får när de blir tillfrågade. Den som begränsar användarnas medverkan är utvecklingsprojektets ledare. Enligt respondenten är det mycket sällan som användarna säger ifrån. Är det vanligt förekommande att användarna har en dålig attityd? Enligt respondent A har användarna generellt en dålig attityd till det nya systemet och förespråkar hellre det gamla. Användarna hakar ofta upp sig på det som inte fungerar. Respondent B anser inte att det är vanligt förekommande att användarna har en dålig attityd. Respondenten menar att om en dålig attityd finns beror den oftast på om det är saker som användaren inte ser någon nytta med eller inte tycker är vettiga. Respondent C har inte upplevt att användarna har en dålig attityd men tror sig ha haft tur eftersom det förekommer. Respondenten menar att användarna kan upplevas som besvärliga då de är kravställare.


32

Enligt respondent E finns det alltid användare som klagar på allt men normalt sett anser denne ändå att användarna är positiva. Respondent F anser inte att användarna har en dålig attityd, tvärt om blir de positiva och får lättare förståelse för det nya systemet. Några av de superanvändare4 som respondenten arbetar trivs som fisken i vattnet med att kunna lite mer än de andra och att lära ut. Enligt respondent G kan användarna ha en dålig attityd och vara skeptiska om de inte alls har varit engagerade i det nya systemet Respondenten menar att det ibland kan vara en tävling om hur fort man kan sänka det nya systemet. Respondent H har inte upplevt att användarna har en dålig attityd och tror att användare är villiga och gärna vill vara med.

4.10 Systemkomplexitet

Hur påverkar graden av komplexitet på systemet behovet av användarmedverkan? Respondent A anser att i vissa fall kan systemets komplexitet påverka behovet av ökad medverkan. Om systemet blir mer komplext krävs det att en anpassning som blir mycket specifik systemeras upp. Det är då viktigt att få ut det verkliga behovet som användaren har. Enligt B är det värdefullt med användarmedverkan om det är ett system som är komplext ur den synvinkeln att det är flera system inblandade. Respondent C anser att om det för användaren bara är en knapp att trycka på, fast systemets uppbyggnad är mycket komplext, ökar inte behovet av användarmedverkan. Men om det är ett komplext system med många funktioner eller filer som skall skickas i en viss ordning, då är användarmedverkan ovärderlig. Respondent D anser att ju komplexare systemet är desto större behov av användarmedverkan. Detta för att användarna skall få systemet utformat på ett sådant sätt att de blir ett hjälpmedel och inte krångligt att använda Respondenten menar att annars utvecklas systemet bara som utvecklaren tror att användarna vill ha det. Enligt respondent E är det viktigare med användarmedverkan ju mer komplext systemet är. Ju krångligare och mer komplext systemet är desto mer stöd behöver utvecklaren stöd från någon som kan verksamheten och som kan säga hur de vill ha systemet. Respondent F anser att det är självklart att ett komplext system kräver högre användarmedverkan. Om inte funktionsspecifikationen är välskriven så utvecklaren vet hur allt skall fungera krävs således hög användarmedverkan.

4 Person som utbildas extra på systemet för att kunna hjälpa vanliga användare.


33

Enligt respondent G finns komplexa system som inte behöver ha några användare då komplexiteten kan ligga i någon typ av beräkningsalgoritm som användarna inte ser. Men enligt respondenten kan det ofta vara nödvändigt att ha med användarna då det kan finnas mycket som utvecklaren inte känner till. När det har att göra med vilken arbetsprocess användarna har är det absolut nödvändigt med användarmedverkan. Respondent H tror att behovet av användarmedverkan är lika viktigt i komplexa som i enkla system.

MÄLARDALENS HÖGSKOLA Ekonomihögskolan - Analys -

34

5 Analys

I detta kapitel analyseras respondenternas svar. Skillnader och likheter i svaren undersöks och jämförs dels med varandra dels med teorin som presenterades i kapitel två.

5.1 Generellt om användarmedverkan

Samtliga respondenter ansåg att användarmedverkan var bra och att det oftast spelar en stor roll i utvecklingsarbetet. Några respondenter hävdade att de inte skulle kunna arbeta utan användarnas inblandning, men det måste vara rätt typ av användare, en användare med system- och verksamhetsförståelse. Detta stämmer överens med det McKeen & Guimares (1997) skrev om att användarmedverkan är direkt relaterat till bra system och ses som en stor informationskälla. Sju av åtta respondenter hade erfarenhet av användarmedverkan. Hälften av respondenterna menade att användarmedverkan ofta förekom i systemutvecklings-projekt. Vissa hade aldrig arbetat utan användarmedverkan. Att de aldrig arbetat utan användarmedverkan kan leda till att de har en positiv inställning till det. Om de hade arbetat utan användare är det möjligt att de sett fördelar med det, eller kanske fått upp ögonen för eventuella negativa synpunkter. De respondenter som arbetade som konsulter ansåg att användarmedverkan inte förekom i någon större utsträckning. Kan detta bero på att utvecklare, som arbetar på ett och samma företag, till skillnad från konsulter, lättare hinner skapa en relation med användarna vilket för det lättare att involvera användarna? Kanske finns en policy på vissa företag som medför att användarmedverkan ska användas och på vissa företag finns inget sådant vilket gör att konsulter, som arbetar på olika platser, kommer i kontakt med olika policys? Flera av respondenterna tyckte att det bästa en användare kan bidra med är information om verksamheten som systemet ska agera i. Sju av respondenterna ansåg att det sämsta användare kan bidra med är förändringsförslag i mängder som berör detaljer. Varför den åttonde respondenten (respondent C) inte ansåg det kan bero på att denne ansågs sig har låg erfarenheten av användarmedverkan och kommer kanske därför inte i kontakt med alla ändringsförslag som läggs fram, utan får de förslag som ska ändras av projektledaren. Samtliga respondenter hade erfarenhet av att det kan bli situationer där många användare i efterhand kommer med tillägg som oftast inte bidrar positivt till systemets funktionalitet. Finns det ingen struktur i involverandet av användare kan detta resultera i ett kaosartat arbetssätt och användarna kan involveras i oönskade utvecklingsfaser. Den åttonde (respondent C) respondenten ansåg att det inte fanns något som var det sämsta en användare kunde bidra med. Detta kan återigen bero på att denne inte har direktkontakt med användarna och det mesta användarna ”ställer till med” filtreras genom projektledaren


35

5.2 Organisation och ledningens support

Enligt undersökningsmodellen (se punkt 2.4) är det viktigt att utvecklingsprojektet är väl förankrat i det beställande företagets organisation och ledningsgrupp. Enligt modellen skall utvecklarna tillsammans med ledningen avgöra vem eller vilka som skall vara med i utvecklingsarbetet. Hälften av respondenterna menade att det var projektledaren som bestämde om användarmedverkan skulle nyttjas. En annan av respondenterna menade att beställande företag hade intresse av att ha med användarmedverkan, men att de ännu inte förstått den verkliga nyttan med detta. Detta kan bero på att de som sitter i företagens ledning inte har kunskap om hur ett system utvecklas och vilken kompetens som krävs för att det systemet som utvecklas skall bli bra. Det är möjligt att när företagsledningens kunskap om systemutveckling ökar kommer de att förstå nyttan med användarmedverkan. Det visade sig att vid webbutveckling, som två av respondenterna huvudsakligen arbetade med, är användarmedverkan troligtvis extra viktigt eftersom man inte vet så mycket om målgruppen. Detta är inte något som berörs i den teori som uppsatsförfattarna tagit del av, vilket kan bero på att vissa av artiklarna är äldre och när de skrevs var inte webbaserade applikationer vanliga. Slutligen hade en respondent förhoppningar om att uppdragsgivare vet vilka som besitter rätt förståelse och kunskap för att på så sätt kunna välja rätt användare. Blir utvecklarna tilldelade användare som inte kan tillföra någon ny kunskap kan det lätt bli som uppsatsförfattarna förmodar i sin undersökningsmodell, att användarna snarare blir en börda för utvecklaren än ett tillgång.

5.3 Typ av inblandning

Enligt undersökningsmodellen är det viktigt att systemutvecklarna avgör vilken typ av inblandning som användarna skall ha i utvecklingsprojektet. Den undersökning som Ljung och Allwood genomförde 1999 visade på att system-utvecklarna anser att användarmedverkan i form av seminarium, projektgrupper och referensgrupper är tämligen eller helt betydelselös. Den enda typ av användar-medverkan som systemutvecklarna anser viktig är användartester. Till skillnad från Ljung och Allwoods undersökning visade resultatet i denna undersökning på att referensgrupper var den vanligaste typen av användarmedverkan. Vad skillnaden i dessa två undersökningars resultat beror på, kan uppsatsförfattarna inte svara på, det kan ha att göra med att undersökningarna har genomförts med fem år mellanrum och synen kan ha förändrats under tiden. Ingen av respondenterna uppgav att de använde sig av frågelådor vid användarmedverkan. Inledningsvis ställde sig uppsatsförfattarna frågande till om det verkligen ansågs som användarmedverkan. En anledning till att ingen av respondenterna använde sig av frågelådor kan vara att de, i enighet med uppsats-författarna, inte ansåg det som användarmedverkan. Annars kan det, helt enkelt, bero på att ingen av respondenterna använde sig av frågelådor.


36

Tre av respondenterna menade att det är projektledare som bestämmer vilken typ av inblandning som användaren skall ha i utvecklingsarbetet, en av respondenterna menade att det är kunden som bestämmer det. Två av respondenterna sade att typen av användarnas inblandning bestäms under utvecklingsarbetets gång. Det var endast en av respondenterna som själv fick bestämma typen av användarmedverkan, vilket ligger i linje med undersökningsmodellens teori. Uppsatsförfattarna tror att det kan bero på att projektledaren kan anses ha erfarenhet av liknande arbeten och på så sätt komma fram till en passande lösning direkt. Enligt resultatet var det endast en av respondenterna som själv fick bestämma vilken typ av inblandning användarna skall ha. Detta kan bero på att flera utvecklare kan arbeta med samma projekt men i olika faser och därför är det mer lämpligt att en person som har en mer övergripande roll, som en projektledare, bestämmer typ av inblandning.

5.4 Utvecklingsfas

Med utvecklingsfas avses i vilken fas av utvecklingsprocessen utvecklingen befinner sig. Detta kan vara avgörande för huruvida användarmedverkan är lämplig eller inte. I teorin framgår dock inte i vilka faser användarmedverkan kan vara olämplig utan bara att den kan vara det. Därför ämnade uppsatsförfattarna att undersöka vilka faser det kunde vara. Det visade sig att större delen av respondenterna inte ansåg att användarmedverkan var lämplig under själva programmeringen av systemet (se diagram 2), då användarna anses störande, vilket också kan leda till att projektet tar längre tid. Även testfasen, analysfasen och implementationsfasen visade sig vara faser där användarmedverkan kan vara skadlig eller negativ. Testfasen kan innebära att användarmedverkan ses som negativt då dessa, enligt en respondent, inte är bra på att hitta de viktiga felen. De användare som testar hittar oftast petitessfel och layoutfel som blir till en last för den huvudsakliga testningen. I analysfasen sker tekniska överläggningar och där har oftast användare inte något att bidra med, menar en respondent och uttrycker att där kan det vara negativt. En respondent hävdade att vid implementeringen är kraven redan satta och om användarna börjar ge invändningar vid detta skede kan det ge störande effekter på projektet. Respondenternas svar ligger i linje med undersökningsmodellen som tar upp att det rent av kan vara skadligt att använda sig av användarmedverkan i vissa faser i utvecklingen. Trots att respondenternas svar ligger i linje med undersökningsmodellen, finns det tecken på att denna uppfattning är högst individuell. Detta då tre av respondenterna arbetade på samma företag men hade olika uppfattningar om detta. Konsulterna däremot, som arbetade på samma företag dock på olika projekt, tyckte båda att programmeringen var den fas som kunde ses som mest negativ.


37

5.5 Grad av inflytande

I undersökningsmodellen går att läsa, att utvecklaren kan hämmas om graden av användarmedverkan är för hög. Detta är inget som påvisats i resultatet. Där visade det sig att användarna generellt sett varken har en hög eller låg grad av inflytande, utan det som avgör en användares inflytande är dess kunskap och kompetens. Resultatet visade även att användarnas krav oftast filtreras genom projektledaren eller beställaren innan det nådde utvecklarens bord. Det största inflytandet en användare har var i början av utvecklingsprojektet då kraven fastställs. Där anses användaren ha en fundamental funktion. Det är viktigt att systemutvecklarna får vara med själva och avgöra hur mycket inflytande användarna har enligt undersökningsmodellen. Resultatet påvisar även att respondenterna har haft goda förutsättningar för att kunna påverka inflytandet användarna har. De flesta kan välja om de vill ta kontakt med berörda användare. Samma sak gäller när utvecklaren ser fel i kravspecifikationen och ser behov av att rätta till det. Respondenterna anser att det enklaste och effektivaste sättet att påverka användarna är genom kontakt med dem för att förklara vad som bör ses över eller ändras. Genom tekniska argument kan respondenterna påverka användarna då utvecklarna anser att de hade mer kunskap om tekniska detaljer och tillvägagångs-sätt i utvecklingen.

5.6 Kommunikation

I undersökningsmodellen skrivs att om kommunikationen tryter kan konflikter uppstå och då minskar nyttan med användarmedverkan. Enligt undersöknings-modellen anses en viktig del i användarmedverkan vara att innan utvecklings-arbetet påbörjas, klargöra på vilket sätt kommunikation mellan de eventuella användarna och utvecklarna skall ske. Detta för att underlätta kommunikationen och förebygga konflikter under utvecklingsarbetet.

Sex av åtta respondenter tyckte att kommunikationen med användarna brukar fungera bra och upplevde inte att det brukar vara några problem. Däremot tyckte en respondent att kommunikationen endast fungera bra ibland, det kan bero på att den respondenten inte hade direkt kontakt med användarna, utan kommunikationen sköttes via en tredje part. Enligt en respondent, som ansåg att denne inte hade speciellt stor erfarenhet av användarmedverkan, fungerade kommunikationen dåligt eller också var den obefintlig. Att två av respondenterna hade en skild syn från övriga beror säkerligen på att de arbetar med användarna på olika sätt och att en av dem inte hade stor erfarenhet av användarmedverkan.


38

Resultatet visade att kommunikationen med användarna skedde på olika sätt, många nyttjade e-brev samt telefon som kommunikationsmedel. Denna teknik anses lämpa sig väl då utvecklarna inte alltid är lokaliserade hos kunden. Men uppsatsförfattarna tror ändå att den bästa kommunikationen uppstår då utvecklare och användare träffar varandra då kan de kommunicera både verbalt och via bilder vilket kan medföra att färre missförstånd uppstår. Två av respondenterna kommunicerade med användarna via en representant dvs. de hade inte direktkontakt med användarna. Men upplevde ändå att de hade en kommunikation med användarna även om den inte var direkt. Då åsikter från användaren kan gå förlorade när kommunikationen sker via en tredje part tros detta ge både för och nackdelar. Detta då det kan vara viktig information som går förlorad men också mycket detaljåsikter som inte är av väsentlig natur kan filtreras bort. Detta anser uppsatsförfattarna borde vara något som ses som positivt då resultatet visade på att de flesta respondenterna ansåg att det sämsta som en användare kan bidra med är allt för detaljerade åsikter på hur systemet skall utformas (se 5.1).

5.7 Terminologi

Enligt undersökningsmodellen är det viktigt att utvecklarna och användarna förstår varandra och pratar samma språk. Tre respondenter ansåg att det var vanligt att utvecklarna och användarna pratade olika språk. Dessa menade att det är viktigt att man som utvecklare lär sig kundens språk, eller som Gulliksen och Göransson (2002) skriver, kommunicera med bekanta begrepp, inte bara med tekniska termer. Tre av de fem återstående respondenterna menade att det förekom terminologiska problem men att det inte skedde ofta. En annan respondent sade att när dessa problem uppstod försökte utvecklaren förklara på ett enklare språk, men hade då svårt att få med sig helheten. Detta ligger i linje med undersökningsmodellen, lyckas man inte förstå varandra på ett bra sätt kan det försvåra utvecklingsarbetet avsevärt, utvecklaren måste då lägga ner tid på att omformulera sig och detta kan i sin tur bidra till att utvecklaren ser användaren som en börda. De övriga två respondenterna hade mindre kontakt med användare men ansåg att det inte brukade förekomma några terminologiska problem. Den ena respondenten trodde att detta var ett mycket större problem för 20 år sedan då användarna hade mindre datorvana.

5.8 Attityd

Enligt utvecklingsmodellen kan användarnas attityd ha stor påverkan på utvecklingsprojektet. Om användaren inte är villig att vara med kan detta leda till oengagemang och motsträvighet från användarens sida. Flertalet av respondenterna ansåg att användarnas inställning påverkade deras attityd till utvecklingsarbetet och syn på det nya systemet. Men även på denna punkt hade respondenterna olika syn, vilket kan bero på att de arbetar med användarna på olika sätt och har olika erfarenheter av systemutveckling och användarmedverkan. Inte heller här kunde en generell uppfattning inom företagen ses. Endast en av de


39

tillfrågade respondenterna hade varit med om att användare uppenbarligen inte har velat vara med i utvecklingsarbetet och svarat ja och nej på frågor för att bli av med det. Detta var inte något som respondenten upplevde som vanligt förekommande. När det förekommit har detta lösts genom att användargruppen har omformats och de som inte var villiga att delta har försvunnit. Därför kan man undra om det är organisationen, eller den som tillsätter användarna, som har ansvaret för att det är rätt användare som väljs ut. Men om inte den som tillsätter vet vilken kompetens och kunskap som krävs av användaren hur ska den då kunna välja rätt person? Hälften av respondenterna anser att användarna är villiga till att medverka i utvecklingsarbetet speciellt om det är i utvecklingen av ett system som de verkligen ser någon nytta med. En av dessa respondenter ansåg att användarna vill vara med så mycket de får alla gånger de bli tillfrågade, det som begränsar användarnas medverkan är när projektledaren för utvecklingsprojektet säger ifrån. Detta stämmer överens med undersökningsmodellen som säger att om användaren har en positiv attityd och är för engagerad och villig att vara med kan det medföra att denne försöker bli involverad i delar i utvecklingsarbetet som denne inte skall vara delaktig i. Två av respondenterna ansåg att det varierar hur villiga användarna är till att delta i projektet. Den ena menade att de flesta användarna hellre tycker till när det är klart istället för att medverka vid specifikationen. Vilket då kan medföra att det som har utvecklas inte alls var det kunden ville ha. Finns inte allt med i specifikationen från början kan det leda till att systemet inte får den utformning och funktion som det är tänkt. Är systemet redan implementerat kan det vara svårt att göra större ändringar, och systemet blir kanske inte så tillfredsställande som det var tänkt.

5.9 Systemkomplexitet

Enligt McKeen (1994) kräver ett system med hög komplexitet en hög grad av användarmedverkan vid utvecklingsarbetet. I undersökningsmodellen antas att ett system med hög komplexitet borde kräva högre tekniskt kompetens av dem som deltar i utvecklingsarbetet. Eftersom användarna vanligtvis inte har den kompetensen kan det vara olämpligt att ha en hög grad av användarmedverkan i system med hög komplexitet. De flesta av respondenterna var i linje med den teori som McKeen lagt fram och ansåg att ett system med hög komplexitet kräver högre grad av användarmedverkan. Detta för att användarna ska få ett system som kan fungera som ett hjälpmedel i deras arbete och inte som ett hinder som är krångligt att använda. En av dessa respondenter ansåg även att om ett system har en komplex uppbyggnad och inte är komplext utåt för användarna ökas inte behovet av användarmedverkan. En annan av dessa respondenter menade att om funktionsspecifikationen är väl skriven, vilket de nästan aldrig är, ökas inte behovet av användarmedverkan En av respondenterna ansåg däremot att behovet av användarmedverkan är oberoende av systemets komplexitet och menade att behovet av användarmedverkan är lika stort i komplexa som enkla system. Ingen av respondenterna hade alltså samma uppfattning som uppsatsförfattarna om behovet av användarmedverkan vid komplexa system.

MÄLARDALENS HÖGSKOLA Ekonomihögskolan - Slutsats -

40

6 Slutsatser

Genom analysen har uppsatsförfattarna kunnat jämföra respondenternas svar mot teorin. Utifrån denna har uppsatsförfattarna dragit slutsatser och svarat på de inledande frågeställningarna. Slutsatserna är inte på något vis generella eftersom uppsatsförfattarna genomförde en kvalitativ undersökning med åtta respondenters åsikter.

6.1 Användarmedverkan som ett negativt tillskott

Syftet med uppsatsen var att söka svar på huruvida systemutvecklare på företag upplever att användarmedverkan kan ses som ett negativt tillskott i system-utvecklingen. Undersökningens resultat visar på att användarmedverkan upplevs som ett positivt tillskott i systemutvecklingsarbetet. De respondenter som deltog i undersökningen hade goda erfarenheter av användarmedverkan och ansåg att det är nödvändigt. Därför dras slutsatsen att användarna tillför mer positivt än negativt till utvecklingsarbetet trots att det finns faktorer som kan påverka. Därmed är det inte sagt att det inte finns något negativt med användarmedverkan. Uppsats-författarna upplever att respondenterna anser att de positiva effekterna som användarmedverkan medför är större än de negativa och anser därför att användar-medverkan är bra. Trots den positiva synen på användarmedverkan visade resultatet att det finns risker med att använda sig av användarmedverkan utan någon struktur. Det kan då bli många användare som involveras och därmed många åsikter att ta hänsyn till vilket kan leda till ett ostrukturerat arbete i projektet. En slutsats som dras av detta är att om användarna skall vara med i utvecklingsarbetet ska det finnas en klar struktur för hur de skall involveras. Annars finns risken att de upplevs som besvärligt med användarmedverkan samt att det kan leda till försening av utvecklingen. Resultatet visade att användarens kunskap om verksamheten var den avgörande delen i om användarmedverkan kan ses som skadligt. Detta är något som uppsats-författarna inte finner särskilt anmärkningsvärt då det generellt brukar vara så, oavsett vad man arbetar med, att man inte vill ha en medarbetare som inte besitter den kunskap och kompetens som krävs för uppgiften. Det framkom även att användarmedverkan alltid förekommer mer eller mindre i systemutvecklingsprojekt. Några av respondenterna hade aldrig arbetat utan användare. Uppsatsförfattarna frågar sig då om respondenterna anser att användar-medverkan är positivt då vissa aldrig har arbetat utan och inte vet hur de skulle gå till väga för att utveckla ett system utan att involvera användarna. En slutsats om kan dras av detta är att de som arbetar med användarmedverkan tycker att det är bra. Enligt resultatet kan typen av utvecklingsprojekt påverka användarens betydelse i projektet. Vid utveckling av webbapplikationer finns ofta ett större antal okända användare än vid traditionell utveckling. Då målet är att nå så många som möjligt


41

med produkten, tar organisationen och ledningen ofta större hänsyn till användar-medverkan vid denna utveckling. Därför dras slutsatsen att användarna kommer att få en ökad betydelse för systemutveckling i framtiden då uppsatsförfattarna tror att fler och fler applikationer kommer att utvecklas webbaserat.

6.2 Utvecklingsfas

Uppsatsens syfte var även att ta reda på i vilka faser som användarmedverkan kan upplevas som ett negativt tillskott. Enligt undersökningsmodellen kan det finnas faser där användarmedverkan kan vara skadligt. Resultatet styrkte detta och visade på att det finns faser där användarmedverkan inte är särskilt användbar. Programmeringsfasen var den fas där användarmedverkan ansågs kunna göra mest skada. Andra faser där användarmedverkan ansågs överflödiga var analysfasen, testfasen samt implementeringsfasen. Dessa faser ansågs dock inte lika viktiga som programmeringen. Det som även framkom i undersökningen var att uppfattningen om hur skadligt och överflödig användarmedverkan kan vara i olika faser är individuellt. Trots detta svarande nästan alla respondenter att programmeringsfasen var den fas där användarmedverkan ses som mest överflödig. Men de hade alla olika syn på hur det kan vara överflödigt. Dock bottnade det i att användarmedverkan i programmeringsfasen kan orsaka tidsbrist eller tidsåtgång i projektet. Därför dras slutsatsen att användarmedverkan i programmeringsfasen ses som negativt då det kan försvåra utvecklarens arbete vilket i sin tur kan leda till att utvecklingen tar längre tid än planerat och därmed får andra, senare faser mindre tid eller också försenas projektet.

6.3 Hur användarmedverkan upplevs av systemutvecklarna

Syftet var även att utreda på vilket sätt användarmedverkan kan upplevas som negativ. Då resultatet visade på delade meningar huruvida det var projektledningen eller uppdragsgivaren som bestämde om användarmedverkan skulle nyttjas, kan inte någon annan slutsats dras än att det varierar mycket mellan företag. Det kan sägas att organisationen och ledningen kan vara en negativ faktor för ett utvecklingsprojekt om det inte är väl förankrat. Med en dålig ledning som inte besitter rätt kunskap att välja lämpliga användare, kan utvecklarna se användar-medverkan mer som en börda än ett tillskott. Resultatet visar även att det kan vara skillnad mellan att arbeta som konsult istället för att arbeta på det företaget som utvecklaren är anställd. Konsulterna får ofta rätta sig mer efter kunden. En slutsats som dras av detta är att konsulterna kanske i större utsträckning upplever användarmedverkan som negativ då det är användarna som har krav på det nya systemet och kan därför upplevas som besvärliga. Konsulterna har inte heller samma förutsättningar att skapa en relation med användarna som de som arbetar på företaget de utvecklar för, då de inte arbetar på företaget så länge. Resultatet visar på att typen av inblandning som användarna skall ha i utvecklingsarbetet vanligtvis bestäms av projektledaren. Att respondenterna själva inte får bestämma typ av inbladning kan leda till att de ständigt tvingas arbeta med


42

användarmedverkan på olika sätt vilket kan vara tidskrävande och leda till att respondenterna upplever det som besvärligt med användarmedverkan. Resultatet visar att förekomsten av terminologiska problem anses ha minskat då många idag har en persondator hemma och använder även datorer i den dagliga verksamheten vilket medför en ökad datorvana. Vidare visade resultatet på att vid kommunikation mellan utvecklare och användare i systemutveckling fanns det få negativa tendenser. Snarare ansågs kommunikationen fungera bra mellan båda parter. Utifrån det dras slutsatsen att problem gällande terminologi och kommunikation idag inte är en faktor som påverkar systemutvecklarnas syn på användarmedverkan i samma utsträckning som den kan ha gjort tidigare Kommunikationen med användarna borde även underlättas för systemutvecklare som är anställda på företaget de utvecklar systemet till då de känner till vissa bransch eller företagsspecifika termer som kan användas vid kommunikationen med användarna. Trots att systemutvecklarna hade väldigt olika syn på hur villiga användarna var att delta i utvecklingen dras ändå slutsatsen att de användare som får möjlighet att vara med och utveckla nya system vill vara oftast med. Det som hindrar dem är att de inte har tillräckigt med tid för att kunna delta i utvecklingsprojektet då de redan är hårt belastade med sina ordinarie arbetsuppgifter. Man kan då anta att det är därför som systemutvecklarna har fått den spridda synen på att användarna är villiga att delta. Det viktigaste för att en användare skall vara villig och tycka att det är meningsfullt att delta i utvecklingsarbetet är att denne skall se det nya systemet som viktigt och känna att det kommer att hjälpa dem och underlätta deras dagliga arbete. Undersökningens resultat visar även på att ett system med hög komplexitet kräver högre grad av användarmedverkan vid systemutveckling. Detta stämmer överens med de resultat som McKeen kom fram till i sin undersökning 1994. Dock ansåg en av respondenterna att användarmedverkan är lika vikigt i komplexa som i enkla system. En förklaring till detta kan vara att respondenten anser att användar-medverkan är så viktig i utvecklingsarbetet att de alltid vill ha en hög grad av användarmedverkan och därför upplever de inte ett ökat behov.


43

7 Fortsatt forskning

Som fortsatt forskning föreslås att en liknande undersökning utförs men då med fokus på att jämföra konsulter och de som utvecklar åt företaget de arbetar på. Det skulle även vara intressant att undersöka om det är någon skillnad på behovet och synen på användarmedverkan i traditionell utveckling i förhållande till webb-utveckling.

MÄLARDALENS HÖGSKOLA Ekonomihögskolan - Källförteckning -

44

Källförteckning Publicerade källor Böcker Avison D. E., Fitzgerald G, Information Systems Development: Methdologies, Tehniques and Tools, McGraw Hill, 1995 Beekman G., Rathswohl E., Computer Confluence – IT Edition, Prentice Hall, 2002 Bell J, Introduktion till forskningsmetodik, Lund, Studentlitteratur, 1995. Eriksson L. T., Wiedersheim-Paul F., Att utreda forska och rapportera, Malmö, Liber AB, 2001. Ejvegård R., Vetenskaplig metod, Lund, Studentlitteratur, 2003. Gulliksen J., Göransson B., Användarcentrerad Systemdesign, Lund, Studentlitteratur, 2002. Holme I. M., Solvang B. K., Forskningsmetodik, Lund, Studentlitteratur, 1997. Lundequist, J, Design och produktutveckling. Metoder och begrepp, Lund Studentlitteratur, 1995, ISBN 91-44-49251-0. Patel R., Davidsson B., Forskiningsmetodikens grunder, Lund, Studentlitteratur, 1994. Artiklar Doll J. William, Xiaodong Deng, The Collaborative Use of Information Technology: End-User Participation and System Success, Information Resources Management Journal; Apr-Jun 2001; 14, 2; ABI/INFORM Global. Ewusi-Mensah Kweku, Przasnyski H. Zbigniew, Factors contributing to the abandonment of information systems development projects, Journal of Information Technology, 9, pp. 185 -205, 1994 Guimares Tor, Staples D. Sandy, McKeen D. James, Empirically testing some main user-related factors for system development quality, The Quality Management Journal, 2003, Vol 10, Nr 4, p.39. Hartwick Jon, Barki Henri, Communication as a dimesion of User Participation, IEEE Transactions on professional communication, Vol. 44 No. 1 March 2001 Hartwick Jon, Barki Henri, Rethinking the Concept of User Involvement, MIS Quarterly, Vol. 13 No. 1 March 1989, s 53

MÄLARDALENS HÖGSKOLA Ekonomihögskolan - Källförteckning -

45

Ljung K., C.M. Allwood, Computer consultants views of user participation in the system development process, Computers in Human Behaviour 15, pp. 713-734, 1999. McKeen D. James, The Relationship Between User and User Satisfaction: An Investigation of Four Contingency Factors, MIS Quarterly, December 1994, pp 427-451 McKeen D. James, Guimares Tor, Successful Strategies for User Participation in Systems Development, Journal of Management Information System, Vol. 14 No. 2, pp.133-150, 1997. Opublicerade källor Internet Susning http://www.susning.nu/Informationssystem, 2004-04-15.

- Intervjufrågor - Bilaga 1

Intervjufrågor – användarmedverkan ur systemutvecklarens syn. Personliga frågor 1. Presentera kort företaget du arbetar för. 2. Vad är dina huvudsakliga arbetsuppgifter? 3. Hur många år har du arbetat som systemutvecklare? Generellt om användarmedverkan 4. Vad anser Du användarmedverkan innebär? 5. Har Du erfarenhet av användarmedverkan? 6. Hur vanligt förekommande är det med användarmedverkan vid systemutveckling? 7. Hur upplever Du uppdragsgivarens syn på användarmedverkan? 8. Vad är enligt din mening det bästa/sämsta som användaren kan bidra med? 9. Vem bestämmer om man ska ha användarmedverkan med i utvecklingsprojektet? 10. Vilka faser har ni med i det utvecklingsarbetet som du brukar arbeta med? Typ av inblandning 11. Vilken typ av inblandning är vanligast vid användarmedverkan (dvs. seminariegrupper, referensgrupper, testgrupper, frågelåda, alltså hur arbetar ni med användarna i projektet)? 12. Vem bestämmer vilken typ av inblandning användarna skall ha? Utvecklingsfas 13. I vilka utvecklingsfaser och på vilket sätt anser Du att användarmedverkan kan vara överflödig/negativ? Grad av inflytande 14. Vilken grad av inflytande har användaren haft under utvecklingsarbetet? 15. Hur mycket har Du haft möjlighet att påverka användarens grad av inflytande?

- Intervjufrågor - Bilaga 1

16. På vilket sätt har Du haft möjlighet att påverka användarens grad av inflytande?

Kommunikation 17. Hur sköts vanligen kommunikationen mellan er och användarna? 18. Anser Du att kommunikationen brukar fungera bra? Terminologi 19. Har vanligt är det att det förekommer terminologiska problem mellan er och användarna? Attityd 20. Anser Du att användarnas inställning till att bli delaktiga i projektet påverkar deras attityd till utvecklingsarbetet? 21. Hur villiga är användarna till att medverka i utvecklingsarbetet? 22. Är det vanligt förekommande att användarna har en dålig attityd? Systemkomplexitet 23. Hur påverkar graden av komplexitet på systemet behovet av användarmedverkan. 24. Vad är din generella uppfattning om användarmedverkan?

- Intervju 1 - Bilaga 2

INTERVJU 1 2004-04-22 1. Presentera kort företaget du arbetar för (Presentera kort vad företaget arbetar med)? R: Det Bolaget jag jobbar på nu då, vi jobbar med affärssystem, vi säljer affärssystem, vi implementerar affärssystem, allt från att kunden tar kontakt med oss önskar en… ja, ställer en förfrågan en offertförfrågan till förvaltning och support och drift av affärssystemetet och det inkluderar, ja allting runt teknik, installation av servrar hårdvara och nät och utbildning, programmering. Allting runt och kring ett affärssystems installation. 2. Vad är dina huvudsakliga arbetsuppgifter? R: Mina huvudsakliga arbetsuppgifter består i att.. man kan säga att jag är verksamhetskonsult eller applikationskonsult och det innebär då att dels vara med vid säljtillfället som säljstöd till säljaren, presentera affärssystemet, presentera lösningar ifall kunden har ställt frågor tidigare i en kravspecifikation eller frågor.. saker som är viktiga för kunden att fungera i ett nytt affärssystem i deras dagliga arbetsrutiner. Att man är väl förberedd, presenterar, presenterar lösningar och följer upp det sedan. Sen när kunden beställer system och ja blir kund så handlar det om att vara.. ja dels utbilda kunden i systemet som de köper och dels vara med och designa upp systemet kan man säga. Att de passar deras behov. Systemera helt enkelt och sedan när man har systemerat ihop med kunden ha tät dialog med programmeraren så att de förstår vad det är som ska göras. Testa av anpassningar när dom är utförda av programmeraren att dom uppfyller kundens önskemål innan dom släpps vidare till kunden för egen test. Och man kan säga delprojektledare också att ansvarar för vissa processer i projektet, inte huvudprojektledaransvar men delprojektledare kan man säga. 3. Hur många år har du arbetat som systemutvecklare? R: 7.5 år I: Förtydligar att det är respondentens generella uppfattning av alla projekt som denna deltagit i som är intressant. R: Ok. 4. Vad anser Du användarmedverkan innebär? R: .. Ja att dom får komma med sina synpunkter och krav på funktionalitet och information som är viktiga för att bedriva deras dagliga verksamhet för att företaget ska fungera. I morgon också efter en implementation eller en färdig lösning. I: Så att i princip en väl utformad kravspecifikaiton som är felfri behöver inte användarna komma med så mycket mer..? R: Ehh, min generella uppfattning är att man inte kan börja utveckla ifrån en kravspecifikation så som bolagen lämnar kravspecifikationerna idag, de är alldeles för generella och ytliga och gjorda så genellt så att de inte är knutna till ett visst system. När man kommer ner på systemnivå sedan så är det så många villkor om och men som man måste ta hänsyn till, man kanske har ett krav och kraven är rangordnade i olika nivåer, även om det kanske är ett måste krav eller driftkritiskt krav så kan det vara så att man hittar en annan väg att gå i systemet sen. Man kanske inte måste anpassa eller designa utan man kan hitta en annan väg. I vilket fall som helst så kommer den där kravspecifikationen alltid upp till ytan och vara ett diskussionsunderlag och man utgår ifrån den, men den bryter man ner sen, man tar kravet och bryter man ner den och tittar om systemet uppfyller de kraven man ställt, gör det de eller hittar man en väg att gå så är det jättebra, det är allas önskan. Gör man inte det så får man bryta ner kravet och titta i detalj i systemet att det verkligen fungerar ihop med användaren då som kanske har ställt kravet eller användaren chef som är ansvarig för att en eventuell förändring ska göras och så måste man i detalj gå igenom så att det uppfyller önskade krav.


5. Har Du erfarenhet av användarmedverkan? R: …Vad klassar ni som användare i detta fallet, är det en slutanvändare ni hänvisar till? I : ..Så fort en användare eller slutanvändare är med i någon del i processen… ja kort och gott en användare som medverkar i utvecklingsprocessen i något steg eller vilken fas som helst. R: En daglig användare? I: ..ja R: Ehh.. Ställ frågan igen. I: Har Du erfarenhet av användarmedverkan? R: JA, räcker det eller? I: Ja det räcker. R: Då håller jag med till viss del. 6. Hur vanligt förekommande är det med användarmedverkan vid systemutveckling? R: Ehm.. Det är väldigt vanligt. På det ena eller andra sättet så kommer det till användaren sen och han eller hon har alltid en åsikt. Har man gjort någonting där användaren kanske inte har fått vara med från början kommer det ändå hamna hos den personen och det är lätt att det kommer tillbaka för justeringar. Så det är ofta.. eller nästan alltid. I: I mer eller mindre grad. R: Ja. 7. Hur upplever Du uppdragsgivarens syn på användarmedverkan? (Beställaren) R: Det beror lite på.. beror på storlek på bolag, brukar det nog oftast göra. Är det mindre bolag då tar man kanske mer hänsyn till användaren om man är så få så att man måste in och fråga den där nyckelpersonen som sitter och kan en viss uppgift och sitter på nyckelkunskap. Då är man så illa tvungen att ha med slutanvändaren. Ett större bolag som kanske har en IT-avdelning som är mer drivande tar nog gärna mer beslut själva och känner ofta vad användarna har för behov och tar nog mer beslut själva och så gör man en lösning och sen så konfirmerar man sen med användarna att det är ok 8. Vad är enligt din mening det bästa / sämsta som användarna kan bidra med? I: Vi börjar med det bästa. R: Han kan ge en förståels e för vad användaren vill ha ut för resultat, det är väldigt viktigt. Inte alltid förklara hur det fungerar idag eller systemet fungerar idag utan vad är det för resultat som önskas i slutändan. Och sen kan man ju lösa det på olika sett… men ja, jag svarar nog så. I: Och det sämsta? R: Det sämsta han kan bidra med.. Många användare förklarar ju hur det fungerar idag med det nuvarande systemet.. Så här har det alltid fungerat, man vill ha samma bild, man vill kunna se det man har sett innan på samma sett, det är oerhört vanligt men om användaren kan se över det och se till slutresultatet att man ser samma information fast på ett annat sett. I: Du menar att dom kan bromsa och vill ha kvar.. det ska vara som förr. Det blir ett nytt system men det blir ingen effektivitetsökning.


R: Nää precis. Utan man ser.. man är för detaljerad och ser till sin rutin. Man ska dyka upp ett steg högre och se slutresultatet. Istället för att det ska se ut som det gjorde tidigare.. För det synkar gärna ner projektet och man gör onödiga anpassningar. 9. Vem bestämmer om man ska ha användarmedverkan med i utvecklingsprojektet? R: Det gör ofta kundens egna projektledare. De är den som tillsätter ihop med ledningen kanske, eller beställaren vilka som ska ingå i projektet. I: Inte ni som utvecklare? R: Först och främst så bestäms det av kunden vilka som ska ingå i projektet och då delar man upp ansvaret i olika områden, man kan kalla dom processansvariga t.ex. Någon har hand om inköp och hela inköpsrutinen på ett bolag och då sätter man en ansvarig för den processen. Jag har dialog. Jag har dialog med den processansvarige för den processen och behövs det göras en anpassning eller att något ska systemeras upp så tar jag först dialog med den personen, anser han att han inte har kompetens nog att förstå hur det ska systemeras upp och hur rutinen ska fungera, då tar han själv kontakt med de personerna på sin avdelning eller dom han finner lämpliga. Ofta är det så. Sen kan jag känna att jag inte får tillräckligt information från processägaren då kan jag själv gå och fråga en användare, men det känner ofta processägaren själv. 10. Vilka faser har ni med i det utvecklingsarbetet som du brukar jobba med? (Förklarar lite mer och nämner exempel som förstudie, analys..) R: Man gör väl de där aktiviteterna på det ena eller det andra sättet men oftast i praktiken så brukar det handla om såhär… oftast har jag varit med om det här på de bolag jag varit på. Man kör en utbildning och man kör en utbildning i standardfunktionen, så här fungerar systemet idag. Och sen så lär sig användaren alla standardfunktioner och sen så ser man kan vi använda detta, ja eller nej. Om man då säger nej så har man efter utbildningen och egen träning av användaren så att användaren verkligen känner till standardfunktionerna. Då har man, ja kalla det designfas eller produktgenomgång. Man går in i systemet och med bakgrund av sina processer och rutiner som man har försöker köra igenom systemet, klarar vi oss igenom standard. Nej, här behöver vi göra en anpassning och i det läget då så försöker man så långt som möjligt systemera upp anpassningen i funktionen tillsammans med kunden sittandes med systemet jämte sig så långt som möjligt vad man vill ha ut av funktionaliteten vad det är för information man vill ha ut. Efter det att man har försökt skriva ner så mycket som möjligt med kunden och alla undantag och villkor och sådant som kan uppstå, så brukar man gå tillbaka, jag går tillbaka till mig och systemerar upp mer i detalj på tabell och fältnivå och klasser osv. vad programmeraren ska göra vad han ska programmera efter. Ja, sen sätter programmeraren igång ifall kunden beställer enligt den specifikationen och tidsuppskattningen som man har lämnat till kunden efter det här produktgenomgången eller designen. Programmeraren sätter igång och utveckla, programmeraren testar själv, oftast är dom testerna inte så mycket värda, utan de måste tillbaka till mig som beställare till programmeraren i och med att jag varit med kunden och beställt och systemerat upp det så vet jag vad kunden har sagt, kanske har jag inte har fått med allt på papper, det är så att man har en känsla hur kunden reagerar hur en funktion verkligen fungerar sen när en programmerare har gjort det. Så jag testar av sen, man testar och efter den testen så installeras det i en testmiljö hos kunden och därefter får kunden själv testa, godkänna och sen vidare till driftsmiljö. Och när kunden har testat och godkänt så blir det någon form av systemdokumentation av programmeraren och sen användardokumentation av mig så att kunden förstår hur det ska fungera. I grova drag så fungerar det ofta så i praktiken.


11. Vilken typ av inblandning är vanligast vid användarmedverkan? Förklarar närmare vad vi är ute efter dvs seminariegrupper, referensgrupper, testgrupper, frågelåda, alltså hur arbetar ni med användarna i projektet R: Efter utbildningen som sagt så bokar någon form av produktgenomgång, alltså ett större möte med ansvarig processägare, ansvarig för en viss funktion. Och vill han då ta med sina slutanvändare dom som ska använda systemet, så är dom med också. Så man sitter som i en projektgrupp kan man säga och går igenom varje funktion och systemerar upp varje funktion ifall det behövs, så projektgrupp kan man säga. I: Ni har möten, dom är inte med i det dagliga arbetet? R: Nä, inte i dagligt programmeringsarbete, utan man tar det i en projektgrupp eller workshopgrupp och försöker skriva ner så mycket som möjligt. Däremot när systemet är i drift kanske, när man är igång och kör då är det mer vanligt att programmeraren kommer tillbaka till kunden och sitter hos kunden, och kanske själv lyssnar in vad kunden vill eller slutanvändaren vill, men då har man oftast småjusteringar så då förstår programmeraren bättre. För oftast är programmeraren så djupt nere i koden och förstår inte den avancerade logiken och alla relationer och allt ihop, systemmässigt. 12. Vem bestämmer vilken typ av inblandning användarna skall ha? R: Det bestäms oftast av våran projektledare tillsammans kundens projektledare. Vilken arbetsform det ska vara, oftast så blir det en form av projektgrupp, större eller mindre. Helst så liten som möjligt med så insatta personer som möjligt verksamheten med beslutsfattande. I: Dom bestämmer alltså löpande för projekt till projekt hur det ska se ut, det är alltså ingen mall man alltid följer? R: Man har en mall där man försöker jobba på det här sättet då att ha en projektgrupp med en ansvarig för varje process, sen får processägaren ta med de personer som han finner lämpligt hos kunden. Men ofta är det situationsanpassat det kan vara så att det inte finns tillräckligt med människor med och sen kan det vara så att processägaren själv är så insatt i verksamheten och har beslutsfattande att han kan ta det själv på sittande fot, vilket är det bästa så få inblandande som möjligt är bra. 13. I vilka utvecklingsfaser och på vilket sätt anser Du att användarmedverkan kan vara överflödig eller rent av negativ? R: Hmm.. Ja det är just vid själva programmeringsarbetet då sköter ju sig programmeraren helt och hållet själv, och vill programmeraren fråga då, så går det ju via mig då som har kontakt med kunden. För att rätt fråga ska formuleras på rätt sätt. Där behövs inte dialogen mellan programmeraren och slutanvändaren. I: Det är bara vid själva kodningsfasen? R: Ja där har de knappt ingen dialog alls.. Ja det är via mig i så fall….. negativ kan jag inte säga att det finns något. I: Vi läste också en artikel att i vissa faser kan det till och med vara skadligt, för projektet att dom är med, det var väl om du hade någon sådan fas? R: …Nä med det är ju efter det att programmeraren har fått sina uppgifter och det han ska göra, då måste han hålla sig till dom och köra efter det, för då är projektets tidsramer planerade efter det man har bestämt och det kunden har beställt. Kommer då användaren och ha dialog direkt med programmeraren så blir det ofta att programmerar avbryts och störs och så kommer det in nya direktiv från användaren som gör att han blir helt förvirrad och hela projektet tar längre tid. Utan att ha pratat med någon systemerare innan eller någon ansvarig projektledare som tar ett beslut så kan det bara dra iväg åt fel håll, så det är väl det spontant som jag kan säga.


14. Vilken grad av inflytande har användaren haft under utvecklingsarbetet? R: Ehh, dom får, Om dom nu får vara med i projektet så att säga eller projektgruppen och ge sin syn på det och sina krav att det här behöver vi, den här informationen behöver vi ha ut, så kommer det alltid… Ja, dom kan vara med till hög grad där och säga vad de behöver med det kommer alltid att filtreras via processägaren eller projektledaren som är beställaren, huvudbeställaren av anpassningen, eller det som ska utvecklas. I: Så man kan säga att de kan ha en hög grad av medverkan men inte så hög grad av inflytande för att det alltid är någon som bestämmer om det dom har sagt duger. R: Det kommer säkert filtreras via en eller två led sen och det beror på att processägaren kanske ser på det hela på mer strategisk nivå att den där funktionaliteten behöver vi inte nu, utan den kan vi leva med och ta sen, eller det där kommer avvecklas det måste vi ha nu men behovet kommer inte vara sen. Och sen måste processägaren sälja in till projektledaren att det här behöver vi, och då kan projektledaren se att det här äventyrar projektet starttid och det drar ut på tiden eller att det inte är ekonomiskt försvarbart eller ja, senarelägga det. 15. Hur mycket har Du haft möjlighet att påverka användarens grad av inflytande? R: … Jag kan gå och prata med vem jag vill, vill jag lyssna på någon eller ha någons åsikt så ser jag till att jag får det, sen kan jag försöka sälja in det behovet till kundens projektledare eller processägaren, men det är ändå kunden som bestämmer sen om beställningen ska göras. I: Man kan säga att du har mer eller mindre ständig möjlighet att påverka? R: Ja, vill jag ha med en användare så har jag hög grad att bestämma det. Men kunden kan ju naturligtvis säga helt ifrån. Oftast sker det där i samförstånd med kunden. 16. På vilket sätt har Du haft möjlighet att påverka användarens grad av inflytande? (Påpekar att Respondenten redan kanske har svarat på denna fråga i föregående fråga) R: Ja, jag kan inte systemera upp den här lösningen om jag inte får den här personen. 17. Hur sköts vanligen kommunikationen mellan er och användarna? (du sa att ni har möten, men bestämmer man i förväg att varje onsdag klockan… har vi möte?) R: När projektet startar så lägger man upp en projektplan som kan vara ett t.ex.ett halvår eller mindre eller mer. Och då har man projektplanen i planeringen, våran projektledare ihop med kundens projektledare satt upp den här projektplanen som då kanske till en början med oftast innehåller generell utbildning och sen specifik utbildning för olika delar och efter det så gör man en sådan där produktgenomgång som jag nämnde, där man designar systemet och då är det bestämda dagar med bestämda personer från oss då och kunden där man sitter hela dagar och kanske några dagar i sträck, där man tar varje område för sig och går igenom det och specar ner det och designar upp det och efter den perioden så kan det i vissa fall presenteras ett lösningsförslag där man presenterar alla specar och systemeringar, så att det är rätt uppfattat med kunden. Och det är också planerade dagar då man sitter i p rojektmöten med projektledare, processägare och eventuellt slutanvändare, för att konfirmera att man har förstått rätt och man presenterar en total lösning. I: Så vid projektstart bestämmer man i princip alla mötesdagar? R: Ja, dom man vet ja, sen under tiden så sköter man det mesta via telefon eller om man har nära till kunden så kan det förekomma besök också. 18. Tycker du att kommunikationen brukar fungera bra, mellan er och kunderna? R: Ja, det tycker jag. Det som kan vara problem är att kunderna inte är så IT-kunniga kanske. Kanske kan vara dåliga beställare ibland, man säger något men menar något annat. I: Det är det vi kommer in på nästa fråga.


19. Är det vanligt att det förekommer terminologiska problem mellan er och användarna? (Man pratar ”olika språk”, utvecklaren och användaren) R: Ja utvecklaren och användaren pratar ofta helt olika språk, mer än ofta. Därför är jag ett filter som förstår både programmerarens språk och slutanvändaren, det är därför man försöker gå via mig då. Jag är en internbeställare till programmeraren, jag är också kundens kontaktperson som förstår mer kundens och slutanvändarens behov, samtidigt förstår jag programmeraren hur han reagerar efter ett behov eller ett krav från en kund. I: Men mellan dig och kunden, ni pratar samma språk tycker du? R: Jag tycker det. I: Tycker kunden det? R: Kunden tycker nog oftast det ja, det vill jag påstå. I: Kommunikationen fungerar bra, på grund av att användaren har dig som filter. R: Ja, jag känner direkt när kunden inte förstår. I: Det är alltså mycket svårare för en användare att prata direkt med en programmerare? R: Ja, det är det, då blir det ofta fel. Ifall kunden är en dålig beställare och inte är så insatt i... ja, vad ska man säga, systemering eller IT. 20. Anser Du att användarnas inställning till att bli delaktiga i projektet påverkar deras attityd till utvecklingsarbetet? R: … Ja det är ju alltid positivt att vara med från början och känna att folk lyssnar på en, då vill man nog hjälpa till och se till så all funktionalitet blir bra. I: Vi menar nog snarare om en användare tvingas att vara med i projektet, eller om användaren verkligen känner att han vill vara med för att han tycker att det är intressant. Att han kan bli för passiva eller vill för mycket. R: Oftast så har nog projektledaren hos kunden sett ut… när man sätter ihop projektgruppen så sätter dom ihop projektgruppen oftast så att det är kreativa människor som har bra koll på verksamheten i bolaget och kan se den röda tråden överallt och gärna vill förändra….

(Respondenten önskar att återkomma till frågan senare) 21. Hur villiga är användarna till att medverka i utvecklingsarbetet? R: Dom vill ju helst… om man ser till slutanvändaren då så får man ju… så är det nog ganska stor förväntan på att det mesta finns i standard. Att det inte ska behövas utveckling, och har man gått igenom en sak med slutanvändaren sen, att så här är det och så här vill jag att det fungerar säger dom och sen så skriver man upp det, specar det och om man så kommer man tillbaka flera gånger efteråt och så fungerar det inte, och så kommer man tillbaka igen så kan slutanvändaren blir lite trött på det. I: En gång men inte mer… R: Jaa, något åt det hållet. En slutanvändare har nog lättare för att… mindre tålamod än en om vi säger så en processägare som är en mer van beställare kanske.


22. Är det vanligt förekommande att användarna har en dålig attityd? (gentemot utvecklingen eller någon process, eller del, du var ju inne på att de blev lite sneda... generellt sett) R: Generellt sett så är det ofta så, frågor och funderingar man har som slutanvändare, varför fungerar inte detta, detta fungerade i förra systemet, vi har ju köpt nytt system nu och allt ska bli bättre osv. Man häktar ofta upp sig på sånt som inte fungerar. I: Jämför nu med då. Det är inte rädslan för att bli nytt da? Den här konservativa användaren? R: Det är det också, ju äldre slutanvändaren är, inte generellt men ofta om man har dålig IT vana så upplevs det som ett hot och man tycker gärna att det gamla systemet var bättre och hittar gärna fel och brister… Men dålig attityd, ja… I: När man tänker dålig attityd till ett nytt system så kanske man automatiskt pratar gott om det gamla systemet, och vill ha det så likt som det gamla… Ja att det gamla var så bra, det måste vi ha kvar. R: Det är nog mer vanligt bland äldre användare som inte är så IT vana som har lärt sig en rutin och känner sig trygga med den. 23. Hur påverkar graden av komplexitet på systemet behovet av användarmedverkan? R: .. Ja det kan ju … öka i vissa fall, om systemet blir mer komplext och man måste systemera upp en anpassning som blir så specifik som möjligt, då måste man se till det verkliga behovet kanske som användaren verkligen behöver få ut. Genom at systemet kan vara så komplext och stort, och ha så många möjligheter att man orkar inte göra en stor anpassning för att klara alla de där varianterna utan man måste dyka ner mer på detalj och då måste man verkligen ha ut från användaren vad är det du vill ha ut. Så ja, i vissa så fall kan det påverka till mer medverkan. 24. Vad är din generella bild av användarmedverkan. Vad tycker du om det? R: Det är både bra och dåligt, är användaren väl IT van och har förståelse för system, hur de är uppbyggda och tänker. Har då användaren en röd tråd i verksamheten, att man inte bara ser till sitt eget arbete, sina egna rutiner utan två tre steg bort, man ser hela flödet för ett bolag. Så är det mycket positivt om det sitter en användare med detaljkunskap också och vet vad han vill, då är det mycket positivt.. i det fallet. I: Det är inte så att du känner att.. i nästa projekt så ska du inte ha en enda användare med, eller i nästa projekt måste vi ha tjugo till för att det här var jättebra, du har inte upplevt det? R: Man är mycket glad ifall det finns en användare som har systemförståelse och vet vad den vill och kan se röda tråden, vad som påverkar här borta om ifall vi gör något här. I: Det kanske inte är mängden användare som är det viktiga. R: Det gäller att få tag på rätt användare. I: Frågar om respondenten har något att tillägga på fråga 20. R: Nä, det har jag inte.


INTERVJU 2 2004-04-27 1. Presentera kort företaget du arbetar för. R: Jag jobbar på X på en avdelning som heter IT under enheten support. Vi levererar energi och vatten i Västerås och Mälardalen och säljer el till hela Sverige. Det är fyra nyttigheter; värme, vatten, el – fjärrkyla och fjärrvärme och bredband som är våra produkter och sen utför vi även lite tjänster omkring det här men det är de huvudsakliga produkterna som vi säljer. 2. Vad är dina huvudsakliga arbetsuppgifter? R: Jag arbetar främst med systemutveckling och förvaltning av vissa system. 3. Hur många år har du arbetat som systemutvecklare. R: Totalt har jag arbetat sen 2001, tre år då och två år där jag är nu. 4. Vad anser du att användarmedverkan innebär? R: Eh… när jag hör ordet såhär direkt då är det egentligen alltifrån innan de börjar hela alltihopa. Nåt IT-projekt tillexempel någon förstudie eller någonting när man kommer fram till vad man… något problem helt enkelt, redan där tycker jag att det börjar egentligen. Användarmedverkan… och slutar någonstans med att användarna är delaktiga i förändringen som sker i systemet, drift och förvaltning, så det är ett ganska stort spann för mig. 5. Har du erfarenhet av att arbeta med användarmedverkan? R: Det har jag! Specifikt kan vi ta det webbprojekt som vi startade för två år sedan, där var det ganska styrt både ur den synpunkten att det var användare i forma av externa användare som hade stort inflytande på vad vi skulle göra och även interna kunde, medarbetare, som vi ville involvera så tidigt och så mycket som möjligt, vi är ju 500 anställda så vi ville få en koncerngemensam webbplats. 6. Hur vanligt förekommande är det med användarmedverkan vid systemutveckling? R: Jag tror att det är långt ifrån den grad man vill ha egentligen för att få system som verkligen accepteras och fungerar. Jag tror att det är ganska lätt att man kommer på att man vill ha någonting och man kör på, hyr in ett par konsulter som gör det här enligt någon liten skiss eller modell över vad man tror är rätt men jag tror att inom vissa områden är användarmedverkan säkert högre än andra men inom speciellt mindre företag köper man nog bara programmeringstimmar rakt av och har inte den här djupa användarmedverkan som finns i de företag som satsar lite mer på befintliga metoder som stödjer användarmedverkan. 7. Hur upplever du uppdragsgivarens syn på användarmedverkan? R: Uppdragsgivaren…. uppdragsgivaren vill dels förstås säkerligen ha en hög grad av användarmedverkan men jag tror samtidigt att man kanske inte är beredd att betala det som det kostar att ha med användarna, det ska ju avsättas tid för de här användarna som skall vara med och det tar ju lite längre tid. Sen om man får igen det i slutändan det är ju inte alltid helt säkert men troligtvis får man igen det. 8. Vad är enligt din mening det bästa och sämsta som en användare kan bidra med? I: Vi börjar med det bästa! R: Det bästa.. det bästa är när en användare bidrar med en sån kunskap och kompetens som inte finns hos den som skall utveckla systemet. Det kan vara en massa manuella rutiner som man gjort i tjugo år och det finns inte dokumenterat någonstans utan det finns bara i huvudet. Sådana saker tror jag att det är det absolut bästa som de kan bidra med. Just sådana saker som inte finns nedskrivet


och inte är dokumenterat, sådana saker dom görs hela tiden och gör att företaget går framåt men inte finns på papper. Där kan man hitta den största nyttan. I: Och det sämsta? R: Det sämsta med användarmedverkan… det kan bli, om man inte har någon modell för hur man skall ha användarmedverkan tror jag att det kan bli väldigt ostrukturerat om man har användarmedverkan lite utspritt och det är med lite här och där i processen så att det blir utspritt jag kan tänka mig att då tar det väldigt mycket tid. Det är väl just den biten att man kan komma in på alldeles för detaljerade saker som man diskuterar, man kanske tycker att det här ser ju inte klokt ur för det är ju en ljusgrön bakgrundsfärg, jag tror att det är lätt att glida in på fel spår om man inte håller hårt i vad man vill ha ut. Man måste tänka ut nyttan med användarmedverkan innan man involverar användarna. 9. Vem är det som bestämmer om man skall ha användarmedverkan med i utvecklingsprocessen? R: Den som jag tycker ska? I: Vem är gör det vanligtvis? R: Det är troligtvis någon funktion som tex projektledare och även beställaren kan ha ett intresse men jag tror inte att de riktigt har förstått nyttan med det än. Men jag tror nog att det är väl från den som tillhanda håller hur man skall komma fram till vad man skall ha och hur det skall utvecklas, dvs projektledaren i det flesta fall, tycker jag är den som i alla fall bör bestämma. 10. Vilka faser har ni med i det utvecklingsarbetet som ni brukar bedriva? R: Vi har… vi kan ta tex från webben då börjar det med att någon som inte alls behöver ha någon teknisk kompetens gör en funktionell kravspecifikation om det handlar om en ny funktion som behöver göras, vi kan ta det som exempel. Så skriver man ner ungefär vad den skall göra och vad som skall hända, inte alls hur den skall göra eller var den skall få saker ifrån. Sen så sätter man sig med en prototypkunnig människa som fixar ihop det så att det ser ut ungefär som man har tänkt sig så dom två samarbetar då. Sen så går det till någon slags instans som bestämmer om designen är ok eller inte, det här kan vara samma person men oftast är det olika. Sen så brukar vi när vi genomför de här större förändringarna på webben ha en integratör med som blir kommunikationskanalen mellan de här specarna som vi har här och det färdiga gränssnittet till programmering. För den här kommunikationen direkt mellan programmerare och användare brukar inte fungera nå sådär väldigt bra. Det är väl dom stegen som finns och sen är det beroende på vad man skall göra mer eller mindre förekommande. Men det är den metoden som vi använder. 11. Vilken typ av inblandning är vanligast vid användarmedverkan? Förtydligar med de fem nämnda i uppsatsen. R: Det beror ju lite grann på vilket skede man är i. Men generellt tror jag det vanligaste är, även fast man kanske inte ser det som användarmedverkan, när man, ja vad ska man tro, referensgrupper är väldigt vanlig även fast man kanske inte tänker sig det som användarmedverkan men det tror jag är väldigt vanligt. Det är ju oftast någon slags kompetens som man behöver av personer som inte är med i själva projektet. Några referenser eller stödgrupper… 12. Vem är det som bestämmer vilken typ av inblandning som användarna skall ha i projektet? R: Det är… det beror nog.. ska se… ja det kan nog vara olika, nu är jag lite låst med hur vi arbetar här, men jag tro att om man har väl definierat de olika stegen i utvecklingsprocessen så tror jag att ansvaret kan ligga på de olika områdena. Men annars tror jag generellt att det är upp till den som är beställare och även den som har ansvar för leveransen. Men det är nog någonstans där. I: Systemutvecklaren?


R: Ja förstås om man stöter på saker som man inte vet hur det fungerar och man tycker att de specar eller användningsfall som man har är otydliga då är det ju såklart systemutvecklaren som tar initiativet till detta. 13. I vilkatav de utvecklingsfaser som ni använder och på vilket sätt anser du att användarmedverkan kan vara överflödig/negativ? R: Den kan vara överflödig i de initiala skedena där man verkligen utvecklar, kodar, själva lösningen. Där tror jag att det är bättre att man har gjort ett bra jobb innan så att man skall slippa ha möten och sånt under tiden för där vill man ha en riktig avstamp, skjuts, så att man vet vad man skall göra. Så där är det risk att man får in mer användarmedverkan än man verkligen vill. Man kan ju komma på att just jag det här ska vi ha och då får man samla ihop alla så jag tror att om det brister i planeringen tidigare så kan man kanske få oönskad användarmedverkan här. Det finns ju säkert i fler steg, men det är det som kommer såhär spontant. 14. Vilken grad av inflytande brukar användarna ha under utvecklingsarbetet? R: Jag tror att generellt så brukar inflytandet på arbetet vara ganska lågt. Eller ja är det frågan om prototyper och sådant där är den ju såklart hög. Men är det i sådana delar där man redan har bestämts vad som skall göras och man bara är ute efter att få information o m hur man skall göra och hur det skall fungera då är ju själva inverkan ganska liten men jag tror att det är större ju tidigare i systemutvecklingsprocessen det är, generellt, för sen ju mer man har utvecklat desto svårare är det att få tillstånd förändringar av alla slag och där är det ganska lätt att man tar bort sådana saker som användare tycker är viktiga men som man själv tycker krånglar till det hela och tar 40 timmar extra att utveckla, då är det lätt att spara ner på den tiden. 15. Hur mycket har du som systemutvecklare möjlighet att påverka användarens inflytande? R: Är det större projekt så tror jag att man har mindre möjlighet än i mindre projekt, det beror på hur många som är inblandade. Men jag tror att om man vill så finns det nog en skaplig möjlighet. Men det beror på lite vad man har valt för sätt att påverka detta på. Om man är systemutvecklare i hela kedjan, dvs. samma person hela tiden, då tror jag att man har större möjligheter att påverka detta än om man har en mindre, avstyckad bit med väldigt definierade överlämnigspunkter i projektet då har man nog större möjligheter ju tidigare i projektet man deltar. 16. På vilket sätt har du som systemutvecklare R: Ju tidigare i systemutvecklingskedjan man befinner sig kan det vara lättare att påverka hela lösningen än i slutet. Men det där är lite svårt att definiera…. Det är…. Har man mycket kunskap om verksamheten själv då vet man ju vilken man skall fråga och då har man ju större möjlighet att skikta rätt när man försöker utnyttja användarna så mycket som möjligt, och det vill man ju såklart för där finns ju väldigt mycket information som man som systemutvecklare inte alls har någon aning om. Men sen ju längre mot realiserings stadiet man kommer desto mer tekniskt blir det, så klart och desto svårare är det ju att få hjälp med det man egentligen vill ha hjälp med. Vi löser det genom att ha ett steg där emellan som översätter och bollar fram och tillbaka och det fungerar väldigt bra tycker jag. Annars brukar det lätt bli att utvecklarna talar om något tabellfält som krävs och användarna vill bara att det skall stå på raderna. Så det är nog en samling av en väldig massa faktorer där. Dels vilken tidpunkt i utvecklingskedjan, dels hur mycket man känner till om företaget och projektet och det man skall göra och sen hur mycket tid man har förstås, budgeten styr ju, förstås, alltihopa. Där kan det vara att man måste bli klar på ett visst antal timmar och då gör man ju det. I värsta fall som man tror är rätt. 17. Hur sköts vanligen kommunikationen mellan er och användarna? R: den sköts ganska direkt. Vi har ju när, som erfarenhet kan jag ju ta vi kör de här lite större utvecklingsprojekten när det är nya funktioner och sånt som ska till så har vi ju oftast konsulter bland annat för att få lite schwung i det hela och då har vi ju en så kallad integratör som kommunicerar med, eller som har ett.. integratören och prototyp den rollen som har de största kommunikationen med användarna förutom projektledaren. Kommunikationen behöver inte vara formell utan det primära är att man skall förstå vad man håller på med och användarna, man kan


inte kräva av dom att dom skall kunna någonting alls utan man vill bara dra nytta av deras kunskap. Så den skall inte behöva vara formell, i realläget är det oftast så. När jag utvecklar lösningar internt och det är bara jag som är inblandad då blir det mycket direkt kommunikation utan något extra steg mellan. Man vill ju trots allt ha så rak kommunikation som möjligt, det blir ju färre missförstånd ju mindre steg det är. 18. Anser du att kommunikationen brukar fungera bra? R: Jag tycker att det brukar fungera bra. Om vi faller tillbaka på samma exempel som tidigare, webbprojektet, där hade vu en ganska väl definierad arbetsmodell som har levt vidare nu under förvaltningsfasen och i utvecklingsfasen. Jag tror att vi var ganska medvetna från början att det krävdes, att det egentligen är våra medarbetare som kan allting. Tekniken den går ju alltid att fixa men det är där kunskapen finns och det trycktes ganska hårt på det redan innan projektet började. Det är liksom ingen idé att ställa en massa konstiga frågor man vet vad man kan får svara på och vem som kan besvara det, vi är ju bara 500 anställda här så efter ett tag vet man vilka man skall fråga om vad. 19. Är det vanligt att det förekommer terminologiska problem R: Det gör det ganska ofta egentligen och det beror ju egentligen på att man inte förstår varandra. Men det kan vara så att man som systemutvecklare försöker beskriva någonting som är väldigt avancerat på ett enklare sätt och då får man inte med sig all information man får inte med sig den komplexitet som det kanske krävs för att man skall förstå det hela. Även fast man förstår vad som sägs kan man missa väldigt stora bitar för att man inte, för att inte systemutvecklaren på ett vettigt sätt kan beskriva vad det är man försöker säga. Det blir bara en massa tekniska termer och förhållanden som vanliga användare inte är intresserade av att kunna och inte skall behöva kunna egentligen. Men det kan vara svårt att beskriva det där på ett vettigt sätt och då är det en fördel om man kan ta till grafiska bilder eller modeller, processmodeller som gör att man kan förklara det på sätt som gör att man inte behöver blanda in alltför många ord för då kan det hända att man trasslar in sig. 20. Anser du att användarnas inställning till att bli delaktiga i projektet påverkar attityden i utvecklingsarbetet? R: Det gör det ju helt klart! Om man skall försöka tvinga användare att vara med eller om man har användare som inte är engagerade då blir det svårt då kör man fast hela tiden. Det brukar ju vara ett ganska pressat tidsschema som man skall hålla och man vill ju inte ligga på för hårt för man vet ju att det tar en viss tid att göra en spec eller någonting men samtidigt vet man att det där kommer inte att blir gjort. Det är svårt att hitta ett förhållnings sätt. Man jag tror att engagemang och intresse från användaren spelar in. En användare med för stort engagemang är ett större problem egentligen. Där är man ju framme vid det här att man går in på detaljer och man får en påverkan under hela tiden. Vissa detaljer är viktiga att få till men vissa detaljer kanske man inte har tid eller råd med och då finns det inte någon möjlighet att lägga för stor vikt vid sådant. Men då om det är någon som har stort inflytande som har stort intresse i det här då är det svårt att veta vad man skall göra då gäller det att man har någon som bestämmer vad det är som gäller. Men självklart kan det var jobbigt att hantera sådana situationer för man vill bevara det engagemang och intresse som finns då det har man ju nytta av fram tills det övergår till något som snarare tar tid än tillför något. Det är inte så vanligt som jag har upplevt det men det finns! Speciellt när man gör system som kommunicerar med andra system som har funnits länge och någon brinner för. Då är man ju trotsallt främling i det systemen och man är rädd att man trampar folk på tårna. Det gäller att ta det väldigt lugnt. Det kan vara svår att veta hur mycket inflytande som användaren har och speciellt när man inte vet själv hur det här andra systemet fungerar. 21. Hur villiga är användarna att delta i utvecklingsarbetet? R: När det är saker som rör dem mycket så är då tror jag att dom är villiga att delta. När det är något som de kan se någon nytta med då är de villiga annars tror jag att det är svårare. Det är risk för att man inte ser hela ledet utan bara till sin arbetsuppgift och det är ju en fara. Där finns det ju roller som integratören, som vi har, och en nivå upp projektledaren som har det ansvaret att se de helheter som finns…. det är svårt… Det kan ju leda till en suboptimering där man tex. utvecklar


fyra likadana lösningar när det egentligen hade räckt med en om man sett helheten. Det är svårt att lyfta huvudet och se, för det första vet man ju inte vad man skall kolla efter och det är det största problemet. Sen är det ju tid och många faktorer som spelar in där resurser… 22. Är det vanligt förekommande att användarna har en dålig attityd? R: Nja det tycker jag inte. Den dåliga attityden kommer oftast om det är saker som man inte ser någon nytta i eller inte tycker att det är vettigt över huvudtaget. Vad det är för arbetsuppgifter som man skall utföra när man arbetar med systemet, är det något som är väldigt tråkigt då kan jag tänka mig att det kan bidra till en dålig attityd. Och det här med att människor är mot förändringar är ett psykologiskt fenomen som jag tycker är väldigt fascinerande att man inte vill ändra utan man har sitt sätt att arbeta på och tycker att det är bekvämt. Man vill göra som man gör nu och inte som man inte vet vad det innebär. Jag tror att det flesta blir förvirrade för att man inte förstå vad förändringen innebär. Det är inte definierat och sagt vad som skall utföras. Jag tror att det är många orosmoment som man ganska enkelt kan ta bort genom information. 23. Hur påverkar graden av systemets komplexitet behovet av användarmedverkan? R: Är det ett väldigt… det finns ju system som inte har någon användarmedverkan alls eller där det är väldigt få som tex. bara administratören. Då blir det ju förstås ingen användarmedverkan att tala om förutom det som kommer ut ur systemet. Men jag tror att komplexiteten om den är hög så tror jag att det är fler användare som inte tror sig kunna,. Det är ganska lätt att inte göra saker och att säga att saker och ting inte går om det är väldigt komplicerat. Det finns säkert samband. I: Men du menar att om det är högre systemkomplexitet då vill inte användarna vara med? R: Vill och vill det vet jag inte. Men jag kan tänka mig att man blir lite mer reserverad och tror att man inte kan som användare. Och det är ju en egenskap som är väldigt viktig att systemutvecklare och projektledare och liknande roller att inte gå på användare och fråga konstiga saker som oftast blir resultatet när det är komplexa system och många systemsamband och liknande. Men… det är svårt att generalisera att behovet av användarmedverkan automatiskt blir högre vi mer komplexa system. Men det är klart är det många, om man tänker sig komplext ut den synvinkeln att det är många system inblandade, då är det ju väldig värdefullt med användarmedverkan och då kanske det kan vara klokt att portionera upp det här så att användaren inte tror att den ska vara med i alltihopa för det kan bli oöverskådligt. Man kanske ska försöka dela upp det i någon slags logiska delar. Det är det jag har upplevt det att det kan hämma användarna om det blir alldeles för komplicerat om man tror att det blir för stort och komplicerat. Då kan det vara smart att dela upp det i lite mindre delar och ta med användare som verkligen är insatta i de områdena. Oftast kan man ju avgränsa vissa delar så att man inte ser allt som ett enda stort system. Det behöver ju i oför sig inte alltid vara så utan det kan ju även vara sporrande att det är något stort man skall utveckla. Som vårt verksamhetssystem som vi utvecklar där är det många som har mycket idéer och gärna vill bidra förstås för att det påverkar hela koncernen. Men det beror ju förstås på vilken detaljnivå som man vill ha hjälp av användarna. Är det på en väldigt fin nivå då tror jag att det kan vara hämmande för användarna men är det på en mer övergripande nivå på ett större system då tror jag att då är det nog många som vill vara med och säga vad som är bäst för så blir det ganska lätt för användarna när det är på en sån övergripande nivå. 24. Vad är din generella uppfattning om användarmedverkan? R: Den var i alla fall, tills jag började jobba, bara positiv förstås. Men min personliga erfarenhet är att den är bra om det finns ett strukturerat arbetssätt och man har tänkt igenom hur man vill ha det annars tror jag att det kan bli svårt för då får man in det här överallt. Och jag tror kanske inte på att man skall samlas i stora möten och gå igenom allt, det kan bli väldigt svårt rent geografiskt , beroende på vart man är placerad. Det är sådana saker som gör att man helt skjuter bort det här med användarmedverkan för det blir för dyrt och tar för mycket tid men i slutändan blir det klart mycket bättre system om de som skall använda systemet är med och utvecklar dem, det råder det ingen tvekan om! Men det finns många fall innan man är där i slutet innan man har fått systemet har man otur och inte vet hur man vill använda den kunskapen som finns hos användarna och dom önskemål som finns på ett strukturerat sätt och har byggt någon form av arbetsmodell då tror jag att man kan tappa mycket arbetstid och resurser innan man är framme vid slutmålet.


INTERVJU 3 2004-04-27 1. Presentera kort företaget du arbetar för. R: Jag jobbar på X och det vet ju alla vad det är. Ni handlar ju mat på där för kom inte och säg att ni handlar på Y… Jag jobbar som systemutvecklare på det administrativa centret, det krävs ganska mycket administration för att sköta alla dessa butiker. Det jag främst har jobbat med är att ta fram prototyp inom de administrativa systemen inte kassasystem. 2. Vad är dina huvudsakliga arbetsuppgifter? R: Se ovan. 3. Hur många år har du arbetat som systemutvecklare. R: Fyra år 4. Vad anser du att användarmedverkan innebär? R: Vad det innebär vad menar ni? I: Alltså vid systemutveckling. R: Jag vill gärna ha med användarna annars vet jag inte vad jag skall gör för system, jag anser att det blir bättre system om användaren är med från början så att man kan fånga upp behoven redan där annars så gör man någonting och så visar de sig att det här var ju inte alls det användaren ville ha. Man kanske bygger en jätte jätte jätte bra funktion fast det var ju inte alls det som var det viktiga. Det viktiga var att det här fungerade och då har man lagt jätte mycket tid på någonting annat. 5. Har du erfarenhet av att arbeta med användarmedverkan? R: Ja! 6. Hur vanligt förekommande är det med användarmedverkan vid systemutveckling? R: Jag har nog aldrig gjort något system som inte användarna har varit delaktiga i om det inte handlar om ett system där det bara skall kommunicera med ett annat system, där det kanske finns något gränssnitt mellan två system. 7. Hur upplever du uppdragsgivarens syn på användarmedverkan? R: Med uppdragsgivare menar ni? I: Beställaren/kunden R: Kunden vill alltid vara med och bestämma. Där kan jag tycka att kunderna vill bestämma lite väl mycket. Jag vill ha med användarna för dels gränssnittet och dels funktionerna, sen hur vi löser funktionerna tekniskt, där behöver de ju inte lägga sig i. Fast det kan ju hända att de gör… 8. Vad är enligt din mening det bästa och sämsta som en användare kan bidra med? I: Vi börjar med det bästa! R: Svåra frågor… Det bästa! Bäst att de på ett tydligt och bra sätt specificerar vad det är de vill ha att de är med redan vid kravställandet så att de inte kommer in sen när man redan har bestämt hur systemet skall se ut. Utan att man redan då, så egentligen vill man ha en användare som, oftast byter man ju ut system, då vill man att de skall ha varit med i det gamla systemet och har använt det men även som är så pass förändringsbenägen så att de klarar av nya system. För oftast är det så att ”såhär gjorde vi i det gamla systemet” sådana vill man inte ha. Man vill han någon som är lite framåt och tänker hur vi vill ha i framtiden. I: Och det sämsta?


R: Det sämsta är när de lägger sig i. Jag har haft användare som lägger sig i vad jag ställer för frågor till databasen och det skall de inte bry sig om bara de får upp den information de behöver. De kan ifrågasätt mig i arbetet, det är det sämsta. 9: Vem är det som bestämmer om man skall ha användarmedverkan med i projektet? R: Där jag jobbar nu så är det jag som bestämmer det, när jag jobbade som IT-konsult så var det kunden som bestämde. Det är alltid kunden som bestämmer och då får man ju oftast användare med. 10. Vilka faser har ni med i det utvecklingsarbetet som ni brukar bedriva? R: Där jag arbetar idag så gör jag alla faser själv. Jag börjar med att fånga upp behov hos användaren, specar ner det på papper så att man vet att man pratar om samma sak. Därefter kontrollerar jag mot användarna att det är det här dom vill ha. Sen så börjar ju själva utvecklingsfasen, testfas och sen oftast, sen går det ju tillbaka att man utvecklar lite mer för man har ju oftast inte alla rätt, och sen utbildar och sen är det drift. Och där efter förvaltning av ett system för ett system är ju inte klart bara för att man levererar det utan det lever vidare och man gör ändringar och småfel och nya önskemål som kommer upp. 11. Vilken typ av inblandning är vanligast vid användarmedverkan? R: Dels i början när man specar upp systemet och dels i test och självklart i utbildningen för det är ju användarna man utbildar. Men test och krav och spec. I: Förtydligar med de fem nämnda i uppsatsen. R: Som referensgrupp absolut. Både seminare/möten, referens- och testgrupper. Ibland bara ringer jag och frågar om det var det här dom menar. Nu för tiden när jag gör små system så är det oftast att man bara ringer och inte har stora möten men det händer ju. Jag använder nog alla typer. Oftast vill jag ha med i stort sätt samma personer hela tiden för att jag hinner inte upprätta nya relationer. 12. Vem är det som bestämmer vilken typ av inblandning som användarna skall ha i projektet? R: Det är jag, det är bara jag som gör det här på mitt arbete för tillfället. 13. I vilka av de utvecklingsfaser som ni använder och på vilket sätt anser du att användarmedverkan kan vara överflödig/negativ? R: Vid utvecklingen, än mer som referensgrupp. Så tycker jag inte att det fyller som stor funktion om det inte är som referensgrupp så att man kan checka av att det var det här de ville ha. 14. Vilken grad av inflytande brukar användarna ha under utvecklingsarbetet? Är deras ord lag? R: Näe inte alltid, i vissa delar är givetvis deras ord lag. Särskilt när det är system som jag inte, när det är ekonomiska system som jag kanske inte förstår riktigt varför man gör såhär och de säger att såhär gör man då har ju jag inte så mycket att komma med och säga att nej kan vi inte göra såhär. Så om det är funktioner som är viktiga, att antingen är det lagligt viktiga att det tex är att man måste spara fakturor i tio år tillbaka för att så är det enligt lagen eller såhär måste vi göra för att det här kräver ledningen att vi tar fram rapporter på. Och sen också, såhär blir det enklast för oss om vi gör, då är det lag, om det inte är tekniskt omöjligt för oss att genomföra det. Men den kan det ju vara andra saker att de säger att de hellre vill ha en röd bakgrund än en grön bakgrund och då ändrar jag inte det. 15. Hur mycket har du som systemutvecklare möjlighet att påverka användarens inflytande? R: Ja jag vill ju gärna ha med dem. Det var en svår fråga… det är ju oftast jag som kallar till möten om vi skall träffas. Det finns ju olika typer av användare, vissa tycker ju att det är väldigt spännande med IT och nya system och är på och ringer och frågar hur skall vi göra med det här.


Sen finns det sådana som är väldigt, väldigt rädda och gärna inte ens vågar gå på möten för att jag skall fråga något tekniskt och tänker ”jag kan inte, jag kan inte jag vill inte vara med”. Så det beror nog en hel del på användaren. Vad var frågan? I: Hur mycket får användarna bestämma? R: I slutändan så är det ju jag som säger att nej det här får ni inte och det här får ni. 16. På vilket sätt har du haft möjlighet att påverka användarens grad av inflytande? R: Återigen att kalla till möten eller ringa upp dem eller svara på mailen. 17. Hur sköts vanligen kommunikationen mellan er och användarna? R: De ultimata är ju att träffas men det har man ju inte alltid tid och råd med. Då blir det mycket mail och telefonsamtal. Mail kan fungera bra för då kan man skicka med bilder och det är ju lättare att visa med bilder än att förklara. Om jag förklarar ett grafiskt gränssnitt så kommer de aldrig att förstå men om jag ritar det så förstår de direkt. Så därför är det alltid ultimat att träffas. Användare tycker ju om att träffas, man kan prata om systemet i timmar och ingen kommer att ha förstått någonting men visar man några bilder så säger de så säger de å jätte bra eller jätte dåligt. 18. Anser du att kommunikationen brukar fungera bra? R: Ja det tycker jag. 19. Är det vanligt att det förekommer terminologiska problem R: Ja! Man försöker lägga sig på en låg nivå och ändå så ligger man mycket mycket högre än hur genomsnittsanvändaren oftast pratar för språk, tyvärr. Det är jätte svårt, det är nog det största problemet att man pratar olika språk, det är därför jag vill ha ner det på papper ocj bilder för att fråga har ni förstått? 20. Anser du att användarnas inställning till att bli delaktiga i projektet påverkar attityden i utvecklingsarbetet? R: Är dom delaktiga är det klart att dom tycker att det är bättre än att dom inte är med. Är det inte med så tycker dom bara att nya system är något som försvårar vårat arbete. Är dom med så är det ju mycket lättare att få förståelse men sen måste man också tänka på att de skall ha tid att vara med oftast så har man ju sina dagliga vanliga uppgifter i arbetet också och de måste hinna göra det och sen kommer det en projektledning som oftast är ganska driven och på i jämförelse med linjechefen och tar deras tid och då kan det ju uppfattas som negativt. I: Men om du har en användare som inte vill vara med från början hur brukar de förhålla sig till utvecklingsarbetet då? R: Vill dom inte vara med så är de oftast väldigt kritiska, nu generaliserar jag jättemycket men.. då är de kritiska och säger det var bättre förr. 21. Hur villiga är användarna att delta i utvecklingsarbetet? R: I mitt fall är de väldigt villiga för det jag gör hjälper dem i deras arbete. Istället för att det skall hålla på med en sak i två timmar så kanske det bara tar tio minuter efteråt och då är det jättevilliga att hjälpa till. Sen kan det finnas fall där de inte är villiga att hjälpa till när det kommer uppifrån, det beror ju i oför sig på ledningen, när det där uppifrån säger att nu skall vi byta affärssystem och ingen vet varför. Då blir det mycket svårare, det viktiga är att användarna vet varför vi byter system eller varför vi gör det här systemet och varför just han/hon är med. 22. Är det vanligt förekommande att användarna har en dålig attityd? R: Jag har inte upplevt det så, men jag kanske har haft tur för det finns! Alla pratar om besvärliga användare och det är klart det är dom som ställer kraven och dom som gör att det kan bli svår att


utveckla. Man vill ju alltid göra det på bästa sätt men det är oftast väldigt ont om tid. Men det är klart att jag har varit med om användare som aldrig blir nöjda. Det var främst när jag jobbade som konsult och det kunde lika gärna bero på att de tycket att de hade betalat för mycket för systemet så att det är lite svårt att säga om det är användaren i sig eller om de tycket att det inte är tillräckligt bra eller att man inte har haft en tillräckligt bra kommunikation. 23. Hur påverkar graden av systemets komplexitet behovet av användarmedverkan? R: Det beror på hur man menar med komplexitet, teknisk komplexitet? I: Ja systemets tekniska komplexitet! R: Om det är utåt för användaren fortfarande bara är en knapp att trycka på i stort sätt, och systemet är väldigt komplext, då behöver ju inte användarna vara med. Men det kan vara ett komplext system där det är väldigt mycket funktioner eller filer mycket filer som skall skickas i en viss ordnig, i sådana fall är användare ovärderlig som kan säga att du måste göra de här innan du gör det här. Så det beror på tekniskt komplext eller funktionellt komplext. 24. Vad är din generella uppfattning om användarmedverkan? R: Generellt så tycker jag att det är bra för annars vet jag inte vad man skulle göra för system. Det är ju för användaren man gör systemen, oftast. Det handlar ju om personkemi också, när man sitter och diskuterar måste det ju vara någon man kan kommunicera med och som kan kommunicera tillbaka. Att man har samma språk.


INTERVJU 4 - 2004-04-28 1 . Presentera kort företaget du arbetar för R. Ja jag jobbar ju för X, och vi är ju internkonsulter inom X-koncernen och vi jobbar ju bara internt inom koncernen så att vi utvecklar ju inget för externa bolag gör vi ju inte och vi har ju olika avdelningar här som jobbar med olika saker jag jobbar ju på Webben, sen finns ju de som sitter i en annan korridor som jobbar med ProFlow-system som använd i produktionen i Avesta. Benny och dom som du känner, jobbar ju med Integrationsprojektet. Sen finns det annat system som heter BAM(?) som folk sitter och jobbar med så att det är ju…vi jobbar ju med olika saker här. Jag själv sitter ju med Webben. 2. Vad är dina huvudsakliga arbetsuppgifter? R. Ja det är ju att utveckla webbapplikationer idag, är det. Då vi pratar webbapplikationer så är det inte vanliga webbsidor utan det är ju med applikationer då, som man gör webbaserade istället för, för gjorde man mycket VB-applikationer nu gör vi mycket på webben istället. Det är enkelt att nu flera programanvändare i flera länder, det enklaste sättet att få dem att använda dem. 3. Hur många år har du arbetat som systemutvecklare. R. Ja jag började ju november 99, innan det så studerade jag på högskolan. 4. Vad anser du att användarmedverkan är? R. Ja för mig så ser jag det som att, då låter man ju användaren vara med och ta fram systemet. Så att inte bara systemutvecklarna själva som bygger system efter vad dom tror det behövs för funktionalitet och hur det ska vara utformat. Många gånger så behöver ju användarna vara med där för att man ska få en applikation att fungera enligt deras önskemål. 5. Har du erfarenhet av att arbeta med användarmedverkan? R. Ja jag skulle säga att det är lite begränsat, oftast får vi ju en ”remmit”, en specifikation på hur vi ska bygga sajten och många gånger har vi ganska fri tyglar att börja med designen och det, men sen många gånger har vi ju även en styrgrupp med som tittar på det och där användare är med så de kan lägga förslag och synpunkter på hur de vill utforma det hela. 6. Hur vanligt förekommande är det med användarmedverkan vid systemutveckling? R. Ja jag kan ju bara svara för hur det är för oss då som arbetar inom webben, hur de andra enheterna det vet jag inte för jag jobbar inte med dem så mycket utan jag skulle vilja säga att det är ganska begränsat där ändå, det tycker jag. Vi utvecklar applikationer efter mycket av eget tycke. I. Ni får en kravspec, sen gör ni efter den? R. Ja precis ja, vi får ju en kravspec sen tittar vi ju på liksom hur vi vill utforma den där då, sen skulle jag vilja tillägga att vi har ju mycket grafiska mallar hur ändå en applikation ska se ut. I. Återanvänder ni samma? R. Ja precis, man sitter ju inte och uppfinner hjulet två gånger utan vi kör ju med den designen/template vi har så bygger vi vidare på det. Sen får man ju anpassa den efter applikationen då hur den ser ut. Den senaste applikationen jag har jobbat med de senaste 2 åren där tog vi ju designen från en template som vi har från en annan större applikation sen har vi ju modifierat efter som vi har tyckt i den här applikationen. 7. Hur upplever du uppdragsgivarens syn på användarmedverkan? R. Ja det är jag lite osäker på. Det är svårt att veta hur dom ser det men, jag menar, dom har ju, uppdragsgivaren har ju ett antal användare som ska använda den här applikationen. Men jag vet inte, de brukar inte säga till oss på något speciellt att vi ska prata med användare, så oftast kommer


det ju via uppdragsgivaren att de som använder applikationen hör av sig till uppdragsgivaren och säger ”det här skulle vi vilja ändra på” då kommer det ju via den vägen till oss sen så vi får göra ändringar. I. Dom pushar inte på att ni ska ha med användare iallafall? F Nej jag skulle inte vilja påstå det. Inte på webben här i alla fall inte. 9. Vem är det som avgör om man ska ha med användare i utvecklingsprojektet? R. Ja i så fall bör det vara uppdragsgivaren. I. Ni har inget att säga till om där? R. Nä alltså jag tror att… skulle vi ha dom… skulle vi vilja det så tror jag inte det skulle vara något problem. Det gäller ju alltid att välja ut ett par användare isåfall som har tid också att sätta sig in i den applikationen man ska bygga upp. Många gånger så får vi ju problem med att få loss till det där. Men det är ingen omöjlighet jag tror att det ska kunna gå och ordna men som vi har kört idag så har vi utvecklat enligt som mallar vi har sen får vi titta på det. 10. Vilka faser har ni med i utvecklingsarbetet som du arbetar med? R. Ja vad tänker du på för vadå faser? I. I hela utvecklingsprocessen, förstudie design, utveckling, implementation mm. R. Det första är ju att man får en ”remmit”, där kunden specar upp vad den vill ha för någonting och när man har fått den får man gå igenom den ganska noga och se hur vi löser det på ett lämpligt sätt. Får vi analysera för bygger man på webben är det ju mycket med databas också det gäller ju att göra den rätt enligt dom krav som kunden har. Men det är ju ett fortlöpande arbete som vi under projektets gång också, jag menar det man har bestämt sig för, för många gånger blir det ju ändringar med tiden, så att man spikar ju inget från början det sker ju fortlöpande ändringar i samråd med… det brukar vara en styrgrupp eller någonting, det beror på projektets storlek, där man kan diskutera olika saker fortlöpande i projektet. Men annars är det… man har ju en analysfas där man, sen ska du ju… sen är det ju… dom har ju oftast en kravspec men vad dom vill ha för funktionalitet i applikationen som vi ska uppfylla. I. Testar ni något efter? R. Ja det ingår ju ja… om man tar alla stegen så är det ju, vi har ju en utvecklingsfas sen är det ju även testning då. I. Men där har ni användare som testar? R. Ja på webben har vi ju tre olika miljöer, vi har ju en miljö där vi utvecklar och där sitter vi ju bara och utvecklar och testar applikationen sen finns det en miljö, det är innan produktion, då skickar vi upp de filer och databasändringar så får användarna testa där, så får man köra där ett tag tills dom är nöjda och inte upptäcker något fel, nöjde med designen bland annat också… sen när man fått OK där så skickar man över det till produktionen så det går ut live. Men just för den där Stadium-miljön där är ju för att just användare ska kunna testa. I. Det är som en betatestning R. Ja precis, vi tar ju hand om den grövsta testningen när vi utvecklar, vi kan ju inte lämna ut något som är massor av buggar i, men när vi tycker det verkar OK så ska vi alltid låta användarna börja testa… bland annat för att de har en förmåga att lyckas hitta buggar som en annan inte hittar. Det är ju mycket det för att man testar efter det hur man har kodat, man vet ju hur man har gjort det och då testar man enligt de förutsättningarna, men de testar ju i alla möjliga kombinationer. Ja det är ganska intressant, de hittar mycket fel de där.


Men i dag ska vi ju jobba enligt en egenutagen metod som heter PMM, ”Project Management Method”, där beskrivs ju alla de här stegen och den ska vi ju egentligen följa också, det är ju en massa olika steg i den här utvecklingen. Ja man ska ju följa den och i mångt och mycket gör vi ju det också, men man kanske inte följer allt fullt ut. Testfasen kan ju många gånger behöva utöka, men man vill ju ha ut filerna någon gång också det är ju dåligt med tid på slutet också så att då kan det ju bli för lite testning ibland. 11. (Det här har vi varit inne på lite grand, ) men vilket typ av inblandning är vanligast vi användarmedverkan, som t.ex. semi nariegrupper, referensgrupper, testgrupper? R. Ja seminarier känner jag inte till att vi använder någonting med vi har ju en referensgrupp, det är ju inget ovanligt vi har sen har vi ju även, det kan ju vara grupper med användare också. Varje enhet i vårat fall, till exempel Avesta är ju en enhet och i Torneå har vi en, till den applikation vi håller på att utveckla nu så finns det ju testanvändare som de har utsett där som ska testa applikationen så de får ut rätt data och att de är nöjda med det de får ut och de får ju ge sina synpunkter så att allting ser OK ut. Det är väl så det fungerar i det projekt vi arbetar i just nu. 13 . I vilken av utvecklingsfaserna och på vilket sätt anser du användarmedverkan kan vara onödig eller negativ? R. Ja i den första fasen där man analyserar kanske man inte har någon större nytta av dem, där är det ju mera tekniskt hur man ska lösa enligt den kravspec man har. Men det är väl där senare i projektet man vill ha in feedback från dem också hur man utformat applikationen så de är nöjda med hur den ser ut grafiskt och att den är lätt att använda. Kanske aldrig i uppstarten tror jag inte det är nödvändigt iallafall. I. När man tittar på den tekniska biten? R. Nä oftast har inte de någon kunskap om det heller dom är nog inte så intresserade heller hur vi löser det tekniska i applikationen de vill ju gärna se något grafiskt som de kan jobba mot, så de är nöjda med den utformningen. Men användarna som ska använda systemet brukar oftast vara inblandade så de vet vad de får ut ur det som ingår i kravspecen. Eftersom de ska använda det verktyget så vill de ju veta vad de får ut ur det också, de har ju idéer om vad de vill ha. I. De är alltså med och utvecklar kravspecen? R. Ja på något sett borde de vara det eftersom jag är ju själv inte inblandad i den processen så att jag är ju ingen kund men många gånger så antar jag att de är… att de borde vara inblandade i det… för att sen… jag menar, bygger vi ett verktyg exempel en webbapplikation så finns det ju ett behov av det annars skulle vi inte bygga det. Så de som har någon nytta av det är ju själva användarna då, men det är ju inte de som kommer till oss och frågar utan de har antingen någon styrgrupp eller någonting, som dom ger önskemål att de vill ha det här verktyget. Så det är väl integration mellan den styrgruppen och användarna som kommer fram till en kravspec mot oss. Det är så jag utgår från att det fungerar… jag är inte helt säker eftersom jag inte är kund. 14. Vilken grad av inflytande har användaren under utvecklingsarbetet? R. Ja det är ju svårt att säga, men när jag utvecklar så lyssnar ju jag på vad styrgruppen har att säga eller projektledaren i det projektet och men den får ju självklart in synpunkter från användarna och jag menar om någon användare ser att ”den funktionen är helt onödig” eller att det kanske saknas någonting så självklart har de mycket att säga till om det för det är ju ändå de som betalar i slutändan. Och då ska vi ju bygga en applikation som de är nöjda med. I. Det går alltid genom en projektledare eller ett annat led emellan? R. Ja, jag menar, en användare ringer ju inte till mig direkt och säger ”jag vill ändra det där” utan… till exempel det systemet vi har… som jag håller på att bygga nu… jag menar det är ju användare överallt runt omkring i koncernen… om en användare har en synpunkt på en grej så kanske inte de andra har det, det är liksom… det där måste de gå via sin styrgrupp det går ju inte att varje enskild


användare hör av sig till en, jag menar då kan ju applikationen bli hur som helst. Det måste ju styras på det sättet. I. så det filtreras av en projektledare eller någon. R. Ja det utgår jag definitivt ifrån, därför att projektledaren… han bestämmer ju inte heller egentligen vad som ska göras utan det kommer ju från styrgruppen som har beställt det eller kunden då. För kunden har ju någon representant som hör av sig till våran projektledare sen och våran projektledare det är ju han som leder hur jobbar i vårat projekt här. Men det är ju inte projektledaren som bestämmer vilken funktionalitet vi ska ha utan det är ju kunden. 15. Hur mycket har du haft möjlighet att påverka användarnas grad av inflytande? R. Ja jag har ju inte gjort någonting åt det egentligen, utan jag har nog inte sett något behov av det heller, utan har de några synpunkter så går det via projektledaren, då får ju jag direktiv om det isåfall om att jag ska göra de ändringarna. Så jag har ju väldigt lite direktkontakt mot kunderna personligen utan jag får ju mer direktiv av projektledaren om vad som ska göras enligt den specifikation vi har. 16. På vilket sätt har Du haft möjlighet att påverka användarens grad av inflytande? Se fråga 15. 17. Det här har du ju nämnt lite grand men hur kommunikationen sköts mellan er och användarna. R. Ja det går ju via… för användarna ringer ju inte till oss, det ska de ju inte göra. Det går ju via… jag egentligen via deras representant och så våran projektledare här. Men jag har ingen normalt sett kontakt med användarna på det sättet. 18. Anser du att det kommunikationssättet fungerar bra? R. Ja jag tror inte jag har några synpunkter på det faktiskt. Jag tror att det är den vägen det bör gå för att, det är som jag sa tidigare, man kan ju inte låta alla användare höra av sig efter vad de vill ha för någonting i applikationen. Du har ju, jag menar, en stor applikation kan ju ha hundratals användare med olika vyer och idéer om hur applikationen ska se ut, det måste ju styras upp av någon person som ser behovet av att man gör det. I. Jag då får vi se om du kan svara på dessa frågor… 20. Anser att du att användarnas inställning till att bli delaktig i projektet påverkar deras attityd till utvecklingsarbetet? Alltså ni har ju inga användare med i den projektdelen du jobbar i vad vi har förstått? R. Nej… normalt sett så är de ju inte det utan… ja jag får ju en spec. som jag ska utveckla med och så följer vi ju de guidelines vi har där. Men användarna är ju ändå med och tittar på den färdiga applikationen sen innan vi lanserar den. I. hur villiga är de att bli delaktiga i den biten då? R. Ja jag hoppas att den är positiv, men många gånger så säger de att det är ont om tid också, när vi gör en ny version och de ska testa så kan det ta en bra lång tid innan de får tid att hinna med det. För att oftast har ju folk fullt upp med vad de sysslar med se natt få ledig tid är inte alltid det enklaste. I. Så de är inte så villiga att deltaga vid testningen tycker du? R. Ja jo det tror jag inte är några problem, utan att det är mera att det kan vara tidsbrist ibland, det ser jag det som. Men jag har svårt att tro att de inte ska vara villiga för det är ju ändå de som ska använda applikationen.


19. Vi hoppar över 22: an, för den är också för om man har direktkontakt. Ja det är ju också om man har direkt kontakt, men förekommer det några terminologiska problem mellan er och användarna? Men ni har ju ingen direktkontakt… R. Nä… normalt sett så har vi ju ingen direkt kontakt. I. Alltså generellt sett, brukar sådana saker vara en bromskloss för projektmedlemmar och användare? R. Oftast när man pratar med användare så pratar du ju inte så mycket tekniska termer, det har ju inte de någon koll på. Där tar man nog bara om vilken funktionalitet de vill ha… jag sitter ju inte och går in på detaljer hur jag ska lösa det för på något sett, utan jag vet ju hur de vill att det ska se ut, vad de vill få ut ur det där, sen får ju jag lösa det på mitt eget sätt sen... det är ju inget som de lägger sig i. 21. Hur villiga är användarna till att medverka i utvecklingsarbetet? Frågan ströks pga. att ingen direktkontakt med användarna fanns. 22. Är det vanligt förekommande att användarna har en dålig attityd? Frågan ströks pga. att ingen direktkontakt med användarna fanns. 23. Hur upplever du att graden av systemets komplexitet påverkar behovet av användarmedverkan? R. Ju komplexare systemet är ska ju… man behöver ju ha med användarna så att de, så att vi får systemet utformat så att det blir ett hjälpmedel för dem, så att det inte blir för krångligt för dem, för det är ju det som är syftet många gånger när man gör en applikation. Det är ju att det ska bli lätt för dem att använda och att de får ut den information de vill ha av systemet och då är det ju ett behov att man har med dem. Annars sitter man ju och utvecklar som man själv tror att de vill ha det, men det är ju inte alltid sanningen, det kan ju vara helt annorlunda om man frågar dem. Så att ta med användaren i utvecklingen är ju ett krav alltså, annars skulle det bli en applikation som du tror att det ska se ut och fungera. 24. Vi avslutar med: Vad är din generella uppfattning om användarmedverkan? R. Ja jag ser det som nödvändigt för ett projekt, sen beror det på hur komplext systemet är, så blir det ju mer nödvändigt. Vissa kanske inte är så noga med det. Det systemet som jag jobbar med nu, där är det ju… där är de ju med hela tiden i alla fall… och testar och har synpunkter om vad de vill ha ut för funktionalitet. Vi har gjort många nya reviser där, hur de vill bemöta oss med mer krav. Många gånger är ju som så att… den första specen man får där de har ett antal idéer om vad de vill få ut. När man väl har gjort det där och börjar se liksom nyttan med verktyget och vad man kan få ut då kommer de ju på mera idéer efter hand vad de kan använda verktyget till och då vill de ju att man bygger mer funktionalitet inom applikationen. Det är väl det som har hänt i det senaste projektet jag jobbar i nu att vi får hela tiden nya… vi får nya idéer att ”Det här skulle vi kunna ta ut ur systemet, det här skulle vilja ha ut”. Då får vi ju nya, man kan säga småspecar med funktionalitet som de vill ha i applikationen och då gör man ju en nya fas i projektet och så kodar vi ju åt dem. Sen när de är nöjda så kör vi ut i produktionen. Så att… ja det är viktigt att man har med det… att ha användarna med när man utvecklar. Annars utvecklar man för sig själv det man tror själv, men även om man har en spec. som styr upp hur man… vad som ska vara med för funktionalitet så kan du ju ändå lösa det på olika sätt och det är ju inte alltid att kunderna är nöjda med det. Många gånger grafiskt så finns det ju mycket idéer om hur det ska se ut som de inte är nöjda med. Så där har vi med dem hela tiden. 8. En fråga som vi missade: Vad är enligt din mening det bästa/sämsta en användare kan bidra med? Börja med det bästa… R. Ja det bästa det är ju att de har ju… de ska kunna bidra med vad de vill ha ut av applikationen och även utformningen så de är nöjda så att det blir enkelt att använda för det är ju deras verktyg, det är ju inte mitt verktyg som jag bygger. Det är väl de grejorna som jag använder mest av när jag kodar…


Det sämsta… ja det är väl de… det kan ju vara det, som jag också gått in på, att många användare har olika idéer och att alla vill ha in sina idéer men man måste ju på något sätt ändå styra upp det på något sätt så att de är överens, kunden, om att funktionaliteten är värd att vi sätter in i applikationen och den här kanske det bara är ett fåtal som har nytta av så att det kanske inte är värt att kosta på sig det. Många har ju väldigt svårt med petitesskrav att de vill just ha ”det här och det där”. Men som sagt var många gånger går det ju via projektledaren och styrgruppen så att det är ju inte så mycket som jag märker av som utvecklar. I. Då är vi klara om inte du har något mer att tillägga? R. Nä jag tror inte det… I. Ok, tack ska du ha.


INTERVJU 5 - 2004-04-28 1 . Presentera kort företaget du arbetar för R: Jaha, X, är ett företag i stålbranschen, det är ett ganska internationellt bolag. Finland, England, Sverige. Sen är det ju, systemavdelningen ligger ju här då och i Finland. Sen finns det ju ute på alla enheter också, lokala IT-kontor. Och vi bygger väl främst, ja vad säger man, koncerngemensamma IT-lösningar. 2. Vad är dina huvudsakliga arbetsuppgifter? R: Ja det är ju att bygga system. Kodare kan man säga. 3. Hur många år har du arbetat som systemutvecklare. R: Ja det är en 20 år ungefär. 4. Vad anser du att användarmedverkan innebär? R: Det är väl att dom… ja från början är de väl de som formulerar ett slags önskemål, vad de vill ha och försöka beskriva det då till oss, och sen ska man väl gemensamt, antar jag, komma fram till något vettigt. Så det är ganska viktigt att de är med rätt så mycket tycker jag. Är de inte det blir det ofta fel och man får göra om för att… fast ofta i början har de väldigt svårt att uttrycka kanske vad de vill ha, de vet inte riktigt. Det är iallafall min erfarenhet. De säger någonting och så bygger man det och så visar men det när det är klart och då var det inte riktigt så va, när man väl får se den färdiga produkten så att säga. Utan då får man bygga om igen. Så det är rätt viktigt att de är med hela vägen, tycker jag. 5. Har du erfarenhet av att arbeta med användarmedverkan? R: Mmm…inte så mycket här, men i mina tidigare jobb. 6. Hur vanligt förekommande är det med användarmedverkan vid systemutveckling? R: Ja tidigare…jag har ju inte riktigt den rollen här, men tidigare har det varit ganska vanligt, det har det varit. 7. Hur upplever du uppdragsgivarens syn på användarmedverkan? R: Ja… ofta har det väl varit så att de… de har nog inte räknat med att tar ganska mycket tid för en användare att vara med. De har ju ofta annat att göra än att… dras huvudsakliga jobb då. Så det kanske går ganska många timmar till det här också. Så ibland har man kanske fått suttit och väntat då, kanske för att den personen man behövt snacka med inte varit tillgänglig, det behöver ju inte vara så planerat kanske, att de ska vara med. Utan det är mest när man har ryckt i dem. 8. En fråga som vi missade: Vad är enligt din mening det bästa/sämsta en användare kan bidra med? Börja med det bästa… R: Ofta är det ju kunskap om verksamheten då som man inte säkert har om utvecklare. Jag jobbade som konsult tidigare och då får man ju hoppa in lite här och där inom områden man aldrig… det kan vara allt från stål till livsmedel eller pensionskassor eller vad som helst va, så de måste bistå med den kunskapen då. Det är väl det viktigare. Plus annat då som layouter och sånt där då. I: Det sämsta då? R: Ja jag vet inte. Det sämsta? Ja de stör kanske rätt mycket… Nä… jag tycker inte det är något dåligt med det, jag kan inte säga något dåligt om det. Det är svårt at säga ”något sämsta”. Jag tycker det är bra om de är med alltså. 9. Vem är det som avgör om man ska ha med användare i utvecklingsprojektet?


R. Jag vet inte… går det att ha utan? kan man ju fråga sig…Det måste ju någonstans initierats iallafall av någon användare. Vad menar ni egentligen med användare? Kund eller den som ska sitta och jobba med systemet. I: Ja slutanvändarna. R: Det gör väl de som drar upp riktlinjerna från början antar jag. Som projekterar det hela så att säga. I: Så det är inte någon av er systemutvecklare som… R: … kräver det? Nä, fast oftast ibland när man sitter och jobbar så känner man ju ”nä nu måste jag få vet någonting här” och då får man ju vända sig till dem. 10. Vilka faser har ni med i utvecklingsarbetet som du arbetar med? R. Nu förstår jag inte riktigt hur du menar? I: Alltså man har Förstudie, Analys… det finns ju olika modeller att arbeta efter R: Ja I: Vilka faser har ni med i det utvecklingsarbetet ni bedriver på den avdelning du arbetar på? R: Det är väl hela vägen antar jag, här finns ju olika slags grupper som jobbar med det här, det finns styrgrupper, referensgrupper och någon beställare…innan det hamnar hos mig, jag får ju ofta en spec då… I: Du sitter på själva utvecklingsdelen? R: Just det ja. Längst ner i kedjan så att säga... I: … och innan det har det gjorts en förstudie då eller? R: Ja det har det naturligtvis gjorts. Med systemering eller vad det nu heter. Först blir det väl en ”Remmit” antar jag och sen en förstudie och ett specifikationsjobb innan det hamnar på utvecklingsbordet så att säga. I: Har ni någon testfas efter? R: Ja det är det ju… ska vara iallafall… i teorin men ibland blir det väl lite si och så med det. Men det är klart det testas… det gör det ju. I: Både av Er och av användare? R: Ja, det gör de här. Här är det rätt så bra faktiskt på det viset. Vi har ju en särskild testmiljö då där vi… när vi tycker vi är klara med utvecklingsjobbet så skickar vi det dit och då kan användarna sitta där i testmiljö och köra innan det godkänns för produktion. 11. Vilket typ av inblandning är vanligast vi användarmedverkan, som t.ex. seminariegrupper, referensgrupper, testgrupper? R: Ja de är nog vanliga på båda dom, det är det ju. Det finns ju användare med i … ja definitivt i test… ja och även i referensgruppen är det. 12. Vem bestämmer vilken typ av inblandning användarna ska ha? R: Ja det misstänker jag att en projektledare gör. Vem som nu sätter ihop dom här olika grupperna det vet inte jag faktiskt. Det måste väl finnas någon över projektledare tror jag.


13. I vilken av utvecklingsfaserna och på vilket sätt anser du användarmedverkan kan vara onödig eller negativ? R. I ingen… I: Inte ens i ditt arbete? Utvecklingen? R: Nä, ibland behöver ju jag också fråga dem. På det viset är de ju medverkande där också. Det är ju inte alltid solklart vad man ska göra. Specar är inte gjorda riktigt och kommer på nya vinklar på saker, så när man väl sätter sig och jobbar va, så då behöver man ju fråga dem. I: Det är inte så att de överöser er under utvecklingsarbetet så att det blir som en bromskloss? R: Jo sådana exempel finns det ju också, det finns ju alltid användare som önskar sig en massa extra. I: Sen kan det ju vara så att de säger olika saker, en vill ha det här och en vill ha det där… R: Visst, på det viset så krånglar det ju till det hela. Ibland försöker man ju vara alla till lags men det går ju inte att vara utan dem alltså. Men det är klart att ibland blir det ju krångligt, det blir det ju. Men att inte ha med dem alls det skulle ju vara ännu värre tycker jag. Nu finns det ju sådana här kedjor man ska gå till… ”ska jag gå till min chef, som i sin tur…” och så ska det vandra den vägen istället för att jag ringer direkt till någon va. Det är meningen som den officiella vägen. Så gör man ju kanske inte så mycket här faktiskt. Det är mera strukturerat här, men på tidigare ställen har det varit mer direktkontakt. 14. Vilken grad av inflytande har användaren under utvecklingsarbetet? Är deras ord lag? R: Nej, det finns ju vissa användare förstås som har mer inflytande än andra på grund av deras kunskap då oftast och kanske för att de är väldigt påstridiga. Det kan ju löna sig det också… vi är ju bara människor. 15. Hur mycket har du haft möjlighet att påverka användarnas grad av inflytande? R: Jag bestämmer ju liksom när jag själv vill fråga någon, på det viset kan jag ju… och jag kan ju heller inte riktigt skita i om någon tar kontakt med mig och har något önskemål, det kan jag ju inte göra. Även om jag inte kan bestämma själv om jag ska gör det de vill… det måste kanske jag förankra någonstans. 16: På vilket sätt har du möjlighet att påverka ditt inflytande? I: Du väljer alltså att ta kontakt med dem eller inte? R: Javisst. I: Behöver du information så tar du alltså kontakt med dem R: Ja det gör jag ju. 17. Det här har du ju nämnt lite grand men hur kommunikationen sköts mellan er och användarna. R: Det är nog ganska informellt tror jag. Man pratar när man behöver. I: Man ringer upp eller mailar? R: Ja, det är ju ofta det. I: Man träffas inte oftast? Eller vad är vanligast?


R: Nä, de här grupperna träffas ju då och då, stämmer av läger så där… det är sällan jag är med i dom grupperna. I: Du får inte vara med eller vill inte? R: Jag behöver inte tycker jag. Jag skiter egentligen i vad de vill ha gjort på ett sätt. Men jag får ju information vad som har avhandlats, vad som ska göras eller inte göras. Jag har ju kontinuerlig information om de här mötena, för det som är nödvändigt för mig i mitt jobb. 18. Anser du att det kommunikationssättet fungerar bra? R. Sådär… får jag väl säga. Både och. 19. Är det vanligt att det förekommer terminologiska problem? R: Jag det kan det ju vara men det tycker jag inte förekommer i någon större utsträckning, det tycker jag väl inte. Man vet ju ungefär… ja man vet att de är användare och det går ju inte att gå in på några tekniska detaljer med dem kanske, det gör det inte. Så att… fast ibland kan det ju vara svårt åt andra hållet också att man vet ju inte riktigt vad allting är vad de pratar om med sina stålsorter och grejor. Så det är nog åt båda hållen isåfall. Men då får man fråga. I: Men det verkar inte vara något problem? R: Nä… 20. Anser att du att användarnas inställning till att bli delaktig i projektet påverkar deras attityd till utvecklingsarbetet? R. Kan du läsa om den där? I: Anser att du att användarnas inställning till att bli delaktig i projektet påverkar deras attityd till utvecklingsarbetet? R: Du menar att om de gärna vill vara med? I: Ja, påverkar det hur de deltar sen i arbetet? R: Ja visst, det är nog olika från person till person tror jag. En del är väldigt sugna och tycker det är väldigt roligt. De är ju väldigt positiva oftast. Men sen finns det ju de som aldrig vill… de tycker det är bra som det har varit tidigare och tycker det är jobbigt att vara med på sådant här. Så det där är nog väldigt individuellt. 21 Hur villiga är användarna till att medverka i utvecklingsarbetet? R: Oftast positiva tycker jag, sen finns det ju alltid undantag som sagt. Men i normalfall är de ju det, det får jag ju säga. 22. Är det vanligt förekommande att användarna har en dålig attityd till utvecklingsarbetat? Även fast det är positivt att de deltar. R: Ja det finns ju alltid de som klagar på allt, det gör det ju, men nä jag tycker normalt sett att de är positiva, det är de. 23. Hur upplever du att graden av systemets komplexitet påverkar behovet av användarmedverkan? R: Det är klart… det borde ju vara viktigare ju mer komplext det är. I: Det är inget du har erfarenhet av?


R: Nä, men det är ju klart, ju krångligare och komplext det är behöver ju jag stöd ifrån någon som kan verksamheten och som kan säga hur de vill ha det, helt klart. Visa saker kan man ju kanske räkna ut själv kanske om det är väldigt enkelt… så går ju det. Men det är ju klart, ju krångligare det är så måste de ju vara med. Det är väl rätt logiskt kanske. 24. Vi avslutar med: Vad är din generella uppfattning om användarmedverkan? R: Ja jag tycker det är bra om de är men, inte liksom bara i förstudier och kravspecar och sådant där, utan även i utvecklingsjobbet helt klart, det tycker jag. Men sen att man behöver mer sådana där formella möten och sådant där, det jag ju inte så stor vän av, däremot gärna informella kontakter. Och sen i testfasen förstås… väldigt viktigt. I: Ja det är ju viktigt, det är ju ändå de som ska använda systemet. R: Jag menar det skulle ju inte gå att jobba utan deras medverkan, det gör ju inte det. Bara presenter någonting det blir ju inte bra. I: Då är vi nöjda om du inte har något mer att tillägga? R: Nä det har jag inte…


INTERVJU 6 - 2004-04-28 1. Presentera kort företaget du arbetar för (Presentera kort vad företaget arbetar med)? R: Vi är ett internbolag för X och våran huvudsakliga arbetsuppgift är att ta fram systemlösningar åt företaget, vi jobbar inte externt, inte än så länge kanske kan göra det senare. Våran målsättning är att vi ska ha spetskunskaper på olika delar av typ webb, integration, där vi använder Tibco t.ex. som en produkt, integrera system. Vi har även egenbyggda system som är baserare på Oracle och sen så sitter vi även, vi är uppdelade på flera orter då så här i Västerås är det mest utvecklare då, software. Sen har vi även projektledare som tar projekt och kör, olika projekt som man begär ute på siterna. Sen har vi då i Avesta sitter infrastrukturgruppen som hanterar routers och servrar och installationer och sånt, där man kan köpa in och hosta SQL servrar, eller webbservrar eller vad som helst, webbfarmar man sköter hela vårt nätverk. Vi har även personer i Sheffield, som också håller på med lite infrastruktur, men mest då software. I Espo sitter naturligtvis folk eftersom vi blev ihop med det finska bolaget X, så där har vi också utvecklare och där har vi faktiskt också en infrastruktur gäng också, så det speglar bilden vi har i Avesta och Västerås. Ehh men inriktningen är att internt hjälpa företaget med allmänna IT frågor. 2. Vad är dina huvudsakliga arbetsuppgifter? R: Mina just nu, jag är lite allt i allo. Lägger näsan i blöt i det mesta då, men det är beroende kanske på mina långa erfarenhet av företaget, så får jag vara med ofta i var det nu gäller, inköp eller strategifrågor policy och sånt då, men det jag jobbar just nu med är integrering av system i företaget där vi använder ett program som heter Tibco, som är en amerikansk produkt som ser till att vi på ett mycket enkelt sett kan hämta information från gamla systems som är byggda kanske på 80-talet. Och sen då skickar det på någonting vi kallar Tibcobussen och sen finns det andra som lyssnar och vill ha det här och sen så uppdaterar man en server någonstans. Det finns ett stort projekt som går nu som heter Osap som är X SAP, SAP är ett stort system, parameterstyrt system det är en sån här.. vad kallar man den för Enterprise system. Där du kan lägga in bokföring, order entry, lagersystem, vad som helst då. När man bestämt att man ska ha finans, all finansinformation då, så samlar man all information från alla site:er då, och då ska vart ända bolag som finns, och det är ju väldigt många bolag skicka information då, och dom flesta har sin information i databaser, en del har vanliga filer, så vi är liksom ute och plockar upp överallt och sen så skickar vi då det till en stor server som tar in det här och sen kan man utföra sin finans. Vi bygger även en webblösning som är ute nu på Internet world wide. Kunder loggar in och kikar på vad det finns för material att köpa. Mitt i det här ligger Tibco emellan och ser till så att alla får kundkontakt med dom. 3. Hur många år har du arbetat som systemutvecklare? R: Började 1978, och sen så har jag hållit fram till, nä 1979 började jag, 1978 gick jag på skola här i Västerås, så 1979 började jag. Byggde upp på Y då, i Torsälla höll jag på att bygga system fram till 1994, då jag tog anställning här istället. Så totalt är det några år jaa. ( dvs 25 år) 4. Vad anser Du att användarmedverkan innebär vid systemutveckling? R: Hhmm, det är både för och nackdelar, jag har själv setat då, refererar till Y då, när jag satt och jobbade mycket med.. 80-talet, det var då vi byggde upp deras system. Och jag mer eller mindre prototype:a nästan allting som skulle göras, jag hade alltså användarna i knät hela tiden så gick vi igenom delar av systemet då var dom med och fick se vad vi gjorde och.. eller jag gjorde exakt, eftersom det var jag som jobbade med det. Då var det väldigt positivt därför att man kunde ha en väldigt bra dialog med användaren och användaren förstod hur han ville ha det. Och jag hade jobbat som planerare eller orderbokare, jag hade ju jobbat med de där olika grejorna själv då, så jag hade lite erfarenhet av administration eller vad det nu var. Så det var enklare för mig att, kanske än vad det är idag att bygga system, så där var det väldigt positivt. För då kunde man sitta och jobba med och säga, är det så här du vill ha det? Ja, så blev han jättenöjd då. Och den killen hade man köpt då sen för hade han kommit med en idé och man la in det i systemet, då kämpade han hur mycket som helst för att få att han skulle få med det, och övertyga alla andra tjugo som satt där, att det här är en jättebra grej, då behövde inte jag hålla på med det, så på så sett så var det bra att ha användare.


Men det finns även en negativ, och det är att dom vill för mycket, alldeles för mycket. Sitter du och utvecklar och gör prototyping, så börjar man lite snyggt med en väldigt stel bild och där man gör några input, ser der bra ut? Ja, säger dom, och så kommer man till ett medelläge, man tycker det känns bra, men då är inte användaren nöjd. Då fortsätter han och vill ha något mer, lite funktioner.. Och ju mer han håller ju krångligare och krångligare blir det, då tappar man kanske designen på det man hade tänkt sig från början och då är det livsfarligt… För då kan man få.. För att klara hans sista tio procent önskan så kanske man gör om massor och det kostar pengar, fruktansvärt och det är krångligt och underhålla och så där är det en fara att ha med dom. I: Så att användarmedverkan är att dom sitter med? R: Jaa, på så sett, man jobbar med dom. Vi har även användarmedverkan vid en designfas man sitter liksom inte prototyping utan man sitter och bygger eller vad heter det.. träffas i projekt och säger att nu ska vi sätta igång med en faktureringsrutin och då frågar man hur jobbar ni idag? Och så sätter man sig och intervjuar och då är dom ju med där och bestämmer lite grann hur dom vill ha då. Där måste dom ju vara med för annars.. jag kan ju inte sitta som systemkille och säga att så här ska erat system se ut. För det var lite så på 70-talet, då sa man det, här har ni ett system och så gav dom en massa listor och grejor, nu kör ni det här. Dom blev liksom matade med att så här ska erat system fungera, det har ju helt vänt, nu är det liksom man frågar användarna istället och… så där är det positivt, det måste ju vara så, men som sagt var det finns en fara att dom kan vilja för mycket så man måste liksom sätta stopp för dom, för det ingår inte i scoopet kan man säga. När man gör sådana här projekt så skriver man ju upp att.. normalt sett de större grejorna, då man inte sitta och programmera bara för att man tycker det är kul, men det är nått mindre system. Men dom stora grejorna dom har man ju skrivit under specifikation så får man design på att det är så här jag ha det. Sen kör man efter den, sen har man ju då med användare där dom får titta då, och då sitter dom så kallade supertestanvändare som testar systemen sen då och så har dom önskemål hela tiden då, så får man kika på var det verkligen det här ni ville ha då och så kommer det in change requests då hela tiden och så vill man ändra då. Då får man kolla scoopet, var det så här dom ville ha? Hoppsan säger man, nu är du ute på fel sida av staketet det här har vi inte sagt, det kostar 50.000 till eller 500.000 till att fixa, vi behöver en ny server och vi behöver tio man som gör en kodning då. I: Då har du besvarat nästa fråga också, ja du har erfarenhet av användarmedverkan. 5. Har Du erfarenhet av användarmedverkan? Se intervjufråga 4 6. Hur vanligt förekommande är det med användarmedverkan vid systemutveckling? R: Ehm.. Jämt. I: Dom är alltid med. R: Det går inte som sagt var, du måste ha.. alltså.. dom sitter ju inte dagligen inne på mitt rum, för jag har inga användare här, om jag skulle sitta här idag, för eftersom vi sitter centralt i Västerås och har inte..jag säger tyvärr, för vi borde egentligen sitta ute vid sajten, där dom är då, man åker ju till dom och är ju där oftast så går man igenom hur saker och ting ska vara och så åker man hem till sin kammare och gör saker och ting och sen tillbaka och visar, men dom måste vara med i ett visst läge behöver dom inte vara med det räcker med på telefon att fråga dom lite grejor. 7. Hur upplever Du uppdragsgivarens syn på användarmedverkan? (eller kundens) R: Ja, det har jag egentligen ingen uppfattning om, för jag tycker… kunden som kommer och säger att dom vill ha ett faktureringssystem dom har ju vissa krav och så utser dom några personer som är nyckelfigurer och det ända man kan hoppas på då är att den som är kund, alltså uppdragsgivare att han verkligen vet vem som är nyckelpersoner och har förståelse för hur processen fungerar för det måste han veta, det räcker inte bara att se bilder på hur det gamla systemet fungerar, man måste förstå hur själva processen fungerar, fakturering t.ex. vad det innebär. Så det är lite svårt att svara på den där, det är bara hoppas att han ger oss rätt personer annars får man säga ifrån.


I: Du upplever att uppdargsgivaren vill ha med användarna? R: Ja, ja på så sett, det vill dom alltid. 8. Vad är enligt din mening det bästa / sämsta som användarna kan bidra med? (Det var du inne på i tidigare frågeställning, det är inget du vill tillägga där?) R: Ja det bästa är ju att han, vad ska man säga, att man har dom med och att han kan.. om man har med dom oftare, man sitter liksom i knät på dom, man är ute vid det företaget man håller på så att man nästan kan plocka in dom och fråga är det så här du vill då kommer man fortare fram till skott för då slipper vi göra fel eller göra sånt som jag var bra men han ville inte det så.. men det är åter igen det är lite ge och ta där. 9. Vem bestämmer om man ska ha användarmedverkan med i utvecklingsprojektet? (Det har du ju redan svarat på, det är..) R: Det är ofta… Vi vill ju ha det även vi som… även om du inte har sagt det uppdragsgivaren, vi behöver det här. När vi kommer till den fasen att vi ska försöka visa för någon så måste vi ha någon att prata med användaren, dom som vi kallar för superanvändare som testar av systemet och trycker att det är bra, dom måste man ha, annars sitter jag och bygger system som jag tycker tror ska passa bra, sen kommer det ut och så blir det hoppsan det var inte alls vad vi ville. Ha r man dom att snacka med då har man rätt kommunikation hela tiden man pratar med samma språk och är på rätt spår så att man kan leverera rätt. I: Men det är vanligtvis uppdragsgivaren som bestämmer, och om dom har valt att inte ha med det så kan ni vara med och påverka det? R: Ja, då ser vi nog till att vi vill ha det, för det är… för jag skulle inte kunna se hur det skulle kunna funka.. Har man jobbat så många år som jag så blir man ju rätt.. man vet hur ungefär hur det ska se ut då, man har gjort det några gånger förut. Men det spelar ändå ingen roll man vill ha med dom. För ska du lägga saker och ting i produktion då.. Vi kör ju oftast i en utvecklingsmiljö, som senare flyttas över till test som står uppe i Avesta. Och den är nästan likhetstecken mellan hur produktionsmiljön ser ut. Frånsett att man loggar in på en testdatabas istället för en produktionsdatabas, testwebb istället för priduktionswebb. Men dom ser precis likadana ut identiskt så den här stageing när användaren sitter och testar av hela tiden, när de säger OK på den så lyfter man bara över den till produktion utan att ändra en kodrad, man loggar in med ett annat userid och sådana saker. 10. Vilka faser har ni med i det utvecklingsarbetet som du brukar jobba med? (Det här har du varit inne på nu) R: Vi kan ju börja med, det är ju rätt så klassiskt. Du kan liksom inte bara sätta igång och bygga ett system, du måste ju sätta dig ner och prata med dom som vill ha det, vad har dom för krav. Vi blir ju mer konsulter här, intern konsulter det är skillnad när man sitter på ett företag som jag gjorde tidigare nere på Y, där vi var en liten IT avdelning då hade jag ju koll på de 1500-2000 program som fanns där, jag visste ju varenda kodrad så när man skulle ändra någonting, det finns här så var det klart. Nu gör du inte det när du är konsult och du har många enheter att hålla om, då måste det bli de här dokumenten som man talar om vad det är för kravspec, det finns projektförslag, det finns massor av dokument som måste fyllas i och vara med då för att vi ska kunna leverera någonting en viss tid då. I: En förstudie? R: Ja… en förstudie, först kommer det en projekt förslag som talar om det här är vad vi vill göra och sen så ska man ha pengar för det. Lämnar man in den och säger det här… man vill ha det här, här står det då ungefär uppskattad budget och allting, mantimmar om vi behöver testmaskiner och sånt, så står det en miljon där. Det ska finnas en styrgrupp som sitter och tar sig an det här projektet då, så att den som är projektledare kan prata med styrgruppen och hela tiden få OK då, ifall det ramlar över kanten när det gäller pengar… Det finns massor med dokument som ska fyllas i så att vi håller ordning på, så vet vi exakt hur vi ska designa och greja.


R: Hur var frågan? I: Vilka faser ni har? R: Så det är den där designfasen då, att gå igenom, sätta projekt, design och sådana saker och sen utser man vilka som ska vara med… Utveckla, titta på resursplanering, har han tid nu hela den där biten sen sätter man igång då. Sedan utvecklar man då tills man kommer till det läget då man tycker att man får en rätt så stabil kod. Man tittar på kravspecifikationen, dom funktioner som man vill ha utförda då, det finns ett ord som heter leverabel vad man ska leverera. Så kanske man kommer fram till version 0.99 eller 1.0 då, sen lägger man upp den i test. I : Testmiljön eller? R: Hmm, och sen ber man användarna sätta igång att testa och då blir det lite lugnare för utvecklarna första dagarna, den kommer det en lång lista med change request, då går det t illbaka då och då ska liksom.. i dom här större projekten då måste man ta tag i dom här, så får man sätta sig ner som vi gör här och prata om förändringarna och titta på, vad är det dom vill göra nu da, vad innebär den här förändringen och är det bara en rubrikändring då är det inge konstigt, men så säger dom att dom vill ha en ny funktion, jaha det är två veckor till med mantid á 500 kr/h eller 1000kr/h eller vad det nu kostar, så då måste det tas upp och man måste värdera varenda förändring. I: Är det väsentlig eller inte liksom. R: Jaa, så gör man då ändringar så går man tillbaka till utveckling och gör man ändringarna och så gör man en ny ”leverans till test” så får vi testa den då, så håller man på och itererar. Sen så säger man, ähh nu är vi nöjda då går man i drift men då har man i alla fall den här ”intensive care” som det heter så vackert dom första dagarna då man sätter igång något i drift så är det någon som har missat någonting i alla fall, man kan inte testa precis 100% det brukar alltid vara någon liten grej som man missar. I: Står ni för förvaltning också? R: Jaa, i Avesta har vi en del förvaltning, en del support vi har något som kallas first line support och second line support, first line är alltid några som svarar i telefon oavsett vad det är för system, så får dom ringa dit och det är det gamla vanliga som om man ringer till Microsoft eller när man ringer till någon annan, vad är det för fel på det här och så styr dom in då till och tar kontakt med min grupp här, för att vi har upptäckt att det är fel-meddelande istället för webbservern eller Sql-servern, och då kallas den för second line support. Så vi driftar system jaa. I: Utbildning? R: Utbildning? Vad vi gör med utbildning här är.. I: Av användare. R: Vi behov så tar vi utbildning, det finns ju budgeterat pengar för utbildning för varje anställd här och i mån om tid då så får dom alltså gå på en utbildning men det ska ju vara behovsprövat så att jag kan inte säga att jag ska.. vad ska vi hitta på en webbutveckling. I: Slutanvändaren? R: Jaså den, jaha förlåt det kommer naturligtvis men den… I: Användardokumentation. R: Ja men det ingår alltså i de leverabler som jag sa, där man sätter upp kravspec då talar man om vad man ska leverera också. Det är mycket möjligt att dom här superanvändarna får skriva dokumentation. Vi skriver den tekniska specen och talar om att vi ligger och rullar på dom här servrarna.


I: Systemdokumentation. R: Ja. I: Man kan säga att ni har förstudie, analys, design, utveckling och implementation. R: Driftsättning och utbildning kan vi också ha. I: Ni har dom klassiska faserna. R: Ja, det är inge konstigt det. 11. Vilken typ av inblandning är vanligast vid användarmedverkan? (Förklarar närmare vad vi är ute efter dvs. seminariegrupper, referensgrupper, testgrupper, frågelåda) R: Det första måste ju vara att vi sitter ju med dom när man startar upp ett projekt då man likasom fått godkänt att köra då måste man ju sätta sig och börja prata med dom. I: Då har ni möten? R: Möten ja, oja det kan vara brainstorming, det kan vara brown paper method man sätter upp ett stort papper på väggen brunt och så har man såna här Post-It, så sitter man och skriver idéer och så upp med dom, det är inte så vanligt med det kan hända och det kan vara alla former och sen blir det naturligtvis uppföljningsmöten när det inte stämmer och att dom klagar på oss.. I: Ni använder möten, och så har ni en testgrupp. R: Jo. 12. Vem bestämmer vilken typ av inblandning användarna skall ha? R: Har ni inte frågat det förut? I: Nä, det var vem bestämmer om dom ska vara med. R: Så vilken typ av inblandning, vem bestämmer.. Jaa det måste ju bli.. det ger sig väl lite grann.. för som jag ser det dom användare vi jobbar med det är ju dom som vi kan.. vi kan ju inte springa till vilka vi vill heller och användarna får inte springa till vilka utvecklare som helst heller. Man har liksom dragit upp riktlinjer för att man inte ska störa varandra när man jobbar då. Så vi har en viss användare utsedda troligtvis av uppdragsgivaren då, eller begär att få några, det är dom vi pratar med dom kan ju bli inblandade i det mesta för det kan ju vara från design till att förklara funktionen eller varför ska det här fältet vara med. I: Man kommer fram till det under utvecklingsarbetet? R: Ja. 13. I vilka utvecklingsfaser och på vilket sätt anser Du att användarmedverkan kan vara överflödig eller rent av negativ? R: Ja, överflödig eller rent av negativ… Vi kan ju börja med den första fasen, då man tittar på, ja först kommer ju projektet igång och sen kommer design då måste dom vara med det kan inte vara överflödigt då. Sen är det ju själva utvecklingen då kanske han inte är med lika mycket, då behöver han inte sitta i knät på en och sen ska man ju.. det ända man behöver ha är telefonkontakt troligtvis och man kan ju oftast i och med att det mesta är webbaserat så kan man ju be han browsa in på eller köra in på en webbsida och säga ser det här bra ut och så men... I: Ska du sitta med någon av det där faserna vad känner du liksom mest, finns det någon fas då du känner att du inte vill ha med dom, dom är överflödiga eller dom kan till och med bromsa er.


R: Ja det skulle vara just det där med kodningen när man gör den här grova kodningen då behöver dom inte vara med, tycker jag, då vill man vara ifred och sätta upp någonting dom får inte vara med och störa hela tiden, ja men du jag vill ha såhär och så, nä då tar man senare. Oftast har det visat sig att man kan komma med en prototyp eller några bilder som man lagt ner lite mer krut på så oftast köper dom det. Jag menar kommer du bara med någon bitmap eller sådär så blir det svårare, visar man dom lite mer real life vad som händer. I: Prototyping vill man göra i lugn och ro? R: Ja det skulle jag nog vilja säga, när den här stora massiva kodningen då, det är på slutet man vill ha med dom. Men ett tag vill man sitta lugn och ro för annars får man inte tänka ifred. Sen är det testningen då och där kan det vara rent negativt alltså och då gäller det att stoppa avtalet under näsan på dom, det här har vi kommit överens om, alltså själva funktionsspecifikationen och då hoppas man att den är så detaljrik så att det står vad det skulle vara. I: Kan det vara negativt i testfasen? R: Nä men dom kan komma på fler grejor, det är oftast då dom gör det. 14. Vilken grad av inflytande har användaren haft under utvecklingsarbetet? (Är deras ord lag) R: Nä definitivt inte, det kan vara dumma påhitt dom hittar på men det brukar jag inte stöta på… Jag tycker inte det för man kan tala om för dom att det här fungerar inte, det är såhär systemet är gjort. Det är klart skulle dom vara riktigt driven användare så kan han ju gå till sin chef eller uppdragsgivaren och tycka att det här är fel och få ändringar i funktions-specifikationen, fine det är ju en ”change request”, men inte lag på det sättet att jag vill att det ska ändras här pang. För då kan dom bara säga jaa men det stämmer inte enligt det vi har sagt, då får dom dra det via en change request och då blir det i och för sig lag jag vet inte, då har ju dom bestämt det men dåra men då tar man in det och pratar med styrguppen och säger att det kostar 50.000 kr till så kan dom ju ha det, via den vägen. 15. Hur mycket har Du haft möjlighet att påverka användarens grad av inflytande och på vilket sett? R: Det beror hur bra man är, man kan ju lura upp honom på läktaren och säga att det här ser bra ut och att det funkar bra… Ähh jag vet inte. I: Du kan inte kasta bort en change request heller? R: Nä det kan jag väl inte göra… det här handlar ju inte om tjuv och rackarspel utan ge en bra funktion till en, så oftast är man ju på samma ”speaking tearms” och säger att det här är helt naturligt att man ska göra den här förändringen. Men vad sa du i frågan igen? I: Hur mycket har Du haft möjlighet att påverka användarens grad av inflytande? R: Jo jag kan ju faktiskt alltså, i så fall om jag tycker att systemet är illa designat så kan ju jag naturligtvis prata med användaren och säga, du det här är ju mycket bättre om vi gör såhär så kan jag visa lite mer, då så ser han ju helt plötsligt att dom har tänkt fel, så kan jag naturligtvis göra. I: Du har möjlighet att påverka? R: Jo det har jag, ok i den aspekten. 16. På vilket sätt har Du haft möjlighet att påverka användarens grad av inflytande? R: Se föregående fråga.


17. Hur sköts vanligen kommunikationen mellan er och användarna? R: Med öppen telefon och workshops I: Direktkontakt med användarna? R: Jaa, jaja. I: Så både informellt och formellt? R: Ja det är det. 18. Tycker du att kommunikationen brukar fungera bra, mellan er och kunderna? R: Ja, inga som helst problem, jag har aldrig några problem att prata med användarna. 19. Är det vanligt att det förekommer terminologiska problem mellan er och användarna? (Man pratar ”olika språk”, utvecklaren och användaren) R: Ja det kan nog förekomma, det kan det nog göra. Man missförstår varandra men jag tycker inte det är så ofta. Jag vet inte om jag har stött på det under de senaste åren här. Det kunde ha vart i början så man satt nere på Y, nää jag tror inte det är så. I: Det är inget som är negativt att användarna inte förstår och bromsar upp er? R: Nä jag tycker det är mer upp till oss, för oftast sitter vi kanske på den mesta kunskapen om hur systemen ser ut och allting och så ställer man.. man har liksom satt in sig i problematiken det man ska lösa så pass mycket så vi måste ha pejl på hur saker och ting funkar, vi märker ofta när de svara på fel saker. I: Men dom förstår er? R: Ja det lär jag nog påstå. Det är ju våran uppgift att vara så pass insatta i det här så vi måste.. alltså jag kan ju inte bygga system om jag inte förstår mig på vad de vill ha gjort och då är det upp till mig att hela tiden intervjua tills jag upptäcker att nu är det speaking tearms. Fast det är klar att i början så kan det säkert bli fel. I: Man kan ligga på olika nivå, på för teknisk nivå? R: Jo visst kan det förekomma men jag tror det är mest i början man kan tänka på det just i design och så här, men när man väl börjar komma fram till.. börjar bygga det var inte det här jag menade nog kan det förekomma men inte så mycket. 20. Anser Du att användarnas inställning till att bli delaktiga i projektet påverkar deras attityd till utvecklingsarbetet? R: Oja… Får dom vara delaktiga (om jag har förstått frågan rätt) dom får till och med någon grej som dom får bestämma över, när man ändrar som dom tycker är bra dom blir ju hur.. det är ju 100% direkt ifrån deras inverkan. I: Men om ni tar in en användare som är negativ till att vara med, hur brukar han förhålla sig till projektet? R: Jo jag har varit med om det vi, nu måste jag gå tillbaka till 1985-1987 någonstans då skulle Avesta orten dom skulle använda exakt samma system som jag hade byggt för Y bruk, Y då, ett Unix baserat system och vi hade en användare som var helt hopplös alltså allt var bara skräp och hans gamla var mycket bättre och en sån kille fick man liksom prata med och så fick man börja visa var det var för saker och det hela visade sig tillslut, det jag förstod att han var alltså lite orolig för att han inte skulle förstå vad det här nya systemet kunde göra så när han väl förstod vad vi håll på med då tvärvänd hand så var han med och tyckte jättebra om vissa grejor, sen försvarade han det


för sen skulle det bytas ut senare, då var det samma visa igen. Så där är han ju liksom väldigt negativ i början och det kan ju påverka oss i utvecklingen att det tar lång tid eftersom vi inte får hjälp, men då gäller det att sätta sig ner och fundera på varför han är så negativ och försöka komma fram till roten till det onda. Det vet jag för just den där killen och då sa jag, då kör du sa jag, men jag vet inte vilken knapp jag ska slå på, tänk om jag slår fel sa han. Då förstod jag, oj han är nervös för att han ska sabba någonting men då sa jag, du det här har jag byggt sa jag och är det så att det blir fel så är det mitt fel sa jag, du ska inte kunna förstöra och då satte han igång och då släppte det just i det fallet då, jag vet inte om det var ett svar på frågan? I: Joo. 21. Hur villiga är användarna till att medverka i utvecklingsarbetet? R: Ja det är blandat måste jag säga för många, tyvärr som ni vet så alla företag drar ju ner på antalet anställda.. så om man har nio anställda tar bort en, den nionde anställda hade ju några arbetsuppgifter dom delar man upp på dom här stackars åtta, så blir det samma visa när man drar ner igen vilket innebär att man tillslut kanske bara är fem och sitter då egentligen med vad nio anställda gjorde och så har man lite hjälp av IT system. Oftast blir det ju att dom här jobbar mer och det tycker jag är en.. vad ska man kalla det för.. som man ser i dagen samhälle att folk jobbar lite mer, ofta hör man det jag kommer hem lite senare från jobbet jag hade inte tid att göra det för det tog en halvtimme till en timme till, många gör så nu och det innebär, jo varför gör dom det jo dom har mycket att göra. Och sen uppe på det här så kommer dom här utsedda, du ska vara testare och du ska göra det här, och då kan dom bli negativa till det här och tycke det är jobbigt, dom har inte tid så då kan det bli svårt att få ihop dom det är.. men det har ju inte liksom med utvecklingen, det är ju deras arbetssituation då, det är ju upp till uppdragsgivaren att peka ut rätt person och avlasta honom eller henne från sina vanliga uppgifter. I: Men är det något som ofta orsakar problem för er utvecklare, att testningen inte blir klar i tid? R: Det kan hända så ja. I: Men det är inte alltid så? R: Nä, men det händer. I: Man kanske får vänta på informationen? R: Ja, jag har inte tid och dom måste göra det ena, och helt plötsligt smäller deras gamla system och då måste de rätta upp det och då faller det vi håller på med för det är ju produktion. Men som sagt det har hänt att det kan vara lite sämre med det då, att man får vänta på dom. 22. Är det vanligt förekommande att användarna har en dålig attityd till utvecklingsarbetet när dom är delaktiga i det? R: Nä jag tycker nästan tvärt om, dom flesta tycker att det lite små roligt att se vad som händer och se.. Nä jag tycker att det är tvärtom, dom blir positiva och då får dom en förståelse, sen.. jag vet vi har några stycken som är så kallade superanvändare för olika system vi har byggt och man ser på dom att dom trivs som fisken i vattnet och dom känner sig lite.. inte för mer, men dom känner att dom har mer kunskap i systemet så dom får ju blir som pappa eller mamma åt resten av gruppen när det är någonting och det tror jag dom.. och så känner dom att dom kan driva sen framöver en ändring och få liksom kan börja tänka själv och börja bli liksom designers också så det tror jag bara är positivt. 23. Hur påverkar graden av komplexiteten på systemet behovet av användar-medverkan? R: Oj, ta frågan en gång till den var ju lång. I: Komplexiteten på ett systemet, graden av den hur påverkar det behovet av att ha med användare i utvecklingen?


R: Men är det inte alltid så att det måste… oavsett komplexitet, hur pass avancerat systemet är så måste vi alltid ha med användare.. Men det kan ju vara så att man behöver mer eller mindre. I: Ja graden av. R: Ja ja, nu hänger jag också med. Ehm nä det säger sig självt ett väldigt komplext system behöver ha med dom mer, om man inte har skrivit den där funktionsspecifikationen väldigt väl och vet hur allting ska fungera, men oftast så är det inte så. Så då behövs det säkert ha dom med. Men är det ett enkelt med två tre bilder i någon webbsida så kanske du kan göra det utan honom, han bara säger kan du göra ordning det här åt mig. Så att naturligtvis påverkar det. 24. Vad är din generella bild av användarmedverkan? R: Jag tycker det är bra, jag skulle inte kunna jobba utan att ha med en användare… det finns ingen anledning att jag sätter mig och bygger ett system och sen bara stoppar det i handen på honom och han inte trivs med det. Så för mig känns det som a och o… När ni frågar såhär så tänker jag oftast på online system när man har dom med och sitter och jobbar, nuförtiden jobbar jag mycket med system till system när inte användaren syns, ser någonting utan där datorer pratar med datorer så att det är liksom automatiskt allting, då tappar man lite det där med användare, då blir det mer att man pratar med IT folket på respektive ort. Då blir dom så kallade användare och man snackar med dom istället. Men rena och skära användare som sitter här som en webbapplikation och ska boka order eller svara på vad det nu är, där måste dom vara med för dom kan ju dialogen också.


INTERVJU 7 - 2004-05-05 1. Presentera kort företaget du arbetar för (Presentera kort vad företaget arbetar med)? R: Företaget jag arbetar för jobbar inom konsultbranschen med datalösningar då, vi jobbar oftast ute hos kund och utvecklar program då, och vi är 20 personer ungefär på två orter. Så ganska så litet och vi försöker väl profilera oss med att vara duktiga men få istället. 2. Vad är dina huvudsakliga arbetsuppgifter? R: Mina huvudsakliga arbetsuppgifter är ju att jag är konsult så att det beror ju på vilket uppdrag man har, men oftast är det ju att då tillsammans med min kund eller åt min kund utveckla lösningar. Ibland så är man resurs i ett projekt eller ibland så jobbar man helt självständigt och utvecklar liksom åt kunden mer efter önskemål alltså man ingår inte i samma grupp som.. de har inga egna utvecklare. 3. Hur många år har du arbetat som systemutvecklare? R: I sjutton år. Dom sista och så har jag fusklapp här… sen 96 som konsult, sista 8 åren som konsult och dom första 9 åren som utvecklare på ABB. 4. Vad anser Du att användarmedverkan innebär vid systemutveckling? R: Användarmedverkan är väl att när man försöker ta in, tycker jag i alla fall, att när man försöker ta in synpunkter på användargränssnittet innan man egentligen, eller ja man börjar med att innan man utvecklar någonting och under tiden man utvecklar och så utvärderar man låter andra som inte är utvecklare titta på det så att det inte blir.. det blir tydligt även för icke tekniker hur man ska göra saker och ting och att man tar in olika referensgrupper, dom som ska vara användare av systemet ska vara involverade i processen, att ställa krav på användargränssnittet. 5. Du har erfarenhet av användarmedverkan? R: Hmm 6. Hur vanligt förekommande är det med användarmedverkan vid systemutveckling? R: Det är väldigt varierande skulle jag säga. För det första så är det ju inte alla system som man jobbar med som egentligen har så mycket användargränssnitt, det beror på, ju mer man kommer mot industrin desto mindre bryr man sig om användarmedverkan skulle jag vilja säga. Jag jobbar med Webb också och där är det ju mer så att säga okända mottagare av systemet så man kanske då lägger ner mer tid på användarmedverkan för att dom som jobbar med webb är en mycket mer flyktig målgrupp, är det inte tillräckligt lätt att hitta så försvinner man från site:en… Jag tycker att det varierar väldigt väldigt mycket, en del kunder tycker att det inte ens behövs och en del inser att det är nästan det viktigaste, så det varierar. 7. Hur upplever Du uppdragsgivarens syn på användarmedverkan? (eller kundens) R: Det är precis samma svar där, det är en mognads process antingen anser dom att det är någonting som är viktigt och att det är någonting som kostar tid och pengar och att det oftast liksom blir bättre att involvera slutanvändarna tidigt, men oftare är det ju särskilt när det gäller system som är väldigt tekniska som ska användas internt på det här företaget, då är det en användargrupp som sätter upp, eller en beslutsgrupp som sätter upp vad systemet ska klara av och sen så när typ är klart så kommer det till dem som ska använda det, och då har de inte fått sett eller haft synpunkter på det förrän det är färdigt och då kanske det inte alls är som de är tänkt använda sitt system.. För då har man liksom en klar målgrupp vilka som ska använda det men när man jobbar med webb liksom då är man ju intresserad att så många som möjligt ska kunna ta del av det, eftersom man inte riktigt vet vem som är målgruppen och då kanske man satsar mer pengar för att man liksom.. tid och pengar för att man är intresserad av.. hur det ska mottagas da och därför involverar man grupper liksom genom interaktionsdesign och så vidare.


8. Vad är enligt din mening det bästa/sämsta som användarna kan bidra med? (Vi kan börja med det bästa) R: Det bästa det är ju att man… Om det kommer användare som… dom tänker på ett annat sätt oftast eller liksom dom, när man får se systemet med nya ögon än någon annan användare som man... för som vet ju inte om hur man Ska använda det utan dom använder det som dom tror att man ska använda det och då förstår man att man kanske inte alltid har varit så tydlig som man tänkt sig och att det inte alls var så självklart allting som man hade planerat så himla klokt. Så då får man ser hur användarna verkligen jobbar med systemet, det alltid är intressant och se liksom vilka sökvägar, hur dom går, hur arbetsmetodiken går till liksom hur man egentligen gör när man använder sig av det som man som systemkonstruktör liksom har gissat sig till.. fast jag tycker alltid att det är bra, man får mycket aha upplevelser särskilt på webb då man har användargrupper som man tar in några som kanske ska svara på ett antal frågor genom att använda hemsidan då och se hur dom söker information, vilken information dom inte ens får fram och vilka begrepp dom inte förstår och sådana saker. Man blir ganska insnöad på sitt eget system när man har arbetet med det så pass länge, så man ser inte sådana saker. I: Vad är det sämsta? R: Sämsta.. jag vet inte riktigt… Det kan ju komma väldigt mycket synpunkter som är av bagatellartat natur som alla har en synpunkt på. Alla har synpunkter på utseendet t.ex. nä jag tycker inte den ska vara blå, jag tycker inte att knappen ska sitta där och det har ju alla en synpunkt på så det kan liksom bli att det… man kan inte lyssna på alla riktigt för alla har inte riktigt… Vissa saker kan man inte ändra bara för att olika personer tycker olika. Så man får helt enkelt filtrera lite gran, sen beror det ju alltid lite på om man jobbar direkt mot en kund så är det beroende på vem som säger det, hur viktigt det är. Jobbar man med en grafikiskt användargränssnitt så måste man vara medveten om att få synpunkter på både utseende och funktion hela tiden, för det är ju det enda man ser… så vad det är därunder det vet man ju aldrig utan hur bara hur det upplevs för användaren… så gnälliga användare är ju aldrig bra, men om man kommer med synpunkter som egentligen liksom, jag tycker att det ska vara såhär liksom bara för att dom är vana med att det är grönt… det är ju synpunkter det också men man kan inte riktigt ta till sig, all feedback är ju någonting som man kan fundera på om det ligger någon sanning i det eller om man det är något man ska göra något åt. 9. Vem bestämmer om man ska ha användarmedverkan med i utvecklingsprojektet? R: Det har jag inte funderat på men det är väl oftast kunden, för det beror helt på, dom kunder som inte tycker att interaktionsdesign är viktigt dvs. hur man arbetar med t.ex. ett gränssnitt, om dom tycker att men det här är så självklart, vi behöver inte lägga ner pengar på det, då får man inte några såna. Det beror liksom helt på vilken mognad och hur pass intresserad man är, om man utvecklar ett system för en egen organisation så hur intresserad man är över att det ska mottagas väl. För allting som man får vara delaktig i tidigt liksom får man bättre.. Ja man tycker bättre om det här nya systemet när det kommer än när det bara dimper ner något på skrivbordet, nu blir det jobbigt, nu är det något nytt när man inte har fått varit involverad i processen liksom att kanske ställa krav eller få tycka lite grann eller säga hur det ska vara.. Men att det i princip alltid så är det kunden. 10. Vilka faser har ni med i det utvecklingsarbetet som du brukar jobba med? R: Det varierar ganska mycket också, på en del ställen så är det att kraven är ställda och att man egentligen skall.. och ibland kan det också vara att funktionerna är specificerade och att man egentligen bara ska utveckla, men det är ganska så sällan. Men att oftast så finns den ju kravbild och vad man vill förvänta sig att det här systemet ska åstadkomma och så beroende på kunden, ibland får man göra alla kravspecifikationer och såna saker själv då och sen utveckling och implementation och test och dokumentation så att. I: Men ni har ingen sådan här fast utvecklingsmodell som vi får läsa om i skolböckerna? R: Hihi, joo men det är samma sak här, som konsult blir det alltid kundens modell som styr, använder dom dig av RUP så är det RUP man använder och om man gör ett projekt själv så kan


man ju använda delar av RUP, men man sitter ju liksom inte och gör saker ting bara helt taget ur luften, men att det är alltid en avvägningsfråga liksom hur pass mycket det får kosta, ska man följa RUP fullt ut så kostar det ganska mycket mer i tid. Om det inte är ett uttalat krav så kanske man inte går igenom alla steg… I: Ni anpassar. R: Man anpassar sig för man.. om man jobbar hos en kund så måste man ju följa deras utvecklingsmodell om de nu har någon, och har dom ingen så får man liksom använda sig av sin erfarenhet och sunda förnuft liksom att producera ungefär lagom mycket specifikationsdokument för att det ska dokumentera systemet men ändå inte ta så mycket tid, dom måste ju vilka betala för det, det måste vara en avvägning. 11. (Vilken typ av inblandning är vanligast vid användarmedverkan? Förklarar närmare vad vi är ute efter dvs seminariegrupper, referensgrupper, testgrupper, frågelåda) R: Jag vet inte om jag kan säga något vanligast, jag har varit med om referensgrupper då man har involverat personalen som ska vara mottagare, inte bara.. för ibland blir det liksom att IT-chefen och hans närmaste som bestämmer det här, men många kunder dom förstår liksom att ta med någon referensperson som presenterar kundtjänst, dom som representerar fakturering dom som ska vara användare/mottagare av systemet. Så att dom får en person som ger gruppens syn på systemet. Jag jobbade hos en kund på ABB-tiden där dom hade med han som var chef för operatörerna fick vara med i hela projektgruppen för att han liksom fick representera dom som skulle använda det. Sen har jag jobbat med externa, där man tagit in då användare och.. så att dom får göra sina tester, ja korttester och sorterings tester och informationssökning tester där man liksom inte har en.. visst man ska vara lite intresserad av det och vete begreppen men inte kunna site:en, så det har varit lite olika. Men det vanligaste som jag har upplevt i alla fall det är att i projektgruppen så kan det finnas med så att säga depassiva deltagare man kanske inte gör så mycket mer än att finnas med som kravställare och kanske med i tester för att se att det fungerar i deras verksamhet. 12. Vem bestämmer vilken typ av inblandning användarna skall ha? R: Nu förstod jag inte. I: Det här vi pratade om vem bestämmer hur.. om det ska vara referens eller om det ska vara… R: Det bestämmer kunden. Kunden sätter upp.. Vi lever en annan värld än om man äger hela processen själv, vi bemannar ju oftast med några fåtal personer där vi aldrig har användar- sidan utan vi jobbar med implementation då så, det är om kunden själv har, eller är intresserad så att.. en projektgrupp är ju oftast ihopsatt liksom av några från kunderna och några resurser, kanske konsulter några externa resurser och där då kunden själv tillsätter någon resurs från sin egen organisation som inte har så mycket med implementation att göra utan mer med kravställningen och då blir det användarpåverkan. 13. I vilka utvecklingsfaser och på vilket sätt anser Du att användarmedverkan kan vara överflödig eller rent av negativ? R: … När dom minst har att göra är ju under själva implementationsfasen helt enkelt för att det.. från det att kraven är satta.. man kanske har gjort specifikationen tills det är klar för test, det är klart man kan fråga men det är då ett ganska självständigt jobb för utvecklarna under den fasen då ska man redan ha ritat upp dom gränser och interaktioner man förväntar sig av systemet, sen så ska det bara implementeras. I: Så då kan det vara jobbigt om dom kommer hela tiden och säger nya grejor, för då ska ju allt redan vara fastställt. R: Ja, jo.. det är ju alltid jobbig om kraven förändras under tiden, oavsett om det är yttre eller inre men att det är om det är något man ser eller något som bara ska funka, men det händer hela tiden…


14. Vilken grad av inflytande har användaren haft under utvecklingsarbetet? R: Ja.. dom har väl inte under utvecklings ja eller implementationen under själva utvecklingsprocessen så är det väl... som konsult så måste man ju oftast sätta sig med någon som använder, för oftast så kanske man har ett liknande system då, hur använder du det här för att det kan ju vara en affärsprocess som man inte vet hur den fungerar, hur gör du när du registrerar en faktura vilka steg vill du gå? Och så kanske dom förklarar dom hur dom skulle vilja jobba och så får man själv försöka ge ett förslag och ibland så har man ju till och med interaktionsdesigner som är involverade som specificerar upp vilka bilder som ska finnas och hur dom ska relatera till varandra. Men jag har bara varit med om en kund som jag jobbat med där dom har haft med interaktionsdesigner, det brukar vara teknikerna som får vara interaktionsdesigners också då, dom som gör skärmbilder och så tror att det bli bra. Så i början så har dom ganska så stort inflytande för att dom är ju kravställare på hur dom vill att systemet ska fungera. Sen så blir det väl alltid mot slutet där man testar och det inte fungerar som dom vill göra och då beror det ju på hur pass viktigt det är att det ska blir klart, eller om man ska göra om så som dom vill ha det… man kommer inte på hur man vill ha det förrän man sitter och klickar på alla knappar och testar… Då får man väl göra om eller också får dom lära om. 15. Hur mycket har Du haft möjlighet att påverka användarens inflytande? R: Hur då menar du? I: Alltså måste du göra som dom säger, eller kan du påverka det? R:... Nä men om man ser direkta tankefel eller det han säger inte kommer fungera i praktiken så kan man ju påpeka att man kanske kan göra på ett annat sett och liksom påpeka varför det här inte blir speciellt bra, men om det är så att kunden vill på ett skitdåligt sätt så blir det tillslut att man gör det på ett skitdåligt sätt om dom står på sig liksom, det är ju så illa. För vi gör ju det dom vill att vi ska göra men man försöker hjälpa till när man ser att det här kommer inte fungera speciellt bra därför att av den erfarenheten som man har man kanske inte vill ha tio stycken pop upp rutor på datorn samtidigt. I: Så alltså den möjligheten du har att påverka är genom att försöka styra och övertyga? R: Jaa, man kan ju också.. rent tekniska argument brukar vara det som biter bäst, liksom att det inte går att göra, det är ju också någonting…. Det kommer att påverka… men det beror ju mycket av vad man gör för typ av utveckling, i vissa fall så kanske man jobbar med någon sorts produkt som inte klarar av det som användaren vill ha, så man får liksom göra en kompromiss att det tar tio veckor att göra det du säger såhär men gör vi det lite såhär så tar det två veckor… man talar om vilka saker som dom vill ha som våldför sig på systemet att det tar lång tid att göra och blir krångligt. Så så kan man ju styra lite grann, men det beror mycket från fall till fall, det finns inget generellt svar. 16. På vilket sätt har Du haft möjlighet att påverka användarens grad av inflytande? Se föregående fråga 17. Hur sköts vanligen kommunikationen mellan er och användarna? R: Oftast så sitter man på samma projektmöten ungefär, annars så är kan det vara genom dokument då. I: Så den är ganska formell? R: nja, jag hittar inget bra exempel ..Ja den är väl ofta ganska så formell eftersom det oftast har det varit en representant för användaren ju som har varit med i projektgruppen så det är ju inte ens.. ibland så är det ju inte förrän som systemet står på plats som det är dom riktiga användarna som man träffar och då är det ju för att dom inte förstår eller för att systemet inte gör som dom vill och då får man träffa dom. I det projektet jag jobbade med interaktionsdesign och dom här riktiga kortsorteringstesterna då träffade jag dom inte alls, då fick jag bara reda på resultatet av dom här


testerna så att, men då fanns det en interaktionsdesigner som satt emellan och såg resultatet av det här så att. 18. Tycker du att kommunikationen brukar fungera bra, mellan er och kunderna? R: Jaa, det brukar inte vara några problem.. det var en sån abstrakt fråga…du menar.. I: Mellan er och användarna. R: Ja det tycker jag väl, det har jag inte upplevt som något problem. 19. Är det vanligt att det förekommer terminologiska problem mellan er och användarna? (Man pratar ”olika språk”, utvecklaren och användaren) R: Ja det är vanligt, jag har en kund nu som är väldigt… dom jobbar inte alls med IT, utan dom jobbar med kunskapsöverföring.. ett kunskapsföretag. Så där får man liksom lära sig deras språk, därför att det räcker inte att säga att det ska vara en pop-upp ruta, det ska vara en skylt eller något sånt där, man måste lära sig deras språk för att teknikerspråket och det svenska språket eller icke -teknikerspråket är liksom så.. jag har lärt mig det. Men det kan ju bli språkbristningsproblem för är man datanörd så använder man sig av vissa termer som är så här självklara för tekniker med inte för icke -tekniker. I: Det där måste ju skilja sig ganska mycket också. R: Jaa det skiljer sig, ja precis, sitter man på ABB t.ex. och jobbar som resurs, ja menar där är det inte så stora skillnader i språken, men jobbar man liksom med ett icke IT företag så.. då kan det skilja väldigt mycket. Sen att jobba med slutanvändare, för att dom.. där är liksom den här datorn kanske ibland till och med något som dom inte vill ha ens vill ha på skrivbordet. I: Ett nödvändigt ont. R: Ja precis och då kan det ju verkligen.. man måste liksom tänka sig hur man förklarar det här på ett enkelt set, utan att blanda in en massa data detaljer som dom inte förstår ändå. 20. Anser Du att användarnas inställning till att bli delaktiga i projektet påverkar deras attityd till utvecklingsarbetet?, du kanske inte vet vad dom har för inställning när dom blir inplockade? R: Jag tror.. om man ska generalisera så tror jag att dom flesta av användarna tycker om att bli engagerade tidigt liksom, att dom för möjlighet att påverka… konsekvensen kan ju bli den att alla får olika förväntningar på vad det här systemet ska göra, dom tror att allas.. från olika perspektiv så ska den här att lösa deras alla världsproblem, vilket inte brukar vara sant liksom, men jag tycker att de flesta.. inställningen till när systemet är klart brukar bli bättre för dom som liksom varit engagerade från början än när man bara får det färdigt på skrivbordet, då brukar det kunna vara lite såhär, det funkade ju bra det här förra, nä nu vet jag inte hur jag ska göra. För då blir deras verklighet svårare den dagen när det nya systemet står på bordet och oftast är det inte heller lika stabilt som det förra gamla, som man minsann visste hur det fungerade. Jag hade en kund som hellre ville gå och bryta på det här stora reläet på väggen liksom men att klicka på en liten knapp, för det där visste man inte hur det fungerade. Dom kände sig inte trygga i det här nya för att dom inte hade fått vara engagerade och förstått liksom och varit med under acceptanstester så lär man ju också som användare hur saker och ting fungerar, så man är mer förberedd på det. 21. Hur villiga är användarna till att medverka i utvecklingsarbetet? R: Ja.. det är också… dom flesta är ju.. det som ligger i naturen hos dom flesta är att tycka till när det är klart, istället för att.. det kräver lite mer tankeverksamhet att fundera och titta på en specifikation och fundera på vad det får för konsekvenser, medan sitter man och använder det så då… nä men så här tänkte jag inte, det var ju underförstått att det skulle vara såhär har man ju fått höra. Det är lättare att säga till när saker och ting är klart, när man får testa det riktiga än att bara.. men det är också väldigt varierande så att.


22. Är det vanligt förekommande att användarna har dålig attityd? R: Nä jag tror snarare att det är dom fallen som jag har haft erfarenhet av när dom inte har varit engagerade alls och att dom har en liten skepsis för det här nya. Då spelar det inte någon roll vad det är för något, då räcker det med att det är något litet fel så är det nya systemet skit. Har man dålig attityd så då.. I: Letar man felen nästan. R: Ja precis, det är nästan så att det kan vara en tävling hur fort dom kunde sänka systemet, ja lyckades liksom.. 23. Hur påverkar graden av komplexiteten på systemet behovet av ta med användare? R: Nja, det beror väl på vad ni menar liksom, det finns ju jätte komplexa system som inte ens behöver ha några användare, bara för att komplexiteten ligger liksom i någon typ av beräkningsalgoritm som inte användaren ser. Om det är ett komplext.. jag har varit med och utvecklat ett publikationssystem där man som skulle kunna publicera artiklar, notiser, bilder och allting som.. CMS system. Där var interaktionsdesign interaktionsspecifikationen liksom ett hundra sidor eller någonting, och det blev ju i alla fall inte riktigt bra, efter specifikationen och den hade vi aldrig kunnat göra, för där ville kunden att vi skulle göra precis som dom ville just då i alla fall så att. Då var det ju nödvändigt att ha med deras deltagande, för det hade man inte kunnat sitta och gissa sig hur de ville arbeta, för när det har att göra med hur, vilken arbetsprocess som man har så är det ju absolut nödvändigt, när man inte kan den processen själv liksom, hur jobbar ni, då måste man ju ha. Men oftast så blir det ju en persons synpunkter man får och att det inte alltid kanske är förankrat nedåt så. Men så brukar det vara. 24. Vad är din generella uppfattning av användarmedverkan? R: Jag tycker att det är bra, det är synd att inte fler kunder liksom förstår att det kan ju avgöra hur ett system blir mottaget om det är bra för användarna, för att liksom det spelar ingen roll det som finns under skalet om det inte är lätt att använda det och man ska absolut inte räkna med att det som tekniker tycker är lätt, så är det för icke-tekniker.. Jag har jobbat dom sista fyra åren hos en kund som då har målgrupp icke-tekniker och dom tänker på det här hela tiden och det har varit jätte lärosamt för mig liksom, man får lära sig att liksom inte.. man måste vara väldigt tydlig och förklara och dom har hela tiden lagt mycket tid och pengar på att det ska vara tydligt och god interaktion och design då. Jag tycker att det är viktigt och i vissa fall så.. det finns så många tekniker som tycker att det där med interaktion och design det är tjafs det kan vem som helst göra men det.. det kan vara skillnad liksom om man sitter ock letar bland en massa menyer och man hittar fan ingenting, men att man tycker det är helt självklart och att man tycker det är så enkelt det här systemet, är det enkelt så är det oftast bra interaktion på det. Då har man varit intresserad av att användarna ska tycka att det här är ett bra system.


INTERVJU 8 - 2004-05-05 1. Presentera kort företaget du arbetar för. R: Oj, det var ju inte så lätt för nu har ju jag inte jobbat här mer än knappt en månad ens. I: Okej men då tar vi din bild nu! R: Det är ett företag som heter e-man som har 20 anställda, startades 2000 av före detta konsultkollegor till mig så jag känner dem sedan ett tag tillbaka även om jag inte har jobbat med dem här. Tanken är väl egentligen att hålla på med, slarvigt sagt, webbutveckling. Fast inte att göra hemsidor utan mera tunga system som man också då kan presentera på webben där egentligen 99% av arbetet är någonting annat än HTML. Och det har man väl lyckas ganska bra med så vitt jag kan förstå. Det hörde jag förut och det ser jag nu när jag är på insidan. 2. Vad är dina huvudsakliga arbetsuppgifter? R: Dom kommer att vara att jag är en av de här personerna som utvecklar de här tunga sakerna i bakgrunden och inte att arbeta med användargränssnitt och sånt. 3. Hur många år har du arbetat som systemutvecklare. R: I 15 år. 4. Vad anser du att användarmedverkan innebär? R: Ja… spontant så innebär det att användarna, av ett system som skall utvecklas, skall tas med i processen någonstans innan systemet levereras undertiden som det utvecklas. Men det är ju inte så himla ofta som det sker så vitt jag har sett. 5. Har du erfarenhet av att arbeta med användarmedverkan? R: Ja! 6. Hur vanligt förekommande är det med användarmedverkan vid systemutveckling? R: Jag tror att det är ovanlig, i princip. Alternativt att ofta har de företag som utvecklar kommit på att användarmedverkan ska vi ha så att det skall får säga sitt och sedan så gör man någon liten pseudogrej för att de skall bli nöjda eller för att man skall kunna ”bocka av” att nu har vi gjort användarmedverkan men man tar ingen större hänsyn till det. 7. Hur upplever du uppdragsgivarens syn på användarmedverkan? R: Det lilla som jag vet av den, eller de projekt som jag har tittat in i, hur det går till där så försöker man ju ändå ta med, möjligen inte användarna i någon stor skala utan någon slags representant för användarna, som får se på tidiga prototyper och säga sitt om de tycker att det är alldeles tokigt. Men det är nog mera i formen av att man presenterar någonting och se lite synpunkter på det och sen ändrar man en stund tills dom tycker att det är ganska bra. 8. Vad är enligt din mening det bästa och sämsta som en användare kan bidra med? I: Vi börjar med det bästa! R: Det bästa som de kan bidra med det är ett gäng bra idéer så att det man utvecklar blir bättre. Om det nu är någonting uppenbart man har missat. Och det sämsta man kan bidra med är, vi kan ta som exempel från ABB, när användarna ändrar åsikt hela tiden. Då har vi typiskt haft användargrupper inför de här stora utvecklingarna med 100-tals personer som har tittat på någonting och slutligen ha de bestämt sig för att de är nöjda. Och sen gick det lite tid och sen hörde de av sig igen och nu hade de kommit på, eller läst i en tidning eller nåt, att nu var det sånt här stuk det skulle vara på det och sedan svängde det där det var någon slags arbetsprocess där saker och ting bara vevades runt och


man kom inte direkt framåt. Det var inte så att från början och sen blev sakerna bättre och bättre utan sakerna bara ändrades utan att det blev bättre. Och då upplevdes ju den här användarmedverkan på ett negativt sätt, det var inte någon som orkade hålla på med det där och tillsits avrundade man och sa att nu är vi nöjda med användarmedverkan, såhär blev det! 9. Vem är det som bestämmer om man skall ha användarmedverkan med i utvecklingsprocessen? R: Ja det är någon som är projekt - eller utvecklingsansvarig och de flesta har säkert till uppgift att ta med användarna på något sätt men väldigt många tror jag av olika skäl hoppar över det. Det kan ju inte rimligen vara så att själva användarna bestämmer att, vi skall vara med. Det kan dom ju framföra som en synpunkt men det brukar ju inte vara de som bestämmer det. 10. Vilka faser har ni med i det utvecklingsarbetet som ni brukar arbeta med, har ni någon särskild utvecklingsmodell? R: Näe på ABB har de ju en särskild sån här ”gate” modell där det ingår användarmedverkan, eller det heter inte användarmedverkan det heter någonting annat. Som egentligen börjar med att man gör en sån här kundundersökning med förväntningar och nya saker som skall in i systemet så att man kan se vad kunderna förväntar sig vad som skall finnas med som är fas 0 eller vad det heter. Sen finns det flera andra faser där man har tagit in det här och gjort lite prototyper och sedan visar man samma användargrupp som deltog i den här idefasen, hur det blev. Sedan får användarna säga sitt och man ändrar lite grann fram och tillbaka och tillsist så kommer man då till fas 1 och 2 där det är för sent för användarna att säga någonting för så har det stora jobbet dragit igång. Det är den enda slags modell som jag har sett under alla dessa år och den är ändå den mest formella av de 25 eller 30 eller 40 projekt som jag deltagit i som är stora så är det ju 20 som man inte har frågat användarna. Där har man antingen själv eller beställaren, i form av någon chef någonstans, som har kommit på hur det skall se ut. Antingen själv eller en förbättring av tidigare system där han i sin tur har samlat på sig åsikter från någonstans. Men det är ingen egentlig användargrupp som är inblandad utan det är ytterst får personer som har kommit fram till hur det skall se ut. 11. Du var inne lite på det nu men vilken typ av inblandning är vanligast vid användarmedverkan? Förtydligar med de fem nämnda i uppsatsen. R: Det som jag har arbetat med det är ju, hur skall man kategorisera det? Det är väl egentligen två sorters användarmedverkan dels är det en slags funktionell medverkan som man alltid brukar börja med när man utvecklar stora system. Då frågar man en grupp utvalda kunder om vad de vill ha med för saker i det nya systemet. Saker som man skall kunna göra. Det är en grovkategorisering sen efter ett tag hamnar man i det här mera detaljläget och då övergår man från vad skall vi kunna göra till hur skall det se ut eller hur skall det fungera och då är det nästan alltid med fokus på utseendet. Hur skall man komma till den här lilla funktionen eller hur får man se resultatet? Så där är det ju dels funktionalitet från början och dels användargränssnittet. I: Det tar ni fram på möten eller? K Den första funktionella insamlingen den brukar ske med intervjuer med användargrupper och sedan hamnar det in en kravspec som sen blir en funktionsspec och sen brukar man göra prototyp. Då har man ett användarmöte där användarna eller representanten får titta på det här. Det fanns några teorier förr att man kunde göra det på papper men nu för tiden går det lika fort att göra ett användargränssnitt på datorn än att göra för hand. Man kan ju göra det på bara några dagar utan funktionalitet bakom som man sedan visar för användarna i ett litet möte. I: Sen när man implementerar har man några testgrupper då med användarna? R: Nej då är det bara egna testgrupper, så då är inte användarna inblandade. De är bara med och bestämmer vad som skall med in och ungefär hur det skall se ut och sedan brakar det lös ett tag och sen testas det av egna testgrupper.


12. Vem är det som bestämmer vilken typ av inblandning som användarna skall ha, vem bestämmer att det skall vara intervju? R: Ja på ABB i de projekten som jag varit med på där då är det den som är programledare som är ansvarig, som bestämmer det. I: Är det en typ projektledare eller? R: Ja, man har en programledare i toppen, när projekten är väldigt stora, och under den har man ett antal projektledare. Man kan säga huvudprojektledare och subprojektledare. Han är ansvarig för hela projektet och alla aktiviteter som ingår där, t ex att få tag på användare eller prata med kunder. 13. I vilka av de utvecklingsfaser som ni använder och på vilket sätt anser du att användarmedverkan kan vara överflödig/negativ? R: Jag tror att användarmedverkan är antingen minst önskvärt eller har minst att tillföra under utvecklingsfasen och under testfasen. Jag tror på att det är bättre att dom är med i början än under tiden och på slutet. Anledningen till att jag tycker det är att har man kommit så långt att man är i utvecklingsfasen så är det oftast mycket att göra och det är bråttom och det är teknikaliteter och sånt. Då har man inte så mycket tid att käbbla om hur någonting skulle se ut för det är lite för sent för det då. I testfasen skulle man också kunna tänka sig att ha med användarna men haken med det är att då är det för sent att göra någonting åt det man ser oftast. I den tidiga fasen kan man ändra allting, har man fått en uppgift och itererat med användarna och sedan utvecklat i ett eller två år då hjälper det inte om användarna sitter och test gruppen och säger att det här är inte riktig det vi tänkt oss för där är det katastrof larm mer eller mindre. Man kan ju tycka att man vill hellre upptäcka det där än vid leverans men det är lika illa. Det är 99% illa eller 100% illa så det spelar ingen större roll. I: Men om de hittar fel, det är ju en sak att de vill ha en annan funktion men det är ju ändå dom som skall arbeta med systemet är det inte dom som lättast hittar felen då? R: Min erfarenhet är att användarna är oftast mycket sämre på att hitta fel än de testgrupper som man tillsätter, det kanske man inte tror men så är det. Jag vet massor av projekt som har levererats där man har testgrupper som inte består av utvecklarna som har gjort det hela, för det är ju väldigt dåligt att ha utvecklarna som testa. Utan man har speciellt testare som egentligen inte alls är utvecklare och inte kan programmera utan de är bara där för och dels ha snälla tester för att se om det i princip fungerar om man gör rätt. Dels eländiga tester när man börjar klicka runt och veva på allt möjligt för att se vad som händer då. De där testerna resulterar alltid i massor med felrapporter som man rättar ett tag men vanligtvis är det så att felskörden kommer aldrig ner till noll, vilket möjligen är överraskande för många. Utan där bestämmer man en grad av fel, är det mindre än 50 eller 100 stycken och ingen är, man kategoriserar de efter svårighetsgrad. Är de mindre än ett visst antal och det bara är sådana lättviktiga fel och release tiden närmar sig då releasar man ändå även fast det är massor av fel. För det där kan man hålla på med i åratal för det finns alltid fel. Erfarenheten är att ytterst få av de felen som finns med på listan som kan vara över hundra kända fel är sådan som kommer in som externa fel från kund utan det kan vara någon enstaka. De gör oftast inte så kaotiska saker utan de försöker ju använda systemet till att utföra den uppgift som den är beställd för. De vanliga arbetssätten är oftast helt felfritt och de fel som finns uppstår oftast när man gör någonting helt annat. Det är bättre med interna testgrupper som är avsatta för det och får lön eller mer eller mindre bons för de fel de hittar, användare är oftast för snälla för att upptäcka fel. 14. Vilken grad av inflytande har användarna under utvecklingsarbetet? R: Olika från projekt till projekt. Jag tror att dom har inflytande så länge de är inbjudna där i början, sen efter det tror jag att de har väldigt lite inflytande för att inte säga inget alls.


15. Hur mycket har du möjlighet att påverka gra den av inflytande? R: Det är ju i oför sig en intressant fråga. Det är ett av de sätten som användarna antingen bjuds in eller självmant en del kommer på att de vill vara med. De är också medvetna att det är i den tidiga fasen och bestämmer och sen rätt vad det är så börjar allting och då vet de att det är för sent att påverka någonting. Då har det hänt ett antal gånger att man pratar med användarna under tiden att utvecklingsarbetet pågår och får lite användarpåverkan därifrån, är det enkla saker då kan man i utvecklingsarbetet göra dem fast de egentligen inte var bestämda eller ingick i det tidigare man kom överens om. Så det tror jag är en sak som användarna möjligen kommer på och är det något som man själv kommer på så kan man ju kontakta dem och ha lite inofficiellt fixande, det är någonting som man lär sig under arbetets gång. Det är väldigt få projekt som bedrivs enligt en projektmodell, bara! När man bestämmer någonting och sedan genomför det och sedan levererar. Så är det inte, under tiden där så pågår det en massa mindre aktiviteter som inte alltid är helt skriftliga. Det är saker som man kommer på är bra att göra, det tar lite längre tid att göra dem men det är ingen skada skedd. Sånt pågår i alla projekt. 16. Så det är med kontakt med användaren som du kan påverka? R: Ja i egenskap av utvecklaren så är det ju genom kontakt med användarna under det att utvecklandet pågår. Då kan man ju få i de sista förändringarna, förutom det är det bara det som pågår i den tidiga fasen. Om jag nu är en av de som pratar med användarna. Det som är på ABB där jag har tillbringat nästan all min tid där är det så att nästan ingen som pratar med de här stackars användarna utan det förvanskas efter hand. När användargruppen kommer in så pratar de med programledaren och kanske någon annan designer person, men det är alltid några enstaka på de här mötena och de typiska utvecklarna och tekniska projektledarna de är inte med då. Dom får höra programledarnas och de andras blid av vad de tycker och det är det man har att rätta sig efter. Det finns ingen direktkoppling utan det förvanskas i nåt eller några led, oftast är det ju flera led. 17. Nu har du väl du besvarat det här med hur sköts vanligen kommunikationen mellan er och användarna? R: Ja är man utvecklare så är den obefintlig, oftast! Då går den genom de här andra personerna som har projektets olika roller. 18. Anser du att kommunikationen fungera bra? R: Nej den fungerar antingen dåligt eller också så är den obefintlig. Å andra sidan vet jag inte hur man skulle kunna göra det heller. Det var ju i många av de projekten som jag har varit med på som man tycker att det har varit dåligt. När de från ovan, som man säger i projekt, kommer med en bild och säger att såhär skall det se ut och såhär skall vi göra. Antingen så har de hittat på det eller också så kommer det från en användargrupp, men det ser man ju inte när man står på den andra sidan. Då tycker man ju ibland att så här kan det ju inte vara. Har man en stor utvecklingsgrupp på hundra personer då har ju inte alla samma idé om att såhär skall det se ut och såhär skall det fungera så då brukar det vara många som räcker upp handen och undrar vem har sagt att det skall vara såhär? Jag tror att det är en väldigt stor skara av de som är med i utvecklingsgänget som skulle v ilja se, om det så bara är ett möte, det sista mötet med användarna, och höra deras åsikter att de faktiskt har sagt ok till det här. I: Men är det tid och pengafråga som ställer till det eller varför blir det inte så? R: Möjligen en tids eller pengafråga men oftast är det ju det att det där mötet på en timma eller någonting är en väldigt liten kostnad i det stora hela, det är bara flimmer i jämförelse med allt strul som inträffar under projektets gång. Tror att det är fråga om att man inte tycker att det är meningsfullt att pressa in alla utvecklare och användare i ett rum som förmodligen skulle bli en hel aula. Då kanske det blir ett logistik problem istället man måste ha en mic osv. har man ett litet möte så kan man klämma in 10 personer i ett konferensrum och så har men en OH projektor, så går det till. Det är svårt när det blir storskaliga grejer för då kan det lätt bli dyrt, det är lätt att det faller på det. Men i små projekt där det bara är en handfull utvecklar då kanske man skulle kunna få till möten.


19. Hur vanligt är det att det förekommer terminologiska problem? R: Inte så vanligt tror jag, fast det kändes ju som en sån fråga som man skulle svara att det är jätte vanligt för användarna pratar ett annat språk. Men jag tror att det är en typis k överskattad punkt att utvecklarna de kan bara prata teknik och användarna de förstår ingenting. Man måste utgå från att båda grupperna är normala människor, vissa jobbar med att programmera och utveckla någonting och andra förvaltar byggnader eller gör någonting annat och vill ha ett system för det. Men jag tror att det där är väldigt mycket mindre problem nu för tiden än vad det var för något eller några årtionden sedan när det här med data var något jätte exotiskt. Majoriteten av de oskyldiga användarna som inte kan någonting dom har ju ändå en hemdator som de vet någorlunda väl hur den fungera och de tycker inte att det är så jättemystiskt att man har ett datasystem på jobbet för att utföra sin uppgift så jag tror inte att det är några stora svårigheter. Inte värre än att man kan ändå förstå, det är ju så att när användarna beskriver så är det inte exakt samma termer som utvecklarna använder men det är inte konstiga eller mera fel än att man begriper vad de menar. I: Men från deras sida om de arbetar inom någon industri som ni inte alls är hemma i kan ni känna då som utvecklare problem att förstå. R: Nja, fast det kan man oftast rationalisera bort i något steg. Ibland kan man tro att skall man göra att system för båtindustrin eller hamnar så måste man kunna någonting om hur den här branschen fungerar men så är det nästan aldrig. Jag har provat att göra system för olika branscher och många gånger har jag inte en aning om hur det fungera egentligen men när man kommer ner på funktionsbeskrivningarna över vad systemet skall göra då är det oftast bara att hålla ordning på ett gäng information det är liksom bara det som gäller. Sen vad det betyder att det här numret här det är egentligen en båt som får ett nytt nummer när det åker igenom tullen det struntar man i. Man koncentrerar sig på infomängden som man skall göra någonting med, den skall paketeras in i gränssnitt och databaser och allt sånt där. Så det brukar gå ganska bra utan att man förstår branschen. Åtminstone om man är så långt fram i processen så att man skall göra system, tror att det är mycket viktigare för dem som är tidigare. Dom som håller på med förstudie och sånt dom skall möjligen då hjälpa användarna och beställande företag att hitta på och utreda vad det är man egentligen behöver för så behöver man branschkunskap men så fort man kommer till det läget att man är i ett utvecklingsprojekt då behöver man inte veta så mycket. 20. Anser du att användarnas inställning till att bli delaktiga i projektet påverka deras attityd under utvecklingsarbetet? R: Ja det gör det väl, alltså det säger ju sig självt att de användarna som får vara med och bestämma mycket i de tidiga faserna tenderar till att vara mera glada både det under att utvecklingsarbetet pågår och vid leverans. Dom som blir överkörda redan från start och sedan får de något elände i knäet de är oftast negativa. I: Kan de inte vara så att användarna tvingas till att vara med fast de egentligen inte hinner eller vill? R: Det är ganska sällan, jag har varit med om det några gånger där några användare uppenbarligen inte har velat vara med och sagt ja eller nej på vilka frågor som helst bara för att bli av med det hela. Men det tre gångerna som det varit så då har faktiskt den här användargruppen omformats efter en stund så att personen har försvunnit och andra har tillkommit som ville någonting. Så det är mera ett sånt kundorganisatoriskt problem, ingen beställare kan ju liksom men rim och reson säga att vi vill beställa det här projektet för en massa pengar men vi är inte villiga och skicka en enda person som vill tycka om det här det verkar ju alldeles orimligt. 21. Hur villiga är användarna till att medverka? R: Jag tror att alla de gångerna de är tillfrågade så vill de vara med så mycket som de bara får. Det som sätter begränsningen är utvecklingsprojektets ledare som mer eller mindre säger att nu har vi inte tid med det här mera, det är mycket sällan som användarna säger att nu orkar vi inte vara med på det här mera. Sen kanske det också beror på anledningen till att projektet finns elle r kommer att uppkomma. Om det är så att det gamla befintliga systemet tycker alla är dåligt och sen kommer det ett beslut från ovan att det skall bytas ut då är det klart att de är intresserade av att vara med. Men


om användarna tycker att det är ganska bra som det är och så här de ändå någon IT-chef som har läst något i Computer Sweden och tycker att det vore skit fräckt med ett nytt system som han har kommit på och vill driva men har inget riktigt användarstöd då är det klart att det är svårare att få entusiasm. Många saker kommer sig av bredare och andra ursprung än att jag är en användare, vill jag eller vill jag inte delta, det ger sig från vart man kommer ifrån. Sitter man i ett bra läge med ett bra system eller sitter man med ett jätte dåligt eller har chefen sagt att jag skall göra det här nu eller vill jag göra det här själv egentligen? Det kommer sig av annat än att man som person vill eller inte vill. Värden är komplex! 22. Är det vanligt förekommande att användarna har en dålig attityd? R: Jag har inte upplevt det, inte på bred front i alla fall, det är några enstaka fall. Men det är några neggiga personer som har blivit utsedda som egentligen inte ville men de försvann och sen kom det ju några nya personer som ville någon och hade tid att delge konstruktiv kritik. Jag tror att användare är villiga och vill gladeligen vara med. 23. Hur påverkar graden komplexitet på systemet behovet att ha med användare? R: Det låter ju rimligt att säga såhär att är det ett jätte komplext system så skall man ha med användarna och är det ett jätte litet simpelt system så behöver man inte ha med användarna. Men jag tror att det är svårare än så. Ett jätte komplext system kan vara komplext på massa olika sätt, är det jätte komplext att göra något i systemet då är det, enligt mig, inte ett komplext system utan då är det någonting som är fel mer eller mindre sen att det är jätte komplext bakom det skall inte synas för användarna. Gör det de då är det något annat som är fel så jag tror att det faktiskt är likvärdigt viktigt i komplexa och i enkla system. 24. Då avslutar vi med din generella uppfattning om användarmedverkan? R: Den är vad ska jag säga… det låter ju fint och säga att den är viktig och allt sånt och det är den säkert men jag tycker att användarmedverkan är rolig snarare än viktig. Men rimligen är det ju så att den är viktig och det tror jag inte bara är för den organisation som skall utveckla utan minst lika viktig för den organisation som beställer någonting, att man faktiskt utser några eller att det framkommer några personer som har chans att tycka till om det nya systemet. Är man inte beredd att göra det på beställarorganisationen då kan man inte förvänta sig att det blir så bra heller.

Documents

Systemutvecklares syn på användarmedverkanvesterdahl.se/c-uppsats/C-Uppsats.pdf · MÄLARDALENS HÖGSKOLA Ekonomihögskolan C-uppsats i informatik, 10 p, VT2004 Eskilstuna, 2004-06-09