Vad är juridiska och kontraktsrelaterade problem kopplade till agil utveckling?

Det finns olika metoder för att driva systemutveckling. Den mest klassiska och allmänna metoden är vattenfallsmodellen, och många juridiska böcker som behandlar systemutveckling diskuterar utifrån denna modell. I denna artikel kommer vi att diskutera vilka juridiska problem som kan uppstå i systemutveckling baserat på den agila utvecklingsmodellen, som det kan vara svårt att hitta information om i böcker och liknande.

Agil utvecklingsmodell och juridik

Vad är en modell inom systemutveckling?

I systemutvecklingsprojekt finns det något som kallas utvecklingsmodeller, som fungerar som ramverk för att få en helhetsbild av projektets framsteg. Det mest kända exemplet på detta är den så kallade “vattenfallsmodellen”. Detta innebär att man, precis som vatten som faller från “uppströms” till “nedströms”, genomför alla steg som kravspecifikation, design, implementering och testning i en enda genomgång. Målet är att minimera återgångar och dubbelarbete så mycket som möjligt, vilket gör denna metod lämplig för planerade arbetsflöden.

Å andra sidan, i den agila utvecklingsmodellen, upprepas processen att implementera små program och sedan testa dem. Genom att upprepa denna cykel av att implementera och testa små program, byggs ett större system upp gradvis. För en mer detaljerad förklaring av dessa systemutvecklingsmodeller och en jämförelse av fördelarna och nackdelarna med båda utvecklingsmodellerna, se följande artikel.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Egenskaper hos den agila utvecklingsmodellen

En stor fördel med utveckling med den agila modellen är att man kan gå in i det faktiska arbetet med en känsla av hastighet. Eftersom uppgifterna i “uppströmsprocessen”, som att definiera krav och skapa designspecifikationer, inte är separerade från implementeringen av programmet, är denna metod lämplig för att flexibelt styra processen, inklusive att hantera tillägg och ändringar av funktioner och specifikationsändringar. Juridiskt sett är de särskilt viktiga punkterna för att göra den agila utvecklingsmodellen framgångsrik hur man hanterar dokumenthantering och ändringshantering. I den agila utvecklingsmodellen är roller och ansvarsområden inte lika tydligt definierade som i vattenfallsmodellen. Dessutom, eftersom denna metod prioriterar “hastighet” för att komma till utförandet och starten, snarare än “hantering”, kan det lätt leda till bristfälligheter i olika designspecifikationer, specifikationsdokument och mötesprotokoll.

Ytterligare, i fråga om ändringshantering, eftersom den agila utvecklingsmodellen är smidig när det gäller att hantera ändringar, finns det en risk att projektet kan brinna upp om man börjar svara på förfrågningar om specifikationsändringar på platsnivå, utan att gå igenom godkännandeprocessen med beslutsfattarna. I så fall kan fördelen med utvecklingsmodellen, att “det är smidigt att hantera efterföljande ändringar”, i sig bli en risk för att projektet brinner upp.

Hur man hanterar dokument och ändringskontroll i agil utveckling

Vikten av dokumenthantering

I utvecklingsprojekt baserade på den agila utvecklingsmodellen, är en juridisk oro att muntliga interaktioner ackumuleras, vilket leder till brist på dokumentation. Vi har detaljerat förklarat varför dokumenthantering blir viktig i systemutvecklingsprojekt i följande artikel.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

I den artikeln förklarar vi vikten av dokumenthantering i systemutvecklingsprojekt från två perspektiv: förebyggande av tvister (det vill säga “förebyggande juridiskt arbete”) och bevarande av bevis när en tvist uppstår (det vill säga “krishantering”).

Upprättandet av ett kommunikationsråd är effektivt för dokumenthantering

När du antar en agil utvecklingsmodell, till skillnad från vattenfallsmodellen, finns det inte en tydlig plan i förväg. Därför är det inte bara en fråga om att hantera skillnaden mellan plan och faktiska resultat, det finns också en oro för att kostnaderna, både ekonomiskt och tidsmässigt, kan svälla om det lämnas helt till fältet.

Därför är det effektivt att ansvariga genomför regelbundna kommunikationsrådsmöten för att säkerställa en smidig framdrift av projektet. När utvecklingsskalan är liten, är det sant att det ofta är föredraget att ansvariga samlas när de kan, snarare än att hålla regelbundna kommunikationsrådsmöten. Men i fallet med den agila utvecklingsmodellen finns det en större risk att missa aktuella problem på möten. Därför kan det sägas att det är säkert att inkludera regelbundna kommunikationsrådsmöten i kontrakt och liknande. Som en reglering är det föreskrivet på följande sätt i det japanska ekonomiministeriets modellkontrakt.

(Upprättande av kommunikationsråd)

Artikel 12 A och B ska hålla ett kommunikationsråd för att diskutera framsteg, riskhantering och rapportering, gemensamt arbete och genomförande av individuella arbetsuppgifter, bekräftelse av innehåll som ska inkluderas i systemspecifikationer, diskussion och lösning av problem och andra nödvändiga frågor för att säkerställa att arbetet går smidigt, tills arbetet är slutfört. Dock, (utelämnat).

2. Kommunikationsrådet ska hållas regelbundet med den frekvens som fastställs i det individuella kontraktet och dessutom ska det hållas när som helst när A eller B anser det nödvändigt.

3. På kommunikationsrådet ska ansvariga och huvudansvariga från både A och B, samt de som ansvariga anser lämpliga, närvara. Dessutom kan både A och B begära att den andra parten ska ha de personer som behövs för diskussionen på kommunikationsrådet närvarande, och den andra parten ska svara på detta, utom när det finns rimliga skäl.

4. B ska skapa och lämna in en framstegsrapport i det format som A och B har kommit överens om separat vid kommunikationsrådet, och bekräfta framstegsstatus baserat på denna framstegsrapport, samt diskutera och bestämma, vid behov, om det finns några försenade punkter, om det finns försenade punkter, orsakerna till och åtgärderna för dessa, behovet av att ändra den främjande strukturen som fastställs i detta kapitel (personalbyte, ökning/minskning, ändring av underleverantörer, etc.), status för genomförandet av säkerhetsåtgärder, om det finns några skäl att ändra det individuella kontraktet, om det finns skäl att ändra det individuella kontraktet, innehållet i dessa, och bekräfta de beslutade punkterna, de punkter som ska fortsätta att övervägas, och om det finns punkter som ska fortsätta att övervägas, schemat för övervägande och de parter som ska överväga dem.

(Artiklarna 5, 6 och 7 utelämnas.)

Den största poängen är att ge kommunikationsrådets existens en viss legitimitet i kontraktsklausulerna och ge den en annan mening än ad hoc-möten som hålls på plats.

Att använda kommunikationsrådet för att hantera ändringar

I agil utveckling är det en förutsättning att de punkter som båda parter ursprungligen kom överens om kan ändras i efterhand. Därför är det mycket viktigt att hantera situationer med efterföljande specifikationsändringar.

Om ett kommunikationsråd hålls regelbundet, blir ändringshanteringen mycket smidigare. Till exempel kan ändringsdiskussioner hållas i kommunikationsrådet, och om det finns en begäran om ändringsdiskussion från en part, kan det införlivas i kontraktet att den andra parten har en skyldighet att svara på den diskussionen. (Här följer ett utdrag från reglerna i det japanska ministeriet för ekonomi, handel och industris modellkontrakt.)

(Ändringshanteringsförfarande)

Artikel 37 A eller B ska, när de har mottagit ett ändringsförslag från den andra parten (…) inom ○ dagar från mottagningsdagen, överlämna ett dokument som innehåller följande punkter (härefter kallat “ändringshanteringsdokument”) till den andra parten, och A och B ska diskutera godkännandet av den föreslagna ändringen vid kommunikationsrådet som anges i artikel 12. (Följande punkter har utelämnats)

De viktiga punkterna i ovanstående bestämmelse kan sammanfattas som följer:

• Metoden för att acceptera en ändringsbegäran har standardiserats med ett format som kallas “ändringsförslagsdokument”.
• Det finns en tidsgräns för datumet från mottagandet av förslaget till diskussionen om det. Detta kan uttryckas som “inom ◯ dagar”, men det kan också ersättas med uttryck som “snarast”.
• Platsen för att diskutera godkännandet av ändringen har standardiserats till “kommunikationsrådet”.

Med andra ord, för att undvika missförstånd som “Jag har gjort en ändringsbegäran, jag har inte gjort det”, “Jag har svarat på godkännandet av ändringen, jag har inte gjort det”, har metoden för förfarandet klargjorts.

Förståelse av uppriktighetsplikt och god tro ifrågasätts

Vi har hittills introducerat modellklausuler för “Kontaktkonferenser” och “Ändringsdiskussioner”. Men det som är viktigt för att förstå deras väsentliga innebörd är frågor som “uppriktighetsplikt” och “god tro”. Agile utvecklingsmodellen blir ofta svår att genomföra utan ett förtroendeförhållande mellan beställaren och leverantören. Detta beror på att den prioriterar hastigheten att börja arbeta, och de förfaranden som leder till starten hålls vanligtvis till ett minimum. Därför blir det vanligt i praktiken att inkludera klausuler som pålägger motparten en “uppriktighetsplikt”.

Paragraf 4.3 I ändringsdiskussioner ska parterna uppriktigt diskutera ämnet för ändringen, möjligheten till ändring, effekterna av ändringen på priset och leveranstiden, och om ändringen ska genomföras.

Detta är för att förhindra att man plötsligt förråder motparten med en formell juridisk argumentation som “om man ska godkänna en kontraktsändring eller inte är helt upp till den som mottar förslaget, och det finns ingen skyldighet att följa tvång”, i förhandlingar som har fortsatt på grundval av ett ursprungligt förtroendeförhållande. Detta återspeglar också principerna i lagen som gäller transaktioner mellan privatpersoner, inte bara systemutveckling.

Civilrättens första paragraf, andra stycket

Utövandet av rättigheter och uppfyllandet av skyldigheter måste ske i god tro och med uppriktighet.

Lagen värderar inte nödvändigtvis bara “innehållet i kontraktet” eller “ordalydelsen i klausulerna”. Särskilt i transaktioner där det finns en motpart bör man använda den flexibelt, med hänsyn till den faktiska “god tro” och “uppriktighet”. Dessutom, att det som kallas “skyldighet” enligt lagen inte nödvändigtvis baseras på “kontrakt” förklaras mer detaljerat i följande artikel.

https://monolith.law/corporate/system-development-unlawful-responsibility[ja]

Sammanfattning

Det är naturligtvis viktigt att förstå risken för att administrativa rutiner och ledningssystem kan bli slarvigt hanterade i systemutvecklingsprojekt baserade på den agila utvecklingsmodellen. Men det är inte bara det, det är också viktigt att förstå de flexibla egenskaperna som lagen ursprungligen har, som är grundade på principer som “god tro”, och att ha en inställning att tillämpa detta i praktiken.