Slutt å vende leverandører eller folka deres mot hverandre

Egentlig trenger ikke mer enn det som er i hovedtittel og ingress å bli sagt, men her skal dere likevel få en utdypning og noen konkrete forslag slik at dere får til bedre samarbeid mellom team, leverandører og fagdisipliner.

Dette skal ikke handle om hva som fungerer best av remote og fysisk tilstedeværelse eller hva som er best av lean, agile eller fossefall-metodikk. Det handler om følgende: SLUTT å gi kun utviklere tilgang til å jobbe med det faktiske produktet og kun designere får jobbe med tegnebrettet. Dette gjelder også andre grupper og situasjoner, men jeg skal holde meg til et konkret et.

Designere og utviklere blir faktisk forente når de støper den samme formen istedenfor å gå hver for seg. Det betyr at det må settes mindre begrensninger på hvor mye utviklere kan gi tilbakemeldinger på designet, eller til og med bidra, og det må også settes mindre begrensninger på hva designere kan bidra til med av kode.

Betydning for design

For design betyr dette i praksis at tegneflaten, som ofte forbindes med Sketch, Adobe XD, Figma, Axure, UXPin eller Framer, må gjøres tilgjengelig for flere i prosjektet. Vi har brukt Figma i diverse kundeprosjekter i Netlife siden begynnelsen av 2019. Figma er et av flere verktøy som har en «multiplayer-funksjon» i nettleseren som fungerer litt som i Google Docs. Dette gjør at både stakeholdere, utviklere og andre designere kan gi tilbakemeldinger på de nyeste skissene eller til og med jobbe samtidig som hverandre.

Utallige ganger har jeg som designer opplevd å bli hjulpet av tidlig tilbakemelding om at for eksempel den tekniske løsningen må gjøres annerledes, jeg har fått et mer realistisk bilde av hva en løsning koster av arbeid i forhold til en annen eller jeg har fått vite at det finnes en bedre teknisk løsning som også er mer brukervennlig.

Betydning for utvikling

For kode betyr det i praksis at kodebaser og test-versjoner gjøres tilgjengelig for flere. Kodebaser blir allerede ofte delt dersom det er flere tekniske aktører i prosjektet og det opprettes også veldig ofte test-versjoner. Men selv internt i noen selskap kan det hende at man holder kodebaser for seg selv uten at det er noen gode grunner til det.

Det er også viktigere å få designere med på å produsere kode ettersom designoppgaver ofte nedprioriteres i fordel for funksjonelle oppgaver. Ved å gi designere tilgang til koden kan de også jobbe ut fra deres egen prioritet og gjøre endringer i designet på produktet som heller ikke krever veldig tunge teknologi-ferdigheter.

Betydning for prosjekteiere

Kanskje det virker rart for deg som er prosjekteier å ha noe å si på hvordan for eksempel et designbyrå og et teknologibyrå skal samarbeide, for man kan jo kanskje tenke at det er noe de selv skal finne ut av fordi det er de som er fagfolka. Jeg stiller meg ikke uenig det, men jeg ønsker å gjøre flere bevisste på temaet slik at flere kan bli gode pågangsdrivere for godt samarbeid. For det finnes også utfordringer rundt for eksempel avtale-detaljer og konkurranse om kontrakter som gjør at aktører fremmedgjør hverandre, der er det dere som kanskje må inn og skape en endring.

Typiske unnskyldninger for IKKE å jobbe sammen

«Våre metoder er hemmelige»

Dere har betalt for at kunnskapen brukes i prosjektet. Unnskyldningen kan misbrukes som skalkeskjul for at man egentlig ikke har nok gode underliggende argumenter eller faglige grunnlag og har ikke sted hvis man skal få til et godt samarbeid.

«Vi trenger å jobbe for oss selv»

Litt arbeidsrom må faktisk ofres for at man skal kunne få til et bra samarbeid. Gjør man det mulig for andre å komme med innspill fortløpende, vil resultatene også bli bedre.

«Hvis designet ikke er ferdig først, må vi gjøre mye utvikling om igjen»

Det er som regel mer effektivt å iterere på designet i koden på sluttproduktet enn å bruke for mye av den samme tiden på å iterere i skisser som man heller ikke får se om består virkelighetens prøve. Det er alltid kjipt for alle når designet har feil og designerne har forlatt. At designere selv møter de utfordringene som kommer når skissene møter virkeligheten, gjør designet mye sterkere og det blir til og med enda bedre hvis det er designere selv som gjør design-iterasjoner i sluttproduktet istedenfor at det går ut over andres tid.

«Verktøyet vårt er bedre»

Dette kan fort være et tegn på at man ikke er villig til å prøve ny teknologi og utvikle seg óg flere funksjoner betyr ikke nødvendigvis alltid beste løsning i prosjektet.

«Vi vil ikke at andre leverandører skal eie vårt arbeid i deres programvare»

Hvis prosjekteier også eier lisenser på programvarer som brukes til samarbeid så er dette problemet så godt som løst, men hvis en leverandør allerede har lisens på noe så er det så klart oftest rimeligere hvis det lar seg gjøre.

Et godt prosjekt er et prosjekt der alle lærer av hverandre og man spiller hverandre gode. Et prosjekt der det legges restriksjoner på hva man kan lære av hverandre eller man begrenser andre for å heve seg selv, er ikke gode utgangspunkter for gode resultater.