Programmeringsspråk, biblioteker og rammeverk preger stillingsannonser, artikler og konferanser i bransjen vår. Forståelig nok – vi er tross alt utviklere. Likevel, om jeg får ønske meg én ting til jul, er det at vi vier litt mer oppmerksomhet til det vi faktisk bruker teknologien til.

Økt fokus på domenet

Teknologi er et verktøy for å løse problemer innen ulike domener. Vi effektiviserer arbeidshverdagen til inspektørene i Mattilsynet, vi automatiserer og forenkler jobben til saksbehandlerne hos NAV, og vi tilgjengeliggjør helseopplysningene våre til legene og sykepleierne på legevakten.

For å lykkes med dette trenger vi mer enn tekniske ferdigheter.

Jeg tror at NAV, for eksempel, ville fått de beste digitale arbeidsverktøyene hvis noen av saksbehandlerne hadde utdannet seg innen IT og utviklet systemene selv. Litt som på 60-tallet, da det var folka med kompetanse på domenet som skrev koden.

Heldigvis får vi de nest beste løsningene om vi setter oss godt inn i jobben til saksbehandlerne. Det betyr at vi må lese oss opp på arbeidsavklaringspenger og barnetrygd. Vi må reise ut og besøke NAV-kontorer. Og vi må dykke ned i de kompliserte prosessene bak ulike søknader sammen med domene-ekspertene.

Deretter må vi gjenspeile forståelsen vår av domenet i koden vi skriver.

Det blir bra, det.

Men det gjør vi jo allerede?

Alle team forholder seg til domenet i større eller mindre grad. Og erfaringen min er at de aller fleste utviklere er nysgjerrige på brukernes fagområde. Samtidig mener jeg vi har mer å gå på.

Jeg har deltatt i prosjekter hvor utviklerne tilbrakte nesten like mye tid foran tavle med domene-ekspertene som foran PC-skjermen. Og det tror jeg ofte må til når vi digitaliserer arbeidsoppgaver innenfor kompliserte domener.

Det man får igjen for det, er:

  • En felles forståelse av domenet og problemene som skal løses
  • Et felles vokabular med utvetydige begreper, som forhindrer misforståelser
  • En uttrykksfull og nyttig domenemodell gjennomsyret av fagord
  • Og en kodebase som ikke drukner i “teknisk” gjeld

Ikke minst sitter man igjen med utviklere med den kruttsterke kombinasjonen av domenekompetanse og teknologisk kompetanse. Med kompetanse “på begge sider”, kan de oppdage muligheter som sparer kundene for mye tid og penger. Og de glir naturlig inn i rollen som sparringspartner for både domene-eksperter og produkteiere.

Konsekvensene av manglende domeneforståelse

Hva med det motsatte tilfellet, hvor du har utviklingsteam med lav domeneforståelse? I mindre alvorlige tilfeller ender man kanskje opp med frustrerte brukere som må forholde seg til uforståelige tekniske begreper, eller systemer hvor viktig informasjon drukner i detaljer brukerne sjeldent har behov for. I andre tilfeller legger kanskje systemene opp til helt andre arbeidsflyter enn det brukerne har i arbeidshverdagen sin.

I verste fall løser ikke programmene brukernes behov og må skrotes.

I nest verste fall ender man bare opp med et fakkeltog eller to.

Domenedrevet design

Vi har beveget oss vekk fra programmerende domene-eksperter på 60-tallet, til programmering som en egen disiplin og et påfølgende mindre fokus på domenet. Eric Evans, mannen bak domenedrevet design, er en av de som så utfordringene med dette. Domenedrevet design er en tilnærming til software-utvikling hvor Domenet står i midten som den store stjernen. Teknologien er fremdeles til stede, men i stedet for å stjele fokuset, ligger den rundt og støtter og bygger opp.

Domenedrevet design har i stor grad bidratt til å bygge opp min brennende interesse for å forstå domenene jeg jobber med. Det er en verktøykasse med både kode-nære og mer strategiske godsaker, og jeg er helt sikker på at du òg kan finne noe av interesse der.

En lavthengende frukt er å samle teamet og sammen lage en liste hvor dere definerer begrepene i domenemodellen deres. Har utviklerne og fagpersonene den samme forståelsen? Lykke til!



Jeg har sendt en kopi av teksten til nissen, så da gjenstår det bare å se om jeg får juleønsket mitt innfridd.

God jul! 🎄