Hjemmekontor til besvær

10 ting jeg skulle ønske noen fortalte meg da jeg begynte å jobbe som utvikler

10 ting jeg skulle ønske noen fortalte meg da jeg begynte å jobbe som designer

Tverrfaglig samarbeid genererer store besparelser

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*dwzD4nSclN7niVbyBmkPZA.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@frantic?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Alex Kotliarskyi</a> on <a href="https://unsplash.com/s/photos/open-office-plan?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Opprinnelig publisert på <a href="https://www.kode24.no/kodenytt/hjemmekontor-passer-darlig-for-ledere-som-liker-micromanagement/73637916">kode24.no</a>
Daglig leder i Alv, Marcus Sahlin Pettersen, skal i hvert fall ha skryt for å våge å gå mot strømmen når han skriver at han <a href="https://www.kode24.no/kodenytt/konsulent-sjef-vil-ha-utviklerne-sine-i-apne-landskap/73623233">vil ha utviklerne sine i åpne landskap</a>. Veldig mange utviklere opplever hjemmekontor positivt, og mange går så langt som å si at de <a href="https://www.kode24.no/nedetid/uaktuelt-a-sitte-i-apent-landskap-noen-gang-igjen/73542449">aldri vil tilbake på kontorene fem dager i uka som før</a>.
Han sender et sterkt og tydelig signal om hva som er viktig for han, og legger inn et spark til utviklerne — “Hvordan kan det ha seg at de samme utviklerne som i årevis har ropt høyt om at de ikke involveres i stor nok grad eller tidlig nok, nå uttaler seg over fortreffeligheten av hjemmekontor?”
Uten å gå inn på hvor ansvaret for å involvere ansatte ligger, så vitner dette på at Sahlin Pettersen ikke har fulgt med i timen det siste året, mens mange andre har innsett realiteten; at vi må forberede oss på en fremtid med distribuerte team.
Selvfølgelig er ikke hjemmekontor uten problemer, og han har nok rett i mye av det han sier; det kan være vanskelig å fange opp små signaler, og det kan være effektivt å sitte sammen når man skal løse en del type problemer — men er det slik at vi etter et år på hjemmekontor ikke har maktet å gjøre disse tingene?
At han ønsker god oppfølging av juniorer og andre medarbeidere er selvfølgelig bra, men hva da med senioren som tar på seg de støydempende hodetelefonene og irriterer seg over alt maset eller utvikleren som er langt nede i en vanskelig problemstilling og blir avbrutt fordi noen spør om han vil ha kanelbolle eller spille bordtennis?
Å ha distribuerte team krever naturligvis endringer, både i hvordan vi samarbeider, men også i ledelsesstil og personaloppfølging — det passer dårlig med hjemmekontor for ledere som liker micromanagement eller som føler de mister kontrollen når de ikke kan se alle sitte sammen.
Nå har både ledere og utviklere fått erfare hvordan det er å ha hjemmekontor i over ett år, og om det er mange som foretrekker dette så ville det vært rart å ikke ha det som en mulighet. Her er det kanskje til og med er en mulighet her for arbeidsgivere som våger ta steget fullt ut, som legger til rette for de som ønsker det, og ikke bare må ha folk på kontoret bare fordi det var slik det ble gjort før og ikke greier å håndtere at verden endrer seg.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9e896f453356" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/hjemmekontor-til-besv%C3%A6r-9e896f453356">Hjemmekontor til besvær</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<h4>Systemutvikling er et erfaringsbasert yrke. I utdanningen vil en utvikler tilegne seg mye teoretisk kunnskap, som absolutt er verdifull, men dessverre samsvarer den ikke alltid med arbeidslivet. Dermed er det ikke uvanlig at ferske utviklere får seg en skikkelig overraskelse når man endelig skal ta på seg voksen-buksene og ut i sin første jobb. Fra oss til deg, for å gjøre overgangen fra skolebenk til jobb litt enklere; her er 10 ting vi skulle ønske noen fortalte oss da vi begynte å jobbe som systemutviklere</h4>
av <a href="https://medium.com/u/e30b5da9a1ad">Kristine Helle-Andresen</a>, <a href="https://medium.com/u/d689599ad372">Mathias Hartveit</a>, <a href="https://medium.com/u/a33bd707f3e8">Malin Milford</a> og <a href="https://medium.com/u/81f56aee65a2">Martin Andersen</a>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*J0VBsMLGezdqwX9uBJ7J4A.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@frantic?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Alex Kotliarskyi</a> on <a href="https://unsplash.com/s/photos/programming?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>1. Å stille spørsmål betyr ikke at du er dum Utviklere har ofte et ønske om å “kunne alt”. Som ny i en bedrift er det lett å føle at en aldri vil bli god nok i visse teknologier eller fagområder. Da er det viktig å tidlig innse at man blir ikke bedre uten å stille “dumme” spørsmål.
Finn en god kollega, enten i utviklingsteamet eller i konsulentfirmaet ditt, som du føler du kan spørre. Husk at alle har vært der du er nå, og vil kjenne igjen de problemene du nå støter på. For dem vil det jo bare være en påminnelse om hvor langt de har kommet, og for deg er det mye hyggeligere å sitte sammen med noen og løse problemer.
2. Du kommer til å gjøre feil. Det er en del av hverdagen til en utvikler. Systemutvikling er vanskelig. I større bedrifter er det ofte mange små bevegelige programvare-deler som skal fungere i harmoni, og da er det lett å gjøre feil. Det viktigste er å danne seg rutiner for å lære av feilene sine. Har du introdusert en ny bug i kodebasen? Skriv en test som reproduserer feilen og du vil være sikker på at dette ikke skjer igjen.
Mange team praktiserer også retrospektiv-møter hvor medarbeiderne gjennomgår arbeidsmetoder og hvordan teamet kan forbedre seg fra uke til uke. Dette er en ypperlig arena for å ta opp utfordringer du har støtt på.
3. Du kommer aldri til å forstå hele kodebasen. Som konsulent og nyutdannet er det ofte man kommer inn i et eksisterende prosjekt, og det kan fort bli overveldende å sette seg inn i kodebasen. Det kan være fristende å studere så mye som mulig av koden for å oppnå forståelse, men dette er feil bruk av tid.
Fokuser på å opparbeide en forståelse av systemet og hva det utfører. Hvilke behov skal systemet dekke for brukerene? Hvorfor har vi en “DTO-Service-Bus” modul og hvorfor er den koblet til API-et? Snakk med seniorutviklere og få dem til å tegne eller vise deg grafiske representasjoner av hvordan systemet henger sammen. Dette gjør det enklere å opparbeide seg kontekstuell informasjon til den gangen du må gjøre en endring. Det er mye enklere å forstå koden i en spesifikk klasse når man på forhånd vet hva den skal oppnå.
4. Google og stack overflow er enhver utviklers aller beste venn
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*qRiA-U0xIEh3vsgpjezSsg.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@wocintechchat?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Christina @ wocintechchat.com</a> on <a href="https://unsplash.com/?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Det er urealistisk å forvente at du skal huske svaret på hvert eneste problem du noen gang har truffet på. Ikke vær redd for å lene deg på andre folks løsninger, hvis det sparer deg for mye tid og hodebry. Likevel bør du tenke deg litt om før du kopierer kode direkte fra en nettside. Forstår du hva koden gjør og hvordan den påvirker systemet ditt?
5. Kommuniser med medarbeiderene dine Det er utrolig viktig å ha god kommunikasjon og arenaer hvor utviklere (deg) kan få oversikt over hva produkteier og bruker har som behov, hva designere ønsker å formidle og hvordan ønsker kan løses teknisk.
Prat og avklar så mye som mulig om en oppgave før du begynner. Dermed unngår du mange tidkrevende iterasjoner når du eller andre medarbeidere misforstår hva som egentlig skal gjøres. Iterasjoner vil det bli, men desto flere avklaringer dere gjør i forkant, desto større er sannsynligheten for at dere holder antallet nede. Det er alle tjent med!
6. Tør å komme med innspill og ideer, selv om du er ny! Perspektivene til nye utviklere er ofte gull verdt for et team; kanskje har man gjort noe unødvendig komplisert? Kanskje kunne man løst noe på en annen eller ny måte? Teknologien kan bevege seg raskere enn mange i arbeidslivet får med seg. Nye personer med erfaring fra andre teknologier kan ofte gi nye muligheter man ellers ville gått glipp av.
7. Perfect is the enemy of done I smidig utvikling har du som utvikler et mål om å fullføre en spesifikk oppgave innen en gitt tid. Da er det er fort gjort med scope creep. Enten det er at du finner bugs underveis, innser at noe burde omskrives, eller at en variabel burde hete noe annet og du finner ut at du skal endre dette i hele kodebasen. Det vil alltid være noe som kan gjøres bedre. Det er alltid noe som kan perfeksjoneres. Husk hva oppgaven din opprinnelig var og lag forbedringsoppgaver på det du finner underveis. Om du skal gjøre alt perfekt så blir du nemlig aldri ferdig.
8. Noen dager vil se slik ut:
<ol>
<li>Du stanger hodet i veggen fordi du ikke klarer å løse et problem</li>
<li>Du tråler internett og stack overflow for å se om NOEN andre i hele verden har hatt samme problemstilling…</li>
<li>Før du går for dagen pusher du tre linjer med kode, som knekker hele bygget, og det var det du gjorde den dagen… Happy times.</li>
<li>Det du må gjøre da, er: gå hjem, sov, løp deg en tur, og la underbevisstheten jobbe. 9/10 dager kommer du på jobb dagen etter og bruker 10 minutter på å fikse det som ikke fungerte.</li>
</ol>
9. … Men, andre dager skriver du tre linjer med kode som fikser alt! Faktum er at størstedelen av tiden som utvikler går med til å fikse feil, som du noen ganger selv har introdusert. Så, når du fikser feilene er det desto viktigere å nyte suksessen før du kaster deg over neste feil. Ta en kort pause og vær stolt over hva du har fått til!
10. Ikke vær redd for å si “nei” Som utvikler i en bedrift er det din jobb å kjenne til mulighetene med teknologien, men også begrensningene. En medarbeider vil sette pris på at du som fagperson stiller kritiske spørsmål til utvikling av systemer og løsninger. I teorien er alt mulig innen IT, men det er din jobb å vite hva kostnaden av å utføre det blir. Det er like viktig at man ikke sier ja til alt, akkurat som at man ikke sier nei til alt.
60% av utviklere rapporterer at de <a href="https://www.kode24.no/kodelokka/60-prosent-jobber-overtid-hver-uke/71078276">jobber overtid</a>. Du kan ofte bli spurt om du “bare kan fikse denne lille ekstra tingen?”. Kvaliteten på det du skal gjøre kan fort bli dårlig dersom du alltid påtar deg ekstra arbeid eller jobber for raskt. Det er viktig å sette grenser for deg selv når det kommer til ansvar og overtid.
11. Å sprekke på et estimat er ikke verdens undergang ;) Å bomme på estimat er noe både nye og erfarne utviklere opplever hele tiden. Det viktige er å tilegne deg verktøy og erfaring som lar deg melde ifra tidlig. Jo tidligere et team melder i fra om at en leveranse overgår estimatet, jo større spillerom har alle involverte i prosjektet.
… Og med dette gjenstår det bare å ønske deg masse lykke til i arbeidslivet!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=974fb21592e" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/10-ting-jeg-skulle-%C3%B8nske-noen-fortalte-meg-da-jeg-begynte-%C3%A5-jobbe-som-utvikler-974fb21592e">10 ting jeg skulle ønske noen fortalte meg da jeg begynte å jobbe som utvikler</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Av: <a href="https://medium.com/u/8fb5525e0684">Eirik Gihle</a> og <a href="https://medium.com/u/cbae7ec46d93">Karianne Tørum</a>
1. Det er ingen andre på kontoret som sitter med fasiten når det gjelder design! De rutinerte har selvfølgelig erfaringer som er verdt å ta med seg, og de kjenner fallgruvene fra tidligere prosjekter. Men,- det er ikke det samme som at de har fasiten for neste prosjekt. Verden forandrer seg fort! Det som var riktig og viktig før trenger nødvendigvis ikke være verken riktig, eller viktig nå.
2. Vi er ikke hjernekirurger! (og heldigvis for det…) Jeg tror det er viktig å ha perspektiv på hva vi som designere faktisk kan oppnå. Et godt og gjennomtenkt design kan gjøre at produkter og tjenester selger eller fungerer bedre. En god strategi og et tett samarbeid med forretningsutvikling og utviklingsmiljøene kan også bidra til at vi evner å lage produkter som betyr noe for brukergruppene. Og det er topp når det funker! Men det er faktisk litt alright å tenke på at, — så lenge du ikke designer en hjertestarter eller utvikler et nytt varslingssystem for nødsituasjoner er det ingen som dør. Ingen! Vi som designer en merkevare, en applikasjon eller en nettside har rom for å lære gjennom å feile. Og det syns jeg er skikkelig digg å tenke på… samtidig som jeg får veldig stor respekt for de som må ta de virkelig store avgjørelsene, som påvirker livene til folk på en helt annen skala enn designet på Zalando gjør.
Jeg tror jeg ville senket skuldrene litt, og kanskje turt å være mer utforskende dersom dette var kommunisert litt tydeligere da jeg begynte som designer.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*d0-mmUDnZZpqscbjnAizzw.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@mimithian?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Mimi Thian</a> on <a href="https://unsplash.com/s/photos/listening?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>3. Lytt mer enn du prater! Dette var en av tingene jeg faktisk ble fortalt, — av en meget klok kollega jeg hadde noen år tilbake. For å bruke hans egne ord, (Correct me if I´m wrong Frank Myrseth): “Det er en grunn til at vi har to ører og bare én munn”. I vår iver etter å overbevise om at man har designet en fantastisk løsning, kan man lett gå glipp av verdifulle perspektiver, dersom man ikke stopper opp og tar i mot innspill fra utsiden. Dessuten er jo nøkkelen til et godt design å faktisk forstå hvilket problem som skal løses.
Siden verden har forandret seg mye siden jeg tok min utdanning og startet i min første jobb, er det ting som selvsagt ingen kunne ha forutsetning for å si, men som jeg håper blir sagt nå:
4. Tenk som en utvikler! Å jobbe strukturert har alltid vært en god ting. Men nå, når vi designer løsninger som skal fungere på fler og fler formater, der brukerne egentlig i praksis selv kan styre mye av hvordan de ønsker å få presentert et innhold, blir det viktigste av alt å utvikle et solid bunnsystem som kan fungere godt på alle flater. NB: Dersom du f.eks. designer et bokomslag kan du se bort fra dette punktet. Da kan du velte deg i fantastisk typografi som bare passer for akkurat det ordet du skal skrive og bruke ditt skarpe visuelle blikk til å tilføre en unik stil der du har latt deg inspirere av akkurat de du vil!
5. Jobben er aldri ferdig! Ingenting av det vi gjør er hugget i stein, og det kan det ikke være heller. Vi må tørre å lansere ting, selv om det ikke er perfekt. For perfekt blir det aldri. I samme øyeblikk som man lanserer noe, begynner man å lære hva som fungerer og ikke. Og nye ting kommer inn fra sidelinja, hele tiden. Dette gjør at vi må tenke nytt og justere systemet vårt kontinuerlig. Så jeg må gjenta meg selv fra punkt 1, bare med en kortere tidshorisont denne gangen: Det som var riktig og viktig «i går» trenger nødvendigvis ikke være verken riktig eller viktig «i dag».
6. Aksepter at du aldri får full kontroll! Design er et håndverk, og vi elsker når alt sitter. Men siden alt er i endring, som nevnt i forrige punkt, må vi tåle å ikke ha full kontroll over alt. Det er for mye for en person. Så enkelt er det. Man bør selvfølgelig klamre seg fast i den røde tråden, og ta høyde for så mange eventualiteter man kan komme på. Men, med et slikt utall av flater og formater vi har i dag, skal du ikke bli lei deg hvis en komponent fikk et merkelig linjefall på én av flatene, i én av nettleserne. Da fikser du det i morgen. Hvis det er viktig nok!
7. Å feile er ikke feil! Det er faktisk ikke det. Vi prøver, vi seirer, vi feiler og vi lærer… og vi utfordrer! Vi må aldri bli så redd for å feile at vi ikke tør å utfordre. Det er bedre å feile litt på veien, dersom man har lært hvordan man kan flytte på noen barrierer, enn å ha gjort alt etter boka… og stå på stedet hvil. Som en leder jeg en gang hadde sa så fint: “Siden vi lærer så mye av å feile, må vi feile oftere, og vi må feile mye fortere!”
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*maurjo94aWjtzeoMZKkncA.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@johnschno?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">John Schnobrich</a> on <a href="https://unsplash.com/s/photos/collaborate?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>8. En ide blir mer verdt når den deles! Uansett hvor mye du har satt deg inn i et tema, og hvor mye du kan, klarer du ikke å se ting med andres øyne. Kommunikasjon er alltid på mottakers premisser. Og jo flere mottakere du klarer å involvere, jo større er sjansen for å lykkes. Man kan selvfølgelig føle seg sårbar ved å dele uferdige idéer, og det er helt normalt. Men det er fort glemt når gevinsten i den andre enden er at man har alle på lag, og konseptet er bunnsolid. Les gjerne; <a href="https://medium.com/dfind-consulting/tverrfaglig-samarbeid-genererer-store-besparelser-62b9f6225d7b">“Tverrfaglig samarbeid genererer store besparelser”</a>
9. Vær bevisst ditt samfunnsansvar! Skal man lykkes med konseptene sine, må man som sagt involvere brukere. Da er det også viktig å huske at en bruker kan ha mange ansikter. Jeg snakker selvfølgelig om universell utforming, eller “design for alle”. UU kan ikke være noe man bare “legger på” på slutten. Fordi det handler ikke bare om skriftstørrelser og kontraster og at man kan tab´e seg gjennom løsningen. Det handler også om hvordan man prioriterer innhold i grensesnittet sitt.
Hvordan oppleves designet for en person med konsentrasjonsvansker, hvor lett er det å forstå for en person med Alzheimer, og hvilke overskrifter blir lest opp for svaksynte som benytter skjermleser?
Selv om det finnes mange gode føringer, kan man ikke lese seg til alt! Så inkluder alle mennesketyper som kan finne på å bruke løsningen din. Inkluderende design ja, det var det ordet jeg lette etter.
10. Du er flink! En slik kommentar fra en leder eller kollega betyr mer enn det koster å si. Er du opptatt av det du gjør, jobber hardt og interesserer deg i oppgaven, gjør du mest sannsynlig en god jobb. Og får du den kommentaren, er sannsynligheten stor for at du fortsetter å være akkurat det, — flink… og kanskje bli enda flinkere!
Lykke til!
Håper vi sees en dag :)
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=99d5720b9af4" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/10-ting-jeg-skulle-%C3%B8nske-noen-fortalte-meg-da-jeg-begynte-%C3%A5-jobbe-som-designer-99d5720b9af4">10 ting jeg skulle ønske noen fortalte meg da jeg begynte å jobbe som designer</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

I 2004 skjedde det noe som fikk store konsekvenser. Det var da vi fikk deltagerdrevne interaktive tjenester, også kjent som web 2.0. Vår intelligens ble koblet sammen i samtid og vi kunne jobbe sammen innenfor samme rammer, ikke lenger bare løsrevet på egenhånd.
Av: <a href="https://medium.com/u/cbae7ec46d93">Karianne Tørum</a> og <a href="https://medium.com/u/8fb5525e0684">Eirik Gihle</a>
Takket være denne innovasjonen kan vi i dag diskutere, gi og få tilbakemeldinger på eget og andres arbeid i samtid og vi kan designe løsninger sammen med andre, løsrevet fra sted og tid. Konseptet der enkeltindivider opererer som «kreative genier» har gradvis gått forbi (– og takk for det)! Det faktum at digitale produkter og tjenester er komplekse har ført til en erkjennelse av at selve prosessen og produktet blir bedre når flere fagfelt jobber sammen mot et felles mål. Med gode digitale samarbeidsverktøy har det blitt enklere å involvere flere i designprosessen, også fra andre fagfelt.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*0IX5b7kLQw-m0-wq"><figcaption>Photo by <a href="https://unsplash.com/@homajob?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Scott Graham</a> on <a href="https://unsplash.com/s/photos/work?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Design Collabration Før i tiden var det vanlig å sette navnet sitt på alt man hadde laget. Spesielt innen design. Man satte gjerne eget navn på illustrasjoner, eller firmaets logo dersom et produkt var utviklet av et byrå. Designmanualer som ble trykket var forbeholdt ansatte i selskapet, og designmanualer på nett var gjerne passordbeskyttet. Vi var opptatte av «åndsverksloven», og at ingen skulle stjele idéene våre. Og tanken var god, den gang. Alle skulle få noe igjen for arbeidet sitt, og alle skulle bli anerkjent for det de hadde utviklet. Det vi imidlertid ikke hadde like mye av var effektiviteten og standardene. Som bruker av en tjeneste ønsker vi forutsigbarhet. Ikke nødvendigvis at alt skal se likt ut, men vi ønsker ikke å bruke tid på å vurdere om knappen kan trykkes på, eller på hvilken måte man kan zoome inn på et bilde. Faste mønster gjør det lettere for alle, og et selskap alene kan ikke stå for opplæringen av et helt samfunn. Derfor kopierer vi hverandre, — med god grunn! (Det hadde forresten også vært ganske slitsomt å reise rundt i verden om alle verdens T-banekart så helt forskjellige ut.) Teknologi og design går i dag hånd i hånd, og det er ikke bare mellom designere det deles. Design Collaboration er en tilnærming til design hvor man erkjenner avhengigheten av andre fagfelt for å kunne flytte en abstrakt idé til et ferdig produkt. Et slikt samarbeide bringer flere perspektiver inn i utviklingsfasen og man ser en utfordring fra flere vinkler, og kan vurdere ideer fra ulike faglige perspektiver. Å tørre å slippe designet sitt, for å la andre bygge videre på idéene man har, bidrar ikke bare til å sikre et mer robust konsept, men kan i tillegg gi et langt større markedspotensiale. Det å kunne diskutere idéer og la andre bygge videre på dem gjør dem robuste med et større markedspotensial.
Økonomisk perspektiv Vi designere i skandinavia er veldig flinke til å plassere brukere og deres behov i sentrum, men vi er også avhengig av å forstå og inkludere det økonomiske aspektet tidlig i utviklingsprosessen. Det koster å utvikle og forvalte en tjeneste, og tjenesten som utvikles må generere penger i form av inntekt fra sluttbruker eller besparelser ved at tjenesten overtar for eksisterende løsning og frigjør kapital. En god designmetodikk koblet med analytisk tilnærming er derfor nødvendig. Et eksempel på økonomisk besparelse ved hjelp av god metodikk kan være samarbeide mellom designere og utviklere tidlig i designprosessen for å sikre at man tar høyde for de tekniske mulighetene som er tilstede og kartlegge eventuelle begrensninger. Dermed elimineres potensielle dyre tekniske sperringer allerede tidlig i utviklingsfasen. Det er også begrenset hvor mye personer fra ett fagfelt klarer å arbeide alene når man skal vektlegge brukerbehov og definere produktmål. Andre tiltak som gir økonomisk gevinst er endringen fra designmanualer til åpne designsystemer. Slike designsystem utvikles gjennom Design collaboration og genererer enorme besparelser da ferdiglagte komponenter og kodebibliotek gjenbrukes, både i skissefaser og utviklingsfaser, på tvers av hele applikasjonen. Det sikrer også en helhetlig og enhetlig profil og, ivaretar merkevaren på alle flater og kanaler.
Effektive verktøy For å gjennomføre effektive prosjektsamarbeid, er det viktig at man har gode verktøy som legger til rette for samarbeid. Slike samarbeidsverktøy fjerner flere barrierer for de involverte parter ved at det er enkelt å få tilgang til det som lages og man kan designe sammen i sanntid. Det hjelper til å holde fokus på rett sted, og man kan samarbeide om design og flyt uten å ødelegge en “original”. Før var vi avhengig av verktøy som gav oss grunnleggende versjonskontroll i steden for effektiv samarbeid. En hver designer satt på sin versjon og lastet for eksempel en sketch-fil opp i dropbox. Et annet team-medlem måtte så laste det ned, gjøre sitt arbeid for så å laste det opp igjen. Det å gjøre kjappe endringer var vanskelig siden et annet teammedlem kanskje satt og arbeidet med filen. Denne versjonskontrollen gjorde et effektivt samarbeid vanskelig, tidkrevende og lite motiverende. Nå har designerne fått nye samarbeidsverktøy som for eksempel Figma. Her kan de involverte jobbe i samme fil på samme tid, kommunisere med hverandre i samtid og involverte stakeholders som for eksempel jurister eller produkteier. Man kan chatte, lage prototyper, gjennomføre brukertester, og generere CSS og html til frontendutviklerne. Rett og slett ganske så flott og på tide!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=62b9f6225d7b" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/tverrfaglig-samarbeid-genererer-store-besparelser-62b9f6225d7b">Tverrfaglig samarbeid genererer store besparelser</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nysgjerrige folk med forskjellig kompetanse gir nye perspektiver og styrker oss som selskap. Du bør ha relevant utdanning og minimum 3 års erfaring som utvikler, designer, arkitekt eller prosjektleder. Bli med på laget!

Bli en av oss banner

Møt en X banner

Vi elsker teknologi og løsninger vi kan lage for både den private og offentlige sektor. 

I dag kreves det kontinuerlig nye funksjoner i applikasjoner for å være konkurransedyktige, derfor er vi en smart samarbeidspartner som innehar kompetanse innen flere ulike frontend rammeverk, kunstig inteligens, maskinlæring, skytjenester, DevOps og solid backend kompetanse.

Systemutvikling artikkel

Systemutvikling

UX design handler om totalopplevelsen en bruker har i et møte med en digital tjeneste, system eller produkt.

Våre designere lytter og utvikler krav basert på innsikt, lager prototyper, tester og itererer til tjenesten tilfredsstiller brukeren og bedriftens krav. Vi jobber tverrfaglig med grafisk-, tjeneste- og interaksjonsdesignere for å lage løsninger med høy brukskvalitet og gode bruksopplevelser. Våre design-konsulenter har lang erfaring og jobbet med mange kunder i privat og offentlig sektor. Vi har særdeles god kompetanse på smidige brukersentrerte designprosesser og universell utforming.

skumring

Design artikkel

UX design

Et digitalt produkt skal fungere på flere platformer og enheter uten at kunden opplever at kvaliteten forringes. Det krever derfor god prosjektledelse som ser helheten og samtidig de enkelte komponentene i et utviklingsmiljø.

Våre prosjektledere/teamledere fungerer som rådgivere for våre partnere. Vi er smidige og tilpasser oss våre kunders behov og skalerer prosjektene ut fra omgivelsene, eksisterende rammeverk og krav. Vi er oppdatert og kjenner til ulike metoder som passer best til forutsetningene, om man sikter mot en MVP som skal itereres eller et rammeverk som skal forvaltes på en hensiktsmessig måte. Våre konsulenter ser helheten i systemporteføljen og sikrer god informasjonsflyt mellom de involverte parter.

Prosjektledelse artikkel

Prosjektledelse

En systemarkitekt sørger for at en utviklingsprosess tar hensyn til allerede eksisterende infrastruktur og hvordan ulike tjenester og produkter samhandler best mulig for å oppnå ønsket mål.

Våre arkitekter ser helheten i infrastrukturen og sørger for at en agil utviklingsprosess kan gå så smertefritt som mulig. De beskriver hvordan ulike tjenester og produkter samhandler best mulig for å oppnå ønsket mål, uten nedetid for øvrige funksjoner.  

Arkitektur artikkel

Arkitektur

Vi jobber med systemutvikling, brukeropplevelser (UX), prosjektledelse, rådgivning og arkitektur.

Prosjektledelse og rådgivning

Blogginnlegg

Bli en av oss

Les om hvordan det er å jobbe hos oss