Masterbloggen

Prototypeutvikling – et annet ord for prøving og feiling

Lesetid: 3 minutter

Da har jeg kommet et godt stykke på vei med min oppgave om å pusle sammen kartbiter, faktisk så langt at det er på tide med prototyper! Hva er egentlig en prototype, spør du? Jo, det skal jeg fortelle deg.

Før man kan ha en prototype, må man vite hvilken utfordring du vil løse med protypen. For å si det på en annen måte, det er ingen vits i å bygge en protype på en ny sykkel når du ikke vet om du skal bruke den til å sykle i Tour de France, gjennom skog og myr, eller bare til og fra butikken. I mitt tilfelle vet jeg hva problemet er, dere har allerede lest om det i mitt forrige blogginnlegg.

 

Så må man sette seg ned og tenke grundig over hvordan man egentlig skal løse denne utfordringen. Hvordan skal prototypen se ut, hva skal den gjøre? Hvordan gir vi den de egenskapene vi ønsker? Hvis du vil ha en sykkel for Tour de France, så har du antageligvis bestemt at den må gå fort. Hvordan skal den gå fortere? Kanskje ved å spare vekt. Hvordan sparer du vekt? Ved å bruke lettere materialer. Slik er tankeprosessen også når både problem og prototype kun befinner seg på datamaskinen din.

 

Når du så har tenkt deg frem til hvordan prototypen skal være, så må du sette den ut i livet. I mitt tilfelle setter jeg med ned og skriver programkode på en datamaskin, for en sykkel hadde det betydd en tur ned på verkstedet. Når du har prototypen klar, kan du begynne å teste den for å se hvor godt den oppfyller de målene du har satt! Og jeg kan garantere deg en ting, og det er at det vil alltid være noe med prototypen som kan forbedres. Det er nemlig hele poenget med prototyper, de både kan og skal kastes straks du har funnet ut hva som er gærent med dem, slik at du kan lage en enda bedre utgave. Det er når du til slutt har en prototype som du ikke finner noe galt med, at du kan pusse på den og kalle den et ferdig produkt.

Fordi en prototype aldri er ment å være et ferdig produkt, kan du spare inn på ting som vanligvis hører med i et ferdig produkt og konsentrere deg om de store spørsmålene. På en sykkel vil det si at man blåser i fargen på lakken og om alle refleksene sitter der de skal, mens på mitt prosjekt vil det si at det ikke er viktig at programmet går så raskt som mulig, men at konseptene man skal teste ut fungerer. Så da kan man spare tid og arbeid her og der ved å gjenbruke programkode  fra andre, ikke skrive instrukser for hvordan bruke prototypene, og fylle alt du skriver med varsler og kommentarer som bare har mening for deg selv. Det er når du er fornøyd med prototypen at du skal rydde opp i alt det og gjøre det forståelig for andre.

Innen sommeren kommer skal jeg også ta steget fra prototype til ferdig produkt!