Mida tähendab süsteemiarenduse tellija, kasutaja poolt kantav koostöökohustus?

Süsteemiarenduse töö nõuab, mida suurem on arendatav süsteem, seda rohkem inimressursse ja tööaega. Seega on seal mitte ainult arendusega tegeleva tarnija, vaid ka süsteemiarendust telliva kasutaja kohustus teatud määral koostööd teha.

See erineb tavalisest tellimuse ja tarnimise suhtest. Näiteks kui tellite rätsepalt kohandatud ülikonna, ei võta klient (kasutaja) endale erilist “kohustust”. “Kohustuse” võtab endale peamiselt rätsep (tarnija). Paljude inimressursside ja tööaja tõttu on IT-süsteemis vajalik, et ka kasutaja “koostööd” teeks tarnijaga.

Käesolevas artiklis selgitame, millised on tellija õiguslikud kohustused süsteemiarenduse puhul, mida ei saa jätta ainult tarnija hooleks.

Oma süsteemi puhul ei saa kõike lihtsalt “käest ära visata”

Ühe süsteemiarendusprojekti puhul on sageli seotud paljud inimesed ja organisatsioonid. Muidugi on olulised programmeerijad ja insenerid, kes on osavad kodeerimistehnoloogias, kuid nende tööjõu tulemuste koondamiseks üheks saavutuseks on projekti juhi roll samuti oluline.

Kuid isegi kui tarnija pool omab kõrget tehnilist ja organisatsioonilist võimekust, ei saa süsteemiarendust läbi viia ainult tarnija jõul. Näiteks ettevõtte siseseid termineid ja ettevõttespetsiifilisi äriteadmisi, mida kasutatakse ainult ettevõtte sees, ei saa tarnija pool ühepoolselt teada. Mida suurem on süsteemiarendus, seda tavalisem on, et süsteemi kasutav ettevõte on suurettevõte, mis haldab paljusid inimesi ja tööülesandeid. Süsteemiarendusprojekti edukaks juhtimiseks on sageli suur osakaal äri loogika korraldamisel, isegi enne arvutitööd.

Seega, kasutaja pool ei tohiks olla passiivne põhjusel, et “ma pole IT-spetsialist”, vaid peaks pigem aktiivselt teavet pakkuma, et projekti edenemine oleks sujuv. Selles mõttes ei ole kasutaja roll süsteemiarendusprojektis tegelikult väike.

Kuidas tõlgendatakse tagantjärele tehniliste muudatuste taotlusi?

Eeldades, et süsteemiarendusprojekt on kasutaja ja müüja ühistöö, liigub arutelu edasi arenenumatele teemadele. See on küsimus, nagu “Kui kasutaja nõuab tagantjärele funktsioonide lisamist või parandamist ja selle tõttu on tähtaegade täitmine keeruline, kelle vastutus see on?”

Süsteemiarendus algab tavaliselt nõuete määratlemisest, järgneb põhikujundus, detailne kujundus, tootmine (programmi rakendamine) ja testimine, eesmärgiga vältida tagasipöördumist võimalikult palju (tavaliselt nimetatakse seda vesiputouks). Kuid mingil põhjusel, kui selgub, et eelnevates etappides on puudusi, juhtub sageli, et protsessis tekib tagasipöördumine.

Kuidas peaksime mõtlema, kui me ei jõua tähtajaks valmis sellistes olukordades? Varasemate kohtuotsuste tõlgendamisel tundub, et järeldused erinevad sõltuvalt ajast, mil lisatööd tekkisid.

Juhul, kui lisatööd olid enne välise kujunduse jms spetsifikatsioonide selgitamist

Eelmainitud kohtuotsus näitab, et kui kasutajalt on saadud lisatööde taotlus põhikujunduse ajal (enne programmi rakendamise etappi), siis sellise nõudmise esitamine ei ole iseenesest koostöökohustuse rikkumine.

Kasutaja esitab müüjale põhikujunduse ajal süsteemi kohta erinevaid nõudmisi, mis on süsteemi arendamise protsessis nagu antud juhul loomulik, ja lisaks, spetsialiseeritud teadmisteta hageja-kasutaja jaoks on raske täpselt hinnata, kas need nõudmised nõuavad lisatasu või tarneaja pikendamist, kas need põhjustavad tööprotsessis takistusi. Seetõttu ei saa öelda, et hageja-kasutaja peaks hoiduma nõudmistest, mis toovad kaasa lisatasu või tarneaja pikendamise. Pigem, kui hageja-kasutaja esitas nõudmisi, mis nõuavad lisatasu või tarneaja pikendamist, siis projekti juhtimiskohustusega kostja peaks sellest hageja-kasutajale teada andma, nõudma nõudmise tagasivõtmist või tarneaja pikendamise arutelu, et arendustöö ei oleks takistatud.

Tokyo District Court, March 10, 2004 (Heisei 16)

Selles otsuses näidati, et kasutajal on teatud koostöökohustus, kuid samal ajal tuleb arvestada, et kasutaja ei ole süsteemiarenduse ekspert. Teisisõnu, kui tellija ei ole süsteemiarenduse ekspert, siis kuni süsteemi sisu selgub, võib ta (sõltuvalt olukorrast, isegi kui ta ei ole harjunud tellima) esitada erinevaid tellimusi ja see ei ole üllatav. Veelgi enam, on ebaõiglane nõuda, et ta peaks “ise märkama” kui tellimuse sisu nõuab tarneaja jne ülevaatamist.

Siiski, müüja kohustus siin on põhimõtteliselt suunatud kommunikatsiooni jõupingutustele, nagu tarneaja pikendamise taotlemine (või kui tarneaega ei saa muuta, siis lisapäringu tühistamise ettepanek). Seega, ei tohiks arvata, et see hõlmab kohustust nõustuda kõigi kasutaja nõudmistega ja tarnida toode algse tähtaja jooksul. Selles punktis tuleb olla ettevaatlik.

Juhul, kui lisatööd olid tootmise või testimise protsessi spetsifikatsioonide kinnitamisest hilisemad

Kui me vaatame ülaltoodud otsuse sisu, saame teatud määral ennustada, milline oleks olnud tulemus, kui lisatööd oleksid tehtud pärast spetsifikatsioonide kinnitamist. Sellisel juhul oleks selliste nõuete täitmine tõenäoliselt keeruline. Tõepoolest, kasutaja ja tarnija vahel võib olla suur erinevus arendustöö mõistmisel, olenemata sellest, kas see toimub enne või pärast spetsifikatsioonide kinnitamist.

Kuid spetsifikatsioonide kinnitamise järel tellimuse muutmine või lisamine võib suure tõenäosusega nõuda töö ümbertegemist. Sellistel juhtudel on sageli raske kaitsta hilinenud tarnimist, väites, et “klient on õigustatud esitama erinevaid nõudmisi”. Lisaks võib olukord, kus paljud spetsifikatsioonide muudatused või funktsioonide lisamised toimuvad pärast seda, tekitada küsimusi, kas kasutaja pool ei ole rikkunud oma koostöökohustusi juba algstaadiumis, näiteks põhikujunduse osas, mis oleks pidanud olema juba lõpetatud.

Seetõttu võib eeldada, et spetsifikatsioonide muutmine pärast nende kinnitamist, mis on viivituse põhjuseks, ei ole tarnija vastutus. Ülaltoodud otsusest võib järeldada, et see tõlgendus on asjakohane.

Lisaks tehakse selliseid otsuseid sageli mitte ainult lepingu alusel, vaid ka süsteemiarenduse edenemisele vastavate koosolekute protokollide alusel. Koosolekute protokollide kohta on üksikasjalikumalt kirjeldatud allpool toodud artiklis.

Seotud artikkel: Mis on süsteemiarenduse koosolekute protokollide hoidmise viis õiguslikust vaatepunktist[ja]

Kokkuvõte: Oluline on meeles pidada, et nõuete määratlus on kasutaja protsess

Nõuete määratlus on küll tarnija oskuste näitamise koht, kuid esmalt tuleks meeles pidada, et see on tegelikult kasutaja äriprotsess. Kui see on süsteem, mida teie ettevõte kasutab, siis isegi kui see on loodud välise ekspertiisi abil, peaks eeldama, et see on valdkond, kus teie ettevõtte juhtimine kehtib ja mida seaduslikult peetakse sobivaks.

Kui kasutajapoolne koostöö arendusprotsessis puudub, siis isegi kui projekt põleb läbi, on suur tõenäosus, et kohus võib kasutaja suhtes olla karm. Seda punkti tuleks esmalt mõista.