Ikke jobb mens jeg forstyrrer!

Vidar Moe
Vidar Moe
Jan 6 · 5 min read

Våren 2015 var jeg på vei til å bli utbrent.

Vi hadde laget ny nettbankplattform som stadig flere av teamene våre tok i bruk. Samtidig var ikke plattformen ferdig. Det var kode vi måtte forbedre, samtidig som nye krav dukket opp.

Selv om mye var likt den gamle plattformen, var også mye annerledes. Teamene trengte hjelp til å forstå detaljene. Det gjorde at utviklingsarbeidet stadig ble avbrutt av pirk på skulderen, meldinger, eposter og møter.

Kombinasjonen av sterkt leveransepress og hyppige avbrudd var i ferd med å spise oss opp. Hvordan skulle vi klare å levere forbedringer raskt og med høy kvalitet, når vi ble avbrutt hele tiden?

Image for post
Image for post
Foto: Getty Images

Avbruddene gjorde at vi følte at vi fikk gjort svært lite. Situasjonen var uholdbar. Samtidig visste vi at flere av avbruddene var verdifulle for systemet som helhet: Hvorfor skulle folk bruke tid på å finne ut av hvordan detaljene fungerte, eller regne ut hva som ville være beste tilnærming til en ny utfordring i den nye arkitekturen, når vi ofte satt med svaret?

I SpareBank 1 Utvikling bruker vi ofte A3-metoden når vi har vanskelige problemer vi skal løse. Vi valgte å kjøre en A3 på avbruddsproblemet. Hvordan kunne vi hjelpe de rundt oss, og samtidig gjøre utvikling på en bærekraftig måte?

Hvorfor er avbrudd så krevende for utviklere?

Dette er et lurespørsmål.

Avbrudd er ikke spesielt krevende for utviklere. Avbrudd er spesielt krevende for alle som driver med problemløsning.

Alle som jobber med problemløsning bygger mentale modeller av problemdomenet i hodet. Disse modellene har flere abstraksjonsnivåer, som en må ha i hodet samtidig for å klare å resonere rundt problemet, og forhåpentligvis også nærme seg en løsning.

Image for post
Image for post
https://www.monkeyuser.com/assets/images/2018/79-focus.png

Avbrudd som omhandler andre tema enn akkurat det en jobber med, river ned den mentale modellen. Den må bygges opp igjen, før en kan fortsette med arbeidsoppgaven. Denne kontekstbyttingen er mentalt krevende, og den tar tid. I arbeidet med A3-en, målte vi på de forskjellige typene avbrudd, og lengden på dem. Vi fant forskjellig byttekost for forskjellige typer avbrudd, med i snitt tre minutter for chat, opp til femten minutter for møter.

Hvis det i tillegg er systemutvikling en driver med, og en er midt i en debuggingssesjon for å forstå mer av problemdomenet, så kan byttekosten gå vesentlig opp, siden en i tillegg til å bygge opp den mentale modellen igjen, også må få systemet tilbake i tilstanden en var i, som før en ble avbrutt.

Alle har en begrenset mengde kognitiv kapasitet, som vi kan bruke av hver dag. Gjennom dagen blir den brukt opp. Avbruddene, og tiden det tar å komme seg tilbake til oppgaven en holdt på med, spiser av denne kapasiteten.

Forskjellige typer avbrudd

Vi så at vi trengte håndtere avbruddene forskjellig. Vi har delt dem inn i fire typer:

  • Møter — både egne og andres
  • Elektronisk kommunikasjon — chat, epost, SMS osv
  • Selvpåførte konsentrasjonsavbrudd — tankene spinner avgårde, enten på oppgaver en vet en skal gjøre, eller en kommer på nye oppgaver som trengs å gjøres
  • Pirk på skulderen og kapring ved kaffeautomaten — “Har du fem minutter?”

Ta tilbake kontrollen over tiden din

Image for post
Image for post
En fin dag for en leder. En trist dag for en utvikler.

For mange prosjekt- eller teamledere er kalenderen over en drømmedag.

For en utvikler er denne dagen ødelagt før den har begynt. Hun vet at med denne kalenderen kommer hun nesten ikke til å få gjort noe som helst:

  • Hun kommer på jobb åtte-halv ni
  • Sjekker epost, Slack og nye Pull Requester
  • Rekker akkurat starte på utviklingsoppgaven før retroen
  • Forbereder seg litt til retroen
  • Gjennomfører retroen
  • Gjør litt etterarbeid etter retroen
  • Rekker kanskje akkurat komme igang igjen med utviklingen før hun skal spise lunsj i elleve-halv tolv tiden
  • Kommer tilbake fra lunsj og sjekker epost, Slack og nye Pull Requester
  • Rekker akkurat komme igang igjen med utviklingen før hun må forberede seg litt til workshopen
  • Gjennomfører workshopen
  • Litt etterarbeid etter workshopen
  • Rekker kanskje fortsette litt på utviklingsoppgaven før hun går hjem i fire-halv fem tiden

Mer sannsynlig er hun såpass sliten etter totimers workshop, at det heller blir en ekstra kaffekopp og en ny sjekk av epost og Slack før hun går hjem igjen, frustrert over nesten ikke å ha produsert noen ting på en hel dag.

Paul Graham har skrevet en fantastisk artikkel om disse utfordringene. Den heter Maker’s Schedule, Manager’s Schedule.

Slik kunne vi ikke ha det.

Løsningen for oss ble å innføre en fast blokk i kalenderen hver dag:

Image for post
Image for post
Fast blokk i kalenderen hver dag for å kunne jobbe effektivt

Vi kan nå bare kalles inn til møter fra 13 og utover. Med denne blokken i kalenderen har vi fått tilbake kontrollen over vår egen tid. Folk kan velge å kalle oss inn til møter også mellom åtte og 13, men da er det vi som bestemmer om vi skal prioritere møtet eller ikke. Er det et viktig møte, ber vi som oftest om at møtet flyttes til etter 13.

Når på dagen bør en ha møter?

Vi har valgt å blokke ut første del av dagen, fordi det er da vi er mest opplagt og jobber best. Det er da det er viktigst å ha sammenhengende tid til å drive med utvikling for oss. Noen jobber best på kveld og natt, men for oss er det de første timene av arbeidsdagen som gjelder.

Møter som krever høy grad av interaksjon og meddeltakelse bør legges så tidlig på ettermiddagen som mulig. Møter som er av typen informasjonsmøter, for eksempel allmøter og demoer, kan gjerne legges mot slutten av dagen.

Hvordan vi har håndtert de andre avbruddstypene går vi nærmere inn på i del to av denne bloggposten.

Takk til Børge Lund for hans humoristiske betraktninger rundt dette temaet, og for tittelen til denne artikkelen.

SpareBank 1 Utvikling

Vi jobber med digitale løsninger hos SpareBank 1.

Thanks to Kristoffer Berg and Stian Conradsen

Vidar Moe

Written by

Vidar Moe

Loves creating great, simple software solutions using continous learning and respect for people.

SpareBank 1 Utvikling

Vi jobber med digitale løsninger hos SpareBank 1. Vi liker å skrive om det vi brenner for

Vidar Moe

Written by

Vidar Moe

Loves creating great, simple software solutions using continous learning and respect for people.

SpareBank 1 Utvikling

Vi jobber med digitale løsninger hos SpareBank 1. Vi liker å skrive om det vi brenner for

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store