Ugovori o pružanju usluga razvoja softvera (za koje se i u domaćem pravnom prometu najčešće koristi terminologija „Software Development Agreement” ili „SDA”, što će biti primenjeno i u ovom tekstu) nažalost često imaju sudbinu holivudskih brakova. Na početku su očekivanja partnera visoka, a budućnost deluje blistavo. Ipak, posle nekog vremena počinje da se naslućuje kraj, a raskid može biti turbulentan i skup.
To je obično momenat kada ugovorne strane shvate da se na samom početku nisu dobro razumele, što pokazuje da nisu sva pitanja regulisana na adekvatan način. Kod SDA [1] svaka odredba je veoma važna i, ako joj se ne posveti dovoljna pažnja, detalj može biti uzrok razdora u budućnosti.
Ugovori o pružanju usluga razvoja softvera su specifični zbog svoje kompleksnosti. Master Software Development Agreement neizostavno prate Specifikacije, Instrukcije, Rasporedi, Licence, kao i Ugovori o nivou usluga (poznat kao „Service Level Agreement” ili „SLA”), što čini ove sporazume složenim aktima, sačinjenim od više različitih dokumenata, koji često nisu sastavljeni tako da čine koherentnu celinu te dolazi do neslaganja između dokumenata koji uređuju isti projekat. Kada se na to doda činjenica da je veoma teško do detalja predvideti tehničke zahteve I specifkaciju za razvoj softvera, te da je inicijalna procena troškova celog projekta često nerealna, ne začuđuje da najmanje 50% projekata propadne pre očekivanog završetka.
Za pružaoca usluge najveći problem nastaje kada plaćanje naknade za usluge izostane ili kasni, kada klijent dodatnim instrukcijama pokušava da proširi prvobitno ustanovljen obim projekta (poznato kao „scope creep”) ili kada pružalac usluge veruje da su unapred definisani kriterijumi prihvatanja za isporuku dela softvera ispunjeni, dok klijent to osporava. S druge strane, za klijenta problem nastaje kada isporuka softvera, odnosno njegovog dela, kasni ili kada kvalitet softvera nije u skladu sa tehničkom i/ili funkcionalnom specifikacijom što opet može biti osporavano od strane pružaoca usluge.
Još veće komplikacije nastaju kada pružalac usluga projekat ne izvršava sam, već angažuje podizvođače (poznat kao „one throat to choke” model). U tom slučaju, ključna odredba SDA je i odgovornost pružaoca usluge za izbor i rad podizvođača, ukoliko ih on bira. Alternativna opcija je multi-vendor IT ugovor, kod koga, zbog postojanja više pružalaca usluga nadležnih za pojedine delove projekta, složenost pravnih pitanja i mogućnost spora raste eksponencijalno.
Imajući u vidu da se ovi ugovori najčešće zaključuju na period od više godina, treba dodati i izazove koje sa sobom nose fluktuacije na tržištu (npr. promene u cenama rada/usluga/sredstava za rad itd.), ali i promene u poslovnoj strategiji klijenta, koje ne moraju biti u vezi sa samim izvršenjem ugovora (na primer: prelazak na insourcing sa outsourcing biznis modela).
Sve navedeno čini da je izlazak iz Ugovora o pružanju usluga razvoja softvera sa što manje štete po ugovorne strane, pravi izazov.
Faktori za donošenje prave komercijalne odluke
Kada dođe do nesporazuma između ugovornih strana, načelno, ugovorne strane imaju sledeće opcije:
- da kroz otvaranje novih pregovora modifikuju ugovor i održe ga na snazi po principu „hajde da damo još jednu šansu”;
- da se raziđu raskidom ugovora po principu „sve smo probali i ne ide”;
- da raskinu samo deo ugovora, a u drugom delu nastave saradnju po principu „nije sve tako crno”.
Da bi se donela najbolja komercijalna odluka treba razmotriti tehničku i pravnu stranu projekta. Tehnička pitanja su: šta se pogrešno desilo u praksi – nerealni rokovi, nedostatak resursa, nepredviđeni troškovi, menjanje obima projekta i sl. Pravna pitanja su: šta ugovor i merodavno pravo kažu na sporno pitanje.
Pitanje br. 1: Dokle smo stigli – tehnički nivo?
Radi donošenja konačne odluke treba utvrditi tehnički nivo do tada izvršenih usluga. Klasična pitanja koja će klijent razmatrati su sledeća:
- U kojoj je fazi projekat? Na primer: da li smo u fazi izrade arhitekture projekta, u fazi razvoja i dizajna, u fazi testiranja, u fazi diplojmenta i sl.
- Koliko je kašnjenje? Koliko bi obim projekta trebao da se smanji da bi se ispoštovao rok predviđen ugovorom?
- Da je važnije očuvati obim projekta ili ispoštovati rok?
- Da li je pružalac usluga u stanju da završi projekat? Da li dizajn sistema dozvoljava da se angažuje novi pružalac usluga u kratkom roku?
- Koliko iznosi dodatno ulaganje?
Poseban problem se može javiti kada klijent proceni da pružalac usluga nije u stanju da tehnički dovrši projekat, a projekat je trenutno u stadijumu da bi bilo neefikasno (ili čak nemoguće) da ga dovrši neki novi pružalac usluga. Tada klijent može biti zarobljen u ugovoru i prisiljen na ustupke pružaocu usluge, samo da bi se okončao projekat.
Pitanje br. 2: Šta kaže ugovor?
Praksa pokazuje da često ugovorne strane nisu svesne svih prava, obaveza i odgovornosti koje proističu iz ugovora, iako je to najvažnije za opstanak saradnje.
Na primer: može biti jasno da je rok od godinu dana za završetak projekta probijen, ali je sporno čija je to krivica. Tada sledi pitanje da li pružalac usluga sada ima obavezu da završi projekat bez dodatnog troška za klijenta ili pak klijent treba da plati uvećanu naknadu zbog izmena i dodatnih zahtev koji su prouzrokovali kašnjenje?
Kada se javi problem u toku realizacije projekta, najčešće odredbe koje će vam pomoći da odlučite da li da otvarate nove pregovore i pokušate da održite projekat ili da raskinete ugovor su sledeće:
1. Tačke provere (Checkpoints)
Odredbe koje omogućavaju da se proveri da li se ugovorne obaveze izvršavaju konzistentno tokom njegovog trajanja, kao i da se sam ugovor uskladi sa promenama u obimu projekta i u troškovima. Benčmarking (Benchmarking) je dobar formalan način da se revidira ugovor sa održavanjem na snazi. Ovakva opcija omogućava da se pružalac usluga obaveže da koriguje cenu usluge razvoja softvera sa cenom koju definiše tržište, u tačno određenim vremenskim periodima. Ipak, veoma je važno da se ovakva mogućnost pažljivo predvidi u ugovoru kako bi obezbedila korist i jednoj i drugoj strani. Ukoliko je ova odredba sačinjena isključivo uzimajući u obzir klijentove interese, pružalac usluge može biti nemotivisan da održi visok standard usluge, što predstavlja samo Pirovu pobedu.
2. Procedura za kontrolu promena (Change Control Procedure)
Gotovo svaki IT projekat podrazumeva promenu nekog elementa, kako tehničkog tako i pravnog, pa je predviđanje procedura za kontrolu promena od ključnog značaja. Ugovorne strane treba da se sporazumeju oko procedure koja se primenjuje u slučaju da određena izmena treba da se implementira, ustanovljavajući jasne parametre za prihvatljivost određene izmene. Ipak, ovde treba biti svestan da ugovorne strane možda nisu uvek pratile proceduru za kontrolu promena propisanu ugovorom, već da su u praksi, tokom izvršenja ugovora, implicitno usvojile drugačije mehanizme za izmenu. Zbog toga je važno da se analiziraju svi formalni zahtevi za promenu kontrole, ali i držanje ugovornih strana tokom trajanja ugovora, kako bi se utvrdilo sve što može da utiče na pravnu poziciju.
3. Plan izlaska i tranzicije
Ako ste klijent, poželećete da ste ugovorili mogućnost da uvedete dodatnog pružaoca usluga u svoj projekat razvoja softvera. Klijentima se često savetuje da ne prenose celokupan projekat na samo jednog pružaoca usluga, jer je činjenica da kada jedan pružalac usluga ima potpunu kontrolu nad projektom raskid ugovora za klijenta je mnogo teži. Osim toga, uvođenjem dodatnog pružaoca usluga pregovaračka pozicija klijenta se pojačava, naročito u pogledu cene.
4. Pravo da se angažuje novi pružalac usluga
Ako ste klijent, poželećete da ste ugovorili mogućnost da uvedete dodatnog pružaoca usluga u svoj projekat razvoja softvera. Klijentima se često savetuje da ne prenose celokupan projekat na samo jednog pružaoca usluga, jer je činjenica da kada jedan pružalac usluga ima potpunu kontrolu nad projektom raskid ugovora za klijenta je mnogo teži. Osim toga, uvođenjem dodatnog pružaoca usluga pregovaračka pozicija klijenta se pojačava, naročito u pogledu cene.
5. Prava intelektualne svojine
Za konačnu odluku da li ćete raskinuti Ugovor ili održati projekat biće važno pravno pitanje šta se dešava sa pravom intelektualne svojine. Najvažnije je jasno razgraničiti ko će biti titular prava intelektualne svojine na softveru, materijama i dokumentima, ukoliko se projekat završi u ovoj fazi?
Ukoliko klijent nije nosilac prava na softveru po ugovoru, već prava zadržava pružalac usluga (u celini ili delu), definitivno otpada mogućnost zamene drugim izvršiocem, koji bi nastavio gde je prvi izvršilac stao.
Nije retko da naizgled zanemarljive jezičke nijanse dovedu do ovakvog rezultata. Na primer: upotreba budućeg vremena u formulaciji (na primer: „…će preneti prava intelektualne svojine”) umesto sadašnjeg vremena (na primer: „prenosi prava intelektualne svojine”) može da bude veoma problematična, jer, čak i u slučaju da je pružalac usluga odgovoran za povredu ugovora zbog propusta u isporuci usluge, ne znači da će klijent steći vlasništvo nad pravima intelektualne svojine.
Osim toga, u ugovorima koji su sačinjeni po pravu jedne od država u okviru SAD, pogrešne jezičke nijanse mogu da dovedu do istinski problematičnih rezultata. Na primer: ugovorne strane često opisuju softver kao „work made for hire”, verujući da će time automatski preneti sva vlasnička prava na softveru na klijenta. Ipak, po pravilima autorskog prava u okviru SAD programski kod ne može spadati u tzv. „work made for hire”.
Za izvršioca, s druge strane, je bitno šta će biti sa intelektualnim pravima na njegovim ranijim projektima i kako jasno odvojiti prava intelektualne svojine koje pružalac već ima (nešto što se naziva „Background technlogy”) od onih koji proizlaze iz novog IT projekta.
Klijent je zapravo taj koji će insistirati na preciznom regulisanju prava intelektualne svojine, jer u odsustvu izričitog normiranja u ugovoru, naše pravo (kao i npr. englesko pravo i mnoga druga širom sveta) štite autora dela – u ovom slučaju izvršioca kao stvaraoca softvera.
6. Koje pravo se primenjuje na ugovor
Ukoliko ugovor jednostavno ne definiše kako da se reši sporno pitanje koje je nastalo između ugovornih strana, ugovorne strane će morati da potraže odgovor u merodavnom pravu. Merodavno pravo je ono pravo čiju su primenu ugovorili klijent i pružalac usluga. Ugovori o pružanju usluga razvoja softvera su često ugovori sa međunarodnim elementom, u kojima ugovorne strane potiču iz različitih država. Odgovore na sva pitanja koja se ne nalaze u ugovoru, ugovorne strane će naći u pravnim propisima i sudskoj praksi te države. Tu je obično problem što će ugovorna strana koja ima jaču pregovaračku moć insistirati da merodavno pravo bude pravo države iz koje ta ugovorna strana potiče. Kada dođe do eskalacije u odnosima između ugovornih strana, mnogo težu poziciju će imati onaj ugovarač koji je prihvatio merodvano pravo druge ugovorne strane.
Komercijalna odluka
Nakon sagledavanja tehničkih i pravnih aspekata, ugovorne strane dolaze do konačne odluke da li nastavljaju zajedničkim putem ili je nemoguće nastaviti saradnju. Ukoliko je to slučaj, potrebno je da se ugovor potpuno ažurira u skladu sa novim dogovorom. Ukoliko je komercijalna odluka negativna, moguć je raskid celog ugovora ili delimičan raskid.
A. Delimičan raskid ugovora – jer nije baš sve tako crno
Prvo pitanje koje sebi morate postaviti jeste, da li postoje delovi ugovornog odnosa koji su vredni spašavanja?
Delimičan raskid se uglavnom svodi na to da li se obaveze u projektu uopšte mogu razdvojiti. U kompleksnim ugovornim odnosima, ključno pitanje će biti da li je od početka ugovorna struktura bila podešena na način da dozvoljava delimičan raskid. Ukoliko prilikom sačinjavanja Ugovora o pružanju usluga razvoja softvera ova opcija nije dovoljno dobro razmotrena i razrađena, postoje male šanse da će ona u praksi moći da se primeni i da će pojedine odrebde Ugovora moći da prežive samostalno.
Ukoliko je pak moguće da jedan deo ugovora opstane, sledi aneksiranje ugovora i definisanje koje odredbe su prestale da važe, a zatim i usklađivanje ostalih odredaba sa naročitim akcentom na odredbama koje su dovele do neslaganja ugvornih strana a to su po pravilu odredbe o plaćanju, rokovima i isključenju i/ili ograničenju odgovornosti.
B. Raskid – jer smo sve drugo probali i nije išlo
Razmotrili ste sve opcije da sačuvate ugovor i nastavite projekat, ali jednostavno održavanje ugovora na snazi se pokazuje više kao teret i/ili trošak, nego razumno rešenje. Tada je jedina opcija koja Vam preostaje da raskinete ugovor. Kada donesete tu odluku, ne samo da niste završili posao zbog kog ste ušli u ugovor, već ste zapravo na početku. Kao što je ugovor (zaključenje i izvršenje) jedan ozbiljan proces, tako sada predstoji jedan potpuno novi (i verovatno znatno neprijatniji) proces – raskidanje ugovora .
Ovo je vreme aktiviranja odredbe o raskidu za koju ste mislili da vam neće ni zatrebati. Dok sporazumni raskid ugovora nije problem, akcenat se mora staviti na jednostranom raskidu, odnosno pitanjima ko, kada, zašto i kako može jednostrano raskinuti ugovor. Ugovori često propuštaju da razlikuju raskid zbog povrede ugovora i raskid ugovora bez određenog razloga, što može da bude veliki propust, ako se nađete u ovoj situaciji.
Osim toga, ukoliko želite da raskinete ugovor, jer smatrate da je druga ugovorna strana povredila ugovor, ključna odredba će biti ona koja definiše koje povrede se smatraju tzv. „raskidnim uslovom” (Material breach). Takva odredba će predviđati određenu skalu težine povreda ugovora, dok će raskidni uslov predstavljati ozbiljne povrede, odnosno povrede koje imaju ozbiljan efekat. Ukoliko je takva odredba precizno definisana, ona će vam dati odgovor na pitanje da li Vam uzork neslaganje daje pravo na jednostrani raskid ugovora.
Sledeće pitanje koje se nameće je da li ćete imati pravo da tražite naknadu štete zbog povrede ugovora od druge strane i da li postoje ograničenja u pogledu visine te naknade štete.
Odgovor na to pitanje pružaju odredbe o ograničenju i/ili isključenju odgovornosti, koje bi morale biti neizostavni deo svakog Ugovora o pružanju usluga razvoja softvera.
Pružalac usluga će često insistirati na ugovaranju gornje granice vrednosti do koje može da odgovara za naknadu štete, što bi moralo da bude srazmerno vrednosti samog SDA. Klijent može biti neprijatno iznenađen, ako u momntu eskalacije utvrdi da je pružalac usluga ograničio iznos potencijalne odgovornosti za štetu na samo deo stvarne štete koju klijent trpi.
Međutim, odgovornosti za neispunjenje pojedinih obaveza, koje su za svaku od strane ključne u ugovrnom odnosu, će često biti neograničene po visini. U situaciji kada raskidate ugovornu saradnju, veoma važno će vam biti koje su tooblasti. Uglavnom će odgovornost pružaoca usluga biti neograničena u pogledu povrede prava intelektualne svojine, jer klijent želi da se zaštiti od odgovornosti za naknadu štete prema trećim licima u iznosu koji je nepoznat i neograničen. Ugovaranje neograničene odgovornosti je karakteristično i za povredu podataka koji čine poslovnu tajnu, a u koje mogu da spadaju i podaci o ličnosti.
Sve navedeno ukazuje da će strategija izlaska iz Ugovora o pružanju usluga razvoja softvera zavisiti od više faktora, od kojih će jedan od najznačajnijih biti sama sadržina ugovora. Drugim rečima, odluka o kraju će vas uputiti na sam početak. Zato ističemo značaj pregovaračkog procesa i kvalitetnog sačinjavanja svake od ugovornih odredbi, bez kojih nema ni uspešnog partnerstva, ali ni lakog razlaza.
