Hvad er lovene omkring 'brand' i systemudviklingsprojekter?
Et projekt som systemudvikling er ikke noget, der kan opnås natten over. Det kræver mange ressourcer, herunder mange mennesker og organisationer, betydelige mængder kapital og en lang udviklingsperiode. I denne artikel vil vi forklare, hvordan fænomenet ‘brand’ i systemudviklingsprojekter kan organiseres inden for rammerne af lovgivningen. Vi vil også samle nogle retningslinjer for løsninger.
Hvorfor “brænder” projekter?
Et enkelt IT-system, selvom det ikke er et særligt stort projekt, fungerer korrekt kun på grund af en stor mængde programmerede filer og kildekode. Det er ofte meget mere detaljeret og præcist konstrueret end man kan forestille sig fra brugerfladen (eller faktisk, jo mere simpel og kortfattet brugerfladen er, jo mere sandsynligt er det).
- Deadline er det eneste, der er fastlagt, mens specifikationer og krav forbliver uklare, og tiden går
- Medlemmerne er for optagede af interne politiske problemer, og mange ender med at droppe ud på grund af stress fra interpersonelle relationer
- Der er mangel på forhandlingsfærdigheder, selv på ledelsesniveau, inklusive projektlederen, og medlemmerne bliver ikke bedt om passende rapportering, kommunikation og konsultation
De specifikke årsager til, at et projekt “brænder”, kan variere fra projekt til projekt. Men juridisk set kan årsagerne til, at et projekt “brænder”, organiseres ret simpelt i flere forskellige kategorier.
Flammekategori 1: Når et projekt går i stå midt i processen
I forbindelse med systemudvikling er en typisk årsag til, at et projekt går i stå midt i processen, manglende kommunikation mellem brugersiden og leverandørsiden. Et systemudviklingsprojekt kræver ikke kun den tekniske og organisatoriske ekspertise, som leverandørsiden besidder, men også samarbejde fra brugersiden, der i sidste ende vil bruge systemet.
Derfor, hvis et projekt fortsætter med uklarhed om, hvilken rolle hver part skal spille, og en form for “skyldfordeling” opstår, vil det hindre en gnidningsfri fremdrift. For en juridisk overvejelse af brugersidens og leverandørsidens forpligtelser, henvises til følgende artikler.
https://monolith.law/corporate/project-management-duties[ja]
https://monolith.law/corporate/user-obligatory-cooporation[ja]
Detaljerne om, hvilket ansvar hver part har, kan findes i ovenstående artikler, men hovedpointen her er, at både brugeren og leverandøren har et vis ansvar i et systemudviklingsprojekt. Generelt set anerkender tidligere domme og retspraksis, at brugersiden har en forpligtelse til at samarbejde om aspekter, der ikke kan fuldføres uden deres hjælp, såsom kravspecifikation, design af udseende (dvs. grundlæggende design), og accepttest.
På den anden side har leverandørsiden også en omfattende forpligtelse til at sikre en gnidningsfri fremdrift af projektet og til at opdage og fjerne hindringer, efter at have modtaget samarbejde fra brugersiden (og samtidig have gjort en indsats for at kommunikere og anmode om sådant samarbejde).
Under disse forudsætninger viser domstolene en holdning til at behandle alle konflikter retfærdigt, ved at begge parter viser deres forpligtelse til at udøve deres ekspertise og tekniske færdigheder som eksterne eksperter for leverandøren, og til at implementere governance fra indersiden for brugeren.
Desuden er accepttesten et tidspunkt, hvor “stagnation” let kan opstå. Accepttesten er detaljeret forklaret i følgende artikel.
https://monolith.law/corporate/estimated-inspection-of-system-development[ja]
I sådanne tilfælde, hvis en konflikt opstår, vil objektivt verificerbare beviser, såsom udviklingen af tidligere projekter og indholdet af mødediskussioner, ofte blive prioriteret. Derfor har dokumenter, der er blevet registreret på forhånd, ofte stor betydning. For at undgå at sætte din egen position i fare er det vigtigt at være grundig med dokumenthåndteringen. For en detaljeret forklaring på vigtigheden af dokumenthåndtering i systemudvikling, se følgende artikel.
https://monolith.law/corporate/the-minutes-in-system-development[ja]
Type 2 af flammekrig: Når brugeren afbryder af egen vilje
Der kan også være tilfælde, hvor et projekt bliver afbrudt midt i processen på grund af brugerens ønske. For eksempel, lad os antage, at en virksomhed har startet udviklingen af et IT-system til at håndtere HR på tværs af alle deres internationale afdelinger, men virksomhedens strategi for international ekspansion bliver pludselig trukket tilbage. I sådanne tilfælde kan det være, at udviklingen af det påbegyndte system ikke længere er nødvendigt for brugeren.
Grundlæggende er spørgsmålet om, hvordan et IT-system skal opbygges i en virksomhed, uadskilleligt forbundet med spørgsmålet om, hvilke typer af arbejde der findes i virksomheden. Derfor er det realistisk at forestille sig, at kravene til et system kan ændre sig efterfølgende, hvis der sker store ændringer i organisationens struktur, forretningsafdelingens sammensætning, eller hvis der er en radikal revision af strategien.
Under sådanne omstændigheder kan der opstå forskellige juridiske problemer, hvis et projekt bliver afbrudt midt i processen. Normalt, da det er på grund af brugerens egen vilje, vil leverandøren have visse juridiske rettigheder, såsom at kræve betaling i forhold til graden af færdiggørelse. Afhængigt af hvilken type kontrakt der er indgået, vil der være forskelle i de relevante juridiske bestemmelser, men indholdet kan opsummeres som følger:
・I tilfælde af en kontrakt om udførelse af arbejde: Japansk Civilret §641
Japansk Civilret §641
→Så længe arbejdet ikke er færdigt, kan bestilleren til enhver tid ophæve kontrakten ved at kompensere for skaden.
・I tilfælde af en quasi-kontrakt: Japansk Civilret §648, stk. 3 (afhængigt af omstændighederne kan der også være krav om erstatning i henhold til Japansk Civilret §651)
Japansk Civilret §648
→Hvis udførelsen af en opgave afbrydes midt i processen på grund af årsager, der ikke kan tilskrives agenten, kan agenten kræve betaling i forhold til graden af det arbejde, der allerede er udført.
Japansk Civilret §651
→1. Begge parter kan til enhver tid ophæve kontrakten.
→2. Hvis en af parterne ophæver kontrakten på et tidspunkt, der er ugunstigt for den anden part, skal den part, der ophæver kontrakten, kompensere den anden part for skaden. Dog gælder dette ikke, hvis der er uundgåelige omstændigheder.
Type 3 af brand: Når mangler i det leverede system opdages senere
Brugere har ofte en tendens til at vurdere et systems kvalitet ud fra dets brugerflade, men fra leverandørens synspunkt er det ofte mere komplekst at designe databasen og identificere testelementer under hensyntagen til alle mulige operationer.
Med andre ord, selvom et system synes at fungere uden problemer i begyndelsen, kan følgende problemer opstå:
- Når mængden af data, der registreres, øges, bliver behandlingshastigheden langsommere.
- Et system, der synes at fungere uden problemer i dagligdagens grundlæggende opgaver, kan vise sig at have fejl under specielle operationer, der kun opstår en gang hver få måneder eller år.
- Selvom det på overfladen ser ud til, at resultaterne korrekt genereres, kan den faktiske logik være forkert. For eksempel, selvom “2” korrekt genereres som output til brugerinputtet “1+1”, garanterer det ikke, at beregningsprocessen er korrekt. Uanset hvilken beregningsformel der indtastes, kan det være, at det altid returnerer “2” som output. Fejl i logikken er ofte svære at opdage ved blot at betjene skærmen tilfældigt. I denne forstand kan man sige, at en vis “teknisk dygtighed” er nødvendig i testprocessen.
Sådanne ting kan faktisk ske. Hvis man tør analysere sådanne sager fra et juridisk synspunkt, kan det tænkes, at det er et spørgsmål om leverandørens overtrædelse af projektledelsesforpligtelser, dvs. ufuldstændig opfyldelse i henhold til den japanske civilret.
I dette tilfælde, hvis der ikke er nogen særlige aftaler i kontrakten, vil bestemmelserne om almindelige kontrakter normalt gælde.
De punkter, der skal overvejes i dette tilfælde, kan opsummeres som følger:
| ・Hvis arbejdet ikke kan siges at være færdigt →Hvis arbejdet ikke er færdigt, er det principielt, at der ikke opstår nogen betaling for det. Men hvis årsagen til dette er brugerens overtrædelse af samarbejdsforpligtelsen, kan leverandøren også tage juridiske skridt, såsom at kræve erstatning for skader. |
| ・Hvis arbejdet er afsluttet, men formålet med kontrakten ikke kan nås →Det anses for at have en retlig mangel (artikel 635 i civilloven). Hvis brugeren annullerer tjenesten, kan sælgeren ikke kræve kompensation. Omvendt vil brugerne kunne kræve erstatning mod sælgeren. (Se venligst den separate artikel for en detaljeret forklaring af sager, der falder ind under denne kategori.) |
https://monolith.law/corporate/defect-warranty-liability[ja]
| ・Hvis arbejdet er færdigt, og et produkt, der kan opnå det aftalte mål, er leveret, men der er stadig nogle mindre mangler, der skal repareres eller erstattes →Leverandøren kan kræve betaling, men brugeren kan også kræve erstatning for skader. Derfor vil det normalt blive modregnet med det beløb, der er aftalt mellem de to parter. |
| ・Hvis arbejdet er færdigt, og der er ingen mangler i indholdet →Dette er ikke en “brand” sag i denne artikel, og projektet vil blive afsluttet med en normal betalingsanmodning. |
Sådan kan det opsummeres.
Opsummering
Hvert enkelt systemudviklingsprojekt vil utvivlsomt gennemgå forskellige og komplekse faser. Men når det kommer til “brand” i juridiske projekter, vil rammen, som vi har præsenteret i denne artikel, fungere som en oversigt. Juridiske spørgsmål relateret til systemudvikling indeholder bestemt en bred vifte af emner.
Ligesom systemudviklingsarbejdet kræver konstruktiv tænkning, kan risikostyring, der følger med det, også udføres mere konstruktivt ved ikke at miste overblikket over hele feltet. Er det ikke det, vi stræber efter?
Category: IT
Tag: ITSystem Development
