Jeg har ofte stått midt mellom ulike fagmiljøer og erfart at teknologi bare er én del av puslespillet. Like viktig er menneskene, kommunikasjonen og samarbeidet på tvers.
Med en bakgrunn fra produktutvikling, prosjektledelse, salg, support, markedsføring og IT har jeg sett hvordan utviklere, designere, markedsførere og kundebehandlere alle bidrar til helheten. Men uten en klar forståelse av hvem som gjør hva kan man fort snakke forbi hverandre, selv når intensjonene er gode. Derfor har jeg valgt å beskrive rollene i et utviklingsteam på en forenklet måte, både for å friske opp min egen forståelse og for å dele det videre med andre.
De vanligste rollene i et utviklingsteam
Det er lett å gå seg vill i jungelen av titler. For hva gjør egentlig en systemarkitekt sammenlignet med en løsningsarkitekt? Og hvorfor er ikke alle utviklere “bare utviklere”? Etter mange år tett på utviklingsteam vet jeg at det ikke alltid er like enkelt å skille rollene fra hverandre. Og jeg roter fortsatt innimellom.
For å gjøre dette mer konkret har jeg laget en oversikt over de vanligste rollene i et utviklingsteam, forklart på et språk jeg håper også de uten teknisk bakgrunn kan forstå.
Systemarkitekt (teknisk rammeverk)
Systemarkitekten har det store bildet. Dette er personen som legger de tekniske rammene for hvordan systemet skal bygges, hvilke plattformer som skal brukes og hvordan ulike deler skal fungere sammen. De tar avgjørelser som påvirker både utvikling, sikkerhet og fremtidig vedlikehold.
Løsningsarkitekt (forretningsbehov koblet til teknologi)
Der systemarkitekten ser på det tekniske overblikket, har løsningsarkitekten gjerne mer fokus på helheten fra et forretningsperspektiv. Løsningsarkitekten går mer i dybden og ser på hvordan ulike systemer kan settes sammen for å møte behovene til brukerne, og samarbeider tett med både produktledelse, arkitektur og utvikling.
Teknisk leder (team lead)
Teknisk leder er som regel en seniorutvikler med dyp teknisk kompetanse. Rollen omtales også gjerne som team lead, og fungerer som et faglig anker som tar ansvar for kodekvalitet, arkitekturvalg og tekniske beslutninger. I tillegg veileder de andre utviklere, svarer på spørsmål og fungerer som en trygg veiviser i hverdagen.
Ikke alle team har en egen teknisk leder. I noen tilfeller fyller en produktleder (Product Manager eller Product Owner) denne rollen, men forskjellen er at produktlederen ikke alltid har koding eller arkitektur som kjernekompetanse. Da blir fokuset mer på koordinering og prioritering, mens de tekniske detaljene håndteres av utviklerne selv.
Utviklere
Utviklere skriver koden som får systemet til å virke. Her finnes det ulike spesialiseringer:
- Grensesnittutvikler (frontend) jobber med det brukeren ser og klikker på. Menyer, knapper, skjemaer og hele det visuelle uttrykket. Litt som maleren og snekkeren som sammen gir huset fasade, farge, dører, vinduer og detaljer som sprosser.
- Bakutvikler (backend) tar seg av det som skjer i kulissene: databaser, logikk, systemintegrasjoner og håndtering av informasjon. Eller den som sørger for armering i veggene, rør og strøm i et hus, om du vil.
- Fullstack-utvikler kan begge deler, og deltar ofte i hele utviklingsløpet fra fundament til fasade.
Drift og utvikling (DevOps)
DevOps er egentlig en metode og kultur for å få utvikling og drift til å jobbe sømløst sammen. Målet er å korte ned tiden fra kode til produksjon gjennom automatisering, kontinuerlig testing og trygg utrulling.
I praksis omtales DevOps ofte som en egen rolle, særlig i mindre team. Da handler det gjerne om å sette opp og vedlikeholde rutiner for klargjøring av programvaren, testing, overvåking og utrulling, slik at nye versjoner kan tas i bruk raskt og stabilt. Dette er ofte personen som trår til når «alt bare må virke».
Kvalitetssikrer og tester (QA)
Kvalitetssikrerne sørger for at systemet faktisk fungerer slik det skal. De lager testscenarier, finner feil og bidrar til at sluttbrukeren får en trygg og god opplevelse. Mange jobber både med manuell og automatisert testing, og samarbeider tett med utviklere og produkteiere.
Produktsjef og produktleder
Dette er rollen jeg selv har hatt i mange år. Som produktleder er man bindeleddet mellom virksomheten, brukerne og utviklingsteamet. Man prioriterer hva som skal lages, hvorfor det er viktig og hvem det skal hjelpe. Rollen handler mye om å oversette behov til løsninger, og om å sikre at alle trekker i samme retning.
I noen organisasjoner brukes begrepene produktleder og produktsjef om hverandre, i andre skilles det tydelig. I smidige metoder møter man dessuten ofte begrepene Product Owner og Product Manager, så her varierer praksisen mye
Smidig tilrettelegger
En smidig tilrettelegger, ofte omtalt som Scrum Master eller smidig coach, hjelper teamet med å jobbe effektivt og strukturert. De leder møter, fjerner hindringer og passer på at teamet lærer og utvikler seg underveis. Rollen er ikke en sjef, men en støttespiller for både prosessen og menneskene.
Et godt eksempel er de daglige standup-møtene. De handler ikke om å fortelle vitser, men om å stå oppreist i fem minutter og si hva du driver med. Kort og konsist: hva du gjorde i går, hva du skal i dag og om noe står i veien. På den måten slipper teamet å gjette, og kan heller hjelpe hverandre videre.
Brukeropplevelsesdesigner (UX)
UX-designeren sørger for at løsningen er enkel, logisk og god å bruke. De kartlegger behov, lager skisser og prototyper, og jobber tett med utviklere og produktledere for å sikre at det som bygges faktisk gir verdi.
På en byggeplass er UX som arkitekten som planlegger hvordan folk skal bevege seg gjennom huset. Hvor dørene skal stå, at gangen ikke blir for trang, og at kjøkkenet henger naturlig sammen med spisestua.
Grensesnittdesigner (UI)
UI-designeren tar ansvar for det visuelle. De bestemmer farger, fonter, knappestørrelser og layout, ofte basert på et designsystem. UX og UI henger tett sammen, men handler om henholdsvis bruk og utseende.
På byggeplassen er UI den som velger flisene på badet, fargen på veggene og formen på dørhåndtakene. Samtidig passer de på at badet er stort nok for en rullestol, at lysbryterne er lett tilgjengelige og at helheten fungerer for alle som skal bo der.
Sikkerhetsansvarlig
I prosjekter der sikkerhet, personvern og databeskyttelse er viktig, har man ofte en egen rolle med ansvar for dette. Personen gjør risikovurderinger, legger føringer for sikker design og sørger for tekniske tiltak som beskytter både brukerne og systemet.
Sikkerhetsansvarlig bør også jobbe tett med den som har ansvar for personvern og GDPR. Ofte er det en databehandler eller personvernansvarlig som sørger for at lovkravene blir fulgt. Samarbeidet mellom disse rollene er avgjørende for å sikre både teknisk trygghet og juridisk etterlevelse.
Dataanalytiker
Når datainnsamling eller maskinlæring er sentralt, har man gjerne med en dataanalytiker. De bearbeider data og oversetter tall til innsikt som kan brukes videre i utviklingen.
På en byggeplass er dataanalytikeren som den som leser måleinstrumentene, sjekker hvor mye huset har sunket i grunnen, regner på energiforbruk eller teller hvor mange kilo stål som faktisk er brukt. De tar tallene fra virkeligheten og gjør dem til beslutningsgrunnlag for videre arbeid.
Release Manager
I større miljøer finnes det egne personer som har ansvar for klargjøring og utrulling av nye versjoner. De sørger for versjonshåndtering, oppsett av testmiljøer og kontrollert lansering, slik at nye funksjoner kan slippes uten risiko.
I moderne utviklingsmiljøer har mye av dette arbeidet glidd inn i DevOps-rollen, men i store organisasjoner ser man fortsatt egne Release Managers som koordinerer prosessen og sikrer stabilitet i leveransene.
Andre støttende roller
I tillegg finnes det ofte roller som teknisk skribent, dokumentasjonsansvarlig, supportressurser, driftsteknikere og prosjektledere. I større prosjekter dukker det gjerne også opp en forretningsanalytiker (Business Analyst) som hjelper til med å oversette behov fra organisasjonen til utviklingsteamet.
Et utviklingsteam kan se litt ulikt ut avhengig av størrelse og behov, men typisk finner vi:
Kjerneteamet
- Utviklere (frontend, backend, fullstack)
- Teknisk leder / team lead
- Produktsjef eller produktleder (ofte kalt Product Owner i smidige metoder)
- UX- og UI-designere
- QA / test
- Smidig tilrettelegger (Scrum Master eller coach)
Utvidet team (vanligere i større organisasjoner)
- Systemarkitekt
- Løsningsarkitekt
- DevOps-ansvarlig
- Release Manager
- Sikkerhetsansvarlig / personvernansvarlig
- Dataanalytiker
- Forretningsanalytiker
- Andre støttefunksjoner (support, drift, dokumentasjon osv.)
Når én hatt ikke er nok
I praksis dekker ofte én person flere roller, særlig i mindre team eller prosjekter med begrensede ressurser. En utvikler kan både kode og teste, en grensesnittutvikler kan ta ansvar for hele designet, og en produktsjef kan ende opp med å være både løsningsarkitekt og prosjektleder. Har produktsjefen teknisk bakgrunn, er det ofte naturlig å ta en arkitektrolle fordi man har den tette kontakten med kunder og bestillere. Det gjør det enklere å oversette behov til løsninger uten at viktig informasjon går tapt.
I noen tilfeller er det til og med produktsjefen som definerer systemarkitekturen. Det er heller ikke uvanlig at en DevOps-ressurs formelt hører til driftsavdelingen, men likevel er tett koblet til utviklingsløpet.
Derfor er det viktig å huske at titler ikke alltid sier alt. Det handler ikke bare om hvem folk er, men hvilke oppgaver de faktisk løser. I tverrfaglige team er fleksibilitet ofte like viktig som formell rollefordeling.
Ta en runde i teamet
Å forstå de ulike rollene i et utviklingsteam gjør samarbeidet enklere. Det gir bedre dialog, tydeligere forventninger og mer effektive prosjekter. Jeg har selv erfart at gode teknologiløsninger sjelden bare handler om teknologi. De handler om mennesker som forstår hverandre.
Derfor kan det være lurt å ta en ærlig runde i teamet og se på hva folk faktisk gjør i praksis, ikke bare hva de ble ansatt som. Roller endrer seg ofte underveis, særlig når prosjekter varer i flere år eller behovene skifter. Den som en gang ble ansatt som utvikler kan i dag bruke mye av tiden sin på arkitektur eller koordinering, mens en designer kanskje har tatt mer ansvar for brukerinnsikt enn for visuell utforming. Å sette ord på dette sammen kan gi bedre forståelse av teamets styrker, og tydeliggjøre hvor det mangler kapasitet.
Hvorfor dette er nyttig å vite
Når vi jobber sammen på tvers av fagmiljøer som utvikling, design, kundeservice, markedsføring og ledelse, er det en fordel å vite hvem som bygger, hvem som tester og hvem som holder i trådene. Ikke for å bli ekspert på alt, men for å kunne samarbeide godt og stille riktige spørsmål.
Det er også nyttig i møte med andre. Når du forstår hvilke roller som finnes, vet du hva du kan forvente av folk, og hva de kan forvente av deg.
Enda viktigere er det at en slik forståelse gjør det lettere å avklare hva man faktisk trenger før man lyser ut stillinger. Ofte ser jeg stillingsannonser som egentlig ber om en unicorn, altså en person som skal dekke fem roller på én gang. Da er det bedre å vite hvilke hatter som er mest kritiske, og hvilke som kan kombineres i praksis.
Dette handler ikke om å være firkantet eller å holde seg strengt til en stillingsbeskrivelse. Det handler om å ha en tydelig og gjensidig forståelse av hvem som gjør hva, slik at samarbeid blir enklere, forventningene klarere og resultatet bedre.
Til slutt vil jeg nevne at dette er en overordnet og forenklet beskrivelse av rollene i et utviklingsteam. Mange utviklere vil sikkert kunne gå mer i dybden eller være uenige i enkelte nyanser, og det er helt greit. Jeg er åpen for innspill som kan gjøre artikkelen bedre, så del gjerne tanker eller erfaringer i kommentarfeltet.
