Prototyper i systemutveckling Agila och traditionella angreppssätt

Transkript

1 ISRN-nr: LIU-IEI-FIL-G--08/ SE Prototyper i systemutveckling Agila och traditionella angreppssätt Prototyping in Systems Development Agile and Traditional approaches Anders Nawroth Höstterminen 2008 Handledare: Tommy Wedlund Systemvetenskapliga programmet Institutionen för ekonomisk och industriell utveckling

2 Prototyper i systemutveckling agila och traditionella angreppssätt Linköpings universitet Institutionen för ekonomisk och industriell utveckling (IEI) kandidatuppsats Anders Nawroth andna041@student.liu.se Handledare: Tommy Wedlund

3 Tack Ett varmt tack riktas till samtliga intervjupersoner för att de tog sig tid att medverka i denna studie. Tack till Tommy Wedlund för återkoppling och stöd och till Hans Holmgren för litteraturtips och idéutbyte.

4 Sammanfattning Syftet med studien är att undersöka prototyper i samband med systemutveckling, och då särskilt om agila utvecklingsmetoder har påverkat hur prototypning används. En genomgång av begreppet prototyp och närliggande begrepp görs för att klargöra vad som kan avses med prototyper inom systemutveckling. En översikt över olika synsätt på prototyper och deras användning presenteras, och leder vidare till en teoretisk modell för prototyper i systemutveckling. Systemutvecklare och experter intervjuas för att bringa klarhet i begreppen och ta reda på hur prototyper används i systemutvecklingsprojekt i praktiken. Utifrån detta material presenteras en vidareutveckling av den första teoretiska modellen. Problemrymd och lösningsrymd hör till modellens centrala begrepp. Studien visar att agila utvecklingsmetoder påverkar arbetet med prototyper i riktning mot att utföra prototypning i det ordinarie utvecklingsspåret samt att hämta in regelbunden återkoppling på prototyper från användare och andra intressenter under hela systemutvecklingsprojektets gång. Sådana arbetssätt visade sig också förekomma inom den praktiska systemutvecklingen.

5

6 Innehåll 1 Inledning Bakgrund Syfte Intresseområde Frågeställningar Avgränsning Målgrupp Referenshantering Disposition Metod Inledande anmärkning Förförståelse Kunskapsläge Kunskapsbehov Kunskapskarakterisering Kunskapsstrategi Metodval Reliabilitet och validitet Metodkritik Teori Begrepp Prototyp Systemutveckling Design och designer Programmering Problemlösning Prototyper och prototypning Användningssätt «Slit och släng» kontra evolutionär prototypning Presentationsprototyper: lo-fi och hi-fi Horisontella och vertikala prototyper Utforskande och experimentella prototyper Funktioner, gränssnitt och implementation...21

7 3.3 Systemutvecklingsmodeller Vattenfallsmodellen Agil utveckling Användarcentrerad systemdesign Att förstå systemutveckling Peter Naur Pelle Ehn Systemutveckling och prototyper Prototypning i verksamhetsutveckling Agila prototyper Prototypernas roll En sammanfattande modell Motivering av modellen Preliminär begreppsmodell för prototypning Empiri Upplägg för intervjuerna Preliminär teoretisk modell Intervjuernas ställning i uppsatsen Urval av intervjupersoner Praktiskt genomförande Återgivningen av intervjuerna Intervjuer Intervju med Lars Degerstedt Intervju med Arne Jönsson Intervju med T. Nilsson och A. Larsson Intervju med Mårten Herberthson Intervju med Tomas Volavka Intervju med Bo Olls Intervju med Karl-Göran Andersson Intervju med Michael Garrido Intervju med Peter Grew Sammanfattning av empiri Sammanfattning av intervjuer inriktade på teori Sammanfattning av intervjuer inriktade på praktisk systemutveckling

8 4.3.3 Sammanfattning av intervju kring konstprojekt i offentliga miljöer Analys och diskussion Prototypbegreppet och systemutvecklingsprocessen Begreppet prototyp i teori och praktik Vidareutveckling av den teoretiska modellen Agil och traditionell systemutveckling Prototyper och systemutveckling i praktiken Resultat Gränsdragningar Råd för användning av prototyper i systemutveckling Konstprojekt jämfört med systemutveckling Slutsats Avslutning Begreppslista Källor Länktips...123

9 Tabeller Tabell 1: Kunskapsbehov och kunskapskaraktär...7 Tabell 2: Ram för systemutvecklingsprojekt Tabell 3: Skillnader mellan agil och traditionell systemutveckling Tabell 4: Sammanställning av resultat

10 Figurer och bilder Där inget annat anges rör det sig om egna figurer. Tillstånd att använda fotografier har inhämtats i förekommande fall. Figur 1. Avgränsning av vad denna uppsats behandlar Figur 2. Förhållandet mellan prototyp och utvecklare. (Schneider 1996, s. 523) Figur 3. En utvecklingsmodell för prototypning. (Andersen 1994, s. 412) Figur 4. Tre olika slags prototyper: vertikal, horisontell eller i form av ett scenario. (Figur efter Gulliksen & Göransson 2002, s. 245)...20 Figur 5. Tre olika dimensioner för prototyper: roll, utseende och beteende samt implementation. (Figur efter Houde & Hill 1997, s. 6) Figur 6. Livscykelmodellen. (Figur efter Andersen 1994, s. 48) Figur 7. Grundelementen i en iterativ användarcentrerad process. (Figur efter Gulliksen & Göransson 2002, s. 109) Figur 8. Relationen mellan systemutveckling och utvecklingen av verksamhetsprocesser i verkliga livet. (Figur efter Gulliksen & Göransson 2002, s. 299) Figur 9. Prototypning under hela verksamhetsutvecklingen för att tidigare kunna ta fram krav som är begripliga för användaren. (Figur efter Gulliksen & Göransson 2002, s. 300)...29 Figur 10. Tidig och kontinuerlig prototypning får produkten att «växa» till. (Figur efter Gulliksen & Göransson 2002, s. 301).. 30 Figur 11. Utkast till modell för prototyper i systemutveckling Figur 12. Preliminär modell för prototyper i systemutveckling Figur 13. Den andra iterationen av begreppsmodellen Figur 14. Den ursprungliga versionen av begreppsmodellen inklusive anteckningar under intervjun med Lars Degerstedt Figur 15. Den tredje iterationen av den teoretiska modellen

11 Figur 16. Den teoretiska modellen kompletterad med tre slags prototyper utifrån Houde & Hill (1997) Figur 17. Den teoretiska modellen med exempel på olika slags prototyper Figur 18. Den teoretiska modellen med tendenserna till dokument respektive aktivitet tillagda Figur 19. Den teoretiska modellen så långt den utvecklats i studien Bild 1. «Dubbelgångare» av konstnären Kent Karlsson. Foto: Bo Olls Bild 2. «Dubbelgångare» av konstnären Kent Karlsson. Foto: Bo Olls

12 1 Inledning Detta kapitel beskriver uppsatsens bakgrund, syfte och frågeställningar. 1.1 Bakgrund Under 1980-talet var prototypning ett område som drog mycket intresse till sig, och även framfördes som en övergripande modell för utveckling av mjukvara (se Bischofberger & Pomberger 1992). Sedan dess har mycket hänt, bland annat har agila utvecklingsmetoder börjat göra sig allt mer gällande (se Wiktorin 2003). Frågan uppstår hur detta påverkat prototypning. Från att datorer en gång var något som endast specialister använde, gick utvecklingen i den riktningen att allt fler kom i direktkontakt med dem. Till exempel innebar introduktionen av IBM PC 1981 ett viktigt steg (se Encyclopædia Britannica 2007) som stärkte utvecklingen i denna riktning. Denna utveckling förde med sig ett intresse för hur gränssnitt för människa-datorinteraktion kunde tas fram på ett bättre sätt. Ett sätt att angripa detta område är att använda prototyper för användargränssnitt. Det handlar också om vilka tekniska möjligheter som står till förfogande. Jag har själv varit med om webbens utveckling från primitiva möjligheter att utforma gränssnitt till dagens stora möjligheter. Som medlem i Web Standards Group vet jag också att prototyper för webbplatser och webbapplikationer är något som diskuteras livligt inom branschen. Närliggande områden är användarmedverkan och användbarhet, där prototyper spelar en viktig roll. Förarbetet till uppsatsen har utförts med stöd av kunskapsprojektering enligt Goldkuhls Kunskapande (1998). 1.2 Syfte Syftet med denna studie är att bidra till en ökad förståelse av prototyper och prototypning. Särskild vikt läggs vid prototypning sedd i 1

13 kontexten av systemutvecklingsprojekt, och hur prototypning eventuellt påverkats genom agila metoder. 1.3 Intresseområde Något jag är nyfiken på är hur man kan arbeta med prototyper på olika sätt i systemutveckling. Vilka perspektiv på prototyper finns det, och vad får de för konsekvenser i praktiken? Vad finns det för möjligheter och problem när man arbetar med prototyper utifrån olika angreppssätt? På senare år har något som kallas för lättviktsmetoder («Agile methodologies», se Wiktorin 2003) stigit fram som ett alternativ till mer traditionella sätt att arbeta med systemutveckling. Här undrar jag hur detta påverkat synen på prototyper. Innebär lättviktsmetoder ett annat sätt att tänka om och använda prototyper? Och hur ser det ut hos företag som sysslar med systemutveckling? Har man anammat dessa nya synsätt, eller arbetar man efter de traditionella metoderna på området? 1.4 Frågeställningar Vad innebär begreppet prototyp inom systemutveckling? Hur kan man relatera prototyper till systemutvecklingsprocessen? Skiljer sig synen på dessa frågor mellan traditonella och agila angreppssätt? Hur ser användningen av prototyper ut inom systemutveckling idag, har agila metoder fått ett genomslag där? 1.5 Avgränsning I samband med en prototyp finns det systemutvecklare som på något sätt har med prototypen att göra. De kan utveckla prototypen med hjälp av olika verktyg, samt följa en utvecklingsmodell i sitt utvecklingsarbete i stort. Detta utgör en sida av prototypens omgivning. Ofta finns en annan sida, med användare, beställare och övriga intressenter. Se figur 1 för en bild av detta, samt den avgränsning som gjorts i denna uppsats. Denna studie begränsar sig till att se på prototyper ur systemutvecklarens perspektiv. Att även bearbeta användarperspektivet utförligt 2

14 systemutvecklare verktyg utvecklingsmodell prototyp beställare övriga intressenter skulle ge en större bredd, men samtidigt ge ett minskat djup, och har därför valts bort. Jag kommer inte heller att gå in på andra intressenters upplevelser och erfarenheter av prototyper. Där finns till exempel personer med en beställarroll och andra leverantörer som man samarbetar med. Ytterligare ett område som lämnas utanför studien är det verktygsstöd för att tillverka prototyper som finns. 1.6 Målgrupp användare Figur 1. Avgränsning av vad denna uppsats behandlar. Målgruppen för detta arbete är personer med intresse för hur systemutveckling kan bedrivas på ett klokt sätt med stöd av prototyper och prototypning. De kan till exempel vara studenter i systemvetenskap eller blivande ingenjörer. Även personer som bidragit med kunskap och erfarenhet till studien kan ha intresse av att se sitt bidrag i det sammanhang som denna studie utgör. Kunskapen i studien baseras på publicerade forskningsresultat samt intervjuer med experter och praktiskt verksamma systemutvecklare. 3

15 1.7 Referenshantering Referenshanteringen följer i stort sett den «Guide till Harvardsystemet» som tillhandahålls av Högskolan i Borås (2007). För att underlätta när det finns flera referenser till resurser på en och samma webbplats har dessa grupperats i en lista i källförteckningen. Muntliga källor anges inom parentes direkt i texten istället för i fotnoter. 1.8 Disposition Uppsatsen är indelad i delar som följer på varandra i en logisk ordning: Inledning Metod Teori Empiri Analys och diskussion Slutsats Avslutning I slutet av teorikapitlet finns en teoretisk modell som sedan används som en preliminär utgångspunkt i genomförandet av empirin. Empirikapitlet innehåller utdrag ur de intervjuer som har genomförts, och avslutas med en sammanfattning av varje intervju. Studiens till stor del explorativa karaktär har lett till att intervjumaterialet är mångfasetterat och rikligt. För att kunna göra materialet rättvisa har relativt omfattande utdrag tagits med i rapporten. Man kan nöja sig med att läsa sammanfattningarna, men för den som vill ta del av en rikare bild finns utdragen direkt tillgängliga i rapporten. Före källförteckningen finns det en lista med några förklarade begrepp som läsaren kan ha nytta av. Samtliga källor finns med i en sammanhållen källförteckning. Utvalda länkar till webbplatser av relevans för studien finns sist i rapporten. 4

16 2 Metod Detta kapitel presenterar förförståelse, kunskapsbehov och de metodval som gjorts. Syftet är att man ska kunna förstå tanken med studiens upplägg. 2.1 Inledande anmärkning Uppsatsens metod har tagits fram med stöd i kunskapsprojektering som beskrivs av Goldkuhl (1998) i hans Kunskapande. Läsaren hänvisas till denna skrift när det gäller bakgrund till detta kapitel och de begrepp som används här. (Se även länktips, kapitel 10.) 2.2 Förförståelse Mina egna erfarenheter av prototypning kommer från webbområdet. Det har rört sig om snabba skisser på papper i en inledande fas samt att arbeta med en fungerande webbplats och förfina den tills kunden är nöjd. Det senare kan man välja att se som en körbar prototyp. Jag har även erfarenhet från olika kurser i det systemvetenskapliga programmet, där främst det stora systemutvecklingsprojektet under det första året samt kursen i handlingsbarhet under det tredje året innebar arbete med prototyper. Ett problem när man ger sig in i detta fält är vilka begrepp man ska arbeta med. Man kan tala om både prototyp som substantiv och prototypning som verb, och även mena olika saker med dessa begrepp. Mitt perspektiv blir här att inte lägga fast en «kanonisk» innebörd i begreppen, utan istället bearbeta dem tillsammans med olika personer för att snarare utforska begreppen och deras möjliga innebörder. Den bild av området som jag har med mig in i arbetet har två sidor. Prototyper framställs å ena sidan som en lösning på viktiga problem i systemutveckling, särskilt kommunikationen med slutanvändare och andra intressenter. Å andra sidan hävdar somliga att arbetssättet är förenat med stora problem, till exempel risk för missförstånd av olika slag. I en sådan situation blir det uppenbart hur viktigt det är med kunskap om området för att kunna dra nytta av fördelarna utan att råka ut för de fallgropar som existerar. 5

17 Man kan även betrakta prototyper som sådana, men jag har valt att se dem i samband med systemutveckling. Till grund för mina resonemang och mina metodval ligger synsättet att systemutveckling handlar om att arbeta med och hantera begrepp på olika nivåer. Dessa begrepp hämtas till exempel från it-systemets verksamhetskontext, från programutvecklingsmiljöns och programmeringsspråkens symboler samt systemutvecklingsmetodernas olika begrepp. 2.3 Kunskapsläge Den källa som kommer allra närmast området för min undersökning är boken Användarcentrerad systemdesign (Gulliksen & Göransson 2002). I den finns det material som jag kan bygga vidare på; inte minst ger den en god överblick över området. Boken Systemutveckling (Andersen 1994) har ett kapitel om prototypning som innehåller värdefull kunskap. Bland annat tar den upp begreppet prototypning i samband med experimentell systemutveckling. I sin bok The Object Primer (2004) lägger författaren Scott W. Ambler fram en lättviktsmetod för objektorienterad systemutveckling. Den har även några intressanta sidor om prototypning av användargränssnitt. Artikeln What do Prototypes Prototype? (Houde & Hill 1997) visar på ett sätt att kategorisera prototyper utifrån vilka aspekter av ett system eller en produkt som står i förgrunden. En magisteruppsats med titeln Tillämpning av prototyper i Rational Unified Process undersöker hur prototyper och RUP fungerar tillsammans (Leventis & Tomazic 2001). Den empiriska delen undersökte ett webbprojekt och slutsatsen blev att prototyputveckling inte påverkas av RUP, men att RUP använder prototyper som ett stöd i systemutvecklingsarbetet. Något vetenskapligt arbete kring prototyper i samband med agila utvecklingsmetoder har jag inte kunnat hitta. Därmed finns det en kunskapsmässig lucka att fylla på detta område. 6

18 2.4 Kunskapsbehov Hur relaterar viktiga begrepp som hör samman med prototyputveckling tillvarandra? Exempel på sådana begrepp är it-system, systemutveckling, prototyp, prototypning, användare, designer och utvecklare. Jag saknar en mer övergripande bild av detta, och vill göra ett försök att ta fram en sådan bild. Hur förhåller sig denna bild i sin tur till traditionella respektive lättviktsperspektiv på systemutveckling? Detta är en annan fråga som jag vill utforska. Var står man idag inom praktisk systemutveckling när man arbetar med prototyper? Vilka begrepp står i centrum, och hur tänker man kring prototypning? Målet med att utforska ovanstående är att kunna ge en hjälp till bättre förståelse av arbete med prototyper i systemutveckling, och i viss mån systemutveckling över huvud taget, eftersom centrala begrepp bearbetas Kunskapskarakterisering Tabell 1: Kunskapsbehov och kunskapskaraktär Kunskapsbehov Relation mellan begrepp Kunskapskaraktär Kategoriell och klassificerande kunskap Systemutvecklingsperspektiv Kategoriell och klassificerande kunskap Dagens systemutveckling Deskriptiv kunskap, förståelseinriktad kunskap Framtidens systemutveckling Normativ kunskap Studien har en tonvikt på att klargöra begreppen inom det studerade området, och att studera olika möjliga sätt som dessa begrepp kan relatera till varandra. Detta arbete förväntas leda fram till en strukturering av begreppens relationer så att en klassificering i kategorier blir möjlig utifrån olika dimensioner. Detta i sin tur ger möjlighet att beskriva och skapa förståelse för de studerade fenomenen. 7

19 Den normativa kunskap som studien syftar till handlar om hur prototyper och prototypning passar in i olika situationer under systemutveckling. 2.5 Kunskapsstrategi När det gäller begrepp och systemutvecklingsperspektiv är denna studie i första hand begreppsutvecklande och klassificerande. I undersökningen av systemutveckling i praktiken är den grundläggande kunskapsstrategin explorativ, med inslag av en komparativ strategi. De data som behandlas kommer i princip genomgående att vara av kvalitativ karaktär. Stor vikt läggs vid att utveckla förståelse, detta är särskilt viktigt då området är relativt okänt för mig, särskilt avseende den teoretiska och begreppsmässiga sidan. 2.6 Metodval Studiens inriktning med framträdande explorativa inslag gör att nyansrikedom och djup i data är viktiga. Därför faller valet på att genomföra ett antal semistandardiserade intervjuer med mycket låg grad av standardisering. Den standardisering som förekommer är att utgångspunkten för intervjuerna är ett antal begrepp, samt frågan hur dessa begrepp kan relateras till varandra (se även nedan). I övrigt genomförs intervjuerna på ett fritt sätt med tonvikt på dialogutvecklande frågor. (Se Lundahl & Skärvad 1999.) Till att börja med genomförs intervjuer med experter med relevant kompetens för frågeställningarna. Data från denna del av studien bearbetas sedan för att kunna användas i dels intervjuer med verksamma systemutvecklare, dels för att ge hållpunkter för analysen. Dessa intervjuer inriktas mer direkt på de begrepp jag kommit fram till att bearbeta, då jag särskilt är ute efter att få respons på dessa. I studiens andra fas genomförs intervjuer med praktiskt verksamma systemutvecklare. Intervjupersonerna väljs bland systemutvecklare som är verksamma inom olika typer av företag. De begrepp som jag särskilt valt att bearbeta kommer i dessa intervjuer att spela en mindre roll, så att det praktiska arbetssättet med prototyper kan stå mer i förgrunden, liksom de begrepp som intervjupersonerna själva väljer att använda. 8

20 Utöver intervjuer med personer inom it-sektorn görs även en intervju med en konstnär som har stor erfarenhet av offentlig utsmyckning i form av till exempel statyer på allmän plats. Detta för att undersöka processerna i samband med offentlig utsmyckning, och se om erfarenheter från detta område kan ge ytterligare infallsvinklar på temat prototyper i systemutveckling. Se kapitel för mer information om det praktiska genomförandet. 2.7 Reliabilitet och validitet En nackdel med att utföra undersökningen med hjälp av ett fåtal intervjuer är att man riskerar att tillfälligheter får en avgörande betydelse för utfallet, det vill säga en låg reliabilitet. Detta ska dock sättas i relation till undersökningens syfte. Det material som föreligger i studien lämpar sig inte för att uttala sig om frågor som hur stor andel av systemutvecklingsprojekt som använder agila arbetssätt i prototypning. Däremot ger upplägget goda förutsättningar att uttala sig om några förekommande arbetssätt. (Se Lundahl & Skärvad 1999.) En relativt fri intervjuform som insamlingsmetod innebär att intervjupersonerna kan ställa frågor tillbaka till intervjuaren vid oklarheter, och intervjuaren kan i sin tur ställa följdfrågor som klargör vad intervjupersonen avser med ett svar. Att ha ett längre samtal ger också möjlighet att lära känna intervjupersonen och skapa en samsyn kring de begrepp man använder i intervjusituationen. ( Jämför Lundahl & Skärvad 1999.) 2.8 Metodkritik Att låta studiens frågor växa fram och preciseras genom och under insamlingen av empirin är problematiskt med avseende på att kunna formulera tydliga hypoteser tidigt i projektet och därmed få möjlighet att pröva dem. Inriktningen blir mer problemformulerande och orienterande, vilket passar väl för att ta fram en undersökningsplan inför en hypotesprövande studie. (Se Lundahl & Skärvad 1999.) En svårighet med studiens upplägg är risken att intervjuaren styr för mycket och hindrar intervjupersonerna att verkligen uttrycka sina tankar. Detta gäller såväl intervjusituationen som den efterföljande tolkningen. 9

21 För att i någon mån kunna möta de svårigheter som nämns ovan har ett brett urval av litteratur inom området studerats, och referenserna till andras tankar om prototyper är många. En ytterligare svårighet är urvalet av intervjupersoner. Målsättningen var här att få en bred bild av prototypbegreppet som det används i praktiska verksamheter inom området systemutveckling. Ett större antal intervjupersoner skulle kunna ha bidragit till en mer välförankrad bild. Samtidigt kan ett för stort antal intervjupersoner vara ett slöseri med resurser, då ytterligare intervjupersoner i allt högre utsträckning kommer att upprepa sådant som redan kommit fram. Man talar i detta sammanhang om en «mättnad» som ska inträda hos forskaren, när tillräckligt med information samlats in. Ett stort intervjumaterial riskerar även att bli allt för ohanterligt, och därmed vara till skada för en djupare analys. (Se Repstad 1999.) 10

22 3 Teori För att skapa en förståelse av prototypers användning i systemutveckling behövs det en översikt över olika användningsmöjligheter och synsätt, vilket detta kapitel syftar till att ge. Oklar användning av begrepp är en särskild svårighet inom området, varför detta tas upp i kapitlets början. Dessutom tas problemlösning och systemutveckling upp för att ställa in prototyperna i ett tydligare teoretiskt sammanhang. Delar av kapitlet finns med för att ge en mer komplett bild av prototypområdet, och kommer inte att användas i analysen. 3.1 Begrepp Prototyp Det finns ett antal uppfattningar om vad en prototyp är för något inom systemutveckling. Jag ska till att börja med presentera några av dessa för att ge en bild av området. Till att börja med har vi Nationalencyklopedins definition: prototy p (av senlat. proto typos ursprunglig, av likabetydande grek. prato typos), originalmodell, som följande former baseras på. Inom industriell produktutveckling avses försöksmodell som är riktig i funktion, konstruktion och utseende men inte i tillverkningsmetod. (Nationalencyklopedin 2007) Att se prototypen som en originalmodell som följande former baseras på är ett möjligt synsätt även inom systemutveckling. När det gäller försöksmodellen skulle man inom systemutveckling snarare använda samma tillverkningsmetod som för den slutgiltiga produkten. En mycket bred definition finner vi hos Houde och Hill: We define prototype as any representation of a design idea, regardless of medium. This includes a preexisting object when used to answer a design question. (Houde & Hill 1997, s. 3) Författarna pekar på ett viktigt faktum, nämligen att man skapar en prototyp för att få svar på en fråga, en «design question», där «design» ska tolkas i vid bemärkelse och omfatta såväl formgivning som 11

23 konstruktion. Att ha en så pass bred definition av prototypbegreppet kan dock bidra till missförstånd. Computer Swedens reporter Anders Lotsson skrev följande i en krönika: En prototyp är en fungerande provisorisk version av en produkt. Den kan vara ful som stryk, den kan ha ett råttbo av sladdar baktill, den kan krångla var femte minut, men den ska vara gjord för att fungera. Prototyper byggs för teknisk testning, användartestning och demonstration. På mässor och pressvisningar får man ofta se modeller av kommande produkter. De är snygga och prydliga, men de fungerar inte. Sådana attrapper kallas ibland för prototyper, men det är fel ord. På engelska kallas de för dummies eller mock-ups, men man kan lika gärna använda de svenska orden attrapp och modell. (Anders Lotsson 2001) Genom att använda orden attrapp och modell för respektive företeelse kan ordet prototyp reserveras för sådant som byggts för att fungera. Enligt Lotsson (personlig kommunikation ) får man dock vara försiktig med ordet modell; en modell kan vara såväl fungerande (modelljärnväg) som icke-fungerande (principskiss). Gulliksen och Göransson (2002) ansluter sig till att prototyper ska vara något som fungerar, och går till och med ett steg längre när de säger följande: I brist på bättre ord eller standarder använder vi i denna bok begreppet prototyp som beteckning på ett system innan det är helt färdigutvecklat och prototyping som benämning på en teknik att ta fram prototyperna. (Gulliksen & Göransson 2002, s. 242) Med en bakgrund inom mjukvaruutvecklingsprojekt har några forskare kommit fram till följande beskrivning av vad prototypning är: Prototyping is an approach based on an evolutionary view of software development, affecting the development process as a whole. Prototyping involves producing early working versions ( prototypes ) of the future application system and experimenting with them. (Lichter et al. 2004, s. 222) 12

24 3.1.2 Systemutveckling I Nationalencyklopedin beskriver Nilsson (2007) inledningsvis systemutveckling med följande ord: systemutveckling, aktivitet i vilken man systematiskt utreder förutsättningarna för att genom ett datorstött informationssystem (IS) förbättra verksamheten i ett företag eller en organisation samt i överensstämmelse med resultatet utformar, konstruerar och inför IS i praktisk tillämpning. Viktigt här är att processen börjar med att man utreder förutsättningarna, vilket ger en mycket bred definition av systemutveckling. Systemutveckling innebär att man nyutvecklar eller vidareutvecklar ett informationssystem. Viktiga inslag i denna process är analys av verksamhet och informationssystem, utformning av såväl principiell som praktisk teknisk lösning samt realisering och implementering av lösningen. Målet är att informationssystemet ska lösa problem i verksamheten, men det gäller att vara uppmärksam på vilken typ av problem som en teknisk lösning kan lösa respektive inte lösa. (Andersen 1994) Inom användarcentrerad systemutveckling ser man gärna utvecklingen ur perspektivet mentala modeller. Man har då att göra med designerns och användarens respektive konceptuella modell av systemet. Ett viktigt problem är här hur designern uttrycker sig angående systemet så att designerns och användarens mentala modeller stämmer överens med varandra. Användarens modell skapas inte direkt från designerns modell, utan genom olika slags interaktion. (Gulliksen & Göransson 2002) Design och designer Design och designer har något skilda betydelser i svenska och engelska, vilket kan leda till missförstånd. Därför tar jag med följande förklaring av hur det ligger till med orden: design konstruktion, formgivning, design. «Design» har en djupare innebörd på engelska än på svenska. «To design a computer» kan oftast översättas med «att konstruera en dator». Svenska «designa» är vanligen syno- 13

25 nymt med «formge», alltså mer estetiskt än ingenjörsmässigt. I systemutveckling används «design» om den fas när man «gör upp ritningarna» till systemet, alltså fasen mellan kravanalys och implementering. (Computer Swedens ordlista 2007, sökord: «design») Jag använder i denna studie orden design och designer med en bred svensk/engelsk innebörd, i linje med hur orden används i mina svenskspråkiga källor Programmering Begreppet programmering visar sig ha olika innebörder beroende på vem man frågar. Här följer två exempel. I Nationalencyklopedin beskrivs programmering på följande sätt: programmering i databehandlingssammanhang skrivande av instruktioner för en dators arbete. (Nationalencyklopedin 2007) Detta är ett synsätt som inte delas av Computer Swedens språkwebb: programmering att tänka ut, planera, framställa och testa datorprogram. Att «skriva kod» är alltså inte samma sak som att programmera. När programmering görs med ingenjörsmässiga metoder talar man om programutveckling eller systemutveckling. (Computer Swedens ordlista 2007, sökord: «programmering») I denna studie används termen programutveckling med innebörden utveckling av mjukvara genom olika steg; detta för att undvika den mindre tydliga termen programmering Problemlösning Det lönar sig ofta att tänka igenom sådant som man annars tar för givet; därför behandlas här kort problemlösning som fenomen. 14

26 När vi ska lösa en uppgift där lösningen är svår att uppnå direkt använder vi vanligen någon form av problemlösning. Detta innebär att vi går igenom flera steg på vägen fram till lösningen. Två övergripande steg kan vara att först förstå problemet, för att sedan söka möjliga riktningar som leder till en lösning. (Encyclopædia Britannica 2007) Ovanstående kan låta självklart, men från pedagogiskt håll har det uppmärksammats att man är omedveten om detta inom undervisning i programmering. Studenterna ställs inför uppgiften att hitta en lösning till ett problem, istället för att först lära sig att identifiera problemet. Genom att först identifiera och sedan lösa problem ökar studenternas självförtroende och förmåga till problemlösning. (Eastman 2003) På 1950-talet togs en modell för problemlösning fram av matematikern Polya som kan sammanfattas i följande steg: Beskriv och förstå problemet. Finn alternativ till lösning bland annat genom att finna likheter med andra problem (som redan är lösta). Välj ett lösningsalternativ och genomför det. Jämför resultatet med det ursprungliga problemet. (Wiktorin 2003, s. 29) För att lösa komplexa problem är vissa egenskaper viktiga, Mumford (1998) nämner särskilt skicklighet, kompetens och koordination. Cunningham (2002) beskriver problemlösning som en aktivitet där vi ägnar oss åt att iaktta, analysera och utforska. 15

27 3.2 Prototyper och prototypning Vi har redan varit inne på att man använder prototyper för att få svar på en eller flera frågor (kapitel 3.1.1). Men att få svar på frågor innebär att man samlar eller utvecklar kunskap. Någon som uttryckt detta mycket tydligt är Kurt Schneider: A prototype can be seen as just another representation for requirements and solution knowledge. (Schneider 1996, s. 522) En fråga som uppstår här är hur denna kunskap tas till vara. Det finns en risk att kunskapen stannar hos den enskilde utvecklaren, vilket Schneider illustrerar på detta sätt (se figur 2): Figur 2. Förhållandet mellan prototyp och utvecklare. (Schneider 1996, s. 523) Risken med att kunskapen är hårt knuten till enskilda utvecklare är att den kan gå förlorad till exempel om en utvecklare lämnar teamet. Förlorad kunskap kan till exempel leda till att man gör något som man redan provat i en prototyp och förkastat, men denna kunskap finns inte längre tillgänglig. Samtidigt är prototyper något som behöver utvecklas snabbt, vilket innebär att begränsade resurser står till förfogande för att skapa dokumentation. En möjlig väg är att skapa ett system för att dokumentera prototyper och den återkoppling man får angående dessa. Ett sådant system måste vara effektivt att samla information i och underlätta navigering i den informationsrymd som skapas. (Schneider 1996) För att få en tydligare bild av vad prototyper kan vara ska vi se närmare på olika dimensioner och synsätt som man använder för att förstå prototyper. 16

28 3.2.1 Användningssätt Prototyper kan användas i olika faser av ett systemutvecklingsprojekt, och har då olika roller. Tre grundläggande aktiviteter som kan utföras med stöd av prototyper är: projektstart, analys av verksamhetens behov, design och realisering av systemet. (Lichter et al 1993) I samband med projektstart kan det handla om att sälja in systemet hos beställare och användare, och även om att ha med visuell information om det framtida systemet i en kravspecifikation. Finns det särskilda tekniska svårigheter med ett system kan man göra en prototyp som visar att det går att få bukt med svårigheterna. (Ibid.) För att klargöra verksamhetens behov och systemets motsvarande funktionalitet används ofta prototyper av användargränssnittet. (Ibid.) För att undersöka olika designer och sätt att realisera systemet kan prototyper användas. Dessa prototyper brukar vara för internt bruk. (Ibid.) «Slit och släng» kontra evolutionär prototypning Två olika arbetssätt som används inom prototypning är att använda prototyper som: slängs när man fått svar på sina designfrågor i vid bemärkelse, utvecklas vidare till en driftsversion av systemet. Figur 3 visar hur dessa alternativ skiljer sig åt, med den första varianten till vänster och den andra till höger. I fallet med slit och släng sker en noggrann dokumentation av det man kommit fram till med hjälp av prototypen. I det andra fallet måste man bedöma om prototypen går att göra tillräckligt effektiv för att användas i drift. I så fall lägger man till felhantering och annat som saknas i prototypen, men behövs i en driftsversion. (Andersen 1994) Ett frågetecken med Andersens modell är om det verkligen inte behövs ett särskilt steg för dokumentation av vad prototypen visat när 17

29 Figur 3. En utvecklingsmodell för prototypning. (Andersen 1994, s. 412) 18

30 man väljer att låta prototypen bli en driftsversion (jämför Schneider 1996). Man kan även rikta en kritik mot Andersens modell från ett annat håll: Andersen verkar utgå från att det i fallet med en prototyp som är avsedd att slängas handlar om att olika personer framställer prototyp respektive driftsversion. Men att överlämna utvecklingen från ett team till ett annat förbrukar i sig resurser, och kan därför ses som att resurser kastas bort. Frågan är om överlämnandet tillför kundnytta till slut eller inte. ( Jämför Poppendieck & Poppendieck 2003) Ytterligare ett perspektiv på evolutionär prototypning är att man skapar en kontinuerlig process för att anpassa ett system till förändrade villkor för verksamheten. Man ser inte systemet som något avslutat, utan system och utvecklingsprocess hör tätt samman. (Lichter et al 1993) Presentationsprototyper: lo-fi och hi-fi För att tidigt i ett projekt komma igång på ett bra sätt är det vanligt att man gör presentationsprototyper, som sedan slängs (Schneider 1996). Dessa kan karakteriseras ytterligare enligt nedan. Man talar om hur «naturtrogen» en prototyp är. En låg nivå (lo-fi) på denna skala har till exempel handritade skisser på papper. Långt upp (hi-fi) kommer datorbaserade representationer av ett system, som omfattar systemets estetik och interaktion. (Bryan-Kinns & Hamilton 2002) Jämför med hi-fi (förkortning av «high fidelity») när det gäller stereoanläggningar, där det innebär en hög grad av trohet mot originalljudet Horisontella och vertikala prototyper Prototyper motsvarar ofta delar av system, och då kan systemet «skäras» på olika sätt (se figur 4). En prototyp som går på djupet har en vertikal skärning, vilket innebär att samtliga skikt från användargränssnitt till datalager finns med. Därmed speglas funktionerna inom en del av systemet. En förenklad variant av detta är ett scenario, som inte omfattar samtliga skikt. Skär man horisontellt kan man till exempel göra en prototyp för hela användargränssnittet, men inte ha någon funktionalitet bakom. (Gulliksen & Göransson 2002) 19

31 Vertikal Horisontell Scenario Användargränssnitt Användargränssnitt Användargränssnitt Logik Logik Logik Data Data Data Figur 4. Tre olika slags prototyper: vertikal, horisontell eller i form av ett scenario. (Figur efter Gulliksen & Göransson 2002, s. 245) En horisontell prototyp kan även göras för till exempel datalagret. Man ska lägga märke till att det översta skiktet inte behöver vara just ett användargränssnitt, och att applikationer kan ha fler eller färre lager än de tre som tas upp här. (Lichter et al 1993) Horisontella prototyper kan användas i systemutveckling för att underlätta parallell utveckling av olika delar av ett system. Till exempel kan man skapa en prototyp av datalagret som sett från systemets övriga delar är ett fungerande datalager med komplett gränssnitt, men som i själva verket bara svarar med data som lagts in fast i programkoden. (Se Evans 2004) Utforskande och experimentella prototyper En utforskande prototyp används när problemet som ska lösas är oklart. Det handlar såväl om systemets kontext på till exempel en arbetsplats som hur själva systemet ska se ut. Man betonar att prova olika designer och inte välja ett spår för tidigt. Utvecklarna får insikt i verksamheten och de problem som de anställda står inför. (Lichter et al 1993) Experimentell prototypning fokuserar på den tekniska implementationen av något. Här handlar det mer om att prova olika lösningar och skapa ett system med hög användbarhet. (Ibid.) 20

32 Role Integration Implementation Funktioner, gränssnitt och implementation Houde och Hill (1997) har beskrivit ett sätt att dela in prototyper utifrån hur de används. De dimensioner som de tar upp är följande (se även figur 5): Role: vilken roll ett system ska spela (funktionalitet), Look and feel: systemets utseende och beteende, Implementation: hur man kan implementera en aspekt av systemet. (Houde & Hill 1997) Systemets roll handlar om vilken nytta man har av det, vad systemet kan göra för användarna. Annorlunda uttryckt handlar det om vilka funktioner som systemet ska ha. Ett exempel kan vara skisser som visar olika aktiviteter som kan utföras med ett operativsystem. Prototyper av utseende och beteende används för att utvärdera de sinnesintryck som man får när man använder det. I denna kategori finns både detaljerade bilder av hur systemet skulle kunna se ut, och klickbara prototyper som uppvisar ett beteende. Implementationsprototyper används för att bedöma om en teknisk lösning håller måttet, till exempel om en filmsnutt kan visas utan att bilden hackar. (Ibid.) De olika sätten att använda prototyper behöver inte användas i någon viss ordning, utan detta beror på projektet. Är det kritiskt för framgång att ett program ska kunna visa upp rörliga figurer med god bildkvalitet på ordinära hemdatorer kanske man börjar med implementationsprototyper för att undersöka om detta är genomförbart. (Se ibid.) 21 Look and feel Figur 5. Tre olika dimensioner för prototyper: roll, utseende och beteende samt implementation. (Figur efter Houde & Hill 1997, s. 6)

33 3.3 Systemutvecklingsmodeller I en undersökning som publicerades 1996 (Bäumer et al) var följande en av de trender som man kunde iaktta: Traditional life-cycle approaches are being replaced by evolutionary strategies in projects focused on building user-friendly systems. Prototyping is today an established part of these evolutionary strategies. (Bäumer et al 1996) Här ser vi hur begreppen användarvänlig, evolutionära strategier och prototypning sammanförs. För att bättre förstå vad det handlar om ska vi se närmare på olika systemutvecklingsstrategier eller -modeller. Jag tar upp vattenfallsmodellen som ett exempel på en traditionell strategi inom systemutveckling, som kontrast till agil utveckling. Citatet ovan och liknande utsagor gjorde mig intresserad av vilken roll användarcentrerad systemdesign har i sammanhanget, därför finns det även ett avsnitt om den Vattenfallsmodellen Den modell för problemlösning som Polya har föreslagit (se kapitel 3.1.5) har inspirerat en fasindelning av systemutveckling enligt följande: specifikation, analys, konstruktion, provning. (Wiktorin 2003) Denna fasindelning är mycket vanlig och innebär en naturlig ordningsföljd mellan momenten, som fått beteckningen vattenfallsmodellen. Tidiga varianter på denna modell föreskrev att arbetet i en fas skulle vara klart innan man fortsatte till nästa fas. I praktiken brukar man behöva gå tillbaka till föregående fas på grund av brister som visar sig. Det senare är det gängse arbetssättet idag. (Wiktorin 2003) En mer omfattande variant av vattenfallsmodellen är livscykelmodellen (se Figur 6). Viktiga punkter i detta synsätt är att användarna 22

34 Systemering Livscykel Systemutveckling Analys Förändringsanalys Utformning Realisering Implementering Förvaltning och drift Avveckling Kravspecifikation Valda utvecklingsåtgärder Realiserbart informationssystem Infört informationssystem Färdigt informationssystem Figur 6. Livscykelmodellen. (Figur efter Andersen 1994, s. 48) ska analysera sig fram till sina önskemål, och att detta ska göras innan utformningen av systemet påbörjas. Analysfasen är särskilt viktig; om den utförs dåligt blir hela informationssystemet dåligt vad man än gör senare i projektet. Till exempel när problemställningarna förändras hela tiden kan livscykelmodellen vara mindre lämplig. Däremot passar den väl för stabila verksamheter, till exempel när man flyttar över manuella rutiner till ett informationssystem. (Andersen 1994) Agil utveckling Inom agil utveckling finns det många olika metoder och angreppssätt med en gemensam kärna av värden som uttrycks i det agila manifestet: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. (Beck et al 2001a) 23

35 Inom agil utveckling undviker man att ha ett långt avsnitt i början av projekt där man utförligt slår fast samtliga krav i detalj. Istället växer kraven fram och utvecklas under projektets gång. Om såväl kraven som den teknik som ska användas är väl kända och förstådda skulle ett mjukvaruprojekt kunna följa ett linjärt förlopp. Men i den utsträckning som det finns oklarheter kring krav eller teknik och det brukar det finnas gott om ökar projektets komplexitet, och ett annat arbetssätt behövs. Istället för att enbart staka ut en färdriktning i början av projektet måste denna kontinuerligt anpassas utifrån vad man upptäcker under arbetet. (Schwaber & Beedle 2002) För att hantera krav på ett rationellt sätt utan att behöva frysa dem helt använder man inom den agila metoden Scrum något som kallas för time-boxing. Det innebär att man fryser kraven under en bestämd tid, då utvecklarna får arbeta i fred. En enda person, exempelvis projektledaren eller produktansvarig, ansvarar för vad som ska utföras i nästa time-box. Den personen hanterar listan med krav och prioriterar mellan dessa. (Schwaber 2004) Centralt för agil utveckling är att underlätta samverkan mellan kund/ beställare och utvecklare. (Wiktorin 2003) Användare har lättare att förstå fungerande programvara än dokument som beskriver programvaran. Därför arbetar man inom agil utveckling med att skapa fungerande program tidigt och ofta i ett projekt. Man behöver också ta hänsyn till att förändringar hör till i mjukvaruutveckling: villkoren för en verksamhet förändras, teknik förändras över tid. Intressenternas förståelse av systemet förändras. Man behöver ha en projektplan, men samtidigt lämna ett spelrum för förändringar av denna. (Ambler 2002) Det tillhör de grundläggande principerna inom agil utveckling att personer från verksamheten och utvecklare arbetar tillsammans dagligen genom hela projektet. (Beck et al 2001b) Användarcentrerad systemdesign Användarcentrerad systemdesign fokuserar på användare och användbarhet under hela utvecklingsprocessen. Systemet utvecklas evolutionärt med den typ av iterationer som beskrivs i figur 7. Prototyper används tidigt i projektet och under hela dess förlopp. Målet är 24

36 Användarfokus, mätbar användbarhet och iterationer Återkoppling med förslag till förändringar Analys av användarna, arbetsuppgifter och användningssammanhang Utvärdering med mätningar mot användbarhetsmål Designförslag med prototyper i sig en iterativ process som beskriver det kreativa arbetets natur Figur 7. Grundelementen i en iterativ användarcentrerad process. (Figur efter Gulliksen & Göransson 2002, s. 109) att visualisera och utvärdera designlösningar tillsammans med slutanvändarna. (Gulliksen & Göransson 2002) Inom användarcentrerad systemdesign rekommenderas att man börjar med prototyper i form av enkla pappersskisser och konceptuell design på hög nivå. Man lägger stor vikt vid att designförslagen utvärderas mot mätbara användbarhetsmål som satts upp för projektet. (Ibid.) En målsättning är att skapa en delad förståelse bland alla inblandade parter. Därför behövs en representation av designen som ger användarna en konkret bild av hur det är att använda systemet, samtidigt som den behöver vara effektiv för utvecklarna. (Ibid.) Alla delar av systemet ska utvecklas parallellt, kontinuerligt och i ett sammanhang med varandra. Detta gäller allt från användargränssnitt till handböcker och arbetsmiljöaspekter. På så vis kan man uppnå en integrerad systemdesign. (Ibid.) 3.4 Att förstå systemutveckling För att förstå prototypernas roll i systemutveckling behöver man också förstå systemutveckling. Därför ägnas följande kapitel åt frågor kring vad systemutveckling är för något Peter Naur Vad är egentligen systemutveckling, vad går det ut på? I första hand kanske man tänker på det system som produceras, i form av specifikationer, dokumentation av olika slag samt programkod. Med detta 25

37 tänkesätt är systemutvecklarens uppgift främst att producera dessa olika artefakter. En person som lagt fram ett alternativ till detta synsätt på sådana frågeställningar är dansken Peter Naur, en förgrundsfigur inom dansk datalogi. Naurs forskning har sin bakgrund i svårigheten att förklara vissa problem utifrån det Naur kallar för ett produktionsperspektiv på programutveckling; alltså att produktionen av vissa artefakter är centralt i programutvecklingsprocessen. Två typiska fenomen som kan belysa detta är de problem som hänger samman med att rätta programkod som innehåller fel, respektive att modifiera program. (Naur 1985) I detta sammanhang använder Naur begreppet programmering, men säger tydligt att han avser hela raden av aktiviteter från utformning på olika nivåer till implementation av mjukvara. Jag väljer här istället att använda ordet programutveckling när jag refererar Naur, eftersom programmering enligt min mening lätt kan förknippas med att «skriva kod» i mer inskränkt bemärkelse. (Se Naur 1985 samt kapitel i denna studie) Naur ser programutveckling som att man får symbolmanipulering som kan utföras av ett datorprogram att överensstämma med en del och aspekt av något i den riktiga världen. Med dessa begrepp som bakgrund blir det tydligt att förändringar i den riktiga världen måste motsvaras av en ofrånkomlig aktivitet i programutvecklingen, nämligen att man modifierar program. (Naur 1985) Att program behöver modifieras är alltså inte någon «extra» aktivitet utanför programutvecklingen, utan ingår som en normal del i denna. Därmed är det också tveksamt om man någonsin kan se programutvecklingsprojekt som fullständigt avslutade. Den huvudtes som Naur driver är att programutveckling i första hand sker i form av att programutvecklaren bygger upp en kunskap av ett särskilt slag. Denna kunskap är primär, medan till exempel varje form av dokumentation utgör en yttre sekundär produkt. Detta kan hjälpa oss att förstå varför det är så svårt att bygga ut befintliga program, även när dessa är väldokumenterade och byggda enligt sunda principer för programutveckling. (Naur 1985) Utifrån ett produktionsperspektiv på programutveckling är det naturligt att anta att man bör kunna modifiera eller utöka program till en låg kostnad. Detta skulle isåfall stå i motsättning till förändring 26

38 av andra komplicerade konstruktioner som till exempel byggnader, där rivning och nybyggnation ofta är mer ekonomiskt fördelaktigt än ombyggnation. Ser man programutveckling som en form av textproduktion att datorprogram redigeras som en form av texter inbjuder till det är det naturligt att tänka att utökning av ett program handlar om skrivandet av ytterligare ett tämligen litet antal rader text (programkod). Men då tar man miste. Programutveckling hanterar i själva verket synnerligen komplicerade konstruktioner. (Naur 1985) En möjlig jämförelse för ett mindre utvecklingsprojekt skulle kunna vara en lärobok där olika kapitel skrivits av olika författare. Inför en ny upplaga låter man någon författare skriva till ett kapitel om till exempel ny teknik som kommit fram. Kanske behöver författaren inte ens läsa resten av boken, och kostnaden inskränker sig till kostnaden för det nyskrivna kapitlet, som helt enkelt läggs till i boken. Då stämmer ett rent produktionsperspektiv, och kostnaden för förändringen är låg. Men det kan också vara så att den nya tekniken har betydelse för innehållet i samtliga kapitel i boken, som plötsligt blivit föråldrade. Då står man inför valet att omarbeta hela boken från grunden eller att låta skriva en ny bok, där bägge alternativen är väsentligt dyrare än att bara lägga till ett kapitel. Skulle man trots att stora delar av boken blivit föråldrade välja att bara lägga till ett nytt kapitel blir resultatet en bok av lägre kvalitet, som inte längre uppfyller sitt syfte lika väl. Upprepas detta flera gånger blir boken allt mer osammanhängande och inkonsistent för varje gång. Den kunskap som programutvecklare bygger upp utvecklas till ett slags teori som går väsentligt längre än till att endast ha kännedom om något. Det krävs insikter på en nivå som gör att man kan förklara hur en lösning svarar upp mot de problem eller behov som existerar i verksamheten samt varför man valt just detta sätt att lösa problemen. Dessutom ska insikten göra att man kan ge en konstruktiv respons på hur förändringar av lösningen kan stödja verksamheten på nya sätt när behovet uppstår. Uppfylls dessa kriterier kan man säga att utvecklaren har en teori om systemet och dess kontext. (Naur 1985) En forskare som anknyter till Peter Naur är Alistair Cockburn, som även är känd som författare med inriktning mot agil systemutveckling. Nedan följer några av hans kommentarer kring Naurs idéer. Den kunskap som utvecklas vid systemutveckling kan beskrivas som en form av tyst kunskap hos utvecklarna. Det rör sig om en förståelse 27

39 av å ena sidan det behov eller problem som finns i verksamheten, å andra sidan av hur detta kan tillfredsställas eller lösas. Dessutom tillkommer förståelsen av hur dessa bägge sidor svarar mot varandra. En samstämmighet mellan dessa båda sidor är nödvändig för att skapa it-system av god kvalitet. När en utvecklare kommer in senare hänger kvaliteten på hans arbete på att hans förståelse av det befintliga systemet överensstämmer med förståelsen hos dem som byggt systemet. (Cockburn 2006) Pelle Ehn Pelle Ehn lyfter fram två utvecklingstendenser inom mjukvaruutveckling: en teoretisk utveckling mot ett processorienterat humanistiskt paradigm, en teknisk utveckling mot kraftfulla miljöer för prototypning. (Ehn 1988) Det nya teoretiska perspektivet handlar om att fokusera på lärande och kommunikation vid både användning och utveckling av mjukvara. Kvaliteten hos mjukvara bedöms i detta perspektiv inte enbart utifrån dess överensstämmelse med en kravspecifikation, utan man ser till dess relevans och ändamålsenlighet i praktiska användningssituationer. Följden blir att mjukvaruutveckling inte kan ses som en rad faser ordnade i tiden där formella dokument förfinas allt mer för att slutligen mynna ut i ett system. Istället ser man den som en fortlöpande process där design, implementation och utvärdering sker i cykler i kontexten av den arbetsprocess där mjukvaran ska användas. Designartefakter som exempelvis prototyper används för att underlätta kommunikation och samarbete, där man steg för steg kommer underfund med systemet. (Ibid.) När det gäller de nya tekniska möjligheterna med prototyper ser Ehn många användningsområden. Det han ser som den centrala frågan är: innebär prototyperna att användarna får möjlighet att experimentera med olika prototyper, så att de kan samla erfarenhet som en grund för designkrav? (Ibid.) Byggt på denna grund ser Ehn framför sig möjligheten till ökad kreativitet och ett större inslag av användardeltagande vid systemutveckling. (Ibid.) 28

40 3.5 Systemutveckling och prototyper Prototypning i verksamhetsutveckling Prototyper kan användas i olika skeden av en systemutvecklingsprocess. Dessutom uppkommer frågan om hur systemutvecklingsprocessen relaterar till verksamhetsutvecklingsprocessen, och vad prototyper har för roll i sammanhanget. Traditionellt sett är systemutvecklingsprocessen och verksamhetsutvecklingsprocessen åtskilda företeelser, och prototypningen saknar då samband med verksamhetsutvecklingsprocessen (Gulliksen & Göransson 2002). Se figur 8. Återkoppling? Verksamhetsutvecklingsprocess Systemutvecklingsprocess Prototyping Figur 8. Relationen mellan systemutveckling och utvecklingen av verksamhetsprocesser i verkliga livet. (Figur efter Gulliksen & Göransson 2002, s. 299) När systemutvecklingen leder till mer konkreta resultat som prototyper är det vanligt att verksamhetsprocesserna behöver modifieras påtagligt. Ett sätt att hantera detta är att arbeta med prototypning redan i samband med verksamhetsmodelleringen. Man tar då fram Återkoppling? Verksamhetsutvecklingsprocess Systemutvecklingsprocess Prototyping Figur 9. Prototypning under hela verksamhetsutvecklingen för att tidigare kunna ta fram krav som är begripliga för användaren. (Figur efter Gulliksen & Göransson 2002, s. 300) 29

41 kraven med hjälp av prototyper, vilket förbättrar möjligheterna att utveckla ett system som passar verksamheten. (Gulliksen & Göransson 2002) Se figur 9. Även med en användarnära och konkret process med prototypning kvarstår att frysta kravspecifikationer under systemutvecklingen innebär klara nackdelar. I själva verket kan man använda prototypning genom hela utvecklingsprocesserna, som därmed knyts närmare till varandra. (Gulliksen & Göransson 2002) Se figur 10. Verksamhetsutvecklingsprocess Systemutvecklingsprocess Det skisserade arbetssättet ger fördelar i form av tidig upptäckt av fel i verksamhetsprocesserna, användardeltagande underlättas, iterativ design underlättas och utvärdering blir möjligt att genomföra tidigt i processen. (Gulliksen & Göransson 2002) Agila prototyper Prototyping Figur 10. Tidig och kontinuerlig prototypning får produkten att «växa» till. (Figur efter Gulliksen & Göransson 2002, s. 301) Den annorlunda processen vid agil utveckling leder till att tidiga prototyper under ett projekt minskar i intresse, eftersom den fas som ligger före själva systemutvecklingen är kort: man bygger fungerande system tidigt istället. (Se kapitel 3.3.2) Istället för att modellera ett system i stor skala («Big Design Up Front») för att sedan utvärdera modellen och slutligen realisera den i programkod modellerar man mindre bitar i taget, och skapar både testkod och programkod för att se att det fungerar (Ambler 2002). Därmed modellerar man och skapar systemet i en integrerad process, vilket kan ses som en form av prototypning (se Gulliksen & Göransson 2002 samt kapitel 3.1.1). 30

42 3.5.3 Prototypernas roll Det som tidigare sades om utforskande och experimentella prototyper kan även uttryckas på andra sätt, och jag menar att Scott W. Ambler har gjort detta på ett intressant sätt när han tar upp olika användningsområden för prototyper, och då nämner: som analysartefakt som ger möjlighet att utforska problemrymden tillsammans med intressenterna, som designartefakt som ger möjlighet att utforska systemets lösningsrymd. (Ambler 2004) Genom att tala om problemrymd och lösningsrymd är Ambler inne på ett spår som vi känner igen från Peter Naur och även Alistair Cockburn (se kapitel 3.4.1). Men nu handlar det om just prototyper som ett hjälpmedel för att utveckla kunskap om problemrymden och lösningsrymden. Här vill jag även tillfoga något. Med anknytning till Pelle Ehn (se kapitel 3.4.2) vill jag hävda att de krav som användare och andra intressenter ställer på ett system till stor del bygger på deras erfarenheter. Den svårighet som uppstår är hur man ställer krav på något som man inte ännu har erfarenhet av! Där kan prototyper hjälpa till med att under projektets gång ge möjlighet att skapa relevanta erfarenheter. På så vis ökar möjligheterna för användare och andra intressenter att definiera problemet på ett adekvat sätt redan under systemutvecklingsprocessen. Systemutvecklare står inför liknande problem när de utvecklar system med inslag som de saknar erfarenhet av. Här kan man på motsvarande sätt skapa erfarenheter genom att arbeta med prototypning, och på så vis minska risken att designbeslut fattas på felaktiga grunder. En annan författare som är inne på ett liknande spår är Kurt Schneider, som ser prototyper som representation av kunskap (Schneider 1996). I takt med att prototyperna utvecklas återger de allt mer kunskap om krav och lösningar, för att kunna vara till hjälp för att fånga kunskaper på nästa nivå. 31

43 3.6 En sammanfattande modell Motivering av modellen Utifrån det som lagts fram hittills i teorikapitlet har jag skapat en preliminär modell för prototyper i systemutveckling. Den beskrivs i text och figurer nedan. Avsikten är lyfta fram väsentliga synpunkter på strukturering av prototypbegreppet utifrån de teorier som jag har tagit upp. Målsättningen är att göra begrepp och deras relationer mer lättillgängliga. Detta uppnås dels genom att utgå från helt grundläggande begrepp, dels genom att en visuell representation av modellen tas fram. Just genom att fokus ligger på grundläggande begrepp ges utrymme att längre fram fylla på med detaljer, och tydligare se hur olika begrepp verkligen relaterar till varandra. Detta minskar risken att gå vilse i den stora mängd begrepp och angreppssätt som utvecklats inom området Preliminär begreppsmodell för prototypning Systemutveckling har två grundläggande sidor, nämligen krav som ska omsättas i ett system. Om vi tar ett steg tillbaka finner vi två begrepp på ett mer grundläggande plan. Såväl krav som system här tätt samman med den praktiska verkligheten. Å andra sidan har vi de teorier som vi bygger upp kring denna verklighet. Ser vi detta sammanhang mer ur ett processperspektiv ger sig begreppen problemrymd och lösningsrymd, som vi stiftat bekantskap med tidigare. Utifrån detta får vi följande sex begrepp som en ram för systemutvecklingsprojekt: Tabell 2: Ram för systemutvecklingsprojekt teori problem lösning praktik krav system Genom att även ta hänsyn till att det finns en ordningsföljd i förloppet vid systemutveckling får vi följande första utkast till en modell för prototyper i systemutveckling (se figur 11): Att cirkeln sluter sig kan symbolisera två olika saker: 32

44 problem teorier lösning krav praktik system Figur 11. Utkast till modell för prototyper i systemutveckling. ett arbetssätt där man tillåter att kraven förändras under projektets gång, det faktum att man ofta påbörjar utvecklingen med utgångspunkt från en tidigare systemutvecklingsprocess (systemarv). Det steg som verksamheten tar är att gå från ett behov som formuleras som beställning eller krav till att ett it-system införs eller förändras utifrån detta. Systemutvecklingsprocessen tar i sin tur fasta på kravmängden och analyserar den i form av ett problem som ska lösas. Den andra sidan av systemutvecklingsprocessen är att man utforskar lösningsmöjligheterna, från rent konceptuella sådana och ned till konkreta lösningar som kan implementeras i det färdiga it-systemet. Detta beskrivs i modellen som två nivåer, som jag betecknat som praktik och teorier. Nu är det dock uppenbart att det viktigaste saknas i modellen: begreppet prototyp. Utifrån det som sagts i detta kapitel vill jag fram- 33

45 hålla att prototypning är ett mångfasetterat arbetssätt, som kan passa in på många ställen i modellen. Därmed får man tänka sig begreppet prototyp som något rörligt som kan finnas på många ställen i modellen samtidigt. Ofta är det en person som tar fram prototypen, och någon, till exempel en användare, som provar och kommenterar den. När en designer tar fram en prototyp för eget bruk kan man även se detta som att designern växlar mellan två olika roller, där man kan se det som att designern även är användare i det fallet. De begrepp som vi nu tillför modellen är: designer prototyp användare Därmed har vi nått fram till följande modell (se figur 12): problem teorier lösning designer prototyp användare krav praktik system Figur 12. Preliminär modell för prototyper i systemutveckling. 34

46 Denna preliminära modell följde med in i arbetet med empirin. Efter att ha gjort två inledande intervjuer med fokus på teorin (se nästa kapitel) försökte jag göra modellen tydligare genom att förändra begreppen något: verksamhet är tydligare än praktik, begreppsstrukturer är ett alternativ till teorier, problemrymd är tydligare än bara problem, lösningsrymd är tydligare än bara lösning, informationsbehov är tydligare än bara krav, it-system är tydligare än bara system, jag insåg vikten av att ha med både substantivet prototyp och verbet prototypning, beroende på vem man talar med kan begreppen designer respektive utvecklare passa in bättre, förutom användare finns även övriga intressenter. Därmed är vi framme vid en bild (se figur 13, nästa sida) av den teoretiska modell som jag hade som grund för resterande intervjuer (se nästa kapitel). 35

47 problemrymd begreppsstrukturer lösningsrymd designer utvecklare prototyp(ning) användare intressent informationsbehov verksamhet it-system Figur 13. Den andra iterationen av begreppsmodellen. 36

48 4 Empiri Kapitlet presenterar utdrag ur intervjuer samt kortare sammanfattningar av intervjuerna. 4.1 Upplägg för intervjuerna Preliminär teoretisk modell Som grund för intervjuerna har jag använt en preliminär teoretisk modell baserad på litteraturstudier. Se teoridelen för ytterligare detaljer (kapitel 3.6) och bakgrund (hela kapitel 3) Intervjuernas ställning i uppsatsen Intervjuerna utgör vid sidan av teorin uppsatsens kärna. Att försöka sammanfatta intervjuernas innehåll låter sig inte göras utan att mycket går förlorat. Därför presenteras intervjuerna innehåll i form av utdrag. För att markera deras vikt i uppsatsen har dessa utdrag placerats direkt i empirikapitlet och inte i ett appendix. Detta kan också ses som en uppmaning till läsaren att även läsa dessa sidor! För att skapa en bättre överblick över intervjumaterialet har trots svårigheterna sammanfattningar av dem lagts till i slutet av kapitlet Urval av intervjupersoner Intervjupersonerna har valts ut med tanke på att ge en bred bild av prototypanvändning inom systemutveckling idag. Såväl produktutveckling av olika slag som it-konsulttjänster finns representerade. Såväl arbete på server- som klientsidan finns med. Ett fåmansföretag hade tackat ja till att delta, men föll bort på grund av den höga arbetsbelastning som rådde på företaget under perioden Praktiskt genomförande I de två första intervjuerna, med Lars Degerstedt respektive med Arne Jönsson, användes den preliminära modellen som ett underlag för att gemensamt utforska området prototyper i systemutveckling. Detta ledde till en mindre bearbetning av modellen, samt uppslag som jag kommer att ta upp i analysen. 37

49 I de följande intervjuerna har jag främst använt modellen som ett stöd för mig själv. Med hjälp av den strukturerade jag samtalen under genomförandet. Beroende på situationen tids- och innehållsmässigt har jag även tagit upp aspekter av modellen mer direkt mot slutet av intervjuerna. Då syftet med studien snarare är att se på olika angreppssätt för prototypning som används idag än att jämföra företag har betoningen varit på den intervjuades egna erfarenheter, inte på företagets «policy». Detta för att undvika att intervjupersonen återger något han hört eller läst istället för sina egna erfarenheter. Man kan därmed inte utan vidare dra slutsatser om företagen utifrån materialet. Intervjun med två personer från Responsive Development Technologies AB intar en särställning. De sysslar inte direkt med systemutveckling, utan de beskriver sin verksamhet enligt följande: Våra kunder utvecklar system och produkter baserade på programvara. Vi utvecklar deras utveckling! (Responsive 2007) Det som gjorde Responsive intressanta för mig var deras inriktning på agila metoder. Företaget är medlem i organisationer som Agile Alliance, Agile Project Leadership Network och DSDM Consortium. (Responsive 2007) Förutom att intervjua systemutvecklare har jag även intervjuat en konstnär med erfarenhet av utsmyckning i offentliga miljöer. Tanken med detta är att ge möjligheter att se om och hur liknande fenomen uppträder inom konstområdet, och därmed kunna få andra perspektiv och bilder med sig in i arbetet med frågeställningarna inom itområdet. Resterande intervjuer är gjorda med verksamma systemutvecklare, med syftet att ta reda på hur de arbetar med och ser på prototyper och prototypning. Intervjuernas längd varierade från 45 minuter till närmare två timmar. Samtliga intervjuer genomfördes under våren Återgivningen av intervjuerna Intervjuerna återges i form av utdrag. Dessa utdrag har endast redigerats för att ge en läsbar text och minskat antal upprepningar. Detta 38

50 är vad Svenska språknämnden (2000) kallar för redigerad direkt anföring. Utdragen har gjorts med tanke på att i någorlunda koncentrerad form samla uttalanden som är av intresse för denna studies frågeställningar. Mellanrubrikerna är insatta i efterhand för att underlätta navigeringen i texterna. Innehållet i intervjuerna skiljer sig mycket, och mellanrubrikerna skiljer sig därmed också mycket. Personerna i intervjusituationen särskiljs med hjälp av sina initialer. När vi pekat på någon skiss eller modell under intervjun har jag lagt till kommentarer inom hakparenteser för att göra texten begriplig för läsaren. Att endast utdrag ur intervjuerna återges inom ramen för uppsatsen har flera skäl. Bland annat skulle uppsatsens omfång nästan fördubblas om man lägger till intervjuerna i oavkortat skick! Detta skulle däremot inte tillföra någon betydande mängd information av intresse för läsaren, och därmed togs intervjuerna inte med i sin helhet. Det är också svårt att motivera den stora arbetsinsatsen som skulle krävas för att bearbeta hela materialet så att det ger en stilistiskt godtagbar text. 4.2 Intervjuer Intervju med Lars Degerstedt Intervjun genomfördes 29 mars på Linköpings universitet. Lars Degerstedt har doktorerat i datavetenskap och undervisar och forskar vid Institutionen för datavetenskap, Linköpings universitet. Till hösten är han med och startar det nya kandidatprogrammet i Innovativ programmering vid Linköpings universitet. Nedan följer utdrag ur intervjun. Problemrymd och lösningsrymd LD: Där finns det ju en fundamental matematisk skillnad mellan problemrymden och lösningsrymden. Och det här det stora kreativa steget sker. Det är här det spännande sker när du går från problem till lösning. Och här finns ingen automatik alls. Det är här människan gör sin stora arbetsinsats, då man bygger system. Samtidigt som man då bygger upp förståelse kring problemet så hittar 39

51 man också en lösning. Eller ibland är det så att man också kan förstå problemet i förväg och sen hitta en lösning efteråt. Det är ju lite olika det där, om det är stora och komplicerade problem, så måste man oftast upptäcka lösningen och problemet ihop. Det är väl en del av Naurs tanke, att man när man programmerar ett system så förstår man också problemet man utgick från. Att utesluta lösningar LD: I och med att du utesluter en lösning så har du oftast lärt dig något mer om problemen, något som du inte hade tänkt på. Du hade antagligen en problembeskrivning som inte tog upp något man måste ta hänsyn till. Därför var lösningen fel. När jag har insett det, då kan jag ta med mig den där erfarenheten tillbaks till problembeskrivningen och säga att allt jag har sagt i problembeskrivningen var rätt, men det var en observation som var kritisk, och som jag inte hade fått med tidigare. Vattenfallsmodellen LD: Det är många idag som jobbar med vattenfallsmodellen på vissa sätt. Man gör en kravspec först och sen implementerar man. Det ställer krav på den som ska använda den här processen att man måste lära sig att ställa kraven i förväg, innan man börjar realisera, det vill säga att det är svårare i någon mening. Och det löser man oftast på företag genom att man har Senior Developers som har jobbat med det här i 20 år och en sådan person kan faktiskt ge en kravspec på förhand för så duktig är han på just den här typen av system. För han har gjort 200 sådana system, och de ser ungefär likadana ut allihop. Men när det blir mer explorativt, när det explorativa och innovativa inslaget ökar, då blir det svårare att jobba vattenfallsmässigt. Iterativt arbete kontra vattenfallsmodellen LD: Att iterera mycket kostar tid. Det är dyrt att iterera. Det är väldigt effektivt att jobba enligt vattenfallsmodellen, om man bara gör rätt. Gör man fel blir det istället 40

52 oftast väldigt dyrt. Det betyder i princip att projektet havererar, och du måste börja om igen. Medan en iterativ metod, med kortare iterationer, är mycket mer robust. Men den har en overhead i det här itererandet. Till viss del gör man om saker för varje varv. Med vattenfallsmodellen hade jag gjort det en gång för alla. Man lever i det gamla industriella tänkandet tror jag, det ska vara effektivt. Men sen blir kvaliteten sämre ibland. Prototyper LD: Det finns olika synsätt. Frågar du Alan Cooper skulle han sätta prototypen väldigt nära det här med krav och problem. Säger du prototyp till en mer programmerarorienterad person från den agila metodiken, då tror jag att man hellre skulle säga att prototypen är den första lösningen. Prototypen är skissen på lösningen och har ingenting med problemet att göra. Problemet är kravspecen, det är en kravinsamling. Men när det går till prototyp, det är just när vi tar steget över från problem till lösning. Och här vi får vi också problem för att man diskuterar lite förbi varandra. Kompetens LD: En dimension som jag tycker är viktig i Naurs synsätt är kompetens, det är en väldigt viktig aspekt. Och då menar jag kompetensen hos de som ska göra det här systemet, kompetensen hos de som ska bygga systemet i någon mening, antingen som en övergripande designer eller som en konkret programmerare och så vidare. Alltså hur ser ditt team ut, vad har du för team? Du har ett team och nu ska du få teamet att fungera. Och det här är på något sätt ett självorganiserande team. Och då kan du inte komma och smaska på och säga att nu ska vi göra prototyper som är problembaserade här, om du har mest Perlprogrammerare. För de vill ha en lösningsorienterad prototyp, de vill ha nånting som hjälper dem. 41

53 Prototyper inom agil metodik LD: Finns det överhuvudtaget prototyper i agil metodik? Det är mer tveksamt tycker jag om man kan tala om det. Agilt tror jag skulle säga så här: vi visade dem det riktiga systemet direkt, det är så här det ser ut idag. Vi håller på med ett forskningsnära projekt tillsammans med ett företag. Då började jag prata prototyp med dem, och då slår de ju bakut allihop. De vill inte ha någon prototyp. De har inte råd att hålla på med prototyper. De vill ha en färdig produkt på en gång. Allting vi gör måste gå rakt in i en färdig produkt, och det tror jag är väldigt vanligt. Det är alltså få förunnat att få hålla på med prototyper när man jobbar i företag som jobbar ganska agilt. Så det är därför man säger att den agila metodiken är som gjord för småföretag, till stor del. Företag som har en stor organisation, som Ericsson, kan ju ha en hel avdelning med HCI-experter som gör prototyper. Men har företaget 20 personer totalt så har du inte råd att ha en person som håller på att göra prototyper på saker och ting. LD: Man kan också tänka sig att frågan är om ska man ha en prototyp eller inte. Vad har man råd med, om man nu ser det som en kostnad. Allting kostar ju. Men du får alltid någonting tillbaks också. Om man säger att man lär sig genom att bygga saker, ja då skulle man kunna använda det som ett argument för att det är ett bra sätt att lära sig, att lära sig genom att experimentera. LD: Man har en fas som är innan lösningen är tillräckligt bra. Innan man har en lösning, så har man en gråzon som är att man håller på att hitta lösningen. Det är den kreativa processen, och där skulle man möjligen kunna säga att man gör en viss nivå av prototyping. Men man skulle kunna kalla det något annat, man skulle också bara kunna säga att det är det här som är programmering. Det är ju problemlösning. Men prototyping skulle kunna vara ett bra ord när den är mer explorativ. 42

54 Agil metodik, prototypning och theory building LD: Vad det handlar om, som jag ser det, är att skapa ett självlärande team, som hela tiden kompetensutvecklas under tiden som man jobbar. Och det är det som är det centrala. Det är nästan viktigare än det man gör, för att då kan man se det som en konsekvens. Blir du riktigt bra på nånting, då gör du bra saker. Så det viktigaste det är att hålla folk bra på det de gör. LD: Om din metod inte är rolig så har du ett problem. Då kommer den inte funka i praktiken, i det moderna industriella klimatet. Det kanske funkade en gång i tiden då man gick på pliktkänsla, men idag är det få som kan jobba baserat på plikt. Därför är innovativitet så viktigt. Så där är det ett skifte i perspektiv på vad som är viktigt. Därför måste det vara roligt, för när det är roligt då gör vi kreativa saker. Är det inte roligt så är vi inte kreativa. LD: Och där tycker jag Peter Naur har den här insikten om att när man bygger ett system så händer det något inte bara i systemet, det händer något inte bara i dokumentationen alltså dokumentationen står inte för sig själv och kommer aldrig att göra det. Det som har hänt har hänt inne i huvudet på dem som har byggt systemet. Det är det fundamentala som har hänt. De här personerna har byggt upp en teori om hur det här problemet och de här lösningen fungerar ihop. Och den teorin har vi i huvudet, och så finns den då avbildad nere i koden, men bara partiellt. Troligen så har vi en massa insikter som inte finns dokumenterade någonstans för att det hinner man inte så att säga, och det kanske inte skulle gå heller att dokumentera på den nivån. Det skulle också bli väldigt oläsligt, det skulle bli väldigt tjocka böcker. Så där har man då människan istället. Så det blir ju ett perspektiv på, om man tar in prototyping i bilden då, om man har den synen på vad det är vi ska stödja. Är prototypen bra eller inte? Ja, det är ju bra om det stödjer att man lär sig, alltså att man får bra theory buildning. Och är det theory building-stödjande då får du antagligen bra cost- 43

55 benefit-balans där. Men om det inte är theory building på ett bra sätt så är det bortkastad tid. Prototyper och kompetensutveckling LD: Du måste jobba med de verktyg som du sen ska använda i projektet. Det ska vara relevanta saker, så vi ska till exempel använda Lucene, en sökmotor för Java, i det här projektet. Då skulle jag kunna ha som ett prototypprojekt: gör något häpnadsväckande med Lucene! Det är jättekul och så gör jag min favorit, hemsida, website, någonting som inte alls har med projektet att göra, men jag blir en hejare på Lucene. Sen tar jag den kompetensen och så flyttar jag över den till det här projektet, och helt plötsligt blir det superbra på en gång i det riktiga projektet. Där finns det ju en spännande koppling mellan prototyping och kompetensutveckling tycker jag. Detaljerade gränssnittsprototyper och kravspecar som hinder LD: De som får ett sådant material som utgångspunkt får en väldigt tråkig uppgift. Och i den här dubbla meningen som Naur säger, dels att dokumentation kommunicerar dåligt, den kommunicerar men det är oftast partiellt. Du får oftast frågetecken, vad menar de med det här ordet, vad menar de med den här meningen? Eller en bild vad menar de med den här bilden? Hela tiden kommer du att stöta på detta, och även om man går till källan så kanske det visar sig att «Aha, det hade jag inte tänkt på!» Och då är det ju nån som har gett sig in och tyckt saker utan att ge hela svaret. Och sen ska du ta över som sagt. Det är en väldigt bra fråga egentligen, alltså både som hinder och möjlighet. Också det om man gör prototyper som inte passar, och får man då en prototyp, någonting som någon annan tyckte att det var jättekul att göra och fick leva ut sin konstnärliga sida, någon som gillar att måla och så vidare. Och så ger du den till en Perlprogrammerare. Det är ju en förolämpning i två steg. Dels är det tråkigt, dels är det som att säga «Hej, jag förstår inte dig. Så jag förstår inte vad du behöver.» Det är det det signalerar. Det signalerar att den som har gjort prototypen har 44

56 ingen aning om vad den här programmeraren behöver för att kunna utvecklas. Man har gett helt fel saker, och det är ju väldigt vanligt i det här kriget, som man säger, mellan utvecklingsavdelningen och andra avdelningar. Agil och traditionell utveckling LD: En skillnad mellan agilt och traditionellt är att i agila företag är ju oftast alla programmerare. Man har alltså bara en sorts människor, yrkesrollsmässigt. Så man har en ganska rund kompetensprofil. Sen kan man ha olika specialiteter, men man har ändå en kärna där alla delar samma värden. Sen kan de välja olika inriktning på den här programmerarkompetensen, men det är ett medvetet val. Många andra har mer traditionella approacher; då har man väldigt olika sorters människor, med olika kompetens, sub-kompetenser, så man har lång utbildning och har specialiserat sig på något, och sedan ska de här människorna försöka samarbeta med varandra. Och då blir det ett kommunikationsproblem. Prototypa eller inte, det kanske inte spelar någon roll hur bra prototyp du gör för att de här människorna kommer alltid ha problem att kommunicera med varandra för att de har för olika erfarenheter. Den ena kommer hela tiden ge postit-lappar som lösningar, och den andra kommer att säga att jag vill inte ha postit-lappar. Och sen kommer man inte vidare. Prototyper och kostnader LD: Kanske är det så att de som vill ha mycket prototyper oftast är problemorienterade individer. Medan lösningsorienterade individer vill ha minimalt med prototyper. Den ena gillar det och vill dra ut modellerna och göra komplicerade saker, för det kostar ingenting på papper. Medan den som bygger sakerna, för den kostar varje sak flera veckors arbete, så att varje sak som ska in i verksamheten avväger man väldigt noga. Är det värt att ta steget? Ska vi verkligen göra en prototyp i det här projektet? Det skulle vara en stor fråga för en lösningsorienterad individ då, medan för en problemorienterad individ så kan det vara «ja, jag kan gärna göra en prototyp». Frågan 45

57 kompetens kreativ process prototype dokument problem? teorier prototyp? designer lösning? handling prototyping användare krav praktik system stakeholder intressent Figur 14. Den ursprungliga versionen av begreppsmodellen inklusive anteckningar under intervjun med Lars Degerstedt. är då om det är så att det finns en tredje väg här så man kan få med på något sätt att man inte har en prototyp i traditionell mening. Men man gör en prototyping. Om vi tar Highsmith med det innovativa synsättet på utveckling: Där kan man se att man ständigt experimenterar när man utvecklar ett system. Och det skulle man ju kunna kalla för prototyping, eller i alla fall något besläktat. Experimentell utveckling LD: Man kanske inte har något som heter prototyp egentligen, alltså det begreppet blir inte så centralt, utan efter den här experimentella fasen så får man ett, kanske partiellt, men fungerande system. Och Highsmith säger då att det viktiga är att metodiken stödjer experimentellt arbete. Så i den meningen kan man ju säga att den agila metodiken stödjer prototyping. Men däremot så använder man inte begreppet prototype så mycket. Han har hoppat över det mellansteget. 46

58 LD: En annan intressant sak om man jobbar experimentellt är att man ju måste inse att man kan inte göra designer «up front» längre. Man vet inte vart projektet kommer att ta vägen. Det är dessutom så att man kan inte lägga fasen i början ens, för att varje dag under projektets gång kommer man att vara experimentell. Man börjar experimentellt, man kommer att sluta experimentellt. Men det som blir viktigt då, och där kopplar det lite till lean production, det är att man måste ändå ha en förutsägbarhet i att processen måste generera bra saker. Det får inte vara så att man misslyckas. Begreppet misslyckas får inte finnas så att säga, utan det måste vara förutsägbart att den här processen kommer att spotta ur sig bra saker i ett jämnt tempo. Men exakt vilka de här sakerna är, det är det vi inte vet. Vi vet att vi har en bra process, och det här det ska vara roligt, det ska vara kreativt och så vidare Intervju med Arne Jönsson Intervjun genomfördes 12 april på Linköpings universitet. Arne Jönsson är professor vid Natural Language Processing Laboratory vid Institutionen för datavetenskap, Linköpings universitet. Nedan följer utdrag ur intervjun. Prototyper som verktyg AJ: Jag skulle mycket väl kunna tänka mig att designern/ utvecklaren tillsammans med intressenterna diskuterar beställningen kring en prototyp. Jag tänker mig gärna en lo-fi prototyp, en pappersprototypsliknande sak. Den tror jag skulle kunna fungera som ett verktyg för beställningen. Jag ser prototypen väldigt mycket som ett verktyg. När den blir hi-fi prototyp, det är svårt att säga egentligen. När det gäller problemrymden och lösningsrymden, så handlar det ju någonstans om att förstå problemet. Och det menar jag att en prototyp skulle kunna hjälpa till med. I min begreppsvärld så blir det då svårt för sen övergår lo-fi prototypen till något annat, beroende på problemet blir det antingen till en hi-fi prototyp 47

59 eller, om man tänker agilt, till en första prototyp av det som ska bli det fungerande systemet. AJ: Prototypingen finns med som en väldigt väsentlig del här i övergången från problem- till lösningsrymd. Och här skulle jag nog vilja börja blanda in användare. Jag menar har du ett stort projekt med mycket folk och du ska göra nånting väldigt stort och väldigt komplicerat, då kan du mycket väl ha en designgrupp som börjar designa beteendet och börjar designa en första hi-fi prototyp när de har förstått problemrymden. Och sen så ska den hifi prototypen realiseras. Det är en syn på stora projekt som jag har. Och det är en syn som har växt fram; den går någonstans stick i stäv med en del av det där som användbarhetsexperter pratar om att vi skulle vara med tidigt i projektet, och inte komma in och rätta till felen i efterhand. Olika användningar av prototyper AJ: Det är två syner, som beror på projektstorleken, tror jag, och naturligtvis karaktären hos projektet. Säg att du ska utveckla en interaktiv webbplats av avancerat slag. Du kan köpa och sälja bilar, eller boka hotell eller något sådant. Så du ska utveckla något ganska avancerat, som går ut och söker i databaser. Du skulle misstänka att användarna har en väldigt stor betydelse i inledningsfasen också. Så att man får så att säga designen av interaktionen. Så att man får en förståelse för de tjänster som man vill använda. Så att man inte börjar att utveckla saker som inte kommer till att användas, eller som inte är intressanta eller som har en annan prioritet. Och där tror jag att användarna är inblandade. Men om du istället tänker att du ska utveckla en växel för mobiltelefoni som ska skötas av en operatör som ska kunna se hur hårt belastade masterna är och så vidare, då skulle jag kunna tänka mig att man inte behöver ha användarnas aspekter med lika tydligt, alltså de som ska köra systemet sen, utan då måste beställarnas krav komma in lite tydligare, de som begriper hur masterna kommunicerar med varandra och allt sådant. Och den kravspecen kan å andra sidan 48

60 växa fram tillsammans med intressenterna utifrån en prototyp. Men användbarhetsaspekterna på prototypen behöver inte vara lika väsentliga. Men för att beställaren ska förstå sitt problem, vilket de inte säkert gör, då de kan ha en vag bild av vad det hela går ut på, kan en prototyp hjälpa till. Men inte en prototyp i syfte att förstå hur man använder systemet, utan i syfte att förstå vilket problem som finns när de ska designa systemet. Det måste vara ett skäl till att prototyper och prototyping blir besvärligt som begrepp, att de används i så många olika typer av projekt. Problem med prototyper AJ: En fallgrop skulle naturligtvis då kunna vara att man fokuserar för mycket på de problem som för närvarande ligger för handen, och inte ser till den helhet som man skulle kunna ha. Om vi går in i någonting så skulle du kunna riskera att ägna för mycket tid åt funktioner som kanske inte ger störst genomslag på den slutliga produkten. Och det kan ju också finnas en risk för att du missar funktioner, som du inte har tänkt på. Därför att det inte finns en stor beställareundersökning. Olika slags prototyper AN: Det finns ju något man kallar implementationsprototyper. Det är två personer från Apple som har skrivit om tre kategorier av prototyper i slutet på 90-talet. Man talar även om designprototyper och funktionsprototyper. AJ: Så funktionsprototyper skulle vara det som ligger nära agil utveckling. Och designprototyp är det med lofi, hi-fi. Och sen så finns där alltså då implementationsprototyper. Betatestning AJ: Lite kritiskt menar man ju att man gör det för att man inte vill betala för testningen. Men mot det kan man säga att det är ju så komplext och diversifierat idag att det skulle inte gå att fånga alla möjliga olika användare, 49

61 och alla möjliga olika maskinvaruplattformar. Det skulle inte bara fördyra, det skulle nästintill vara omöjligt också därför att det finns oändligt många användare och det finns oändligt många sätt att konfigurera datorer på Intervju med T. Nilsson och A. Larsson Intervjun genomfördes 17 april på Linköpings flygplatsrestaurang. Bägge intervjupersonerna är verksamma inom Responsive Development Technologies AB, ett företag i Linköping. Thomas Nilsson är CTO och Agile Mentor, med en bakgrund som civilingenjör i datateknik. Han har erfarenhet som utvecklare, systemarkitekt och ansvarig för utvecklingsverktyg och metoder i ett stort antal projekt i många olika företag. Andreas Larsson är CIO och Senior Agile Consultant. Han har civilingenjörsexamen i datateknik. Andreas har arbetat med utveckling och systemdesign i både produktmiljö och kundanpassningsprojekt, it-strategier, projektledning, utredningar/utvärderingar av teknik och system. Nedan följer utdrag ur intervjun. Prototypning eller inte TN: En av de viktigaste aspekterna av utveckling är att man får nånting, att man får nån nytta av den. Och en av de saker som jag ömmar för är att man har täta cykler, det vill säga att man har feedback mellan användare och så. Så det kan man ju använda prototyper till: att så att säga skaffa sig information om vad användarna tycker. Min erfarenhet är att det är ofta så att prototyper får ett liv för sig själva, där man lägger ner för mycket energi på att bygga prototypen för att verifiera nåt som man nästan kunde gjort i produkten, det riktiga systemet som man sen levererar. Och mycket av de moderna utvecklingsmetoderna säger ju egentligen att ja, det är bättre att bygga systemet och faktiskt få en konkret återkoppling på hur det beter sig, än att göra en prototyp. Bara så där lite kort så skulle väl jag kunna tycka att det är okej att göra prototyper men de måste vara mycket begränsade i insats. I extremprogrammeringen pratar man ju om spikes, alltså ett snabbskott, utväxt på AL: ett testskott för att se om det här är en hållbar idé, som man inte måste göra nån form av programmering 50

62 eller prototyputveckling för, man kanske bara ritar upp nånting egentligen för att diskutera «är det här användbart eller inte». Prototyparbete TN: Och det kan väl jag också konstatera i ett antal projekt som jag har varit med i att när man tänker sig att göra prototyper så fastnar fokus på prototypen istället för på produkten. Det gäller ju när prototypen är så att säga likadan som produkten man tänkte producera. Det finns ju andra sätt att göra prototyper, till exempel matematiska modeller eller så att säga andra typer av prototyper som inte är likadana som produkten. Och pratar vi programvaruprodukter, applikationer, gör man då en applikation som en prototyp så skulle jag nog säga att det är lite bortkastat, för att hårdra det. Däremot att vi har prototyper för användargränssnittet, för att modellera upp det bara på nåt sätt, i powerpoint eller vad som helst. AL: Det kan ju vara så att utvecklingsteamet har två idéer eller inriktningar på till exempel användargränssnittet: endera kan vi gå den här vägen eller så kan vi gå den här vägen. För att få en bra dialog kring det så behöver man visa lite grand vilka fördelarna och nackdelarna är med de olika idéerna. Då kan man ju ha prototyper. Men om vi går tillbaks till ren systemfunktionalitet då, och inte bara användargränssnittet utan prototyper av systemet så kan man tänka sig i vissa lägen att man kan bygga en prototyp. Ta bildbehandling som exempel, där kan man utveckla en viss sorts algoritm i Matlab eller något annat högnivåverktyg, där själva beräkningen eller själva idén bakom det man ska bildbehandla fram går att göra ganska fort. Men den slutgiltiga implementationen måste man sen sitta och optimera beroende på vilken processor man ska köra och så vidare. Algoritmdesignen kan man då prototypa fram medan implementationen för det som ska användas i till exempel en röntgenkamera eller någonting sånt skulle kunna ta flera månader, innan man kan implementera på den korrekta hårdvaran och så vidare. Det kan vara en typ av prototyparbete också. 51

63 Vad är en prototyp? AL: Jag tror att det här vilken benämning man använder och vad prototyp betyder är ganska domänberoende. Om du pratar web-databasapplikationer, då kommer prototypsbegreppet bara att handla om användargränssnitt, möjligtvis att man gör några HTML-saker bara för att inte ha nån koppling till nåt riktigt system bakom sig. Om du pratar prototyper i samband med att du tar fram radarsystem, eller en radar, en apparat som ska sitta i ett flygplan, då kommer prototypen att vara den första apparat som fungerar men som inte är byggd för serieproduktion. Den är kanske lite för tung, den har för stort kraftaggregat, och den är producerad på ett manuellt sätt och inte på ett automatiserat sätt. Då kallar man det för en prototyp. Det kanske finns prototyper som inte ens får flyga omkring, utan bara får sitta i en simulerad omgivning, men som ändå har korrekta processorer, det är korrekta interface och så vidare till omvärlden på den. Där har du ju ett prototypbegrepp som skiljer sig ganska mycket. TN: Jag skulle vilja tänka mig prototyper som sådant man gör bara för ett specifikt användningsområde, som inte är rätlinjig till den riktiga användningen. Förhållandet mellan prototyp och produkt AL: Om man tänker sig att det här handlade om någonting, säg en såg, då kanske du kan visa hur den ser ut, du kanske till och med kan känna hur den känns i handen, men det går inte att såga med den. Då är det ingen som kan sälja den som den ser ut. Men anledningen till att kunden vill göra nånting som är mjukvarubaserat, det är ju, du vet att det faktiskt fungerar, till stora delar. Det är ju en egenskap hos mjukvara, som finns där. När du har utvecklat nåt som fungerar så går det att använda direkt. Det finns inte något produktionssteg, som vi ju har pratat om. Det räcker med att kopiera över det så går det att använda det till just det det fungerar till just nu. Men en såg som inte har vassa tänder, den går inte att använda. 52

64 Och generellt så är det här problemet, eller ett problem och en möjlighet, något som man måste kunna hantera när man gör produkter som innehåller mycket mjukvara; möjligheten att använda nånting som inte är 100 % färdigt enligt någon viss spec eller enligt ett visst önskemål. Det räcker med att du gör 30 % av den funktionaliteten så är det fortfarande användbart. Var går gränsen mellan vad som är prototyp och vad som är nånting som jag kan använda fast inte till allt jag skulle vilja använda det till egentligen? Mjukvaruprodukter har ju den egenskapen att det finns ingen gräns där. AL: Då kan det ju behövas att man har lite disciplin inom ett företag som gör att man kan använda sig av prototyputveckling eller demonstratorer eller vad du vill kalla det för, som då inte är produktfärdiga. För de mjukvaruprodukter eller mjukvarubaserade system eller produkter som finns idag har två syften. Det ena är att de ska lösa en uppgift, de ska funka för nånting, och så ska de i alla förekommande fall vara grund till fortsatt utveckling. Det finns inget system som byggs idag som man inte tänker bygga vidare på, eller vill ha möjligheten att bygga vidare på. Och det är det som gör att det inte är okej att fulhacka in nånting längre. För det är inte så att man jobbar fram till den 19 maj och sen är det klart, utan vi jobbar fram och sen så börjar du att använda dig av det, och kommer med all säkerhet att fortsätta att göra mer funktioner och bredda produkten, bygga vidare på den och så vidare. Så om man inte gör produkter så att de är både funktionsdugliga och en bra bas för att bygga vidare på har du bara löst halva ditt problem. Och där är det många som fastnar, som bara har gjort den ena delen. Det är alltid den ena sidan av någon konstig anledning. TN: Det är ingen fara om du säger att din konkurrent har kommit med en produkt, så kommer du med en prototyp illa kvickt. AL: Men sen är frågan, bara för att du har varit i deras monter och sett på den, vet du då om att de har en produkt eller kan det vara så att de bara har en prototyp de 53

65 också? Mycket av det vi jobbar med handlar ju om att man ska jobba på ett sånt sätt att man får fram prototyper och produkter hand i hand. Att man har ett arbetssätt för systemutvecklingen som ser till att man inte glömmer bort det här, den kompletta produkten. AN: Det finns ju det här att man inte fulhackar utan att man bygger nånting bra men använder det för att visa upp också längs vägen. TN: Den modellen tror vi mest på. Det vill säga att man faktiskt gör äkta produktutveckling i sitt produktspår men man börjar inte sälja den förrän man fått upp tillräckligt mycket funktionalitet. För varje sånt litet steg är så att säga färdigt ur produktperspektiv, eller produktfärdigt eller vad vi ska kalla det för. Och för varje sånt litet funktionellt delsteg så kan man ju visa upp sig. AL: Om man ska jobba på det här sättet som vi tycker att man borde jobba på, så utvecklar man funktion för funktion genom hela systemet. Om du har ett system som kan exportera till olika filformat till exempel så tycker vi att man ska lägga till ett filformat i taget, medan en säljare som ska åka på en mässa kanske hellre vill kunna klicka på knappen, exportera och så finns det sju filformat, och så är det bara det ena som funkar, och eftersom han demonstrerar så vet han vilket han ska välja. Det finns ju olika behov där också då. TN: Men det kanske är mycket det det handlar om att om man vill göra en prototyp så måste det på nåt sätt synas att det är en prototyp. Så ser produkten förvillande lik ut då kommer ju alla att lura sig, för då kommer de att säga «ja men den finns ju där, det är väl bara att sälja nu». Om man däremot har sju val men sex av dem är liksom utsuddade, eller nåt annat, en varningstriangel på dem eller något sånt, då finns det ju ändå nåt att hålla i och säga «ja men den här aspekten är inte färdigutvecklad». Det är lite det som en tillverkningsprototyp gör. 54

66 Gränssnitt som ser «färdiga» ut TN: Ett intressant experiment vore ju helt enkelt ungefär det som jag sa. Det vill säga man har en enkel switch, och switchar om från XP-look till Windows 3.11 eller något sånt, det är ju lite mera fyrkantigt, utan rundade hörn och så, och liksom gadgets i övrigt av enklare sorten. Vad skulle det få för psykologisk effekt på användarna? AL: Jag tror nästan det skulle räcka med att man gjorde det svart-vitt. Självklart, det här är inte på riktigt. Det skulle man nog kunna använda, man skulle komma en bit på vägen. Som du ser på Windows XP innan du ska stänga av till exempel, så tonar den över lite till grått. Då ser man ju också att det här är någonting som är på gång att hända. Det här är utanför normal användning. Så det kanske inte fungerar definitivt så som det ska. Jag har aldrig sett det användas i prototypsammanhang. Dokumentation av återkoppling AL: Och är det så att det finns krav som säger att den här designen vill vi av någon viss anledning ha här, då är det inte bara ett prestandabeslut utan då är det ju faktiskt då ett krav på någonting. Och sen om, man brukar ju kalla det för designbegränsningar, krav- och designbegränsningar, den här funktionen ska ni ha och vi vill att ni ska göra det på det här sättet. Så när kunden har en åsikt om att det ska göras på det här sättet, att det ska fungera på Windows XP för att det är det som används inom den här branschen till exempel, eller Macintosh. Så är det ju så att en del av resultatet från prototyparbetet borde komma in i kravbilden så som designbegränsningar, tror jag. De som man är väldigt noga med att man inte får råka plocka bort senare på det här sättet, men om du sen byter ut en lista mot ett flervals-, alltså du byter en komponent, det har förmodligen liten betydelse. Men om du kan göra drag and drop på en sak, det kan ha väldigt stor betydelse för de som använder den. TN: Jag tänkte på det här du sa om att dokumentera designbeslut på grund av prototyper. Det hänger väl egent- 55

67 ligen ihop med det som du anförde som är syftet med en prototyp nämligen den här kunskapsinsamlingen. Så man borde ju, om vi nu har diskuterat prototyper som försteg till vår produkt ganska mycket här nu ett tag, så det andra spåret är ju när man försöker fokusera på kunskapsinhämtningen. Och ett sätt att betrakta det är ju att den typen av prototyper, vilket jag tycker är de riktiga prototyperna, blir ett litet projekt. Det vill säga att man gör det här för ett visst syfte, man genomför det, man gör en analys och någon slutsats. Och där borde ju det här finns på något sätt då. Att bara liksom slänga det där och sen så gå vidare känns ju som att då har man slängt bort ett helt miniprojekt. TN: Alltså de här prototyperna jag tror vi pratar om är till för utforskning, inte för kunskapsinhämtning, vilket är en av skillnaderna i syfte också. Okej, det är klart att det är kunskap. Men det är ju någonting som vi inte visste. Det fanns ingen som visste, ingen som har dokumenterat hur den potentiella användaren tror att vår produkt betedde sig. Det visste vi inte. TN: Det finns ju ett sätt att hantera det här och det är att man ser till, till exempel om det är ett team som gör gränssnitt och tar beslut där, och sen har du ett annat team som ska bygga. Då har du en person som följer med över, och åtminstone träffas ibland med de som ska utveckla det, för att det är så svårt att fånga det här i dokumentation. Då gäller det ju att man har någon kvar också ett år senare när man ska bygga vidare. Spikes i extreme Programming TN: Nej, just det. Men vad jag tänker på är just att om man sitter i ett större projekt där man vet att vi behöver veta hur våra användare beter sig, att då sätta igång fyra människor som ska jobba med prototyper, för att ta reda på det när vi inte ens vet vad vår produkt ska göra, det blir liksom fel. Utan det måste vara att ja, vi har tänkt ut att den här funktionen måste vi ha nu, fast vi vet inte riktigt hur den ska vara designad, eller hur interaktionen 56

68 med användarna ska se ut, eller om de behöver de här attributen eller inte. Då gör vi en prototyp för det. Och då kan vi återmata precis det här in i vår design och i det här steget. Och det är därför jag gillar XP:s modell med spikes, för de utgår från att vi faktiskt skulle implementera en user story i vår produkt. I det syftet gör vi något sådant för att ta reda på hur var det här då, gick det här? AL: XP skiljer ju då på såna här spikes. Det är verkligen throwaway-principen. jämfört med att det är helt okej att bygga en funktion i nästa iteration för systemet, för att se om det här var något att ha. Det är också okej att göra, men då gör man den på riktigt, då är det testfall som gäller. Då ska den releasas tillsammans med allt det andra, dokumenteras tillsammans med det andra och så vidare. Men det är helt ok att prova sig fram i produkten också, medan då de här spikes-grejerna det är riktigt throwaway så att säga. Så där skiljer man ju ganska snyggt åt på det som verkligen är det som man kallar för spike, de har ett eget ord för det till och med. Prototyper i DSDM AL: DSDM pratar ju mer om prototyper faktiskt. De kommer ju från prototyping, alltså de har ju rekommenderat prototyparbete mycket. De är på väg bort lite grand ifrån det. De hade väl planer, alltså det var väl mycket prototyp i början, eftersom det har hållit på ett bra tag med DSDM så var ju prototyper ganska hett när de satte igång. TN: De kommer ifrån RAD-miljön också då, från Rapid Application Development. AN: Jag har undrat över det för när jag har läst om DSDM så får jag olika bilder, men det är sån utveckling som har skett då att man tonar ner den sidan. AL: Vi var på en konferens i London i höstas, och ordföranden i DSDM pratade lite där. Och han fick just frågan om prototyper: det här med prototyper kändes 80-tal var det någon som tyckte. DSDM är ganska tungt på prototyping i sin processbeskrivning. Då sa han just det att där 57

69 är det någonting som vi håller på att tona ner lite. Vi försöker arbeta med språket för att skilja kanske på prototyp och att visa upp produkten tidigt. De hade väl hamnat i det här problemet med vad som är en prototyp och vad som är tidig återmatning. Och i deras fall hade det nästan alltid handlat om tidig återmatning. AL: Och sen just att det kommer från den tiden när det här var väldigt hett. Då försökte man kanske applicera det på lite fler ställen än vad man så här i efterhand finner är lämpligt. Kravhantering och utvecklingsmodell AL: Att man designar för mycket i onödan för att du kanske får en massa krav, eller en massa behov som kunden har. Sen sätter du dig och skriver use-cases i två år. Du kanske jobbar med den här kravbilden för att designa, arkitekturera ditt system så att det har allting som kunden har sagt. Det här kastar ju de ihop på tre veckor. Sen sitter du i ett bra tag. Och sen så har du då designat ett system som det kommer ta åtminstone ett år att bygga. Och sen, när du kommer att mata tillbaks nånting, ja för det första så är den informationen som de gav dig från början inaktuell sen länge på många punkter, ogenomtänkt på många ställen, dåligt beskriven, dåligt förklarad och så vidare. Inkonsistent mot sig själv och så vidare. Och visst, då kan vi ju stå där och skrika att ni fick vad ni beställde, men då får vi inga fler uppdrag från den kunden. Eller också kan vi säga, kom hit och prata i några dar om de här funktionerna som vi tillsammans kommer överens om är de mest intressanta. Så pratar vi mycket om dem och sen så implementerar vi de mest centrala funktionerna och så visar vi dem. Så att man snurrar hela den här rundan. Man snurrar inte bara här [lösningsrymd och problemrymd], utan det här ska med, och det där ska med [behov och system]. Om du bara gör det här [lösningsrymd och problemrymd], då riskerar du att du bygger en funktionstillväxt inkrementellt. Men du får ingen feedback för du tar inte hand om anledningen till att du ville göra den här funktionsstegen, det var att nå- 58

70 gon skulle titta på det och säga är det här bra eller är det här dåligt. Gör du bara den här loopen [lösningsrymd och problemrymd], då tappar du det Intervju med Mårten Herberthson Intervjun genomfördes 17 april hos Lawson i Linköping. Mårten Herberthson arbetar som domänarkitekt och projektarkitekt hos Lawson. Nedan följer utdrag ur intervjun. Prototypning och design MH: Min erfarenhet av prototyper är den att jag upplever att den faktiska användningen av prototyper och hur man kanske förväntas använda prototyper i utvecklingsarbetet inte riktigt stämmer överens. Ofta kan man ju till exempel tänka att man först ska göra en design, man kanske gör en prototyp som hjälper en att göra en design eller validera designen och så vidare. Och sedan kanske man till och med förväntas kasta en prototyp. Men min erfarenhet är mer att man gör inte en design, i den bemärkelsen att man gör det på ett papper först. Det kanske man gör väldigt schematiskt, så att man får en mer konceptuell design, på ett väldigt övergripande plan. Men så fort man kommer ner till detaljfrågor sätter man sig helt enkelt ner och kodar en prototyp. Och det vävs samman med designarbetet, så att designen och prototypen går parallellt. MH: Angående det här med att kasta prototypen och börja om: Jag har varit med om det några enstaka gånger, men då är det mer beroende på att man helt enkelt under prototypfasen insett att man är helt fel ute. Däremot om man upplever att det här har funkat ganska bra, då utvecklas prototypen helt enkelt till att bli den slutgiltiga produkten. Happy days MH: Ofta är det så att om jag ansvarar för att ta fram en ny produkt försöker jag göra det vi kallar ett happy days-scenario. Det är en konstig term egentligen. Det är 59

71 Kruchten som för länge sedan var på besök här och lärde oss hur man gör UML-diagram. Nu använder vi inte UMLdiagram så mycket, men en idé som han hade när det gällde prototyping var väldig användbar tycker vi. Låt oss säga att du ska ta fram en produkt där till exempel performance är det centrala. Då gör man en prototyp där det första målet med prototypen är att få ett komplett flöde, även om flödet har massor av brister. Den kanske inte har felhantering, den har inte specialhantering för något udda fall, utan bara det enklaste flödet som ändå är det som applikationen oftast gör. Och det är det som kallas happy days-scenario: Allt går bra, och det finns inget behov av felloggning. Det finns inget behov av sådana saker. Och tanken är då att man så snabbt som möjligt får upp det här happy days-scenariot, att man så snabbt som möjligt kan börja mäta på saker som ger den här designen tillräckligt bra performance. För det var det som var det viktiga för mig i det fallet. Och man kan helt plötsligt börja göra lite mer problematiserade tester, och vartefter man då får mätvärden på det här kan man använda dessa i arbetet. Om jag måste gör en omdesign någonstans, så kan jag direkt få feedback, om den här omdesignen innebär att performance ändrades antingen negativt eller förbättrades. MH: Ganska tidigt försöker vi göra en prototyp som, även om det är väldigt tunt, går hela vägen igenom. Applikationen gör vad den ska. Målet med det är ju att så tidigt som möjligt upptäcka allvarliga brister i sin design. Här ser man ju också igen hur prototypandet och designandet vävs samman i någon mening. Jag utvecklar program på serversidan. Om man däremot arbetar mer på klientsidan, då kan det ju finnas behov av att göra prototyper av lite andra skäl. Man kanske vill göra en prototyp för att visa för kunden hur det kommer att se ut. Man kanske vill mäta användarinteraktioner och sådana saker. För mig handlar det mer om performance, skalbarhet, att koden löser funktionaliteten som den ska. 60

72 Designprocessen MH: Jag har lärt mig av ren erfarenhet att om man sitter för länge och designar på papper, så är det bortkastad tid, för det visar sig alltid att när man väl börjar koda att det kommer saker som man inte har tänkt på. Så det gäller att designa på papper, när syftet med pappret är till exempel att skaffa sig en samsyn i projektet om vad det är vi ska göra. Så att man måste ha en whiteboard eller ett papper där man bollar idéer och får en gemensam bild av det är det här vi vill göra. Men när alla är överens om vad som ska göras, då är det bättre att börja koda och hitta problem. Det kanske dyker upp specifika problem som man går tillbaks till och börjar designa på papper. MH: Jag har ibland jobbat i projekt där man försöker följa till exempel RUP-processen. Det sägs ju alltid när man klagar på RUP, att RUP är helt konfigurerbart, att det är fel på din konfiguration om du tycker att processen är dålig. Men jag håller inte riktigt med, för att i alla fall i den normala tolkningen av RUP har man olika roller som gör olika saker. Jag har varit med i situationer där jag har rollen som arkitekt eller designer i ett projekt, sedan så kanske vi har en nyanställd person där jag också har ansvar för att vara hans mentor. Rent projektmässigt är jag arkitekt kanske, och jag förväntas göra designer. Sedan på ett helt annat plan så är jag dessutom mentor för en person som jag ska försöka lära upp. Och då enligt RUP så är det så att jag kanske ska göra en design, och sen ska jag sätta den i näven på den här personen, och han ska kanske implementera den. Men det strider mot min fundamentala målsättning när jag är mentor. Om jag gör allt tankearbete och sen sätter en färdig lösning i näven på honom och han bara ska stansa ner det så att säga, då kommer han inte att lära sig någonting. Så jag anser att det är mycket så att varje individ så att säga får hantera hela cykeln: här har vi ett problem, både designa lösningen och implementera den. Hela den här cykeln med att göra testkod och ta fram en design, det får han då lösa för då kan jag få honom att utvecklas. Så att här pågår det ju saker i olika skalor så att säga. Det finns en 61

73 liten sak, en större sak, och hela systemet kanske. Så att arkitekten kanske mer ansvarar för designen av att hela systemet hänger ihop, men inte designen ner på detaljnivå i varje läge. AN: Det är ju en allmän fråga inom utveckling att det sitter en person och gör en väldigt detaljerad specifikation, och sen lämnar över till någon annan som «stansar koden» så att säga. Det är ju ett upplägg som förespråkas. MH: Ja, och jag är totalt emot det, därför att jag anser att för personerna som sitter och bara kodar ser man ju inte till att de utvecklas maximalt så att de är så nyttiga som möjligt för företaget. Den enda situation där jag kan tänka mig att det där är relevant, det är om man har en outsourcingsituation med Indien till exempel. Man måste göra en väldigt exakt design och sen skicka till någon som kodar. Men inte ens då tycker jag att det är bra för att min erfarenhet, rätt eller fel, är trots allt att enda sättet att få designen att bli korrekt, det är att göra en prototyp. Så om jag har gjort en prototyp, då är frågan varför ska jag skicka den till Indien, jag kan lika gärna göra klart det sista själv. Enda skälet till att man ska lägga ner väldigt mycket tid på att designen ska bli korrekt innan man ska börja koda, det är frågan om hur dyrt det är att korrigera fel senare i processen. Jag förstår mycket väl att om NASA skickar iväg en satellit som är svår att reparera i efterhand så måste man tänka efter mycket i förväg. Men när man tar fram mjukvara så kan man göra tester innan man skeppar den till kund, och man kan till och med rätta buggar efter leverans. Det påverkar lite grand vad som är mest kostnadseffektivt så att säga. MH: När jag leder ett projekt som arkitekt är jag väldigt fokuserad på risker. Jag försöker alltid attackera det som är störst risk först. Och då kommer man in på det här med kostnaden för att göra en rättning. Låt säga att rättningen är att i user-interfacet så har vi felstavat ett ord, det är relativt enkelt och relativt billigt att fixa. Men låt säga att designen på servern är fel, vi valde en stateful model istället för en stateless model, och helt plötsligt kan 62

74 vi inte skala ut till många samtidiga användare. Det är ju en jättestor kostnad. Det krävs antagligen en total redesign. Så att det är ju en stor risk då. Om jag upplever att det är en stor risk att skalbarheten inte blir tillräckligt bra, då kommer jag genast börja mäta på det så tidigt som möjligt. Så prototypen syftar då till att ta bort de här stora sakerna, som blir väldigt, väldigt dyrt att korrigera sedan. MH: Vi har ju ständigt behovet av att alla våra applikationer måste gå att internationalisera. Det är ett ganska komplext område. Det är komplext att förstå problembilden som vi har, och att se till att det fungerar. Men å andra sidan, när man väl har tagit sig över den tröskeln, då kan man gå ganska mycket på rutin. Man har en lösning som fungerar sedan tidigare och den kan man ta med sig. Utvärdering AN: Brukar det vara så att det är nån annan som utvärderar ens prototyper, eller utvärderar man dem själv? MH: Man kan väl säga att det är både och i den bemärkelsen att man utvärderar själv först Och sedan går det vidare till ens projektmedlemmar. Men det är nog inte någon formell granskning. Ibland förekommer det att vi gör en formell granskning, men då kan det vara ett specifikt syfte med det. Vi har det inte som ett obligatoriskt steg, men det händer att vi gör det, men då beror det ofta på att vi har ett specifikt behov, att det funnits ett problem. Vi har formella granskningssteg, fast det har inte så mycket med prototyperna att göra, utan mer med när produkten närmar sig leverans. Då är det ju formella tester och det är acceptanstester av kunder och så vidare. Men vi har inte formella sådana steg under själva prototypandet. Dokumentation av prototypning och designval MH: Vi dokumenterar vissa val, men skälet är kanske ibland så att säga lite mer tråkiga skäl än goda skäl. Om 63

75 vi står inför ett val, och till slut så har vi en lång tankeverksamhet kring det. Det kanske finns en grupp inom organisationen som förespråkar det ena valet, en annan grupp som förespråkar det andra valet. Och sedan så har man någon form av brainstorming omkring det här, och någonstans så leder det fram till någon form av beslut: Vi går på det spåret. Då kan det rent av vara att man gör så för att slippa trassel. För den här gruppen som inte tyckte att beslutet var bra, de kommer hela tiden att ifrågasätta: «Varför gjorde ni det här valet?» Då är det av ren erfarenhet bra att dokumentera hur man gjorde det där valet. Men annars har vi ganska lite dokumentation i och för sig, implementerade testfall är ju i någon mening en form av dokumentation. Och sedan har vi ju också ofta dokumentation på övergripande design för att man kanske hamnar i olika möten, man måste ändå visa en PowerPoint-presentation som förklarar vad som kommer att ske. Så på den nivån finns det ju alltid lite material. Sedan, ju närmare man kommer färdig produkt, desto mer formell dokumentation uppstår. Det blir ju då dokumentation för hur man installerar det, hur konfigurerar man, hur använder man det och sådana saker. Så att visst dokumenterar vi, men man kan säga att ju tidigare man är i cykeln, desto mindre formellt är det, och ju närmare man kommer slutet desto mer formellt är det. AN: Jag tänker på att det här är ju någon slags kunskapsutveckling, man utvecklar kunskap kring det man ska bygga. Och risken blir ju då att man upptäcker någonting med en prototyp, och därför väljer man ett nytt spår. Men om inte det är dokumenterat, då kan det ju hända att man ännu längre fram börjar böka med det här och tycker att så här borde man ha gjort. Och så gör man om det från ett spår som du kanske varit inne på, men som inte fungerade. Man utvecklar kunskap i samband med prototypandet, men tar man tillvara på den? MH: Det där är ett problem. Jag vet ju i vår grupp till exempel, vi har ju individer som till exempel har varit med om att driftsätta sådana här applikationsservrar hos kunden. Och nu när vi implementerar en ny, vi håller precis 64

76 på med en ny version av den här, så bland de möjliga lösningarna så plockar de rent automatiskt vissa lösningar som de av erfarenhet vet fungerar ute hos kund. För att de vet att den där lösningen kan se jättebra ut på ytan, men vi vet att vissa kunder i Sverige kör på det sättet och det blir inte bra. Och det är ju en jätteviktig kunskap som den personen besitter, men den är inte dokumenterad. Och inte ens efter att han har gjort valet så dokumenterar han ner varför, utan för honom är det bara en självklarhet Intervju med Tomas Volavka Intervjun genomfördes 13 april hos WM-data i Norrköping. Tomas arbetar som senior konsult. Specifikationer TV: Som jag sa förut har jag inte jobbat på WM-data så länge och jag har inte deltagit i själva prototypandet än så länge här. Däremot har jag varit med om det genom andra företag som jag varit anställd vid, där man haft en uttalad metod för hur man ska gå tillväga. Då ingick bland annat själva prototypningen ganska klart i processen eftersom man i det fallet sålde tjänsten till fast pris. Då vill man avgränsa sig så mycket som möjligt. Då gjorde man det bland annat med hjälp av att bygga en prototyp, innan man gick igång med den fullständiga implementationen. I det fallet var det ju ett viktigt steg. Personligen så anser jag att just när man bygger nya applikationer eller nya gränssnitt, så är att bygga en prototyp ett ganska bra hjälpmedel, för då kan man stämma av just interaktionen med användaren och även integration med andra system på ett helt annat sätt än när man bara skriver specifikation och designdokument. TV: I en specifikation kanske det kommer med ett blad som visar gränssnittet, «så här ska det se ut», men det är inte samma känsla som att sitta med en prototyp där man kanske i alla fall hjälpligt kan klicka men kanske inte all funktionalitet finns, men det utseendemässiga gränssnittet finns och då får men en helt annan känsla. Det är un- 65

77 gefär som att sätta sig och köra bil. Du kan få en broschyr för bilen men det är ju inte samma sak som att sätta sig ner och köra. Försäljningsfas TV: De gånger jag har varit med om har man delat upp i faser och man har någon typ av försäljningsfas där man diskuterar med kunden vad det är vad men vill få fram och lämna ett kostnadsförslag. En prototyp kan vi bygga eller generera. Vi har jobbat tajt med kunden i ungefär en vecka där man interaktivt jobbar med applikationsdesignen alltså själva gränssnittet, användargränssnittet och dess funktionalitet. Man specificerar vilka funktioner som ska ingå. Även om man kanske inte presenterar själva prototypen så visste man att i den färdiga produkten ska de här funktionerna ingå och de ska åskådliggöras med de här gränssnitten. Och då har man i stort sett en försäljningsfas och så har man ett själva prototypbyggandet. I det fallet kallar vi det för rapid solution workshop. Utifrån det kunde man räkna på i stort sett vad det skulle kosta att ta fram hela produkten, hela applikationen. Kommunikation kring prototyper AN: Brukar det vara svårt att få kunden att förstå var prototypen handlar om? Får man feedback på rätt saker? TV: Jag tror att så länge man är involverad i en ganska interaktiv process tajt med kunden så att man kanske inte sitter och tar fram bilderna på skärmen, alltså i en utvecklingsmiljö, utan man sitter oftast med whiteboard och ritar och tar sedan fram förslag. Och nästa gång man träffas kan man diskutera och eventuellt kanske provköra saker och ting då. Då får man bra respons. Då tror jag att de förstår. Däremot är det svårare att förstå att nu har vi gjort en prototyp och nu ska vi bygga applikationen. Då kanske vi inte använder samma verktyg och då kanske man måste göra om vissa delar av koden. Då kan vissa kanske kunder ha lite svårt att förstå det där. Varför måste vi skriva om det här en gång till? Eftersom det blir en annan prislapp då. Idag väljer man verktyg som man 66

78 vill använda även i fortsättningen. Det underlättar naturligtvis. Idag kan det handla om webbsidor, det är mycket enklare då. Det går ju även att skapa stilen med hjälp av olika mallar. Att återanvända kod TV: Om det fanns något specialfall för någon funktion som man byggde in i prototypen som kunde återanvändas senare till själva koden för funktionalitet, det går ju att använda, men jag tror i stor utsträckning ska man nog undvika det. Prototypkoden är oftast inte bra strukturerad och dokumenterad. För det har man inte tid med då. Dokumentation TV: Man skriver anteckningar oftast, och även kunden fick ju läsa anteckningarna så att vi hela tiden hade samma resonemang. Problemet är oftast det att när man jobbar tajt med kunden så jobbar man med en mindre grupp med människor. Sedan kanske applikationen ska komma ut i hela företaget också, och alla har inte samma åsikt så där brukar man få annan feedback sedan när det ska in i produktionen naturligtvis. Samverkan i senare faser TV: I fall där jag varit med så satt men mer på kammaren och byggde och hade avstämningsmöten. Det har man ju alltid med kunden. Man berättar hur långt man har kommit och presenterar saker och ting. Men oftast när man kommit ifrån prototypen och beskrivit själva prototypen. Till exempel designdokument, för det måste vara en överenskommelse om att det här ska vi verkligen göra. Själva prototypen kan ju utgöra en delmängd av det och dokumentationen. Så får man stämma av vartefter. AN: Visar man upp systemet på något sätt vid den här punkten eller hur gör man på mötena? TV: Det är nog längre fram i utvecklingsfasen tror jag. Eftersom första delen oftast innebär att man inte har något 67

79 och visa egentligen. Naturligtvis ingår det ju vartefter en testfas, där kunden måste vara involverad. AN: Men det är inte så vanligt då att kunden är involverad i mitten av projektet, utan det är i början och i slutet? TV: Ja, det blir ju så. Naturligtvis kan det hänga ihop med om det finns så att säga beröringspunkter med deras övriga system, då är kunden självklart involverad på ett annat sätt. Om man till exempel ska integrera med deras nuvarande databaser eller nånting sådant. Då måste man veta att det fungerar. Man har ju oftast en projektledargrupp som kunden naturligtvis deltar i. Det är ju mest för att stämma av att saker och ting flyter på enligt planen, och inte så mycket för att förändra själva applikationen. Jag menar det skulle ju inte hålla om kunden skulle vara inne och peta och så halvvägs. Risken finns att det kommer nya människor och då blir det nya åsikter och så att försöker man att, ja, i så fall göra förändringar efter att man levererat en viss nivå. Sammanhang över faser AN: Är det samma personer som brukar göra prototypen som sen gör systemet eller är det ofta olika? Man har en blandning av personer som är involverade, typ arkitekt och systemutvecklare. Sen har man säkert någon person som bär integrationen och kan beskriva deras miljö. Det hänger ju fullständigt på vad det är för applikationer naturligtvis. Men oftast är de här personerna involverade även i utvecklingen. På ett eller annat sätt är de egentligen experter i det läget, för resten av gruppen som ska utveckla. Eftersom de varit med i den förberedande fasen och kanske fått lära sig om kunden och deras affärsidé och vad applikationen egentligen ska leda till. För att egentligen ska det vara som en röd tråd för annars tappar man ju kunskap mellan faserna. 68

80 Pappersprototyper AN: Brukar ni använda pappersprototyper? TV: Jo, det gör man i säljfasen. I de första delarna blir det oftast att rita kanske enkla varianter med bara ramar och var ska saker finnas och vilken funktionalitet som ska vara med Intervju med Bo Olls Intervjun genomfördes 19 april hemma hos mig. Bo Olls är konstnär och skulptör med lång erfarenhet av projektledning, utredning, utställningar, utsmyckningar och gestaltningsuppdrag inom statlig, regional, kommunal och privat verksamhet. Han är nu verksam bland annat som projektledare för Visioner vid Vatten, som arbetar med konstnärliga gestaltningar längs och i trakterna kring Göta Kanal Östergötlands största sammanhängande konstprojekt. Vid intervjun närvarade även Bibbi Nawroth, konstnär och gift med författaren till denna uppsats. Nedan följer utdrag ur intervjun. Olika arbetssätt BO: Det finns ju ensamvargar som går från ax till limpa på väldigt kort tid. Och som också tror att det är en bra modell att göra det. Det kan bero på bristande erfarenhet. Det kan bero på bristande intresse för uppdraget. Det kan bero på att det i regel finns en ekonomi i de här uppdragen som inte finns i andra sammanhang inom konstområdet, därför att här arbetar man ju ändå på en typ utav marknad som har med verkligheten att göra och inte med den ideella världen. Utan det finns i regel ett förhållande till en beställare eller till en grupp av något slag som är med i de här processerna. Beställarkompetens och långsiktighet BO: Jag har jobbat som informatör på just det här området för att bereda väg för den här sortens arbeten, och inte alltid då åt mig själv utan för att slussa in rätt sorts konstnär i en sådan process. Därför att det är en del utav problematiken med det här. Det beror ju på att det måste finnas kunniga beställare och såna är det inte så gott om, 69

81 utan de har väldigt luddiga idéer om hur man hanterar såna här modeller. Och då finns det väldigt olika behov utav att tydliggöra för dem själva också vad det är de ska göra eller vill göra för nånting. BO: Konstområdet har den svagheten och fördelen att folk har väldigt stor respekt ibland och väldigt liten respekt ofta för området. När man kommer just till de här situationerna då hamnar folk lätt i bryderi. Och när de offentliga strukturerna är starka, till exempel när kommun, landsting och stat har haft organisationer för det här, och det är ju det från 60-talet ungefär; när man byggde upp kulturnämnder, då byggde man in strategier för hur samhället skulle utvecklas, då har det också funnit möjlighet att samla på sig erfarenhet i de här avseendena. Men när samhället sadlar ner den delen, och det börjar man göra på 80-talet, då försvinner också kunskapsnivåerna, även i den privata sektorn. då hamnar man i ett läge där tycke- och smakfrågor av privat karaktär är det som styr. Och det är en väldigt trång modell eftersom de offentliga modellerna ofta bär iväg över väldigt lång tid. Mycket saker finns kvar i de här sammanhangen i upp till tio, femton, tjugo, fyrtio eller hundra år. Och därför gäller det att, både när man planerar för det här och genomför det, tänka på vad det är dels som man sätter dit, men också att tänka i materialiteter, att tänka i hållbarheter. Att tänka i system som ska tåla förändringar över tid. Jag antar att det har beröringspunkter även med ditt arbete eftersom det finns besvärliga sätt att göra det, som ingen annan sen kan gå in i. Och det finns sätt att göra det som gör det enkelt att lösa problematiker som ligger en bit framåt i tid. Offentliga miljöer BO: Det är ofta mer komplicerat än det ser ut. Man tycker ju att jaha, nu ska det stå ett konstverk där, och så ska man hitta en konstnär som ska ställa det där, och konstigare än så behöver det ju inte vara. Men det är mera komplicerat än så. 70

82 BO: Du ska försöka argumentera för konstverket, och du måste på olika sätt sälja in det i förhållande till brukare. Det är en väsentlig skillnad att jobba med konst i ett äldreboende än om du jobbar till exempel som projektledare med konst ute på stan. Därför att det blir två olika, helt olika, väsensskilda sätt att förhålla sig. På ett äldreboende till exempel där människor inte kan undvika konsten, utan måste vara i den, har du skäl att ta större hänsyn i den offentligheten, än vad du har om du jobbar ute på stan. Därför att där kan folk välja att gå ett kvarter nedanför om de tycker att det ser alldeles förfärligt ut. Där finns också en toleranstrappa som är större därför att den refererar och relaterar till väldigt många andra saker i staden som neutraliserar delar utav den här situationen som kan dyka upp. Och ändå blir väldigt många kontroversiella just därför att man bryter ett mönster som har funnits, man ställer dit nånting annat som kanske inte direkt förväntas finnas där, och man möter den relation som människor har till en plats där man i sin värld har placerat alla saker redan. Så bryts det mönstret och då kommer det in ett moment som väcker ibland intresse, ibland aggressivitet, ibland oro, ibland andra sådana affekter. Projektprocessen BO: i regel gör man ju så att man skriver ett program innan man sätter igång, och det försöker man då skriva så pass luddigt så det finns möjligheter att i praktiken göra förändringar, utan att bryta mönstret för mycket från programmet. Programmet är i regel allmänt hållet, men handlar om hur man förankrar det här i förhållande till brukare och beställare. BO: Det sker ju olika anpassningar efter olika förutsättningar. I somras så reste vi en nio meter hög skulptur ute i Roxen. Ungefär en sex sjuhundra meter ut från Bergs slussar. Och en bit ut i Roxen då så är det en stenpir som är kanske 100 meter lång och sen är bara lite bredare än köksbordet här, och består av stenbumlingar. Det är alltså nio meter hög krysställd skulptur av perfo- 71

83 Bild 1. «Dubbelgångare» av konstnären Kent Karlsson. Foto: Bo Olls. rerat stål. Den väger fem ton och är nio meter hög. När man står på stranden så ser den ut som den är så här liten därför att den har evigheten bakom sig så att säga. Det finns inget annat än vattnet att relatera till storleksmässigt. Men när man kommer nära så är den oerhört stor! Och det där är alltid en svårighet, plus att står du på marknivå så ser den ut på ett sätt. Står du upp på slusstrappan har du höjd och ser den från ett annat perspektiv. Så här handlar det om att prova vilka skalor som en sådan sak ska ha till exempel, att prova vindstyrkan för hållbarhetens skull. Man ska prova hur tung den får vara i förhållande till om de här stenarna åker ner i gyttjan utav tyngden på skulpturen. Det här är en lång process utav successiva ändringar och förändringar som sker un- 72

84 Bild 2. «Dubbelgångare» av konstnären Kent Karlsson. Foto: Bo Olls. der förprocessen. Och då tar en sån här process från de första skisserna till verklighet ungefär ett år. Och det är en rätt så bra cykel att arbeta i. Det har också lite att göra med hur väderlek och årstider ser ut om man jobbar ute på platser där det inte finns någon förkunskap om saker. Det är skillnad om du är i stadsrum. Då finns ju el framdraget någonstans i närheten. Det finns en vetskap om hur man tar sig dit, inte minst. I det här fallet fick vi ju då hyra in till exempel ingenjörstrupperna från Eksjö som kom med en stridsvagnsponton. Man tror varje gång att man lär sig nånting utav gången innan. Men det är alltid nya komplikationer i en sån här process, plus att man blandar in ett par hundra människor på olika sätt, allt från entreprenörer till tillfälliga hantverkare som ska komma dit och svetsa i tre timmar. Så finns det inget att 73