IT-kvalitet i praxis: systemutvecklares kunskap om och syn på kvalitet
Författare
Summary, in Swedish
Popular Abstract in Swedish
Alla har vi väl någon gång varit med om att datorer, dataprogram och datasystem inte fungerar som vi har tänkt oss. Inte sällan inträffar det fel och konstigheter som kan vara frustrerande och, i värsta fall, direkt farliga. Många gånger undrar man hur ett visst program eller system skall användas och hur de som har designat och byggt det har tänkt och resonerat.
I stort handlar detta om kvalitet eller ännu hellre olika kvaliteter, d.v.s. egenskaper hos produkter som påverkar upplevelsen av att använda dem, hur lätta de är att förstå och lära sig att använda, vilken nytta man kan ha av dem, möjligheten att förändra dem till nya krav som omgivningen ställer och möjligheten för dem som har utvecklat dem att själva förstå hur de fungerar och kan anpassas. Att ITs genomslag i samhället dessutom ökar och berör allt fler människor och verksamheter och därmed har en stor påverkan på många människors vardag, gör det relevant att studera kvalitet på den alltmer omfattande och närvarande informationstekniken (IT) som datasystem och dataprogram är en del av.
Kvalitet har också blivit ett sorts slagord och närmast ett krav för olika verksamheter för att kunna konkurrera på marknaden. I en allt större utsträckning talas det om och efterfrågas olika satsningar för kvalitetsarbete, exempelvis ISO-9000 certifieringar, för att garantera kvalitet och trovärdighet. Detta gäller också inom den bransch och de verksamheter som tillverkar mjukvara, d.v.s. datasystem och dataprogram. Det handlar då om en del av det totala området kvalitet som kallas IT-kvalitet, d.v.s. kvalitet på informationsteknik.
Det finns alltså goda skäl att intressera sig för och studera systemutvecklares kunskap om och syn på IT-kvalitet.
Anledningen till att vi, Odd och Theis, intresserar oss för systemutvecklares perspektiv, hänger ihop med att bland andra Mitchell Kapor (1996), som var en av grundarna till Lotus Corporation och en av huvudmännen bakom det en gång mycket framgångsrika kalkylprogrammet Lotus 1-2-3, har riktat kritik mot systemutvecklares förmåga att designa goda och användbara produkter. Mitchell Kapor efterlyser nya arbetssätt och en bättre förmåga att skapa god kvalitet för användarna.
Frågor om arbetssätt och förmåga leder också till ett intresse för systemutvecklare som yrkesmänniskor. Hur en systemutvecklare tänker och arbetar är, bortsett från studier av Erik Stolterman (1991) och Christer Hoberg (1998), dock dåligt belyst.
Kopplas detta till att kvalitet blir allt mer viktigt, samtidigt som kritik riktas mot systemutvecklares förmåga att uppnå god kvalitet, uppstår ett intressant område att studera. Detta område är IT-kvalitet som begrepp och systemutvecklares kunnande om och syn på kvalitet. Kvalitet som begrepp är väl bearbetat inom delar av vårt område, däremot finns det mycket lite skrivet om systemutvecklare som yrkesutövare.
Kvaliteten på system och program blev redan tidigt i ITs historia ett problem, eftersom den tidens teknik krävde att man ägnade all uppmärksamhet åt att utnyttja datorernas mycket låga prestanda på bästa sätt. System och program skrevs med effektivitet som ledstjärna, viket ledde till att snabba och resurssnåla men kryptiska program skapades.
När de som använde dessa enkla system och program, i huvudsak tekniker och vetenskapsmän inom USA försvarsmakt, var de samma som byggt dem, var det egentligen inga större problem. I takt med teknikens utveckling och spridning till andra verksamheter i samhället, och andra typer av användare, började emellertid mängden programvara och komplexiteten i dem att öka och därmed ökade också behoven att kunna förstå dem för att rätta de fel som alltid finns i program. En marknad för programvara uppstod också och den översvämmades med dåligt byggda program. Så småningom var situationen så besvärlig att en mjukvarukris uppstod under 1960-talet och ett eget ämne, Software Engineering, skapades för att forska fram arbetssätt och teorier för att åstadkomma mjukvara som lättare kunde rättas och anpassas. Målet var att skapa objektiva och matematiskt grundade utvecklingsmodeller, som skulle anammas av den växande mjukvaruindustrin. Dessa ansatser lyckades inte helt, men gav ändå upphov till en bättre förståelse för god teknisk uppbyggnad av mjukvara.
Den tekniska kvaliteten på mjukvara förbättrades så sakteliga, men nya bekymmer uppstod. Även om mjukvaran är tekniskt perfekt hjälper det inte mycket om användarna av systemen och programmen inte förstår hur de kan användas och har svårt att lära sig dem. Inte heller hjälper teknisk perfektion mycket om mjukvaran inte stödjer de arbetsuppgifter som användarna utför. Man insåg därför efterhand att kvalitet på mjukvara inte bara handlar om rent tekniska egenskaper, utan att kvalitet lika mycket är en fråga om användbarhet. Därmed uppstod ett nytt område, Människa-Dator Interaktion (MDI), för att studera detta vetenskapligt och praktiskt.
Även inom MDI var man till en början intresserad av objektiva metoder och teorier som skulle vara allmängiltiga för alla människor. Människan sågs som ett sorts biologiskt maskineri som mjukvaran kunde anpassas till. Detta begränsade synsätt på människan kritiserades dock dels för att det utesluter den verkliga arbetssituation som de tänkta användarna befinner sig i, dels för att det inte tar med sociala och mänskliga perspektiv på arbete. MDI-området utvecklades därför i en mängd olika riktningar och är numera ett tämligen omfattande ämnesområde.
Software Engineering och MDI har på var sitt sätt bidragit till mycket av förståelsen för IT-kvalitet och hur man kan uppnå god kvalitet. De har också bidragit med en mängd definitioner och kvalitetsbegrepp som kan fästa uppmärksamheten på viktiga egenskaper.
Systemutvecklares kunskap om och syn på IT-kvalitet behandlas däremot inte i den teori om kvalitet som vi har studerat. De enda vi har funnit som har undersökt det här är David Wilson och Tracy Hall (1998), som visar att synen på kvalitet varierar kraftigt mellan olika systemutvecklare och deras chefer.
Vi väljer att se IT-kvalitet som en kunskapsfråga och för att göra detta har vi utgått från, förutom teorierna om kvalitet, Kjell S. Johannessens (1999) tolkning av Wittgensteins senfilosofi och Bertil Rolfs (1995) tolkning av Polanyis teorier om praktisk kunskap. I korthet handlar detta om att det finns kunskaper som visar sig när man utför en handling. Under lång tid i det västerländska samhället har äkta och sann kunskap endast varit sådan som kan formuleras i logiskt klara satser och regler. Viss kunskap låter sig dock inte fångas på detta sätt, exempelvis moralisk kunskap. Det är också så att det krävs kunskap för att formulera en logisk regel, men den kunskapen framgår inte av själva regeln. Det måste alltså finnas andra kunskaper än de som klart och koncist kan formuleras.
Kjell S. Johannessens använder begreppen påstående-, färdighets- och förtrogenhetskunskap för att tala om olika sorters kunskaper. Påståendekunskap är kunskap som kan formuleras och uttryckas verbalt. Färdighetskunskap däremot visar sig i handling; det är i handlandet man kan se kunskapen. För att kunna handla, och därmed uppvisa färdighetskunskap, måste man vara bekant med en mängd situationer som möjliggör handlingen. Man måste alltså också ha förtrogenhetskunskap och även den är mycket svår att uttrycka verbalt. Det begrepp som har kommit att beteckna denna typ av kunskaper är tyst kunskap. För att ändå kunna kommunicera den tysta kunskapen måste man förlita sig på indirekta medel som exempel och liknelser.
Även Bertil Rolf behandlar praktisk och tyst kunskap. Skillnaden är utgångspunkten att den tysta kunskapen fungerar tyst, snarare än att den inte är möjlig att uttrycka verbalt. Det handlar alltså mera om en sorts kunskap som vi utnyttjar i bakgrunden när vi utför våra handlingar. Viss kunskap kanske aldrig kan uttryckas verbalt, men vilken kunskap det är kan vi inte peka ut.
Enligt Bertil Rolf har man praktisk kunskap om man kan utföra en handling väl enligt vissa regler eller kriterier som skiljer en illa utförd handling från en väl utförd och om reglerna eller kriterierna fungerar tyst. Att ha praktisk kunskap handlar alltså om att kunna utföra handlingar med god kvalitet i förhållande till olika kriterier. Om den som har praktisk kunskap skall vara kompetent innebär det dessutom i korthet att kriterierna är förankrade hos andra utövare som avgör kvaliteten på ens handling, att kriterierna på något sätt kan uttryckas och reflekteras över, samt att utövaren kan påverka kvalitetskriterierna för att förbättra dem. Endast då kan man tala om kompetens enligt detta synsätt.
Kompetens kan med andra ord aldrig endast handla om att följa regler. Dels krävs det erfarenhet för att förstå reglerna, dels måste reglerna kunna förändras till det bättre. Därför är reflektion och olika sätt att uttrycka kunskap avgörande för att den skall kunna utvecklas tillsammans med andra. Det gäller då att fokusera på tysta kunskap och uttrycka den så att olika personers erfarenheter kan spridas och diskuteras. Den egna erfarenheten kan dock inte ersättas, eftersom den behövs för att förstå regelsystemet som man försöker förbättra. Detta är våra teoretiska utgångspunkter - IT-kvalitet samt kunskap, kunnande och kompetens. I vår empiriska undersökning av systemutvecklares kunskap om och syn på kvalitet ställer vi bland annat följande frågor: Vilka begrepp använder de för att tala om kvalitet? Vilka betydelser lägger de i begreppet kvalitet? När talar de om kvalitet och hur? Hur bedömer de kvalitet? Är erfarenhet viktigt för att kunna bedöma kvalitet? Är erfarenhetsutbyte viktigt för att utveckla den praktiska kunskapen om kvalitet? Dessa frågor hänger ihop med vår vilja att se systemutveckling som en praxis, d.v.s. ett yrkesmässigt sammanhang med regler och kriterier för bedömning och praktisk kunskap. Att tala om begrepp och definitioner innebär att tala om kunskap som kan uttryckas verbalt, d.v.s. påståendekunskap. Vi vill även försöka förstå den praktiska kunskapen i form av färdighet och förtrogenhet, eller personlig praktisk kunskap för att använda Bertil Rolfs begrepp. Förmågan att bedöma kvalitet, erfarenhetens och reflektionens betydelse, samt erfarenhetsutbyte är då intressanta att studera, eftersom de är uttryck för praktisk kunskap och kompetens.
För att få svar på dessa frågor genomförde vi 19 djupintervjuer med systemutvecklare, programmerare, projektledare och funktionsdesigners. Dessa intervjuer genomfördes under perioden december 1998 till juni 1999 på tre olika företag, varav ett var ett konsultföretag och de två andra interna IT-avdelningar. Alla intervjuerna spelades in på band och skrevs ut ordagrant.
När det var gjort analyserade vi materialet med ett kodningsramverk byggt på Johannessens tre kunskapsformer och gjorde sedan tolkande sammanfattningar av intervjuerna. För att presentera resultaten skrev vi ett fiktivt samtal mellan tre personer. Projektledaren och systemutvecklaren Eva, hennes man Adam, som är programmerare och systemutvecklare, och Lars, som fungerar som samtalsledare, för ett samtal om vad kvalitet betyder, hur viktig den är, hur den bedöms, hur förmågan att bedöma den utvecklas och hur man kan tala om en bedömning av kvalitet med andra systemutvecklare.
Det vi kommer fram till när vi analyserar systemutvecklarnas förståelse för och kunskap om begreppet kvalitet, är att kvalitet alltid är en fråga om någons uppfattning och att kvalitet inte helt och hållet kan regelstyras, t.ex. genom standarder, mätmetoder och utvecklingsmetoder.
Kvalitetsbegreppet är också komplext och inrymmer många olika egenskaper som tillsammans utgör innebörden av kvalitet. Eftersom det är ett svårt och sammansatt begrepp, kan systemutvecklarna inte ge en allmän definition som slår fast vad kvalitet faktiskt är.
Bedömningen av kvaliteten på system och program sker genom att någon gör en värdering och jämför detta med vad man anser vara bra eller tillräckligt. Sällan handlar värderingen om att mäta eller beräkna. Därför vilar förmågan att bedöma kvalitet i viktiga avseenden på den personliga erfarenheten och därmed kan värdering av kvalitet endast till viss del regelstyras genom exempelvis olika sätt att mäta eller beräkna. Metoder och beräkningssätt räcker alltså inte för att värdera kvalitet.
För att uppnå hög kvalitet räcker det enligt våra systemutvecklare inte att uppnå det som kunden har satt upp som krav på systemet eller programmet. Hög kvalitet blir det om kunden får något som är bättre än han eller hon har förväntat sig. För att nå hög kvalitet måste systemutvecklare ha en erfarenhet av och fingertoppskänsla för vad som kan ge hög kvalitet. För att kunna göra bedömningar kan regler och normer fungera som en grund, men när erfarenheten kräver det måste man bryta mot dem.
Förmågan att bedöma kvalitet utvecklas främst genom den personliga erfarenheten från olika projekt, kunder, användare o.s.v. Viktiga för att bygga upp denna erfarenhet är de åsikter som kommer från kunder och användare. Främst handlar det om negativa åsikter om saker och ting som inte fungerar som det är tänkt, mer sällan handlar det om beröm. Att systemutvecklarna talar med varandra om erfarenheter och åsikter är också viktigt för att bygga upp erfarenhet.
Om systemutvecklarna anser att erfarenheten är det viktigaste när det gäller kvalitet, kan man tänka sig att det skulle vara viktigt för dem att reflektera över vad kvalitet är, vad ordet betyder, vad som är hög eller låg kvalitet o.s.v. för att bli bättre på kvalitet och öka kunskapen. En sådan reflektion förekom dock i liten utsträckning, dels på grund av att systemutvecklarna inte hade tid avsatt för detta i arbetet, dels för att de var fokuserade på att lösa problem och rätta fel, dels för att de i allmänhet var omedvetna om att detta skulle kunna vara viktigt.
För att utveckla sin kunskap och sitt kunnande om kvalitet är det viktigt, utgår vi ifrån, att systemutvecklare talar med varandra om kvalitet och uppfattningar. Systemutvecklarna för samtal med varandra och anser att dem vara viktiga, men de mesta av samtalen handlar om aktuella projekt som de deltar i och sällan om att öka varandras kunskap i allmänhet. Detta kan bero på att systemutvecklarna upplever att de inte har ett speciellt bra språk eller bra begrepp för att tala om kvalitet och värdering och att de därför använder ett ganska knapphändigt vardagsspråk som det är svårt att vara precis med. Användandet av exempel, liknelser m.m. var ovanligt hos våra systemutvecklare, i alla fall med syftet att mer allmänt diskutera kvalitet, värdering o.s.v. för att förbättra kunskapen om kvalitet och förmågan att bedöma kvalitet.
Systemutvecklares bedömningsförmåga var också intresset i projekten "IT-designkvalitet - paradigmatisk form och funktion" och "Kvaliteket", som vi deltog i när vi blev forskarstuderande. Dessa projekt leddes av professor Pelle Ehn och pågick mellan 1993 och 1997. Grundtanken i båda projekten var att brukskvaliteten var låg på grund av systemutvecklares bristande bedömningsförmåga och att de för att förbättra den behöver goda förebilder i form av stilar för system och utvecklare att jämföra sig med snarare än ytterligare utvecklingsmetoder. Vi i projekten fann därför att det var mer fruktbart att tänka på brukskvaliteten på produkterna, alltså systemen och programmen, än på sättet de utvecklas. Brukskvalitet uppfattades förenklat som att system skall vara bra byggda, vara väl anpassade till användares behov och ge en god upplevelse och känsla vid användning, d.v.s. bruk. En annan utgångspunkt var att systemutvecklare till viss del redan har förebilder och kunskaper som inte ryms i utvecklingsmetoder.
I projektet Kvaliteket utvecklade projektgruppen en speciell och allmänt tillgänglig webbplats, där man kunde finna beskrivningar av system ur de tre perspektiven på brukskvalitet, d.v.s. byggkvalitet, behovsrelevans och upplevelsekvalitet. En debattdel ingick också i Kvaliteket och där skulle enskilda beskrivningar och kvalitet i allmänhet debatteras. Det fanns även en namnkunnig jury som skulle bedöma kvaliteten på beskrivningarna och ge pris till de bästa, för att åstadkomma goda förebilder. På så vis ville vi i projektet skapa en mötesplats där goda förebilder skulle uppstå och användas för jämförelse och diskussion. Framgången uteblev dock och det är ett av skälen till att vi har skrivit den här avhandlingen.
Ett annat skäl är att vi, Odd och Theis, såg ett problem med projektens kvalitetsmodeller - begreppet brukare var dåligt utrett. En viss aspekt av brukskvalitet, nämligen byggkvalitet, betraktades i modellerna som värderingsfri och fri från användningens sammanhang. Detta håller vi inte med om, eftersom även t.ex. de som bygger om och bygger ut system kan ses som någon form av användare. Vi har funnit att för dem är inte byggkvalitet något objektivt eller värderingsfritt. Även projektens modeller och begreppet stil var besvärliga precis som kvalitetsbegrepp och kvalitetsdefinitioner är det. Modellerna uttrycker inte den praktiska kunskap som krävts för att utforma dem och ger därför dålig vägledning om man inte själv har rätt kunskap för att tolka dem.
Arbetet med stilarter blev besvärligt i och med att detta begrepp har många betydelser. Projektgruppen hade svårt att finna ett bra sätt att ordna en stilapparat, eftersom det var svårt att veta om ett visst system eller program gav upphov till en stil eller om det var resultatet av en befintlig stil - en hönan-eller-ägget situation. Att stilarna dessutom skulle vara allmängiltiga, samtidigt som modellerna betonade sammanhanget som systemen och programmen användes i, gjorde det än mer besvärligt.
Vi har i denna avhandling haft liknande utgångspunkter som de ovan diskuterade projektens. Men vi har istället för att konstatera att systemutvecklare har bristande kunskap om och förmåga att bedöma kvalitet, ställt oss frågan hur deras kunskap och kunnande ser ut. Det vi kommer fram till är att kvalitet långt ifrån är någon värderingsfri egenskap och att det i och för sig går att definiera kvalitet, men att definitionerna endast kan användas för att rikta uppmärksamheten. Den kunskap som krävs för att åstadkomma en definition finns inte med i själva definitionen och därför kan en definition inte ersätta kunskap och kunnande om kvalitet. Innebörden i kvalitet är också beroende av ett sammanhang av arbetsuppgifter, omvärldens utseende och teknikens möjligheter. Dessa faktorer förändras ständigt och därför förändras också kvalitetsbegreppets innebörd kontinuerligt.
Det är alltid så att värdering av kvalitet sker av någon intressent, t.ex. en systemutvecklare, utifrån ett perspektiv. Eftersom det är en fråga om värdering, fungerar inte kriterier som är oberoende av någons uppfattning eller som inte tar hänsyn till det sammanhang som systemet eller programmet ingår i. Därmed kan olika kvaliteter, eller egenskaper, vara olika viktiga för olika personer och projekt, och kvalitet blir därför alltid en kompromiss mellan intressenter med olika perspektiv.
Att kvalitet fungerar på detta sätt leder till att bedömning av kvalitet till avgörande grad bygger på personlig erfarenhet. Metoder, sätt att mäta, standarder m.fl. reglerande inslag är endast stöd för erfarenheten, inte ersättningar. Det mesta av systemutvecklares kunskap om kvalitet bygger också på erfarenhet, d.v.s. tyst fungerande färdighet och förtrogenhet, som är den viktigaste delen i bedömningsförmågan. Detta kommer inte fram i teorierna om IT-kvalitet.
Eftersom erfarenhet är så viktigt är det förvånande att systemutvecklare resonerar och talar så lite om kvalitet med varandra, i alla fall med det direkta syftet att öka sin kunskap och förbättra sitt kunnande om kvalitet. Dels beror detta på att de inte får den tid de behöver för att reflektera, dels beror det på att de saknar ett bra direkt och indirekt språk med begrepp, termer, exempel och metaforer. Som framgår av teorin om kunskap och kunnande behöver man använda indirekta medel, såsom exempel och liknelser, för att kunna uttrycka den så kallade tysta kunskapen, den som är svår att fånga i ord. Det framgår också av teorin att kunskapen behöver reflekteras över och uttryckas för att kunna utvecklas.
De slutsatser vi drar om IT-kvalitet i praxis är att begrepp och definitioner kan peka på viktiga aspekter att tänka på, men att kvalitet alltid är någons värdering ur vissa perspektiv. Vi kan alltså inte göra en bra definition av IT-kvalitet, men vi kan definiera fenomenet IT-kvalitet. Det är ett antal begrepp och värden sedda ur intressenters perspektiv och bedömda i det sammanhang som systemet eller programmet utvecklas, underhålls och används i. Det innebär att kvalitetsegenskaper, som delvis kan uttryckas genom begrepp och definitioner, väljs av intressenter för vissa sammanhang och att intressenternas bedömningar av kvaliteten sker i relation till dessa sammanhang och alltid innebär värdering. Begreppen och definitionerna är inte entydiga och uttömmande och måste inte ingå som element i en bedömning av kvalitet. De värden de representerar varierar över tiden genom att nya tillkommer och att gamla kanske försvinner, beroende på att intressenter och sammanhang utvecklas, förändras och tillkommer. Relationerna mellan aspekterna skall inte tolkas som absoluta och enkla, vilket vi har visat i den här avhandlingen.
Alla har vi väl någon gång varit med om att datorer, dataprogram och datasystem inte fungerar som vi har tänkt oss. Inte sällan inträffar det fel och konstigheter som kan vara frustrerande och, i värsta fall, direkt farliga. Många gånger undrar man hur ett visst program eller system skall användas och hur de som har designat och byggt det har tänkt och resonerat.
I stort handlar detta om kvalitet eller ännu hellre olika kvaliteter, d.v.s. egenskaper hos produkter som påverkar upplevelsen av att använda dem, hur lätta de är att förstå och lära sig att använda, vilken nytta man kan ha av dem, möjligheten att förändra dem till nya krav som omgivningen ställer och möjligheten för dem som har utvecklat dem att själva förstå hur de fungerar och kan anpassas. Att ITs genomslag i samhället dessutom ökar och berör allt fler människor och verksamheter och därmed har en stor påverkan på många människors vardag, gör det relevant att studera kvalitet på den alltmer omfattande och närvarande informationstekniken (IT) som datasystem och dataprogram är en del av.
Kvalitet har också blivit ett sorts slagord och närmast ett krav för olika verksamheter för att kunna konkurrera på marknaden. I en allt större utsträckning talas det om och efterfrågas olika satsningar för kvalitetsarbete, exempelvis ISO-9000 certifieringar, för att garantera kvalitet och trovärdighet. Detta gäller också inom den bransch och de verksamheter som tillverkar mjukvara, d.v.s. datasystem och dataprogram. Det handlar då om en del av det totala området kvalitet som kallas IT-kvalitet, d.v.s. kvalitet på informationsteknik.
Det finns alltså goda skäl att intressera sig för och studera systemutvecklares kunskap om och syn på IT-kvalitet.
Anledningen till att vi, Odd och Theis, intresserar oss för systemutvecklares perspektiv, hänger ihop med att bland andra Mitchell Kapor (1996), som var en av grundarna till Lotus Corporation och en av huvudmännen bakom det en gång mycket framgångsrika kalkylprogrammet Lotus 1-2-3, har riktat kritik mot systemutvecklares förmåga att designa goda och användbara produkter. Mitchell Kapor efterlyser nya arbetssätt och en bättre förmåga att skapa god kvalitet för användarna.
Frågor om arbetssätt och förmåga leder också till ett intresse för systemutvecklare som yrkesmänniskor. Hur en systemutvecklare tänker och arbetar är, bortsett från studier av Erik Stolterman (1991) och Christer Hoberg (1998), dock dåligt belyst.
Kopplas detta till att kvalitet blir allt mer viktigt, samtidigt som kritik riktas mot systemutvecklares förmåga att uppnå god kvalitet, uppstår ett intressant område att studera. Detta område är IT-kvalitet som begrepp och systemutvecklares kunnande om och syn på kvalitet. Kvalitet som begrepp är väl bearbetat inom delar av vårt område, däremot finns det mycket lite skrivet om systemutvecklare som yrkesutövare.
Kvaliteten på system och program blev redan tidigt i ITs historia ett problem, eftersom den tidens teknik krävde att man ägnade all uppmärksamhet åt att utnyttja datorernas mycket låga prestanda på bästa sätt. System och program skrevs med effektivitet som ledstjärna, viket ledde till att snabba och resurssnåla men kryptiska program skapades.
När de som använde dessa enkla system och program, i huvudsak tekniker och vetenskapsmän inom USA försvarsmakt, var de samma som byggt dem, var det egentligen inga större problem. I takt med teknikens utveckling och spridning till andra verksamheter i samhället, och andra typer av användare, började emellertid mängden programvara och komplexiteten i dem att öka och därmed ökade också behoven att kunna förstå dem för att rätta de fel som alltid finns i program. En marknad för programvara uppstod också och den översvämmades med dåligt byggda program. Så småningom var situationen så besvärlig att en mjukvarukris uppstod under 1960-talet och ett eget ämne, Software Engineering, skapades för att forska fram arbetssätt och teorier för att åstadkomma mjukvara som lättare kunde rättas och anpassas. Målet var att skapa objektiva och matematiskt grundade utvecklingsmodeller, som skulle anammas av den växande mjukvaruindustrin. Dessa ansatser lyckades inte helt, men gav ändå upphov till en bättre förståelse för god teknisk uppbyggnad av mjukvara.
Den tekniska kvaliteten på mjukvara förbättrades så sakteliga, men nya bekymmer uppstod. Även om mjukvaran är tekniskt perfekt hjälper det inte mycket om användarna av systemen och programmen inte förstår hur de kan användas och har svårt att lära sig dem. Inte heller hjälper teknisk perfektion mycket om mjukvaran inte stödjer de arbetsuppgifter som användarna utför. Man insåg därför efterhand att kvalitet på mjukvara inte bara handlar om rent tekniska egenskaper, utan att kvalitet lika mycket är en fråga om användbarhet. Därmed uppstod ett nytt område, Människa-Dator Interaktion (MDI), för att studera detta vetenskapligt och praktiskt.
Även inom MDI var man till en början intresserad av objektiva metoder och teorier som skulle vara allmängiltiga för alla människor. Människan sågs som ett sorts biologiskt maskineri som mjukvaran kunde anpassas till. Detta begränsade synsätt på människan kritiserades dock dels för att det utesluter den verkliga arbetssituation som de tänkta användarna befinner sig i, dels för att det inte tar med sociala och mänskliga perspektiv på arbete. MDI-området utvecklades därför i en mängd olika riktningar och är numera ett tämligen omfattande ämnesområde.
Software Engineering och MDI har på var sitt sätt bidragit till mycket av förståelsen för IT-kvalitet och hur man kan uppnå god kvalitet. De har också bidragit med en mängd definitioner och kvalitetsbegrepp som kan fästa uppmärksamheten på viktiga egenskaper.
Systemutvecklares kunskap om och syn på IT-kvalitet behandlas däremot inte i den teori om kvalitet som vi har studerat. De enda vi har funnit som har undersökt det här är David Wilson och Tracy Hall (1998), som visar att synen på kvalitet varierar kraftigt mellan olika systemutvecklare och deras chefer.
Vi väljer att se IT-kvalitet som en kunskapsfråga och för att göra detta har vi utgått från, förutom teorierna om kvalitet, Kjell S. Johannessens (1999) tolkning av Wittgensteins senfilosofi och Bertil Rolfs (1995) tolkning av Polanyis teorier om praktisk kunskap. I korthet handlar detta om att det finns kunskaper som visar sig när man utför en handling. Under lång tid i det västerländska samhället har äkta och sann kunskap endast varit sådan som kan formuleras i logiskt klara satser och regler. Viss kunskap låter sig dock inte fångas på detta sätt, exempelvis moralisk kunskap. Det är också så att det krävs kunskap för att formulera en logisk regel, men den kunskapen framgår inte av själva regeln. Det måste alltså finnas andra kunskaper än de som klart och koncist kan formuleras.
Kjell S. Johannessens använder begreppen påstående-, färdighets- och förtrogenhetskunskap för att tala om olika sorters kunskaper. Påståendekunskap är kunskap som kan formuleras och uttryckas verbalt. Färdighetskunskap däremot visar sig i handling; det är i handlandet man kan se kunskapen. För att kunna handla, och därmed uppvisa färdighetskunskap, måste man vara bekant med en mängd situationer som möjliggör handlingen. Man måste alltså också ha förtrogenhetskunskap och även den är mycket svår att uttrycka verbalt. Det begrepp som har kommit att beteckna denna typ av kunskaper är tyst kunskap. För att ändå kunna kommunicera den tysta kunskapen måste man förlita sig på indirekta medel som exempel och liknelser.
Även Bertil Rolf behandlar praktisk och tyst kunskap. Skillnaden är utgångspunkten att den tysta kunskapen fungerar tyst, snarare än att den inte är möjlig att uttrycka verbalt. Det handlar alltså mera om en sorts kunskap som vi utnyttjar i bakgrunden när vi utför våra handlingar. Viss kunskap kanske aldrig kan uttryckas verbalt, men vilken kunskap det är kan vi inte peka ut.
Enligt Bertil Rolf har man praktisk kunskap om man kan utföra en handling väl enligt vissa regler eller kriterier som skiljer en illa utförd handling från en väl utförd och om reglerna eller kriterierna fungerar tyst. Att ha praktisk kunskap handlar alltså om att kunna utföra handlingar med god kvalitet i förhållande till olika kriterier. Om den som har praktisk kunskap skall vara kompetent innebär det dessutom i korthet att kriterierna är förankrade hos andra utövare som avgör kvaliteten på ens handling, att kriterierna på något sätt kan uttryckas och reflekteras över, samt att utövaren kan påverka kvalitetskriterierna för att förbättra dem. Endast då kan man tala om kompetens enligt detta synsätt.
Kompetens kan med andra ord aldrig endast handla om att följa regler. Dels krävs det erfarenhet för att förstå reglerna, dels måste reglerna kunna förändras till det bättre. Därför är reflektion och olika sätt att uttrycka kunskap avgörande för att den skall kunna utvecklas tillsammans med andra. Det gäller då att fokusera på tysta kunskap och uttrycka den så att olika personers erfarenheter kan spridas och diskuteras. Den egna erfarenheten kan dock inte ersättas, eftersom den behövs för att förstå regelsystemet som man försöker förbättra. Detta är våra teoretiska utgångspunkter - IT-kvalitet samt kunskap, kunnande och kompetens. I vår empiriska undersökning av systemutvecklares kunskap om och syn på kvalitet ställer vi bland annat följande frågor: Vilka begrepp använder de för att tala om kvalitet? Vilka betydelser lägger de i begreppet kvalitet? När talar de om kvalitet och hur? Hur bedömer de kvalitet? Är erfarenhet viktigt för att kunna bedöma kvalitet? Är erfarenhetsutbyte viktigt för att utveckla den praktiska kunskapen om kvalitet? Dessa frågor hänger ihop med vår vilja att se systemutveckling som en praxis, d.v.s. ett yrkesmässigt sammanhang med regler och kriterier för bedömning och praktisk kunskap. Att tala om begrepp och definitioner innebär att tala om kunskap som kan uttryckas verbalt, d.v.s. påståendekunskap. Vi vill även försöka förstå den praktiska kunskapen i form av färdighet och förtrogenhet, eller personlig praktisk kunskap för att använda Bertil Rolfs begrepp. Förmågan att bedöma kvalitet, erfarenhetens och reflektionens betydelse, samt erfarenhetsutbyte är då intressanta att studera, eftersom de är uttryck för praktisk kunskap och kompetens.
För att få svar på dessa frågor genomförde vi 19 djupintervjuer med systemutvecklare, programmerare, projektledare och funktionsdesigners. Dessa intervjuer genomfördes under perioden december 1998 till juni 1999 på tre olika företag, varav ett var ett konsultföretag och de två andra interna IT-avdelningar. Alla intervjuerna spelades in på band och skrevs ut ordagrant.
När det var gjort analyserade vi materialet med ett kodningsramverk byggt på Johannessens tre kunskapsformer och gjorde sedan tolkande sammanfattningar av intervjuerna. För att presentera resultaten skrev vi ett fiktivt samtal mellan tre personer. Projektledaren och systemutvecklaren Eva, hennes man Adam, som är programmerare och systemutvecklare, och Lars, som fungerar som samtalsledare, för ett samtal om vad kvalitet betyder, hur viktig den är, hur den bedöms, hur förmågan att bedöma den utvecklas och hur man kan tala om en bedömning av kvalitet med andra systemutvecklare.
Det vi kommer fram till när vi analyserar systemutvecklarnas förståelse för och kunskap om begreppet kvalitet, är att kvalitet alltid är en fråga om någons uppfattning och att kvalitet inte helt och hållet kan regelstyras, t.ex. genom standarder, mätmetoder och utvecklingsmetoder.
Kvalitetsbegreppet är också komplext och inrymmer många olika egenskaper som tillsammans utgör innebörden av kvalitet. Eftersom det är ett svårt och sammansatt begrepp, kan systemutvecklarna inte ge en allmän definition som slår fast vad kvalitet faktiskt är.
Bedömningen av kvaliteten på system och program sker genom att någon gör en värdering och jämför detta med vad man anser vara bra eller tillräckligt. Sällan handlar värderingen om att mäta eller beräkna. Därför vilar förmågan att bedöma kvalitet i viktiga avseenden på den personliga erfarenheten och därmed kan värdering av kvalitet endast till viss del regelstyras genom exempelvis olika sätt att mäta eller beräkna. Metoder och beräkningssätt räcker alltså inte för att värdera kvalitet.
För att uppnå hög kvalitet räcker det enligt våra systemutvecklare inte att uppnå det som kunden har satt upp som krav på systemet eller programmet. Hög kvalitet blir det om kunden får något som är bättre än han eller hon har förväntat sig. För att nå hög kvalitet måste systemutvecklare ha en erfarenhet av och fingertoppskänsla för vad som kan ge hög kvalitet. För att kunna göra bedömningar kan regler och normer fungera som en grund, men när erfarenheten kräver det måste man bryta mot dem.
Förmågan att bedöma kvalitet utvecklas främst genom den personliga erfarenheten från olika projekt, kunder, användare o.s.v. Viktiga för att bygga upp denna erfarenhet är de åsikter som kommer från kunder och användare. Främst handlar det om negativa åsikter om saker och ting som inte fungerar som det är tänkt, mer sällan handlar det om beröm. Att systemutvecklarna talar med varandra om erfarenheter och åsikter är också viktigt för att bygga upp erfarenhet.
Om systemutvecklarna anser att erfarenheten är det viktigaste när det gäller kvalitet, kan man tänka sig att det skulle vara viktigt för dem att reflektera över vad kvalitet är, vad ordet betyder, vad som är hög eller låg kvalitet o.s.v. för att bli bättre på kvalitet och öka kunskapen. En sådan reflektion förekom dock i liten utsträckning, dels på grund av att systemutvecklarna inte hade tid avsatt för detta i arbetet, dels för att de var fokuserade på att lösa problem och rätta fel, dels för att de i allmänhet var omedvetna om att detta skulle kunna vara viktigt.
För att utveckla sin kunskap och sitt kunnande om kvalitet är det viktigt, utgår vi ifrån, att systemutvecklare talar med varandra om kvalitet och uppfattningar. Systemutvecklarna för samtal med varandra och anser att dem vara viktiga, men de mesta av samtalen handlar om aktuella projekt som de deltar i och sällan om att öka varandras kunskap i allmänhet. Detta kan bero på att systemutvecklarna upplever att de inte har ett speciellt bra språk eller bra begrepp för att tala om kvalitet och värdering och att de därför använder ett ganska knapphändigt vardagsspråk som det är svårt att vara precis med. Användandet av exempel, liknelser m.m. var ovanligt hos våra systemutvecklare, i alla fall med syftet att mer allmänt diskutera kvalitet, värdering o.s.v. för att förbättra kunskapen om kvalitet och förmågan att bedöma kvalitet.
Systemutvecklares bedömningsförmåga var också intresset i projekten "IT-designkvalitet - paradigmatisk form och funktion" och "Kvaliteket", som vi deltog i när vi blev forskarstuderande. Dessa projekt leddes av professor Pelle Ehn och pågick mellan 1993 och 1997. Grundtanken i båda projekten var att brukskvaliteten var låg på grund av systemutvecklares bristande bedömningsförmåga och att de för att förbättra den behöver goda förebilder i form av stilar för system och utvecklare att jämföra sig med snarare än ytterligare utvecklingsmetoder. Vi i projekten fann därför att det var mer fruktbart att tänka på brukskvaliteten på produkterna, alltså systemen och programmen, än på sättet de utvecklas. Brukskvalitet uppfattades förenklat som att system skall vara bra byggda, vara väl anpassade till användares behov och ge en god upplevelse och känsla vid användning, d.v.s. bruk. En annan utgångspunkt var att systemutvecklare till viss del redan har förebilder och kunskaper som inte ryms i utvecklingsmetoder.
I projektet Kvaliteket utvecklade projektgruppen en speciell och allmänt tillgänglig webbplats, där man kunde finna beskrivningar av system ur de tre perspektiven på brukskvalitet, d.v.s. byggkvalitet, behovsrelevans och upplevelsekvalitet. En debattdel ingick också i Kvaliteket och där skulle enskilda beskrivningar och kvalitet i allmänhet debatteras. Det fanns även en namnkunnig jury som skulle bedöma kvaliteten på beskrivningarna och ge pris till de bästa, för att åstadkomma goda förebilder. På så vis ville vi i projektet skapa en mötesplats där goda förebilder skulle uppstå och användas för jämförelse och diskussion. Framgången uteblev dock och det är ett av skälen till att vi har skrivit den här avhandlingen.
Ett annat skäl är att vi, Odd och Theis, såg ett problem med projektens kvalitetsmodeller - begreppet brukare var dåligt utrett. En viss aspekt av brukskvalitet, nämligen byggkvalitet, betraktades i modellerna som värderingsfri och fri från användningens sammanhang. Detta håller vi inte med om, eftersom även t.ex. de som bygger om och bygger ut system kan ses som någon form av användare. Vi har funnit att för dem är inte byggkvalitet något objektivt eller värderingsfritt. Även projektens modeller och begreppet stil var besvärliga precis som kvalitetsbegrepp och kvalitetsdefinitioner är det. Modellerna uttrycker inte den praktiska kunskap som krävts för att utforma dem och ger därför dålig vägledning om man inte själv har rätt kunskap för att tolka dem.
Arbetet med stilarter blev besvärligt i och med att detta begrepp har många betydelser. Projektgruppen hade svårt att finna ett bra sätt att ordna en stilapparat, eftersom det var svårt att veta om ett visst system eller program gav upphov till en stil eller om det var resultatet av en befintlig stil - en hönan-eller-ägget situation. Att stilarna dessutom skulle vara allmängiltiga, samtidigt som modellerna betonade sammanhanget som systemen och programmen användes i, gjorde det än mer besvärligt.
Vi har i denna avhandling haft liknande utgångspunkter som de ovan diskuterade projektens. Men vi har istället för att konstatera att systemutvecklare har bristande kunskap om och förmåga att bedöma kvalitet, ställt oss frågan hur deras kunskap och kunnande ser ut. Det vi kommer fram till är att kvalitet långt ifrån är någon värderingsfri egenskap och att det i och för sig går att definiera kvalitet, men att definitionerna endast kan användas för att rikta uppmärksamheten. Den kunskap som krävs för att åstadkomma en definition finns inte med i själva definitionen och därför kan en definition inte ersätta kunskap och kunnande om kvalitet. Innebörden i kvalitet är också beroende av ett sammanhang av arbetsuppgifter, omvärldens utseende och teknikens möjligheter. Dessa faktorer förändras ständigt och därför förändras också kvalitetsbegreppets innebörd kontinuerligt.
Det är alltid så att värdering av kvalitet sker av någon intressent, t.ex. en systemutvecklare, utifrån ett perspektiv. Eftersom det är en fråga om värdering, fungerar inte kriterier som är oberoende av någons uppfattning eller som inte tar hänsyn till det sammanhang som systemet eller programmet ingår i. Därmed kan olika kvaliteter, eller egenskaper, vara olika viktiga för olika personer och projekt, och kvalitet blir därför alltid en kompromiss mellan intressenter med olika perspektiv.
Att kvalitet fungerar på detta sätt leder till att bedömning av kvalitet till avgörande grad bygger på personlig erfarenhet. Metoder, sätt att mäta, standarder m.fl. reglerande inslag är endast stöd för erfarenheten, inte ersättningar. Det mesta av systemutvecklares kunskap om kvalitet bygger också på erfarenhet, d.v.s. tyst fungerande färdighet och förtrogenhet, som är den viktigaste delen i bedömningsförmågan. Detta kommer inte fram i teorierna om IT-kvalitet.
Eftersom erfarenhet är så viktigt är det förvånande att systemutvecklare resonerar och talar så lite om kvalitet med varandra, i alla fall med det direkta syftet att öka sin kunskap och förbättra sitt kunnande om kvalitet. Dels beror detta på att de inte får den tid de behöver för att reflektera, dels beror det på att de saknar ett bra direkt och indirekt språk med begrepp, termer, exempel och metaforer. Som framgår av teorin om kunskap och kunnande behöver man använda indirekta medel, såsom exempel och liknelser, för att kunna uttrycka den så kallade tysta kunskapen, den som är svår att fånga i ord. Det framgår också av teorin att kunskapen behöver reflekteras över och uttryckas för att kunna utvecklas.
De slutsatser vi drar om IT-kvalitet i praxis är att begrepp och definitioner kan peka på viktiga aspekter att tänka på, men att kvalitet alltid är någons värdering ur vissa perspektiv. Vi kan alltså inte göra en bra definition av IT-kvalitet, men vi kan definiera fenomenet IT-kvalitet. Det är ett antal begrepp och värden sedda ur intressenters perspektiv och bedömda i det sammanhang som systemet eller programmet utvecklas, underhålls och används i. Det innebär att kvalitetsegenskaper, som delvis kan uttryckas genom begrepp och definitioner, väljs av intressenter för vissa sammanhang och att intressenternas bedömningar av kvaliteten sker i relation till dessa sammanhang och alltid innebär värdering. Begreppen och definitionerna är inte entydiga och uttömmande och måste inte ingå som element i en bedömning av kvalitet. De värden de representerar varierar över tiden genom att nya tillkommer och att gamla kanske försvinner, beroende på att intressenter och sammanhang utvecklas, förändras och tillkommer. Relationerna mellan aspekterna skall inte tolkas som absoluta och enkla, vilket vi har visat i den här avhandlingen.
Avdelning/ar
Publiceringsår
2002
Språk
Svenska
Publikation/Tidskrift/Serie
Lund Studies in Informatics
Volym
1
Fulltext
Dokumenttyp
Doktorsavhandling
Förlag
Department of Informatics, Lund University
Ämne
- Information Systems, Social aspects
Nyckelord
- Informatics
- judgement ability
- IT quality assessment
- IT artefact
- IT quality
- knowledge in practice
- systems theory
- Informatik
- systemteori
Status
Published
Handledare
- [unknown] [unknown]
ISBN/ISSN/Övrigt
- ISSN: 1651-1816
- ISBN: 91-628-5277-9
Försvarsdatum
6 juni 2002
Försvarstid
10:15
Försvarsplats
Ekonomicentrum II, Lund
Opponent
- Erik Stolterman