Õiguslikust vaatenurgast vaadatuna, mis on süsteemiarenduses muudatuste haldamise viis?

Süsteemiarendusprojektides juhtub sageli, et kasutaja poolt eelnevalt selgitatud sisu muutub töö edenedes. Seetõttu võib ka tööd vastu võtval tarnijal tekkida vajadus muuta juba sõlmitud lepingut.

Käesolevas artiklis selgitame, kuidas peaksime käsitsema “muudatusi”, mis tehakse järele, seaduslikust vaatepunktist süsteemiarendusprojektide suhtes, mis ei pruugi alati plaanipäraselt edeneda.

Miks süsteemiarendusprojektid “muudetakse” tagantjärele?

Süsteemiarendus on tarnija ja kasutaja ühine töö

Süsteemiarendus on tavaliselt protsess, mis algab planeerimis- ja pakkumisetapist, millele järgneb arendusnõuete määratlemine ja lepingu sõlmimine. Pärast lepingu sõlmimist järgneb mitmesuguste disainilahenduste väljatöötamine, millele järgneb disaini järgi teostamine, lõpetades testimisega. Kogu protsessi vältel on tarnijal, kes on süsteemiarenduse spetsialist, loomulikult laialdased kohustused, kuid ka kasutajal on teatud koostöökohustused. Eriti oluline on kasutaja koostöö süsteemi funktsioonide määratlemisel (ehk nõuete määratlemisel), kasutajaliidese välimuse ja kasutatavuse (ehk põhikujunduse) väljatöötamisel ning kontrollimisel, kas nõuetele vastav süsteem on valmis (ehk testimine või vastuvõtmine). Üldine ülevaade kasutaja kohustustest süsteemiarenduses on toodud allpool.

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

Kuigi on koostöökohustus, nõuavad kasutajad sageli muudatusi

Kuid kasutajad, kes pole süsteemiarenduse spetsialistid, ei pruugi alati suuta tarnijale täielikult ja põhjalikult edastada kõiki süsteemiarenduseks vajalikke andmeid. Tegelikkuses on see detailne ja täpne töö, mistõttu on sageli raske ennustada, millised faktid võivad hilisemates etappides olla määrava tähtsusega. Seetõttu võib iroonilisel kombel juhtuda, et mida olulisem on fakt, seda hiljem see ilmneb. Selliste asjaolude tõttu on tegelikud projektid sageli “ühtse läbimurde” ideaalidest kaugel ja eeldatakse, et tagantjärele tehakse mitmesuguseid muudatusi. Seetõttu on oluline, kuidas “muudatuste haldamist” teostada.

Mis on muudatuste haldamise dokument?

Muudatuste haldamise dokumendi kasutamise olukorrad

Muudatuste haldamise dokument on dokument, mida kasutaja kasutab, et paluda tarnijalt eelnevalt antud selgituste sisu muutmist või funktsioonide lisamist. Nagu eespool mainitud, on kasutajal kohustus koostööd teha tarnija tööga nõuete määratlemise ja põhikujunduse faasis, kuid on võimalik, et hilisemas etapis esitatakse erinevaid soove.

Näiteks muudatuste haldamise dokument on vajalik järgmistel juhtudel:

• Kui nõuete määratlemise või põhikujunduse ajal on mõni punkt vahele jäänud ja soovitakse lisada funktsioone hiljem
• Kui arenduse käigus tehakse äriplaanis ülevaatus ja on vaja muuta spetsifikatsioone

Need on vaid mõned näited.

Muuhulgas, seoses funktsioonide lisamise ja spetsifikatsioonide muutmise teemadega, on töö vastuvõtja jaoks kõige olulisem küsimus, kas hinnapakkumise muutmine on seaduslikult lubatud. Selle punkti kohta on üksikasjalik selgitus eraldi artiklis.

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

Muudatuste haldamise dokument on aluseks, kui hinnatakse hinnapakkumise suurendamise sisu pärast seda, kui see on tehtud. Selleks, et vältida vaidlusi teise poolega, kui esitate arve suurenenud hinnapakkumise alusel (ja et anda oma argumendile veenvust, kui tekib vaidlus), on muudatuste haldamise dokumendi koostamine oluline.

Muudatuste haldamise dokumendi kirjeldatud punktid

Millised on seaduslikult muudatuste haldamise dokumendis kirjeldatud punktid? Muudatuste haldamise dokumentide kasutamine, et vastata spetsifikatsioonide muutustele ja funktsioonide lisamisele, on juba laialdaselt tunnustatud. Seega, kontrollides valitsusasutuste, nagu Jaapani Majandus-, Kaubandus- ja Tööstusministeeriumi (METI) mudellepingute klausleid, saab üldiselt aru, milliseid punkte tuleks kirjalikult jäädvustada.

(Muudatuste haldamise protseduur)
Artikkel 37. Kui A või B saab muudatusettepaneku vastavalt artiklile 34 (süsteemi spetsifikatsioonide muutmine), artiklile 35 (kasutaja poolt vahepealsete materjalide heakskiitmine) või artiklile 36 (lahendamata küsimuste käsitlemine), peab ta esitama teisele poolele kirjaliku dokumendi (edaspidi “muudatuste haldamise dokument”), mis sisaldab järgmisi punkte, päevade arvul alates selle saamise päevast, ja A ning B peavad arutama muudatuse sobivust artiklis 12 määratud kontaktide konsultatsioonikomisjonis.
① Muudatuse nimi
② Ettepaneku eest vastutav isik
③ Kuupäev
④ Muudatuse põhjus
⑤ Muudatuse üksikasjad, sealhulgas muudatusega seotud spetsifikatsioonid
⑥ Kui muudatuse tegemiseks on vaja raha, siis selle summa
⑦ Muudatuste töö ajakava, sealhulgas arutelu periood
⑧ Muud mõjud, mida muudatus avaldab lepingule ja eraldi lepingu tingimustele (tööperiood või tähtaeg, tasu, lepingutingimused jne)

Kui loete otse seaduse teksti ja kontrollite soovitatud kirjeldatud punkte, pole rohkem selgitusi vaja. Selleks, et vältida hilisemaid “ütlesin-ei öelnud” vaidlusi, tuleks muudatuste kulgu üksikasjalikult ja konkreetselt dokumenteerida.

Kui need kirjeldatud punktid on selgelt märgitud ja need on seotud müüja ja kasutaja vastutavate isikute või otsustajate allkirjade või pitseritega, siis isegi kui peaks tekkima kohtuasi, on need lepinguga võrdväärse tähendusega tõendina.

Mida peaks teadma muudatuste haldamisega seoses

Muudatuste haldamine tuleks enamasti läbi viia koos ülesannete haldamisega

Muudatuste haldamise dokumendi loomise põhjuseks on projekti juhtimine muudatuste ajaloo kaudu (või kui projekti ei saavutata, vältida ebaõiglast vastutust). Praktikas on muudatuste haldamise dokumendi loomine sageli seotud ülesannete haldamise nimekirja loomise ja uuendamisega. See tähendab, et kui muudatused on muudatuste haldamise tabelis haldatud, siis kokkulepitud muudatused integreeritakse tulevaste ülesannetena ülesannete haldamise nimekirja.

Muudatuste arutelu korraldamise reeglite kehtestamine on samuti hea

Mitte ainult muudatuste haldamise viis, vaid ka muudatuste arutelu korraldamise viis tuleks kindlaks määrata, et muudatuste haldamine sujuks. See on eriti oluline, kui kasutatakse arendusmeetodeid, nagu Agile, kus eeldatakse, et pärast muudatusi tehakse palju muudatusi. Praktikas on sageli näha, et kui muudatuste haldamise arutelu on nõutud, määratakse kindlaks, millal teine ​​pool peaks arutelule vastama.

Muudatuste arutelu ja ausa kohustuse põhimõte

Kui mõlemad pooled on lepingu üle kokku leppinud ja soovivad seda hiljem muuta, on see sisuliselt uue lepingu sõlmimine. Kuna leping põhineb isikute vabal tahtel, ei ole müüjal põhimõtteliselt kohustust muudatustega nõustuda. Kuid kui õiguste aspekti rõhutatakse liiga palju, võib tekkida mure, et süsteemiarendusprojekt ei suju enam sujuvalt.

Seetõttu on praktikas sageli lepingus selgelt märgitud “kohustus ausalt arutada muudatusi” ja on näiteid, kus on märgitud, et kui müüja ei vasta muudatustele ausalt, võib ta nõuda kahjutasu.

Näiteks järgmine lause on näide (allpool on toodud seaduse sõnastuse näide, mis on tsiteeritud Jaapani sõltumatu haldusasutuse Information Processing Promotion Agency ametlikult loodud “ff Basic / Individual Contract Model Basic Contract Proposal”).

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

Muudatuste tegemise reeglid

Nagu eespool mainitud, on muudatuste tegemisel “ohutum” korraldada iga kord muudatuste arutelu. Kuid väiksemate projektide puhul ei pruugi olla vajalik määrata muudatuste arutelu korraldamise viisi. Sellisel juhul võib olla mõttekas, et muudatuste haldamise dokumendile allkirjastavad ja pitserdavad kasutaja ja müüja vastutavad isikud ning alles siis tehakse muudatused. Kui muudatusi saab teha lihtsalt suulise kokkuleppe alusel, võib muudatuste tegemise küsimus muutuda ebamääraseks ja hiljem võib tekkida suur probleem, seega tuleks dokumentide haldamist põhjalikult järgida.

Kuid võib-olla on iga kord muudatuste haldamiseks eraldi dokumentide ettevalmistamine koormav ja soovite rohkem rõhutada paindlikku reageerimist. Sellisel juhul võib olla üks võimalus dokumenteerida muudatuste küsimused koosoleku protokollides. Süsteemiarenduse koosolekute protokollide hoidmise kohta leiate üksikasjalikumalt järgmisest artiklist.

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

Kokkuvõte

Tõepoolest, keskkondades, kus tehnilisi muudatusi tehakse sageli, võib sageli esineda probleeme ja vaidlusi. Kuid sellistes olukordades, kus nõutakse paindlikkust, võib olla keeruline rakendada praktilisi meetmeid, kui rõhutatakse ainult “juhtimise olulisust”.

Küsimus, kuidas ühendada äris nõutav kiirus ja ettevalmistus igaks juhuks, sõltub sageli ettevõtte olukorrast ja projekti sisust. Arvestades selle artikli sisu, on oluline ka suhtumine, mis otsib igale ettevõttele ja projektile sobivat lähenemist.