Grunnpillarer i IT-utvikling: Læring

For noen år siden deltok jeg på en smidig-konferanse i Salt Lake City, og gikk på en workshop med Christopher Avery med tittelen «Responsibility».  I tillegg til å ha mye tankevekkende materiale om ansvarlighet, så stilte han dette spørsmålet:

Forestill deg at du har laget en applikasjon, og en dag du kommer på jobb så er all kode og dokumentasjon til applikasjonen borte. Hvor lang tid vil du bruke på å lage akkurat den samme applikasjonen på nytt? 100% av tiden du brukte første gang? 70% 50% 10%

Dette er selvsagt en hypotetisk situasjon (de fleste i dag har jo feks versjonskontroll og backup), men problemstillingen er interessant. Hvis du selv driver med utvikling – hva ville du svart? (tenk noen sekunder på dette før du leser videre).

I løpet av årene har jeg nå sett ganske mange svare på dette spørsmålet, og selv om svarene varierer stort, så er det overraskende mange som sier at de trenger ca. 30% av tiden for å lage akkurat det samme på nytt (de fleste mener også at de vil kunne gjøre det på en bedre måte på 2. forsøk). På seminaret jeg var med på spurte Avery så følgende:

Hva brukte dere de resterende 70% av tiden på da dere lagde systemet første gangen?

Her ble det en del diskusjon frem og tilbake, og etter en stund ble det klart at de 70% av tiden som vi ikke trenger 2. gangen består av ting som utprøving av løsningsalternativer som ikke fungerte så bra og lavere effektivitet fordi vi måtte gjøre oss kjent med forretningsregler, APIer, mm. Kort oppsummert var det tid vi trengte for å lære oss det som var nødvendig for å løse oppgaven. Figuren under viser vanlige aktiviteter for en programmerer, sortert etter hva som er læring, og hva som er nedtegning/koding av det vi har lært:

Hvis man tenker litt på dette, så er dette en svært interessant innsikt:

Hovedaktiviteten i IT-utvikling er læring

For mange er dette nærmest et paradigmeskifte i tekning rundt organisering av IT-prosjekter. Dersom det vi kom til over stemmer, så er det flere svært interessante konsekvenser av dette:

Den viktigste ferdigheten å ha i IT-utvikling er evnen til å lære

Da jeg tok Olympiatoppens topptrenerutdanning lærte jeg et lite ordtak som ikke bare passer godt på trenere og utøvere som ønsker å bli best, men som passer ekstremt godt på oss som driver med programvareutvikling: Hvis du tror du er ferdig utlært, så er du ikke utlært, bare ferdig

En annen viktig konsekvens av at læring er så sentralt er organiseringen av prosjekter. Tradisjonelt organiseres jo disse etter tid, kostnad og scope/omfang. Vi vil jo selvsagt ønske å kontrollere dette, men nettopp for å lykkes med prosjektgjennomføring, så må man organisere rundt det som er viktigst:

Utviklingsprosjekter bør organiseres slik at de i veldig stor grad muliggjør læring

Med tanke på hvor sentralt læring er, så kommer det neppe som noen overraskelse at læring stadig vil bli referert til, og at læring vil være en viktig del av forklaringen for hvorfor mange tradisjonelle/intuitive måter å gjøre utvikling på ikke fungerer særlig godt. Mer om dette i fremtidige innlegg.