Viešieji pirkimai IT sektoriuje: būtina tobulinti ginčus keliančias taisykles
Pastarųjų metų patirtis rodo, kad laikas permąstyti nusistovėjusias normas ir metodus, kurie akivaizdžiai nebeatitinka sparčiai kintančios IT projektų realybės.
Ginčai užprogramuoti, o realių laimėtojų – nėra
Nors oficialios statistikos viešai skelbiama nedaug, nuolat susiduriant su ginčais IT sektoriaus projektuose bei vykdomų sutarčių turiniu matyti, kad didžioji dalis projektų vis dar vykdomi tradiciniu „Waterfall“ (krioklio) metodu. Tradiciškai viešieji pirkimai šio metodo pagrindu vykdomi remiantis aiškiai apibrėžtais poreikiais, kainos ir termino fiksavimu bei su tiekėju pasirašoma sutartimi, kurioje numatyta, ką ir per kiek laiko jis turi įgyvendinti.
IT sistemų kūrimo ir diegimo atveju tai dažnai reiškia, kad iš anksto bandoma „popieriuje“ tiksliai užfiksuoti visus reikalavimus, procesus ir funkcionalumus, nors praktika rodo, kad tikroji projekto apimtis išryškėja tik po detalios analizės ir projektavimo darbų ar net sistemos diegimo etape. Ilgi projektavimo dokumentai – ne išimtis, o rezultatas neretai skiriasi nuo pirminės vizijos.
Kai vėliau paaiškėja, kad darbų apimtys akivaizdžiai tampa didesnės nei tikėtasi, prasideda derybos, ginčai ir teismai. Tiekėjas kaltinamas nerūpestingumu skaičiuojant kainą ir nepasiruošimu galimiems pokyčiams, o perkančioji organizacija dažnai lieka „teisi teisiškai“, bet be norimo rezultato. Tad „Waterfall“ modelis puikiai tinka situacijoms, kur projekto apimtis stabili ir nesikeičia, tačiau IT sektoriuje tai – greičiau išimtis, o ne taisyklė.
„Agile“ – lankstumas ir bendradarbiavimas vietoj dokumentų kalno
Šias keblias situacijas spręsti padedantis receptas jau seniai išrastas, tačiau jį reikia naudoti – tai „Agile“ metodologiją. Lietuvoje ji reglamentuota dar 2014 metais, tačiau iki šiol retai taikoma praktikoje, nors jos privalumai IT projektų valdyme yra akivaizdūs.
Lietuvoje šis metodas vadinamas iteraciniu inkrementiniu metodu. „Agile“ siūlo visiškai kitokią filosofiją: projektas skaidomas į trumpus iteracinius etapus, vadinamus „sprintais“, kurių metu sukuriama veikianti sistemos dalis (inkrementas). Užsakovas ir tiekėjas glaudžiai bendradarbiauja viso projekto metu, nuolat derindami poreikius ir prioritetus. Tokiu būdu probleminės situacijos pastebimos iš karto, o projekto pabaigoje, kai visi darbai jau turi būti atlikti.
IT sistemos diegimas dažnai trunka ne vienerius metus. Per tą laiką gali keistis teisės aktai, atsirasti naujos integracijos su kitomis sistemomis, keistis paties užsakovo poreikiai. Visos šios aplinkybės lemia, kad projektą tenka adaptuoti, keisti specifikacijas, grįžti į ankstesnius etapus.
Beje, „Agile“ eliminuoja „sutartinę euforiją“, kai abi šalys po sutarties pasirašymo paprasčiausiai iš laimės „apstingsta“. Čia bendradarbiavimas yra nuolatinis, kas savaitę ar kas dvi. Jei paaiškėja, kad tiekėjo kompetencija nepakankama ar perkančioji organizacija neskiria pakankamai kompetentingo produkto vadovo, rezultatai matomi labai greitai. Tai leidžia priimti sprendimus laiku ir nesukrauti nesusipratimų į vieną didžiulį ginčų šleifą projekto pabaigoje.
„Agile“ nėra tik skambus žodis
Kadangi „Agile“ nėra jokia naujiena, praktikoje turime ir ne vieną šio metodo taikymo pavyzdį. Deja, dabartinė praktika nė iš tolo neatliepia „Agile“ metodo esmės ir matome, kad jis taikomas formaliai, bet ne realiai.
Viena didžiausių problemų – tai nesugebėjimas „Agile“ principų visa apimtimi integruoti į viešųjų pirkimų procesą. Nors sutartyje neretai minima, kad projektas bus vykdomas „Agile“ metodu, sutarties sąlygos ir pirkimo procedūros išlieka būdingos tradicinei „Waterfall“ metodikai. Dėl to projektas formaliai vadinamas „Agile“, tačiau praktiškai jį vykdyti pagal „Agile“ principus tampa neįmanoma.
Norint sėkmingai taikyti „Agile“ metodą, nepakanka sutartyje to vienu sakiniu pabrėžti – visos sutarties sąlygos ir viešojo pirkimo struktūra turi būti paremta „Agile“ metodo esme.
Tradicinis „Waterfall“ modelis kainą dažnai fiksuoja nuo pat pradžių, nepalikdamas erdvės pokyčiams. „Agile“ reikalauja kitokio požiūrio, čia verta taikyti mišraus tipo kainodarą (pvz., mažos apimties sistema fiksuota kaina, tolesni darbai – valandiniu įkainiu) arba fiksuoto įkainio kainodarą, kas leidžia adaptuotis prie kintančių perkančiosios organizacijos poreikių. Tas pats galioja ir terminams: jie gali kisti atsižvelgiant į naujai identifikuotus poreikius ar projekto sudėtingumą.
Sutartyje turi būti numatytas nuolatinis aktyvus šalių bendradarbiavimas, jo vykdymas išskaidytas iš tiesų trumpais etapais (iteracijomis ir inkrementais). Pavyzdžiui, jei numatysime, kad iteracija trunka 4–6 mėnesius vietoj 1–2 savaičių, turėsime tą patį tradicinį „Waterfall“ metodą (tik su „Agile“ prieskoniu).
Jei sutartis nebus pritaikyta „Agile“ principams, liks tik tuščios deklaracijos. Reikia lanksčios kainodaros ir terminų, „inkrementinio“ perdavimo ir atsiskaitymo, veikiančios valdymo struktūros, aiškių vaidmenų ir kompetentingų sprendimų priėmėjų iš abiejų pusių, nuolatinio bendradarbiavimo ir eilės kitų nuostatų.
Ar mokysimės iš klaidų?
Tad „Agile“ metodas jau seniai nebe naujiena pasaulyje. Lietuvoje jis taip pat oficialiai pripažintas, bet realių, sėkmingų ir pagal taisykles įgyvendintų „Agile“ projektų viešajame sektoriuje trūksta. Kol kas dažniau matome bandymus tiesiog prilipdyti „Agile“ etiketę prie tradicinių „Waterfall“ sutarčių. Tačiau, susidūrus su problemomis, viską lemia sutartis, o ne geri norai.
Senus, nebelanksčius standartus laikas pakeisti šiuolaikiškais ir atitinkančiais IT projektų dinamiką. „Agile“ nėra stebuklingas vaistas, tačiau tai – žingsnis link efektyvesnių, greitesnių, skaidresnių ir rezultatu paremtais faktais grįstų sprendimų. Viešieji pirkimai gali tapti inovatyvūs ir sėkmingi, jei tik pasiryšime įdiegti realiai veikiančius „Agile“ principus į jų DNR.
