Kodėl dideliuose projektuose kartais ilgiausiai deramasi dėl vieno žodžio?
Daugiau nei mėnuo derybų, bent penkiasdešimt darbo valandų ir daug dalyvių iš abiejų šalių. Taip vyko vienos IT projekto sutarties derinimas. Diskusijos apėmė ir esminius komercinius įsipareigojimus, ir atskiras frazes bei sąvokas. Pavyko pasiekti subalansuotą susitarimą, o jo praktinę vertę šiandien patvirtina tęsiamas bendradarbiavimas: šalys vykdo sutartį ir dirba toliau.
Ši patirtis atskleidžia IT projektams būdingą problemą. Užsakovas siekia sutarto rezultato, biudžeto ir įgyvendinimo termino, o vykdytojas turi įsipareigoti dėl sprendimo, kurio dalis techninių ar funkcinių detalių paaiškės tik vykstant projektui. Programinės įrangos kūrimo, sistemų diegimo, integravimo ar modernizavimo projektuose reikalavimai dažnai detalizuojami etapais. Todėl sutarties sudarymo metu svarbu susitarti, kiek šio neapibrėžtumo prisiima kiekviena šalis ir kaip bus priimami sprendimai jam išryškėjus.
Sąlyga, pagal kurią vykdytojas už fiksuotą kainą įsipareigoja atlikti „visus užsakovo poreikiams įgyvendinti būtinus darbus“, gali atrodyti pakankamai aiški, kol jos nereikia pritaikyti konkrečioms užduotims. Ar ji apima tik sutarties dokumentuose aprašytus poreikius? Ar ir tuos, kurie buvo aptarti derybose, tačiau liko neužfiksuoti? Kaip vertinti poreikį, kurį užsakovas suformuluoja analizės ar testavimo metu ir laiko savaime suprantama užsakomo sprendimo dalimi?
Žodis „sutartus“ tokioje sąlygoje gali reikšmingai pakeisti įsipareigojimo ribas, tačiau tik tuomet, jeigu šalys gali nustatyti, kur ir kokiu būdu konkretūs poreikiai buvo suderinti. Derybos dėl vienos formuluotės dažnai apima platesnį klausimą: kokį rezultatą vykdytojas įsipareigoja pateikti ir pagal kokius kriterijus bus sprendžiama, ar jis šį įsipareigojimą įvykdė. Nuo atsakymo priklauso papildomų darbų apmokėjimas, terminų keitimas ir atsakomybė už projekto eigą.
Galimybė kilus ginčui nustatinėti tikrąjį susitarimo turinį nepakeičia poreikio jį aiškiai apibrėžti iš anksto. Projekto komandai bendro atskaitos taško reikia jau tuomet, kai priimami kasdieniai sprendimai dėl konkrečių užduočių.
Fiksuota kaina užsakovui suteikia biudžeto kontrolę, tačiau jos praktinė reikšmė priklauso nuo sutartos apimties. Vien kainos nurodymas nepašalina nesutarimo, jeigu viena šalis ją sieja su konkrečiai aprašytu funkcionalumu, o kita – su visais darbais, kurių gali prireikti platesniam verslo tikslui pasiekti.
Pavyzdžiui, įsipareigojimas sukurti specifikacijoje aprašytą duomenų apsikeitimo funkciją ir įsipareigojimas užtikrinti sklandų informacijos judėjimą tarp visų užsakovo sistemų gali reikšti labai skirtingą darbų bei rizikos apimtį.
Todėl kainos pagrindą turi sudaryti pakankamai apibrėžti funkciniai ir nefunkciniai reikalavimai, sutartos integracijos, darbų ribos ir esminės įgyvendinimo prielaidos. Reikšmingi gali būti duomenų kokybės, sistemų prieinamumo, našumo, saugumo ar trečiųjų asmenų dalyvavimo klausimai. Nebūtina sutarties sudarymo metu išspręsti kiekvienos techninės detalės, tačiau turi būti aišku, kurios detalės dar bus tikslinamos vykdant jau prisiimtą įsipareigojimą ir kurie sprendimai gali pakeisti jo apimtį.
Teisinės pasekmės priklauso ir nuo sutarties pobūdžio. IT sutartyse gali būti derinami rangos, paslaugų, licencijavimo ir kiti elementai, todėl jų kvalifikavimas turi remtis konkrečių įsipareigojimų turiniu. Kai taikomos rangos taisyklės, Civilinio kodekso 6.653 straipsnio 5 dalis paprastai neleidžia didinti konkrečios darbų kainos vien todėl, kad sudarant sutartį nebuvo galima tiksliai numatyti darbų kiekio ar būtinų išlaidų. Didesnės, nei planuota, vykdymo sąnaudos ir užsakovo pakeista darbų apimtis yra atskirai vertintinos aplinkybės.
Gerai parengta IT sutartis nesiekia sukurti iliuzijos, kad projektas nesikeis. Ji nustato, kurios rizikos jau įskaičiuotos į kainą, o dėl kurių šalys turės priimti naują komercinį sprendimą.
Fiksuota kaina gali būti labai gera sutarties konstrukcija. Tačiau ji apsaugo biudžetą tik tada, kai šalys vienodai supranta, už ką ta kaina sutarta.
