Jeg jobber med teknologer i det daglige og ønsker å dele erfaringer om hva UX og bedriften forventer av en god utvikler. I artikkelen kan du lese om hva er en kick-ass utvikler er i mine øyne – og hvordan kommer vi i mål sammen.
#soft-skills #kick-ass utvikler
Hva forventer en designer seg av en utvikler?
Jeg har spurt designfolk rundt omkring om hva kan en utvikler gjøre for å imponere en designer. Svarene jeg fikk var blant annet at utvikler bør: «Komme med sine ideer og tilbakemeldinger»”, «Bli med på brukertest», «Være i kontinuerlig dialog og tettere samarbeid», «Spørre hvis man lurer på noe», «Være med på å definere kravspesifikasjonen». Den røde tråden her er kommunikasjon. Vi vil ha mer dialog med utviklerne.
Hva forventer en designer seg av en utvikler?
Jeg har spurt designfolk rundt omkring om hva kan en utvikler gjøre for å imponere en designer. Svarene jeg fikk var blant annet at utvikler bør: «Komme med sine ideer og tilbakemeldinger»”, «Bli med på brukertest», «Være i kontinuerlig dialog og tettere samarbeid», «Spørre hvis man lurer på noe», «Være med på å definere kravspesifikasjonen». Den røde tråden her er kommunikasjon. Vi vil ha mer dialog med utviklerne.
I mine øyne er de tre tingene som en utvikler imponerer meg med (i tillegg til forventet kunnskap i faget sitt) at:
- Jeg kan få rask avklaring
- Utvikler tar initiativ til dialog
- Dialogen er tidlig og tydelig
Raske avklaringer om forslag fra designer
– For å velge riktig hypotese, trenger en å se på spørsmålet fra flere perspektiver: forretningsmessig, menneskelig, teknologisk og noen ganger, intern-politisk. Teknologiske muligheter avklarer jeg med utviklere. Jeg beskriver eller viser noen varianter til en utvikler og spør hva han/hun synes. «A eller B?» Noen ganger er forslag A enklere å utvikle enn B, noen ganger er det ikke så lett å si, og noen ganger er det ingen betydelig forskjell i utviklingstiden. I det siste tilfellet blir ikke utviklingstimene del av kabalen når jeg skal komme med anbefaling til bedriften.
– Ofte har jeg et konkret og kort spørsmål som starter med «Er det mulig…?» Det er enkelt når jeg får svar enten «ingen problem» eller et klart «nei». Noen ganger får jeg svaret «Jeg må undersøke litt til».
Screenshot fra samtalen på Slack. Utvikler tar kontakt og foreslår teksten som mangler i web-view header. Sjekker noe og følger opp. Saken blir løst.
«Jeg er veldig fan av at utviklere kommer med innspill til design».
Martin G, designer, Gjensidige
Og det er enda mer kult når en utvikler foreslår ny funksjonalitet.
«Programmerere har ofte de beste ideene til tekniske muligheter. For å vite om en ide er gjennomførbar er det ofte avgjørende at en programmerer tar initiativ til å lage en fungerende prototype».
Johannes B, utvikler, Sopra Steria
Yurii P, iOS utvikler hos EVRY har foreslått ny funksjonalitet. Ideen falt i smak og Yurii har utviklet en prototype som demonstrere basis-funksjoner. Dette er imponerende og det synes.
Men det som også er veldig viktig er å ikke glemme når utvikler agerer ad-hoc. «Det har oppstått en feil her, kan du fikse det ASAP?». Slik teknisk feil kalles en «bug» og kunden blir rimelig provosert når det oppstår. Her må man agere fort.
Diverse former for kontinuerlig dialog
Når en utvikler er «in the zone», hater han/hun å bli distrahert fra koding. De bør helst ikke bli forstyrret. Men vi på forretningssiden har behov for å avklare. Derfor trenger vi flere måter å samhandle på, avhengig av type problemstilling. Jeg har fast statusmøte med utvikling hver sprint. Min favoritt kanal for raske avklaringer er Slack. Når vi skal løse litt større ting, er det best med møte eller workshop.
«Uansett hvilket fagområde man jobber med, er det viktig at man viser interesse for hverandres fagfelt. Nysgjerrighet, initiativ, våge å stille spørsmål – ofte og tidlig (unngå antagelser), tenke utenfor ditt eget fagfelt. Istedenfor å sitte med «design» og så «utvikling», bør man jobbe samtidig med alle deler av oppgaven. Ikke overleveringer, men diskusjoner og spørsmål.»
Martin S., designer, Bekk
For at vi kan sammen skape verdi så bør vi snakke sammen.
For å ha god kommunikasjon må vi snakke sammen ofte. For å få vellykket resultat må vi snakke sammen tidlig. For å få behagelig kommunikasjon må dialogen være tydelig. Et godt digital produkt oppstår gjennom et tverrfaglig team og engasjerte deltakere.
Tekst og bilder: Darija Sapozenkova-Hauge. Artikkelen publiseres også i Typografiske Meddelelser (TgM) – et fagblad utgitt av Oslo grafiske fagforening. Takk til Eva-Lill Bekkevad for korrekturlesing.
