Programvareutvikling er særlig utsatt for konflikter. Teknisk usikkerhet, gjensidige avhengigheter og løpende valg påvirker både omfang, kvalitet og kostnad. Samtidig varierer det hvor proff og kompetent kjøperen er. Dermed blir konflikter mellom kunde og utvikler vanlig.
Som advokater med spesialkompetanse på programvareutvikling ser man en rekke «klassikere» som går igjen; Budsjettsprekk, forsinkelser og uenighet om hva som faktisk er levert. Utvikleren krever betaling og kunden nekter. Hva da?
Avtalen avgjør hvem som er ansvarlig
Partene har full avtalefrihet og en dårlig avtale binder deg akkurat like mye som en god.
I mange softwareprosjekter benyttes konsulentmodeller med betaling etter medgått tid, gjerne kombinert med uforpliktende timeoverslag. Dette innebærer normalt en innsatsforpliktelse, ikke et ansvar for et ferdig og feilfritt resultat. Mange kunder undervurderer hva slags konsekvenser dette bør ha for arbeidsformen mellom partene. Strenge fastprismodeller er sjeldne. Programvareutvikling har naturlige usikkerheter som gjør at de fleste utviklere vil kvie seg for å gå med på det. Da trengs i så fall en svært detaljert kravspesifikasjon og en lang rekke forbehold.
Avtalen er med andre ord svært viktig. Den hjelper imidlertid lite dersom den hopper bukk over sentrale tema eller i verste fall ikke er skriftlig i det hele tatt.
Det er heller ikke uvanlig med et misforhold mellom hvordan partene tror avtalen fungerer, og hvordan den faktisk virker juridisk. Utvikleren bruker fagbegrepene korrekt og presist, mens kunden ikke nødvendigvis har samme innsikt. Det er ikke uvanlig at kunden sitter med feil forventninger pga. manglende erfaring, mens utvikler har tenkt at forventningsavklaringene var tydelige.
Normalt er verken kunde eller utvikler jurister og med vage formuleringer kan man være like langt.
Endringer er normalen (og hovedkilden til konflikter)
I praksis utvikles kravspesifikasjonen ofte underveis. Nye behov avdekkes, forutsetninger endres og løsninger justeres. Endringer er ikke et avvik i softwareutvikling, men normalen.
Konflikter oppstår når partene har ulik forståelse av konsekvensene:
- Kunden opplever endringen som «liten»
- Utvikler ser tekniske ringvirkninger som påvirker arkitektur, testomfang og tidsbruk
Når kunden gir instruksjoner og tar tekniske eller funksjonelle valg, får det direkte betydning for medgått tid. Samtidig bør utvikler informere om kostnads- og tidskonsekvenser der dette lar seg gjøre. Manglende forventningsstyring forsterker problemet.
Et rasjonelt og kostnadseffektivt prosjekt får du når sentrale valg og behov er avtalt på forhånd, og forutsetter at det ikke skjer mange eller substansielle endringer i løpet av prosjektet. Endringer betyr høyere pris og mer tid.
Sprikende syn på kvalitet vanskeliggjør
Et annet klassisk konfliktpunkt er uenighet om programmets egenskaper:
- Hvor robust skulle løsningen være?
- Hvilket testnivå var forutsatt?
- Hva ligger i «ferdig»?
Programvare er sjelden feilfri. Uten klare avtalepunkter om kvalitet, testregimer og akseptansekriterier, oppstår det ofte urealistiske forventninger, særlig hos bestillere uten teknisk bakgrunn.
Utvikler mener dette er åpenbart. Kunden mener det motsatte. Noen ganger skyldes konflikten manglende «bestillerkompetanse». Andre ganger mangelfull rådgivning fra utvikler. Oftest er det en kombinasjon.
Dessuten er programvare et levende produkt. Det vil være behov for løpende «vedlikehold» også etter leveringsdatoen.
Å legge all risiko på utvikler er fristende, men risiko har en pris. Feilfri og ferdig testet programvare er betydelig dyrere enn en ren innsatsforpliktelse. Den mest rasjonelle fordeling avhenger av behovet som må avklares i det konkrete prosjektet.
Hva kan gjøres for å forebygge konflikt?
1. Bruk tid på avtalen
Avtalen må fordele risiko bevisst. Den trenger ikke være lang, men bør regulere sentrale tema som betalingsmodell, ansvar, tydelige rutiner for endringsrutiner, og rutiner for informasjon og rapportering. Avtal øvre budsjettrammer og når utvikler skal varsle ved avvik. Spesifisering av timelister og statusrapporter har også en pris. Hva er rett detaljnivå i prosjektet?
2. Lag skriftlige beskrivelser og spesifikasjoner
Det er vanskelig å påberope seg mangler dersom man ikke har avtalt tydelig hva som egentlig skulle leveres. Samtidig er det ikke alle detaljer det er rasjonelt å spesifisere på forhånd. Prosjektet kan dessuten bli fryktelig dyrt hvis spesifikasjonen er laget av en som ikke kan faget.
3. Vær bevisst på begrensinger i egen bestillerkompetanse
Store budsjetter kombinert med lav bestillerkompetanse er særlig risikofylt. Skrekk-scenarioet er å ende opp med «Helseplattformen light».
I større prosjekter med store budsjetter og risiko, bør ekstern fagbistand innhentes allerede før utvikler velges. Det er ikke uvanlig at rundt 10 % av budsjettet går til forberedelser, kravarbeid, forhandlinger og juridisk bistand før kontrakt inngås. Dette reduserer risikoen for kostbare overskridelser og konflikter senere.
Dersom det ikke er aktuelt å kjøpe ekstern teknisk bistand må du bruke god tid sammen med utvikler for å lage en leveransebeskrivelse eller kravspesifikasjon så tidlig som mulig i prosessen. Dette betyr ikke at alle valg skal skrives i stein med en gang, men at sentrale forutsetninger for arbeidet bør settes tidlig.
4. La eksperten være ekspert – også i tilbudsprosessen
Du som kunde kjenner behovet, og utvikler har fagkompetansen til å møte det. Prisbevisste kunder kan likevel havne i en felle der de ønsker mest mulig kontroll og instruksjonsmyndighet gjennom prosjektet «for å styre kostnadene». Paradoksalt nok fører dette ofte til at prosjektet blir dyrere enn nødvendig.
Beskriv heller behovet løsningen skal dekke, slik at utvikler kan foreslå hvilke egenskaper, valg og prioriteringer som gir rett resultat til rett pris. Det som avtales må gjøres skriftlig. Utvikler kan levere en overordnet løsningsbeskrivelse sammen med tilbudet, og peke på hvilke avklaringer det er naturlig å ta underveis. Be utvikler forklare hvilke valg som bør gjøres tidlig for å få et rasjonelt og effektivt prosjekt. Revider om nødvendig etter fastsatte rutiner.
5. Skriftliggjør alle endringer
Ekstraarbeid og endringer bør formaliseres skriftlig. En e-post er bedre enn ingenting den dagen partene har blitt uenige.
Er prosjektet prissensitivt kan det også være lurt å be om råd og diskutere priskonsekvenser med utvikler før endringer besluttes. Be om timeoverslag.
6. Skaff juridisk bistand tidlig
Arbeidet med en ideell utviklingsavtale starter allerede før utvikleren er engasjert. Risiko er langt vanskeligere å fordele når tilbud er gitt og priser og sentrale forutsetninger fastsatt. Samtidig er det alltid bedre å få på plass en avtale etter at prosjektet er i gang, enn å stå helt uten skriftlige rammer.
Er uhellet først ute og konflikten et faktum, vil advokat kunne bistå med rettslig vurdering og bidra til å finne løsninger eller håndtere tvisten i rettssystemet.
Pretor Advokat bistår med kontrakter og tvister knyttet til programvareutvikling.
Ragnhild Kristina Ølstad har særlig kompetanse innen softwarekontrakter, offentlige anskaffelser av IT-løsninger, samt avtaler for både små og store softwareprosjekter, inkludert avtaler om tjenester for trening av AI.
