3 murere jobber hardt i sola med å legge murstein.
Vi spør dem hva de driver med:

“Jeg legger murstein”

svarer den første.

“Jeg lager en vegg”

svarer den andre.

“Jeg bygger en katedral”

svarer den tredje.

Vi har vel alle hørt varianter av denne før. Hvordan vi ser på arbeidet vi gjør, påvirker motivasjonen vår og hvordan vi jobber.

Hvorfor?

God forståelse for hvorfor vi gjør det vi gjør er kjempeviktig. Når vi skal lage IT-systemer må vi forstå hva de skal brukes til. Er det en katedral som skal bygges? Eller er det billige midlertidige boliger for å huse folk etter en naturkatastrofe?

Vi lager ikke IT-systemer for romvesener, delfiner eller AI. Det er menneskelige behov som står bak all utvikling av software. Vi må forstå disse behovene slik at vi ikke lager systemer som løser feil problemer.

Leger bruker software til å redde liv og forbedre livskvalitet. Politiet bruker software til å ivareta tryggheten og rettssikkerheten til befolkningen. Løsningene vi lager har kun verdi hvis de bidrar til å levere disse verdiene.

Men skal koden vi skriver redde liv? Skal koden vår ivareta rettssikkerhet? Er det koden vår som bygger katedralen?

Som oftest ikke.

Det er ikke verktøyene som leverer verdi: Det er brukerne.

Skal man bygge en katedral, trenger man murstein og mørtel. Hammer og drill. Skruer og spiker. (Gjerne levert sammen i verktøykasser.) Små, enkle, spissede verktøy, som håndverkeren bruker for å bygge katedralen. Det er hun som gjør jobben. Ikke drillen. Ikke drill-fabrikanten. Enkle solide verktøy kan brukes til å løse utallige menneskelige behov. En drill kan brukes til å bygge både katedral og utedass. Oftest er det denne typen fleksible verktøy vi bør levere.

I vår søken etter forståelse for brukerbehov, er det veldig lett å glemme hva som er brukerens ansvar, og hva som er vårt ansvar som verktøyleverandører. Vi skal ikke bygge katedralen. Selv om vi har aldri så lyst.

“Computer says no”

Verktøy som prøver å gjøre jobben for brukerne ender altfor ofte opp med å være hemmende heller enn hjelpende. Hvis man noensinne får dem til å fungere optimalt, fører de til at prosesser blir låste og rigide. Man kan ikke endre arbeidsrutiner med et kjapt møte etter lunsj lenger. Man må ta kontakt med IT-avdelingen og bestille ny funksjonalitet som kanskje blir levert om et år, hvis det er “viktig nok”. Når koden prøver å levere verdien helt på egenhånd, fører det fort til systemer som “sier nei”.

Leger, sykepleiere, saksbehandlere i NAV, politifolk, lærere… dette er alle folk som er utdannede eksperter i å levere forskjellige samfunnsverdier. Deres behov er komplekse og sammensatte.
Løsningene vi lager for dem, bør være det motsatte: enkle og løst koblede. Tenk drill og murstein. Det er det brukerne trenger.

Det er ikke en svakhet ved drillen at den ikke løser hele behovet til katedralbygging på en helhetlig måte. Dens enkelhet, og frakoblethet fra helheten er en av dens store styrker.

Brukerbehovene er komplekse. Løsningene bør være enkle

Ved å fokusere for mye på de overordnede verdiene brukerne skal levere er det lett å bli blendet av kompleksitet og prøve å lage løsninger som omfatter “hele katedralen”. Hvis man følger en murer på jobb, og kartlegger alle aktiviteter og behov hen har gjennom dagen, med mål om å lage verktøy som leverer en katedral, så hadde det fort blitt en avsporing og et tidssluk som førte til overkompliserte verktøy med begrensede bruksområder.
Da Akson-prosjektet til direktoratet for e-helse ble forkastet, hadde de brukt 10 år og godt over 500 millioner kroner på å prøve å kartlegge hva helsepersonell i kommunal sektor trengte. Uten å ha begynt å levere noe som helst av verdi.

Fragmentering er ikke problemet

Når brukere klager over fragmenterte IT-systemer som ikke snakker sammen, så er ikke problemet fragmenteringen. Problemet er hva fragmentene består av - hvordan de er bygget opp. En drill, en hammer, et borr - disse verktøyene brukes alle til å bearbeide verdien man leverer. Drillen i seg selv er ikke en del av verdien som leveres.

IT handler om å få informasjon ut av data. Det er data og informasjon som er verdiene vi leverer. Informasjon om et prøvesvar. Informasjon om et straffbart forhold. Informasjon om en trygdesøknad. Denne informasjonen må kunne bearbeides og vises med forskjellige verktøy. Akkurat som at huset ditt kan pusses opp med både Bosch og Makita-utstyr.

Vinduet i stua kommer ikke med integrert Bosch-verktøykasse som ikke er kompatibelt med andre deler av huset.

Når verdien som leveres kommer med innebygde verktøy, det er da det blir kompleksitet og kompatibilitetsproblemer.

Når vi IT-folk skriver software til oss selv, da gjør vi det riktig. Verdien vi lager er representert som kode, og kode er bare tekst. Verktøyene vi bruker, fra terminalen, til editoren, til CI/CD-verktøy osv jobber alle på samme datagrunnlag. Vi har massevis av forskjellige verktøy, som alle gjør sin lille greie med koden vår. Fordi alle bearbeider den samme koden, er fragmenteringen av verktøy helt uproblematisk.

Data vs Verktøy

Vi må skape det samme skille mellom data (verdi) og verktøy i løsningene vi lager for andre. Da åpner vi opp for gode økosystemer, der det er lett å lage nye verktøy som gjør det lettere og lettere å skape verdi. Folkeregisteret og alt det muliggjør er et godt eksempel. Det at navn og adresse ligger i folkeregisteret, og disse dataene er eksponert over et API, gjør at både banken, skolesystemet Vigilo og saksbehandling i NAV alle kan bearbeide og vise frem disse dataene på forskjellige måter for å skape verdi for sine brukere. Uten at NAV trenger å være integrert med Vigilo. Verktøyene tar i bruk data fra felles kilder.

Å lage gode IT-systemer som løser komplekse brukerbehov handler om å skape og skaffe til veie informasjon til brukerne våre, som gjør at de i større grad evner å levere verdi. Vi vil aldri klare å lage étt system som viser eller innhenter all informasjon brukerne våre trenger. Vi må se etter de små verktøyene som viser eller henter inn en bestemt liten del av puslespillet.

Enkle løsninger

Små enkle ting, som ikke løser alt, er enklere å komme i gang med, raskere og billigere å utvikle, enklere forvalte og ikke minst enklere å forkaste hvis de viser seg å ikke (lenger) ha verdi. Ved å levere raskt, og aktivt justere verktøyene etter feedback fra reell bruk vil brukerne få bedre og bedre verktøy, og dermed levere mer og mer verdi.
Dette er et evighetsarbeide. Vi blir aldri ferdige. Det å få et verktøy ut til brukere er bare starten på reisen.
Verktøyene blir aldri “ferdige”, og målet er ikke verktøyene. Målet er å hjelpe brukeren levere verdi.

Så ja, vi må ha kontinuerlig fokus på å forstå de store helhetlige behovene til brukerne, men samtidig må vi forstå hva vår rolle som software-utviklere er i det hele.
Vår jobb er å spille brukerne våre gode med små enkle verktøy, slik at brukerne kan levere verdi.