Historien er velkjent: prosjektet startet med god stemning, leverandøren viste imponerende demoer, og ni måneder senere står du med et system som teknisk sett «virker» — men som ikke passer måten dere faktisk jobber på. Brukerne lager Excel-ark ved siden av. Endringer tar uker. Hva gikk galt?
Feilen skjer før første kodelinje
Undersøkelser av mislykkede IT-prosjekter peker sjelden på teknologien. De peker på misforstått behov: systemet som ble bygget, løste ikke problemet virksomheten hadde. Utviklerne bygde det de trodde ble bestilt, bestilleren beskrev det de trodde var mulig, og ingen oppdaget gapet før leveransen.
Gapet oppstår i språket. Når selgeren sier «ordre», mener hun noe annet enn det lagersjefen gjør — og utvikleren, som aldri har jobbet i bransjen, gjetter på en tredje betydning og støper den i kode. Hver slik gjetning er en liten tikkende regning som forfaller ved lansering.
Tre varselsignaler i ditt prosjekt
- Utviklerne stiller ingen fagspørsmål. Et team som bare snakker om teknologi, bygger sannsynligvis feil ting — imponerende raskt.
- Kravdokumentet er «ferdig». Forståelse av et fagområde blir aldri ferdig. Prosjekter som låser kravene tidlig, låser også misforståelsene.
- Demoene viser skjermbilder, ikke arbeidsflyt. Pene skjermer er lette å lage. Spør heller: «vis meg hvordan en vanlig tirsdag ser ut i systemet».
Slik snur domenedrevet utvikling risikoen
Domenedrevet utvikling angriper rotårsaken — forståelsesgapet — med tre enkle, men kraftige grep:
Fagekspertene inn i rommet
Vi starter ikke med skisser, men med samtaler. Dine folk forklarer hverdagen sin; vi stiller spørsmålene som avdekker unntakene («hva skjer hvis kunden avbestiller etter at dekkene er sendt til lager?»). Unntakene er der systemer knekker — og der verdien ligger.
Et felles språk som binder alt sammen
Begrepene vi blir enige om, brukes i møter, i dokumentasjon og i selve koden. Når språket er felles, blir misforståelser synlige som uenigheter man kan diskutere — ikke som overraskelser i produksjon.
Korte sløyfer, ekte tilbakemelding
Vi leverer i små steg og viser fram ekte arbeidsflyt tidlig. Er modellen feil, koster det en ukes justering — ikke en omskriving etter lansering.
Spørsmålet du bør stille neste leverandør
«Fortell meg hvordan dere har tenkt å lære dere faget vårt.» Hvis svaret handler mer om teknologivalg enn om samtaler med folkene dine, vet du hvor risikoen ligger. Vi svarer gjerne på det spørsmålet selv — det er slik vi jobber hver dag.