Kjære systemutvikler!

Ustanselige avbrytelser fra ulike kravstillere og prosjektmedlemmer. Den evige dansen mellom ulike oppgaver og uten mulighet for å konsentrere deg om en ting av gangen. Alle mener godt, men ser ikke at kapasiteten er sprengt og det er i ferd med å etablere seg et fullstendig "trafikkaos" i hodet ditt.

Det vil ikke alltid føles naturlig å skrive kode for tynne, vertikale, funksjonelle deler av systemet. Blant annet vil følelsen av å kunne glemme noe og ønsket om å være effektiv ved å lage generelle tjenester på tvers, forsøke å lure deg til å gå bort fra et funksjonelt fokus. Dessverre er det nettopp dette som er årsaken til at vi så ofte ender opp med mange avhengigheter, som igjen gjør at vi må jobbe på mange oppgaver samtidig.

Den beste måten å glemme noe på veien, er om vi unngår å teste ut det vi lager løpende ved å få reelle tilbakemeldinger. Reelle tilbakemeldinger får vi når vi tester kode og funksjonalitet ute i produksjon mot reelle brukere. Og et par huskeregler best beskrevet på engelsk: "The devil is in the detail" og "Assumption is the mother of all f¿ ups".

Konseptet med tilbakemeldingssløyfer (feedback loops) er sentralt her, men det vil jeg overlate til andre å utdype (du kan google "Knowing you feedback loops"). Jeg skal forsøke å illustrere dette ved å trekke en parallell til trafikken.

Jeg har valgt å hente inspirasjon fra morgenrushet på vei til jobb. Mens jeg kjører langs motorveien, lyttende til P3 eller lesende på en innkommende tekstmelding på mobilen (!), hender det titt og ofte at jeg blir overrasket over at trafikken plutselig står. Det kan være mange årsaker til dette, men ofte handler det om at kapasiteten er sprengt. For mange biler i for stor fart som vil utnytte veikapasiteten til det fulle. Ikke noe slingringsmonn. Ingen 1001-1002-1003 å se. (for nærmere informasjon prøv å google "Queueing theory").

Det er akkurat det samme prinsippet når et team med mennesker forsøker å løse flere oppgaver enn vi klarer å ta unna. Og jo saktere det går, desto mer prøver vi å presse oss frem og utfordre kapasiteten. Avhengighetene øker og før du vet ordet av det starter et møteorgie som svar på å få gjort unna flere avklaringer raskere. #avhengigheter #oppgavebytte #hodepine

I vårt produktivitetsbesatte samfunn er det per definisjon sløsing av tid når man ikke gjør noe. Derfor blir vi stresset og ukomfortable når vi ikke jobber på en definert oppgave. "Sitt nå ikke der gutt og tvinn tommeltotter." "Har du ikke noe å gjøre, så bruk huet og finn på noe!"

Den siste uttalelsen hører mer hjemme hos vår samvittighet enn hos dagens ledere. Uansett, vi trives ikke når vi har det for godt. Jeg opplever at noen rapporterer fremdrift ved å vise til at "¿vi har nå forbrukt 560 timer av totalt 1.000 budsjetterte timer og er godt over halveis ferdig¿".

Vi må se det fra kundens perspektiv. Det er det eneste som gir mening. Av to grunner; a) forretningsverdi oppnås når kundene opplever tjenesten din som bra og b) det er den beste måten å forsikre oss om at vi lager det kunden vil ha.

I ett av mine siste oppdrag skal vi bygge it-løsninger for å selge billetter fra blant annet Oslo til New York og Bangkok. For å kunne fly distansen direkte har vi kjøpt oss nye, moderne og store fly som er mer drivstoffeffektive. Disse flyene kan tilby en egen kabin med ekstra store og komfortable seter lengst foran. Dette ønsker vi at kundene skal dra nytte av selvfølgelig og har definert en brukerhistorie som følger:

Som en kunde - Ønsker jeg å kjøpe et Premium sete - Slik at reisen blir mer komfortabel

Når vi bryter ned brukerhistorien for å definere nærmere hva vi må implementere, så gjør vi det i en eller flere akseptansekriterier. Basert på innspill fra forretningssiden, jobber tester og systemutvikler sammen for å gjøre kriteriet så utvetydig som mulig. (om verden ikke er 100 prosent slik i dag, så jobber vi hver dag med å komme nærmere en slik virkelighet). Slik forsøker vi å spesifisere våre akseptansekriterier, utvetydig:

Gitt at kunden har valgt en langdistanserute fra <opprinnelse> til <destinasjon> med et fly av typen 787 Dreamliner. Når kunden bestiller <billett-type> og <sete type>så vil billetten koste <forventet_pris> og setet skal være plassert i <forventet_kabin>.

Fremover vil vi benytte konkrete eksempler som nedenfor når forretning, testere og systemutviklere sammen skal bli enige om ønsket løsning:

|| opprinnelse || destinasjon || sete type || billet-type || forventet_pris || forventet_kabin ||¿| OSL | JFK | Premium | Restricted | 1000NOK | C cabin |

Mitt spørsmål er enkelt: Hvorfor har vi tilsynelatende så "vanskelig" for å sette oss ned sammen, på tvers systemer og fagområder, for å dele våre ulike perspektiver og komme frem til den beste løsningen? Kun på denne måten kan vi unngå en hverdag full av avhengigheter og parallellprosessering av oppgaver.

"Jeg tror noe av årsaken til at det er vanskelig å få folk til å jobbe sammen, på tvers av systemer, er at det gjør hver enkelt sårbar i forhold til eventuelle feil eller mangel på forståelse." (Systemutvikler)

Som prosjektleder vil jeg gjerne hjelpe deg, men du må bidra tilbake. Vi må få med kravstillerne, testerne og sammen fine måter vi kan levere små, uavhengige, leveranser direkte til brukerne så vi kan få rake tilbakemeldinger. Hvis du som systemutvikler ikke bidrar til dette, så må du ta din del av ansvaret for kaoset og hodepinen som følger.

NB! I Gøteborg har de lykkes å redusere kø i morgenrushet gjennom å senke fartsgrensene i de periodene hvor det er størst pågang av biler.

Tom Johannes Bang, prosjektdirektør i Iterate

NB: Bang er medarrangør i Smidigkonferansen som går av stabelen 5 og 6. november på Radisson Blu Plaza hotell i Oslo. Artikkelen er grunnlaget for en lyntale som vil bli avholdt der.