Hvad er flertrinskontrakter i systemudvikling? En forklaring inklusive anbefalede grunde

I systemudviklingsprojekter er det ofte sådan, at kontraktpraksis skrider frem ved hjælp af en metode kaldet flertrinskontrakter. I denne artikel vil vi forklare om flertrinskontrakter i systemudvikling, herunder også grunde til, hvorfor de anbefales.

Hvad er flertrinskontrakter?

Generelt udføres kontraktindgåelse gennem en kontrakt. Det vil sige, den betalende part (brugeren i systemudvikling) påtager sig forpligtelsen til at betale en løn, og den arbejdende part (leverandøren i systemudvikling) lover skriftligt at levere den tilsvarende service. På denne måde er det essensen af en kontrakt, at begge parter lover at opfylde deres forpligtelser.

Indgå kontrakter i henhold til karakteren af hver proces og fuldfør arbejdet

Men i tilfælde af systemudviklingsprojekter, går projektindholdet selv gennem flere processer, og indholdet kan blive komplekst. Når man tager hensyn til karakteren af sådant arbejde, kan det være passende at gennemføre kontrakten i flere omgange. Det vil sige, det er bedre at strukturelt samle ideer og skabe selve kontrakten, der styrer hele projektet. For eksempel er det meget ønskeligt i praksis at indgå en ny kontrakt for hver proces. Denne kontraktmetode kaldes en flertrinskontrakt. Modelkontrakter leveret af det japanske ministerium for økonomi, handel og industri er også baseret på disse flertrinskontrakter.

Typer af kontrakter indgået i hvert projekt

De kontrakter, der ofte bruges i systemudvikling, er to typer: kontrakt- og quasi-delegationkontrakter, og disse to bruges skiftevis afhængigt af karakteren af hver proces for at styre det hele. Blandt alle processer i systemudvikling er det almindeligt at bruge kontrakt-kontrakter for detaljeret design, implementering af programmer, enhedstest osv. Grunden til, at disse processer passer godt til kontrakt-kontrakter, er, at kontrakt-kontrakter vægter “fuldførelse af arbejde” som en præstationskrav, og det er let at konkretisere “fuldførelse” krav som en proceskarakter. For mere information om “fuldførelse af arbejde” i kontrakt-kontrakter, se følgende artikel.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

På den anden side er det almindeligt at bruge quasi-delegationkontrakter i de tidlige stadier af systemudvikling, såsom planlægning og kravdefinition. Karakteristika for disse processer er, at det ofte er svært at klarlægge kravene til “fuldførelse af arbejde”, og at tillidsforholdet mellem begge parter ofte er grundlaget for kontrakten. I processer som grundlæggende design og integrationstest bruges både quasi-delegation og kontrakt afhængigt af projektets karakter. Et punkt at overveje, når man vælger hvilken kontrakt der skal bruges i disse processer, er, hvor meget brugerens samarbejde er nødvendigt.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Hvis det er en type arbejde, hvor leverandøren ensidigt kræver “fuldførelse af arbejde” som en forpligtelse, kan det være nemmere at vælge en kontrakt-kontrakt. Men hvis det faktisk er nødvendigt med fælles arbejde mellem brugeren og leverandøren, skal man forstå, at det i nogle tilfælde er mere realistisk at give juridisk beskyttelse til det tillidsforhold, der er baseret på begge parter. For mere information om forskellen mellem kontrakt- og quasi-delegationkontrakter, se følgende artikel.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

I denne artikel forklarer vi, at kontrakt-kontrakter ofte bruges, når resultaterne, såsom implementering af programmer, let kan identificeres, og jo mindre denne tendens er, jo mere sandsynligt er det, at quasi-delegationkontrakter bruges. På denne måde er det at se på hele projektet som en helhed af flere kontrakt- og quasi-delegationkontrakter, der indgås, praksis for kontrakter baseret på flertrinskontrakter. Desuden kan det siges, at en “grundlæggende kontrakt” er noget, der ekstraherer og samler fælles elementer, så man ikke behøver at gentage den samme beskrivelse mange gange. Det ligner meget at samle fælles elementer i klasser og funktioner, når man implementerer programmer.

Eksempler på ting, der ofte skrives sammen i en grundlæggende kontrakt, inkluderer:

• Definition af termer, der bruges gentagne gange
• Proceduren for at indgå individuelle kontrakter
• Metoden til at ændre specifikationerne, der skal realiseres, efterfølgende
• Metoden til levering og accept af produkter for hver proces
• Metoden til at holde hemmeligheder

Disse egenskaber er, selvom kontrakten er opdelt i separate dele for hver fase, ikke nødvendige at skelne efter proces, da de er konsekvente, når man ser på det som et enkelt projekt. På denne måde er det en egenskab ved flertrinskontrakter at ekstrahere mere generelle og alsidige aftaler som grundlæggende kontrakter og placere individuelle aftaler, der skal skelnes for hver proces, som individuelle kontrakter under grundlæggende kontrakter. Flertrinskontrakter bruges ofte ikke kun i systemudvikling, men også i kommercielle transaktioner, der er kendetegnet ved deres størrelse og kompleksitet. For øvrig er det modsatte koncept af flertrinskontrakter med en kompleks struktur en engangskontrakt. Hvis emnet ikke er systemudvikling, men bestilling af en skræddersyet dragt, ville en engangskontrakt normalt være tilstrækkelig.

Fordele ved flertrinskontrakter

Så hvad er fordelene ved bevidst at vælge en flertrinskontrakt? Hvis vi skal organisere det lidt mere konkret, kan vi nævne følgende fordele.

Fordele ved flertrinskontrakter 1: Nemmere at håndtere udviklingsprojekters fluiditet

En af fordelene ved flertrinskontrakter er, at det er relativt nemt at håndtere fluiditeten i udviklingsprojekter. Normalt går en række systemudviklingsprojekter fremad i henhold til foruddefinerede krav, såsom design og implementering af programmer, og processen fortsætter uden tilbageskridt eller tilbagevenden. Men på grund af kompleksiteten af det, der skal produceres, strækker tidsplanen sig normalt over en passende periode, og det er ikke usædvanligt, at indholdet af de specifikationer, der skal realiseres, ændres efterfølgende. For mere detaljeret forklaring om, hvordan man håndterer ændringsanmodninger efter specifikationer, se følgende artikel.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Med andre ord, ved starten af projektet er det endelige mål ikke nødvendigvis klart defineret. I sådanne projekter, der indeholder usikre elementer, kan det være svært at indgå en kontrakt, hvor alle forpligtelser er gensidigt aftalt på én gang. Det er lettere at opdele i hver proces, hvilket undgår unødvendige risici for begge parter og gør det lettere at fremme forretningsaftaler.

Fordele ved flertrinskontrakter 2: Nemmere at lave præcise estimater

Den ovennævnte fordel, “at kunne undgå at forpligte sig til noget usikkert”, fører også til, at det er nemmere at lave præcise estimater. Hvis specifikationerne ændres efterfølgende, er det meget muligt, at estimatet også skal ændres efterfølgende. For en mere detaljeret forklaring af, hvordan man genberegner estimater i sådanne tilfælde, se følgende artikel.

https://monolith.law/corporate/increase-of-estimate[ja]

Den ovennævnte artikel forklarer, hvordan man håndterer ændringer i estimater som følge af efterfølgende specifikationsændringer, men det er ikke ønskeligt for hverken brugere eller leverandører at skulle håndtere sådanne ændringer efterfølgende. Det er bedst at undgå at lave estimater, der kræver korrektioner, og at gøre det korrekt første gang. Med flertrinskontrakter kan du opdele kontrakten i hver proces, hvilket gør det nemmere at lave præcise estimater og mindsker sandsynligheden for efterfølgende ændringer i estimater.

Fordele ved flertrinskontrakter 3: Nemmere for betaleren at forstå rimeligheden af beløbet

Desuden, ved at opdele og estimere hver proces, er det også nemmere for brugeren, der betaler vederlaget, at forstå rimeligheden af beløbet for hele projektet. Som nævnt tidligere er det ikke let at nærme sig en række projekter med perfekt planlægning. Derfor er det ofte tilfældet, at der sker forskellige ændringer, og at det oprindelige estimat ændres i processen. I en engangskontrakt er det forventet, at den eneste mulighed for at forklare estimatbeløbet er ved indgåelsen af kontrakten. For brugeren kan det være svært at forstå, hvorfor der er en forskel mellem det oprindelige estimat og det faktiske betalingsbeløb på betalingstidspunktet. Med dette i betragtning kan det siges, at flertrinskontrakter også har visse fordele for brugeren.

Opsummering

Flerniveaukontrakter er velegnede til at forme en fair og klar aftale mellem parterne og er også effektive til at forebygge fremtidige problemer. Nogle kan dog tænke, “Er der ikke nogle ulemper ved flerniveaukontrakter, og er der ikke tilfælde, hvor individuelle kontrakter er bedre?” I denne henseende, hvis vi skal sige noget, kan det argument, at det er bedre med en samlet kontrakt, hvis det er en lille skala og det er indlysende, at arbejdet vil blive afsluttet hurtigt, fordi det tager tid at indgå en kontrakt hver gang, være gyldigt. Men det er vigtigere at forstå fordelene ved præcise og ændringsresistente flerniveaukontrakter end at være opmærksom på de meget begrænsede ulemper ved flerniveaukontrakter. Hvis det er et projekt af en vis størrelse, bør vi naturligvis bruge denne metode.