• No results found

4 Empiri

4.2 Intervjuer

4.2.5 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 ge- nom 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 app- likationer 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änssnit- tet finns och då får men en helt annan känsla. Det är un-

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 applikationsdesig- nen 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äl- va 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 prototypbyggan- det. 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 pro- totypen 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 prov- kö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 applikatio- nen. 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

vill använda även i fortsättningen. Det underlättar natur- ligtvis. 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än- das 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 strukture- rad 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 sam- ma 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 proto- typen. 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. Ef- tersom första delen oftast innebär att man inte har något

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 öv- riga system, då är kunden självklart involverad på ett an- nat 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 na- turligtvis 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 personer- na involverade även i utvecklingen. På ett eller annat sätt är de egentligen experter i det läget, för resten av grup- pen som ska utveckla. Eftersom de varit med i den för- beredande 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.

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. …

Related documents