Ką svarbu žinoti dirbant su globaliais projektais

Lietuvoje įmonių, dirbančių su tarptautiniais projektais, tik daugėja. Tačiau, tai ne tik įvertinimas, bet ir dideli iššūkiai. Marius Guobys, IT įmonės „Cognizant“ DevOps praktikų vadovas, su tokio pobūdžio klientais dirba nuolat. Jis dalinasi, į ką svarbiausia atkreipti dėmesį imantis tokių darbų.
Marius Guobys, IT įmonės „Cognizant“ DevOps praktikų vadovas
Marius Guobys, IT įmonės „Cognizant“ DevOps praktikų vadovas / „Cognizant“ nuotr.

Ruošiantis ir dirbant su didelės apimties IT projektais kyla tikrai nemažai iššūkių. Tai nėra paprastas procesas, kurio metu gali numatyti visus įmanomus scenarijus. Vertinant sudėtingus IT projektus ir jų įgyvendinimo galimybes bei planą, tenka daryti daug prielaidų, numatyti galimas rizikas, pokyčius.

„Gal todėl taip dažnai ir išvystame straipsnių ir pranešimų apie tai, kaip sudėtingi projektai trunka ilgiau nei numatyta, ar jų kaina iškyla dėl neplanuotų pokyčių rinkose, versle, atsiradus naujiems reikalavimams. Įgyvendinant sudėtingus IT projektus reikia įvertinti ne tik organizacinius aspektus, bet ir skirti ypatingai daug dėmesio inžineriniams klausimams, architektūrai ir pan.“, – kalba ekspertas.

 „Cognizant“ nuotr./Marius Guobys, IT įmonės „Cognizant“ DevOps praktikų vadovas
„Cognizant“ nuotr./Marius Guobys, IT įmonės „Cognizant“ DevOps praktikų vadovas

Nuo ko pradėti

IT projektas inžinieriui prasideda nuo reikalavimų surinkimo ir supratimo su kuo ketiname susidurti kurdami produktą. Tai yra itin svarbus pirmasis žingsnis, nes reikia įvertinti daug aspektų pradedant nuo domeno (angl. domain) supratimo, nes yra skirtumas, ar kuriame produktą užtikrinti kritinių procesų veikimui (medicina, aviacija, finansinės institucijos), ar, pavyzdžiui, sistemą, kuri yra skirta priimti maisto užsakymus.

„Cognizant“ šiuo tikslu, kaip prieiti prie šių klausimų sprendimų, turime kelias nusistovėjusias ir patikrintas praktikas. Vienas iš pagrindinių įrankių yra problematikos supratimo ir produkto vystymo vizijos aptarimo sesijos (angl. workshops), kurių metų kartu su kliento atsakingais žmonėmis (verslo, inžinerijos, produkto vystytojų) kartu aptariame einamuoju metu kylančias problemas, kaip mes įsivaizduojame, manome, kad jas galėtume spręsti ir kaip tą sėkmę išmatuosime. Pavyzdžiui, įmonė nori skaitmenizuoti savo užsakymų priėmimo procesą. Tokių gyvų sesijų metu išsiaiškinsime, kokia šiuo metu yra pagrindinė problema, kaip įmonės atstovai įsivaizduoja ką reikėtų atlikti norint išspręsti šią problemą (pritaikyti naujas technologijas, apmokyti personalą, įgalinti DI naudojimą) ir kaip tuos pakeitimus įvertinsime, t.y. neužtenka tik atlikti pakeitimus, bet reikia ir įvertinti, ar tie pokyčiai atnešė naudos. Tai turi būti išmatuojami įverčiai, pavyzdžiui, dokumentų apdorojimo laikas sutrumpėjo 30 minučių ir pan.“, – sako M.Guobys.

Be to, reikia įsigilinti ir į būsimus technologinius reikalavimus (naudojamos technologijos) ir turbūt svarbiausias – kokią gi mes problemą stengiamės išspręsti kurdami šį naują produktą. Kiekviena organizacija turi tikslą, kurį nori pasiekti naujo produkto pagalba – suprasti problematiką, sprendimą ir kaip mes vertinsime ar pasiekėme išsikeltus tikslus ar ne. Iš viso šio kyla bendras supratimas apie verslo tikslą ir siekius.

„Pavyzdžiui, įmonėje „Cognizant“ susidūrėme su kliento iššūkiu (dirbančiu automobilių pramonės srityje visame pasaulyje). Jų iškeltas tikslas yra debesijos sprendimų panaudojimas su jau turimais produktais. t.y. produktų migracija į debesijos sprendimus. Čia susidūrėme pirmiausiai su klausimu – ar norimų pakeitimų diegimas yra tik noras panaudoti debesijos sprendimus? Konkrečiu atveju kliento tikslas naudoti modernias technologijas, kurių negali diegti savo turimuose duomenų centruose ir kurios jau nebeatitinka saugos ir patikimumo reikalavimų.

 „Cognizant“ nuotr./Marius Guobys, IT įmonės „Cognizant“ DevOps praktikų vadovas
„Cognizant“ nuotr./Marius Guobys, IT įmonės „Cognizant“ DevOps praktikų vadovas

Toliau teko spręsti technologinius klausimus – ką konkrečiai turėsime perkelti į debesiją. Egzistuojančius produktus? Ar šie produktai pritaikyti pasirinktai konteinerizacijos technologijai? Ar įmonė turi automatizacijos praktikas, kurios padeda užtikrinti paruošti platformą debesijoje ir ten perkelti produktus. Kaip vyks pats perkėlimas, ar komandos kliento komandose tam pasiruošę. Atsakę į šiuos tik kelis klausimus supratome, jog pirminė kliento paruošta architektūra ir kelias yra netinkami tikslų pasiekimui, kadangi neatitinka siekio perkelti sėkmingai esamus produktus į debesiją. Ir reikia keisti priėjimą prie problematikos sprendimo ir jos pritaikymo. Tuomet nustatėme tikslus kaip įvertinsime ir sėkmingai išsprendėme problemą – produkto naujų versijų išleidimas turėtų paspartėti 20%, saugos defektų kiekis turi sumažėti 50 proc.“, – kalba jis.

Dėl to, visų pirma, pati organizacija turi sau atsakyti, kiek ji yra pajėgi vykdyti pokyčius – kiek turi tinkamų specialistų, kurie galės įsisavinti šias naujas technologijas, kaip greitai svarbu įgyvendinti pokyčius. Jeigu to nepavyks racionaliai įsivertinti, tuomet projekto eigoje gali iškilti papildomų darbų, nenumatytų išlaidų. Dėl to tinkamas visų aplinkybių įvertinimas ir supratimas yra itin svarbus.

„Surinkę reikalavimus, parengus architektūrą, rodos, susidarome vadinamąjį didelį paveikslą (angl. big picture) ir belieka pradėti dirbti. Bet dar ne – turbūt lieka svarbiausias klausimas užsakovui, į kurį reikia atsakyti ir sau – laikas, biudžetas ir žmonių poreikis. Kaip tiksliai įvertinti kiek mums reikės inžinierių, projekto valdytojų ir kitų sričių specialistų norint įgyvendinti šias užduotis? Viskas kyla iš patirties. Į šį vertinimo procesą yra tiesiog būtina įtraukti inžinierius, kurie turi patirties dirbant prie kompleksiškų projektų įgyvendinimo. Tik jų pagalba galima adekvačiai įvertinti pastangas ir laiką, kurį reikės skirti dirbant prie tokio projekto.

Galbūt turėsime nemažai darbų su nauja technologija, reikia įvertinti ir laiką skiriamą įsisavinant naujus įrankius, technologijas ir pan. Inžinierių pagalba įvertiname vadinamas pastangas (angl. effort) norint sukurti vieną ar kitą produkto dalį. Pats vertinimo procesas dažniausiai vyksta skaldant projektą į atskiras dalis ir vertinant kiekvieną dalį atskirai bei vėliau įvertinant visumą. Iš to kyla ir projekto biudžeto vaizdas bei laikas reikalingas įgyvendinti. Bet laikas ir biudžetas tikrai nėra 100% tikslus ir reikia vis tiek galvoti, jog nežinomųjų tikrai bus – tų, kurių galbūt klientas nepateikė arba nepastebėjome iškart. Kalbant apie laiką visada tenka dar ir įvertinti pačios organizacijos lankstumą priimant sprendimus ir įsisavinant technologijas, nes neužtenka tiesiog deklaruoti, jog dabar mes darysime taip, reikia iš tikrųjų ir įgyvendinti pokyčius organizacijos viduje“, – pabrėžia M.Guobys.

Įveikti biurokratiją

„Vienas iš didesnių iššūkių su kuriuo susidūrėme buvo dirbant su projektu aviacijos industrijoje. Tai industrija, kuri yra itin jautri pokyčiams, nėra lanksti ten yra labai daug reguliavimo, taisyklių ir priklausomybių nuo kitų. Dažnai tokiu atveju kompleksiški IT projektai negali būti nei įgyvendinti greit, bei itin sudėtinga tiksliai įvertinti reikiamą biudžetą. Tokiu atveju mūsų tikslas yra parodyti ir įvertinti projektą naudojantis savo turima patirtimi. Surenkame reikalavimus, įvertiname kompleksiškumą, parenkame technologinius ir architektūrinius sprendimus.

Visa tai mums leidžia susidaryti apytikrį laiką ir biudžetą reikalingą tokio produkto įgyvendinimui. Tuomet jau turime ilgą ir kantrų procesą, kurio metu su klientu aptarinėjame tai, ką suprantame apie projekto kompleksiškumą, laiko reikalavimus. Įvertiname visus aspektus, kurie nebuvo paminėti, kaip, pavyzdžiui, integracijos su kitomis sistemomis, sauga, reguliavimas (teisinė bazė), technologijų prieinamumas ir pačios organizacijos pasiruošimas. Tai itin komplikuotas procesas, nes niekas nenori išleisti per daug pinigų, tad čia svarbus balansas tarp lūkesčių ir galimybių. Tuo pačiu klientas gali matyti visą šį procesą kaip nereikalingas išlaidas ir laiko švaistymą. Svarbu įvertinus visus faktorius užsakovui suprasti savo biudžeto galimybes ir funkcionalumą kurį norima įgyvendinti“, – paaiškina ekspertas.

Dirbant su dideliais klientais, kurie turi didelius kiekius žmonių atsakingus už skirtingas sritis, viena dažniausių problemų yra greitis ir sprendimų priėmimo biurokratija. Anot eksperto, atrodytų, juk biurokratija yra labai valstybinėm institucijom taikomas terminas, bet ne tik.

„Proceso metu tenka matyti ir daug vidinės politikos, biurokratijos, kai nenorima prisiimti atsakomybės už tam tikrų klausimų sprendimą. Mūsų tikslas šiuo atveju yra ne tik sėkmingai įgyvendinti projektą sėkmingai, bet ir edukuoti klientą parodant kur kyla organizacinės problemos, kaip jas galima spręsti kartu, augti bei tobulėti kartu. Toks edukavimo ir konsultavimo procesas iš pradžių būna itin sunkus, nes kyla nemažai frustracijų, bet svarbu, jog užsakovas patikėtų tavo idėjomis ir pasiūlymais, o tai dažniausiai ir pavyksta“, – sako M.Guobys.

Pranešti klaidą

Sėkmingai išsiųsta

Dėkojame už praneštą klaidą
Reklama
Pasisemti ilgaamžiškumo – į SPA VILNIUS
Akiratyje – žiniasklaida: ką veiks žurnalistai, kai tekstus rašys „Chat GPT“?
Reklama
Išmanesnis apšvietimas namuose su JUNG DALI-2
Reklama
„Assorti“ asortimento vadovė G.Azguridienė: ieškantiems, kuo nustebinti Kalėdoms, turime ir dovanų, ir idėjų