Derfor får ikke utviklere bygge de beste løsningene
Mange store selskaper ender opp med «greie nok» systemer – selv om de har dyktige utviklere. Ny forskning peker på en klassisk årsak mange vil kjenne igjen.
Nils Brede Moe i Sintef og Alexandra Diem i Gjensidige er medforfattere av denne kronikken.
Digitalisering går raskere enn noen gang, og teknologien endrer seg hele tiden. Det gjør det ekstra viktig å lykkes med smidig utvikling.
Men i mange store selskaper skurrer det fortsatt i praksis.
Vi har studert flere kunnskapsbedrifter, blant annet innen bank og forsikring, og ser et mønster: mange jobber fortsatt på en måte som i praksis hindrer dem i å lage de beste løsningene.
Kastes over gjerdet
Når utviklere får oppgaver «kastet over gjerdet»
Det som skjer, er ofte dette:
En avdeling lager en ferdig kravspesifikasjon og sender den til utviklingsteamet. Oppgaven er tydelig beskrevet. Alt virker klart.
På papiret burde det være enkelt å gå i gang.
Men i praksis betyr det ofte at utviklere bare får beskjed om hva de skal lage – uten å få være med å forme løsningen.
Dette er det vi kaller en bestillingskultur.
Mange utviklere vil kjenne det igjen: Man får en ferdig spesifisert oppgave – og det forventes å implementere, ikke utfordre.
Resultatet? Dårligere løsninger
Problemet er ikke at kravene er dårlige. Problemet er at viktige perspektiver mangler.
Utviklere ser ofte ting andre ikke ser:
- hva som faktisk er mulig
- hva som blir vanskelig å endre senere
- hvor det ligger teknisk gjeld
- hvilke løsninger som skalerer – og hvilke som ikke gjør det
Når de ikke får bidra tidlig, risikerer teamet å bygge løsninger som:
- er mindre gjennomtenkte
- henger dårligere sammen
- og i verste fall gir mindre verdi for brukerne
Og det går saktere – ikke raskere
En annen konsekvens er klassikeren mange kjenner på:
Mye fram og tilbake.
Når utviklere først kobles på etter at alt er bestemt, dukker det opp spørsmål, avklaringer og justeringer underveis.Da blir det fort pingpong mellom team.
Ironisk nok fører en «effektiv» bestilling ofte til mer friksjon og lavere fart.
Mindre samarbeid = mindre læring
Når team ikke jobber tett sammen, mister man også noe annet:
- mindre læring på tvers av fagområder
- dårligere forståelse for helheten
- færre gode diskusjoner
Og ikke minst: mindre eierskap.
Det er vanskelig å være motivert når du bare får beskjed om hva du skal lage – uten å få påvirke hvordan.
Dette blir ekstra tydelig i komplekse oppgaver, der gode løsninger krever innsikt fra flere fagområder samtidig.
Ikke alltid enten eller
Samtidig er det ikke så enkelt som at bestillinger alltid er feil.
I praksis må begge deler fungere.
Bestillinger kan gi mening når:
- oppgaver er enkle og kjente
- løsningen allerede er godt forstått
- eller når prosesser er sterkt regelstyrt
Men når oppgavene er komplekse og åpne, fungerer samarbeid gjerne langt bedre.
Hva kan man gjøre for å lykkes?
Gjensidige har i samarbeid med Sintef jobbet med å synliggjøre nettopp denne spenningen i egen organisasjon. Å løfte fram utfordringene ved bestillingskulturen er helt nødvendig for å komme seg videre. I tillegg må folk få erfare verdien av å jobbe sammen, ikke bare høre om det.
I Gjensidige finnes det også team som konsekvent prioriterer samarbeid fremfor bestillinger. De involverer utviklere tidlig, diskuterer løsninger sammen og justerer underveis.
Lykkes man med å samarbeide om de komplekse oppgavene, kan man få:
- bedre flyt i arbeidet
- høyere kvalitet på løsningene
- og mer engasjerte team
Vi tror store selskaper har mye igjen for å ta en fot i bakken og spørre seg: Er det sånn at vi har en uhensiktsmessig bestillingskultur hos oss? Blir svaret «ja», er det lurt å justere kursen. Det vil si: gå for mer utstrakt bruk av samarbeid i stedet.