Intervju med Michael Garrido

Intervjun genomfördes 23 april hos Gaia AB i Norrköping. Gaia sysslar med informationslösningar, it-projekt och verksamhetsut- veckling med särskild kompetens inom detaljhandelsområdet. Mi- chael Garrido arbetar som utvecklingsledare. Nedan följer utdrag ur intervjun.

Användningsområden och arbetssätt

MG: Vi jobbar ganska mycket med prototypframställning, eller egentligen även med attrappframställning om man uttrycker det så. Ofta har man en grundidé som man då skissar mer än att man bygger den från scratch. Och i olika utvecklingsdelar så använder man prototyper gan- ska ivrigt just för att lyfta ut en del av problemställningen och kunna se på något med lite andra ögon än om det kanske finns i ett befintligt stort system. Så ibland kan det vara bra att lyfta ut det och göra en prototyp av den anledningen eller göra en prototyp för att testa gränssnit- tet och kanske testa det även mot kund också.

MG: Man kanske har åstadkommit vissa funktioner och så andra delar av det kanske är så att det mest ser ut. All- ting fungerar inte alltid i den prototypen utan man kan- ske vill visa till en viss del hur vi hade tänkt att det skulle fungera. … Och sen hur mycket som är attrapper eller hur mycket som är program skiljer sig åt, meningen är att man ska få en visuell känsla för hur programmet fung- erar. Så där kan det vara en liten gråzon angående hur mycket som är ren bild och hur mycket som är program. Vi försöker hitta en mix däremellan för att få en rimlig kostnad för att ändå ta fram prototypen. Och vissa pro- totyper tar man fram och så blir de ingenting, man bara kastar bort dem i stort sett. Man kanske använder vissa klasser och sånt.

AN: Men ni gör dem i en programmeringsmiljö?

MG: Det gör vi. Ofta gör man det för att testa ett koncept eller för att se om det håller eller fungerar och det kan ju även vara ur prestandasynvinkel. Så kanske vi vill trycka

in data i det där gränssnittet som det normalt sett inte håller för, för att testa prestandan och för att se att det verkligen fungerar. Även om man normalt sett vet att det är 10–15 rader som ligger här och de borde vi kunna visa på det här sättet men vad händer? Tar det två minuter att öppna den här sidan eller fönstret eller vad det nu råkar vara för någonting, om man trycker på lite mer data, som ändå är inom rimligheternas gränser så att säga.

Återkoppling

MG: Om det är någon större del så kanske man har en referensgrupp som man lägger ut den lilla prototypen på. Så att man försöker visa upp någonting relativt tidigt för att kunna få respons tillbaka. Men det måste ändå fin- nas en viss funktionalitet i det för att de användarna ska kunna ta till sig det och tycka någonting om det. För om det bara är bilder som man kanske kan klicka på så ger det inte någonting. Utan det måste nästan hända lite för att de ska kunna se att, ja, det här är verkligt, det här ska jag kunna ta ställning till.

MG: Oftast när man har en prototyp så vill man få spon- tan feedback på den också. Oftast är det bra att sitta till- sammans med kunden. Eller med de personer som kör den, för det ger också en viss signal om det är bra eller dåligt. Medvetet eller omedvetet så beter man sig ändå på ett visst sätt. Eller man tycker att något kanske fungerar dåligt. «Jag brukar göra så här», eller «ja, men då kan du kanske göra så där istället», så får man mer dialog i det. Att bara skicka ut en prototyp och säga «testkör den här» blir sällan så mycket värt att det är värt att lägga tiden på den på det sättet.

MG: Vi får inte alltid prototypfeedbacken direkt ifrån den användare som gjort kommentaren, utan det kanske samlas ihop av någon. Men oftast försöker man ha en ganska nära dialog där. Annars är det lätt att tappa något ganska viktigt spår där, som gör att man tappar i använ- darbarhet till exempel. Man skriver alltid ned vad som fungerar bra och vad som fungerar dåligt. Och oftast går

man igenom det på nästa projektmöte: «Det här måste vi kanske ändra på. Med deras data ser det här jättekonstigt ut så vi måste kanske ändra på någonting utifrån de för- utsättningarna.»

Produkt eller kundanpassat

MG: Själv jobbar jag ju med produktutveckling så det ställer ju kanske lite speciella krav, olika kunder ser ju det här på lite olika sätt och olika typer av kunder har lite olika behov så att det gör ju också att man får tänka lite annorlunda när man utvecklar systemet. Så produkt- tänket måste ge en annan infallsvinkel än att bara göra ett kundanpassat case, som är lite mer förlåtande ur an- vändbarhetssynvinkel. Men om du har en produkt som du vill få ut till ett visst antal användare på en mängd olika företag med olika verksamhet, kanske inom samma område men ändå där de jobbar på olika sätt, så kräver det lite mer så att säga av tankearbetet och prototypar- betet. Det är inte bara att göra något som någon tycker om, utan det måste fungera mer generellt och vara mer anpassat till standarder eller hur det beter sig mot andra program och så vidare.

MG: Vi har ingen prototypavdelning som sitter och jobbar enbart med prototyper, vi är ju totalt kanske 40 personer på utvecklingsavdelningen och det är ju inte så mycket att det lönar sig att ha en egen prototypavdelning som enbart jobbar med det. Men däremot har vi ganska bra överhörning mellan projekt där vi försöker se designap- proacher eller användbarhetfördelar som vi försöker ut- nyttja i flera projekt. … Det är utvecklaren som sitter och gör prototyperna också för att de ska få en bra förståelse hur det ska fungera. Det blir ju också en naturlig brygga mellan användare och utvecklare. Att man så att säga får en samsyn, att man förstår vad det är man vill utföra för någonting. För annars kanske det kan vara lite svårt att enbart beskriva i ord utan man måste åtminstone ha bil- der men gärna i vissa fall då prototyper också.

Risker med prototyper

MG: De få riskerna då man prototypar ett helt system är vanligtvis att beställaren kan inbilla sig att det antagligen nästan är klart. Det är väl den enda risken som man kan se. Där försöker man vara ganska tydlig på att poängtera att det är en prototyp som ser ut som att den fungerar och den beter sig nästan som den är tänkt att fungera men att man ska förstå att det finns ett antal saker till som vi behöver göra för att det ska vara ett produktions- mässigt system som vi kan leverera med vettig kvalitet och så vidare. Det har inte varit någon problem hitintills. Andra typer av problem som kan tänkas uppstå är att när man utvecklar prototypen så har man nästan utvecklat funktionen, prototypen blir lite för stor för att det ska vara ekonomiskt försvarbart. Det är väl en annan risk som finns, att den blir ett för stort eget djur. Om man inte drar strecket i tid och säger okej vi ska titta på just den här delen av det vi utvecklar, och de här och de här delarna som också ligger kring den här prototypen fast det inte var det som var syftet. …

Återanvändning av kod från prototyper

MG: Jag försöker max återanvända vissa delar, annars för- söker man revidera koden lite grand när man går från prototypsteget till produktionssteget. Dels för att man antagligen har gjort massa småfula saker som man inte borde göra i det verkliga programmet. Så att man lyfter de delar man är väldigt nöjd med och resten kastar man. Men i vissa fall har vi återanvänt hela prototypsteget ock- så. Då har man haft den ambitionen att det ska bli nästan så bra, då lyfter man in det och kör en kodrevision på det och ser att det följer den standard som man tänker sig, och sen så ser man att det fungerar. Och i vissa fall har vi byggt programidéer som bara är till för demonstra- tion, men som inte har blivit funktioner i systemet än så länge.

Utformning

AN: Det ni visar upp för kund, brukar det ha det utseende fullt ut som den färdiga produkten ska ha?

MG: Ja, så nära som möjligt i alla fall när det gäller kund- delar, för ibland kan det vara små detaljer som gör hela skillnaden. Det ska verkligen se ut och bete sig som pro- grammet borde göra, det är viktigt i kundprototyper. … När man tittar på interna prototyper så behöver det inte se rätt ut, utan då kan det kan vara lite yxigare i sin ut- formning.

Utvecklingsmodell

MG: Dels så har man en tidig attrapp kan man säga. Man ritar upp. Så här borde det kunna se ut, så här borde det kunna fungera och sen jobbar man lite kring det och sen försöker man ha några nedslag under utvecklingsfaserna där man stämmer av. … När vi börjar närma oss slutfa- serna så släpper vi oftast iväg olika betaversioner kan man kalla det för, som de kan testa och känna på lite. Vi har flera nedslag under utvecklingens gång också. Vi jobbar i block om funktionalitet, ganska små fokuserade block där man kanske lägger ned omkring 250 timmar. Sen har man en funktionalitet som är färdig för leverans, den kanske inte är paketerad och kanske inte fixerad. Och i det läget kan ju kunden titta på den funktionaliteten och se om det fungerar, och sen har man kanske flera såna utvecklingsblock inför en leverans. Men i varje sådant utvecklingsblock är tanken att det ska vara levererbart i det läget. Och sen så har vi även ett slutblock egentligen där man kan hantera förändringar och vara lite flexibel i sin hantering. Men det beror ju på lite också. Ibland har man ett fastprisuppdrag, då ska det göras på det här sät- tet och då blir det lite fyrkantigare hantering. Men om man har en mer blockuppdelad process och säger att vi ska lägga så mycket tid och göra den här funktionaliteten och dela in det på det här sättet, och att man även får med lite tid för att hantera förändringar från start. Så har man möjligheterna att samla lite inför slutleveransen och

göra lite finjusteringar eller vissa funktionsförändringar inom projektets ramar.

Kravspecifikationer

MG: Vi försöker ha en ganska bred kunskapsbas så att det är inte så att det är några som alltid sitter med kravspe- candet. … Varje utvecklare som sitter i ett team kan få ansvaret att jobba med sin kravspec-del. … Vi försöker göra så att alla utvecklare är delaktiga i hela processen och inte bara att «nu ska du göra den här grejen, den ska se ut så här och fungera så här». Det blir inte så krea- tivt och så schysst för den som utvecklar. Vi vill hellre att man ska få en större helhet. För då tror jag också att man kan göra ett mycket bättre jobb. Och den utvecklaren kan också utvecklas … få en bättre personlig utveckling, och även komma med bättre förslag om att vi borde göra så här istället. För att den personen som utvecklar det då också har verksamhetskunskapen om hur det borde fungera eller hur man jobbar med det. Det är inte så att projektledaren kommer med ett stort dokument och slår i huvudet på utvecklingsavdelningen och säger «gör det här». För det fungerar inte riktigt tror jag. Det går säkert att göra och det går säkert att göra på hyggligt rätt tid men det får inte den verksamhetsmässiga sluteffekt som man vill ha tror jag.

MG: De kravspecar vi har innehåller mycket visuellt, allt- så hur man vill att det ska se ut. Eller en idé om hur det ska se ut, och ibland vill man ju då ta det ett snäpp till och då se till att det blir en prototyp också. Så att vissa delar försöker man kanske prototypa men vi försöker vara väl- digt visuella i hur vi upplever att det borde funka. För då får man också den verksamhetsmässiga dialogen … Prototyper och kunskapsutveckling

MG: Och har man en prototyp så har man en lite större frihet att använda andra angreppssätt. Man kanske an- vänder nåt annat designmönster i just här fallet för att se om funkar det här bättre. … Då kan man utifrån proto- typen diskutera om det blir bra eller dåligt. Och då är det

en mer intern prototyp men det ger ju också de utveck- lare som är med och gör prototypen ny kunskap.