Agile arendusega seotud õiguslikud ja lepingulised probleemid

Süsteemiarenduse läbiviimiseks on olemas metoodikad. Kõige klassikalisem ja üldisem neist on veekeeris mudel (Waterfall model), millest paljud süsteemiarendust käsitlevad õigusraamatud lähtuvad. Käesolevas artiklis käsitleme agiilse arendusmudeli põhjal süsteemiarendusega seotud õiguslikke probleeme, mille kohta on raamatutest ja muudest allikatest raske infot leida.

Agile arendusmudel ja õigus

Mis on süsteemiarenduse mudel?

Süsteemiarenduse projektides on arendusmudelid raamistikud, mis aitavad jälgida projekti edenemist. Üks tuntumaid on nn “kosemudel”. See tähendab, et nagu jõgi voolab “ülevalt” “allapoole”, läbitakse ka nõuete määratlemise, disaini, rakendamise, testimise jne etapid ühe jutiga. See mudel on suunatud protsessi kordamise ja topelttöö vähendamisele ning sobib hästi planeeritud tööde teostamiseks.

Teisalt, Agile arendusmudelis rakendatakse ja testitakse väikseid programme korduvalt. Sellise korduva töö käigus luuakse järk-järgult suurem süsteem. Täpsema selgituse süsteemiarenduse mudelite kohta ja mõlema arendusmudeli eeliste ning puuduste võrdluse leiate allpool toodud artiklist.

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

Agile arendusmudeli omadused

Agile arendusmudeli suur eelis on võime kiiresti tööd alustada. Nõuete määratlemise ja disainidokumentide loomise “ülemise astme” tööd ning programmi rakendamise tööd ei ole eraldatud, mis võimaldab paindlikult juhtida funktsioonide lisamist, parandamist, spetsifikatsioonide muutmist jne. Õiguslikust vaatepunktist on Agile arendusmudeli edukaks juhtimiseks eriti oluline, kuidas dokumentide ja muudatuste haldamist korraldada. Agile arendusmudelis ei ole rollid ja vastutus nii selgelt jaotatud kui kosemudelis. Lisaks, kuna see meetod keskendub “tegevusele” ja “kiirusele”, mitte “haldamisele”, võib see viia disaini- ja spetsifikatsioonidokumentide ning koosolekute protokollide puudulikkuseni.

Lisaks, seoses muudatuste haldamisega, kuna Agile arendusmudel võimaldab muudatustele sujuvalt reageerida, võib projekt põleda läbi, kui spetsifikatsioonide muutmise taotlusi rahuldatakse kohapeal, mööda minnes heakskiidu protsessist otsustajate tasandil. Sellisel juhul võib “sujuv reageerimine hilisematele muudatustele” – arendusmudeli eelis – muutuda projekti läbipõlemise riskiks.

Dokumentide haldamine ja muudatuste juhtimine Agile arenduses

Dokumentide haldamise tähtsus

Agile arendusmudelil põhinevates arendusprojektides on seaduslik murekoht see, et suuline suhtlus koguneb ja see toob kaasa dokumentide puuduse. Selle punkti osas, miks dokumentide haldamine on süsteemiarendusprojektides üldse oluline, selgitame üksikasjalikult järgmises artiklis.

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

Selles artiklis selgitame dokumentide haldamise tähtsust süsteemiarendusprojektides kahest vaatenurgast: vaidluste ennetamine (st “ennetav õigusteenus”) ja tõendite säilitamine vaidluse korral (st “kriisijuhtimine”).

Kontaktide nõupidamise loomine on dokumentide haldamisel tõhus

Kui kasutatakse Agile arendusmudelit, ei ole erinevalt Waterfall mudelist ette valmistatud selget plaani. Seetõttu ei piisa ainult plaani ja tegelikkuse erinevuse haldamisest, vaid on oht, et kui kõik jätta töökoha otsustada, võivad nii ajalised kui ka rahalised kulud paisuda.

Seetõttu on tõhus meetod, kui vastutav isik korraldab regulaarselt kontaktide nõupidamisi projekti sujuva kulgemise nimel. Kui arenduse mastaap on väike, on tõepoolest eelistatud pigem selline lähenemine, kus vastutavad isikud kogunevad järjest, kui regulaarselt kontaktide nõupidamisi korraldada. Kuid Agile arendusmudeli puhul on eriti suur oht, et ajakohaseid probleeme ei käsitleta koosolekul. Seetõttu on regulaarsete kontaktide nõupidamiste korraldamine turvaline, kaasates need ka lepingutesse. Selle reguleerimise viis on näidatud järgmiselt Jaapani Majandusministeeriumi (METI) lepingumudelis.

(Kontaktide nõupidamise loomine)

Artikkel 12. A ja B korraldavad kontaktide nõupidamise kuni projekti lõpuni, et arutada projekti edenemist, riskijuhtimist ja aruandlust, ühiseid ja individuaalseid tööülesandeid, süsteemi spetsifikatsioonide sisu, probleemide arutelu ja lahendamist ning muid vajalikke asju, et projekt sujuvalt läbi viia. Kuid, (jäetakse vahele).

2. Kontaktide nõupidamist korraldatakse põhimõtteliselt regulaarselt individuaalse lepingu sagedusega ja lisaks korraldatakse seda vajadusel A või B poolt.

3. Kontaktide nõupidamisel osalevad mõlema poole vastutavad isikud, peamised vastutavad isikud ja need, keda vastutav isik peab sobivaks. Lisaks võivad A ja B nõuda teise poole esindajate osalemist kontaktide nõupidamisel ja teine pool peab sellele vastama, välja arvatud juhul, kui on mõistlik põhjus.

4. B loob kontaktide nõupidamisel eraldi A ja B vahel kokku lepitud vormis edenemisaruande ja esitab selle, kontrollib edenemise olukorda selle edenemisaruande alusel ning arutab ja otsustab vajadusel hilinemise olemasolu, hilinemise põhjused ja meetmed, selle peatüki muudatused (personalimuudatused, suurendamine või vähendamine, uue alltöövõtja määramine jne), turvameetmete täitmise olukord, individuaalse lepingu muutmise vajadus, individuaalse lepingu muutmise põhjused, kui need on olemas, ja muud küsimused.

(Järgnevad punktid 5, 6 ja 7 on välja jäetud.)

Kontaktide nõupidamise olemasolu annab lepinguklauslitele teatud õiguspärasuse ja eristab seda teistest ad hoc koosolekutest.

Kuidas kasutada kontaktide konsultatsiooninõukogu muudatuste haldamiseks

Samuti, Agile arenduses, on eelduseks, et mõlemad pooled muudavad esialgselt kokkulepitud asju pärast. Seetõttu on väga oluline, kuidas pärastlõunaseid spetsifikatsioonimuudatusi hallata.

Sel juhul, kui kontaktide konsultatsiooninõukogu korraldatakse regulaarselt, muutub ka muudatuste haldamine väga sujuvaks. Näiteks muudatuste arutelu toimub kontaktide konsultatsiooninõukogus ja kui üks pool nõuab muudatuste arutelu, lisatakse lepingusse kohustus vastata sellele arutelule. (Allpool on väljavõte Majandusministeeriumi mudellepingu sätetest.)

(Muudatuste haldamise protseduur)

Artikkel 37. Kui A või B saab teiselt poolelt (jäetakse vahele) muudatusettepaneku, peab ta ○ päeva jooksul alates selle saamise kuupäevast andma teisele poolele kirjaliku dokumendi (edaspidi “muudatuste haldamise dokument”), milles on kirjas järgmised asjad, ja A ja B peavad kontaktide konsultatsiooninõukogus arutama selle muudatuse heakskiitmist või tagasilükkamist. (Järgnevad kirjeldused on välja jäetud)

Ülaltoodud sätete punktid võib kokku võtta järgmiselt:

• Muudatuste taotluse vastuvõtmise meetod on ühtlustatud “muudatuste ettepaneku” vormingus
  
• On olemas tähtaeg ettepaneku saamisest kuni selle arutamiseni → seda ei pea märkima “◯ päeva jooksul”, vaid võib asendada sõnadega “kiiresti” jne.
  
• Muudatuste heakskiitmise või tagasilükkamise arutelu koht on ühtlustatud “kontaktide konsultatsiooninõukogu” koosolekuga
  

Teisisõnu, nad on selgelt määratlenud protseduuri, et vältida arusaamatusi, nagu “ma esitasin muudatuse, ma ei esitanud” või “ma vastasin muudatuse heakskiitmisele või tagasilükkamisele, ma ei vastanud” suulisel alusel.

Usalduskohustuse ja hea usu põhimõtte mõistmine on oluline

Oleme siiani tutvustanud lepinguklausleid, mis puudutavad “kontakti konsultatsiooninõukogu” ja “muudatuste arutelu”. Kuid nende põhiolemuse mõistmiseks on oluline mõista selliseid aspekte nagu “usalduskohustus” ja “hea usu põhimõte”. Alguses on Agile arendusmudel ilma tellija ja töövõtja vahelise usaldussuhteta sageli keeruline. Selle põhjuseks on asjaolu, et töö alustamise kiirus on olulisem ja protseduurid enne töö alustamist on tavaliselt minimaalsed. Seetõttu on tavapärane lisada lepingusse klausel, mis kohustab teist poolt “usalduskohustuse” täitmisele.

Paragrahv 4, lõige 3: Muudatuste aruteludes tuleb arutada muudatuste objekti, muudatuste võimalikkust, muudatuste mõju hinnale ja tähtajale ning mõlemad pooled peavad muudatuste tegemise üle siiralt arutlema.

See on mõeldud selleks, et vältida olukorda, kus läbirääkimised, mis on algusest peale põhinenud usaldussuhtel, muutuvad äkki selliseks, et “kas nõustuda lepingu muutmisega või mitte, on ainult selle poole vabadus, kes pakkumise saab, ja ei ole kohustust sundida”. See peegeldab ka õigusprintsiipe, mis kehtivad eraisikute vahelistes tehingutes, mitte ainult süsteemiarenduses.

Tsiviilseadustiku paragrahv 1, lõige 2

Õiguste kasutamine ja kohustuste täitmine peavad toimuma hea usu põhimõtte järgi ja olema siirad.

Seadus ei rõhuta ainult “lepingu sõnastust” või “paragrahvi sõnastust”. Eriti tehingutes, kus on teine pool, tuleks seda kasutada paindlikult, kaasates tegelikku “hea usu” põhimõtet ja “siirust”. Lisaks selgitame üksikasjalikult järgmises artiklis, et “kohustus”, mida seadus kehtestab, ei põhine alati “lepingul”.

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

Kokkuvõte

Agile arendusmudelil põhinevates süsteemiarendusprojektides on muidugi oluline mõista riske, mis tulenevad asjaajamise ja juhtimiskorralduse järkjärgulisest hooletusse jätmisest. Kuid mitte ainult, on oluline mõista ka õiguse paindlikke omadusi, mis põhinevad põhimõtetel nagu “ausa mängu reegel”, ning suhtumist, mis rakendab neid praktikas, peetakse samuti oluliseks.