Kartais perkame jau pagamintus produktus, kartais ieškome mums dedikuoto sprendimo, o kartais tereikia integruoti kelis pokyčius į jau esančius sprendimus. Bet kuriuo atveju, patikimumo kriterijai visuomet išlieka. Tai kaipgi tuos pačius pasirinkimo kriterijus pritaikyti renkantis IT įmonę ir kaip išsigryninti klausimus, kurie pasakys, kad pasirinkimas teisingas?
Nuo ko pradėti
Kaip teigia Lina Bisikirskienė, „Cognizant“ verslo analitikų praktikos vadovė, pirmas žingsnis yra atsakyti sau į klausimą, ar gerai žinome, kokio produkto (IT sistemos) mums reikia, ar žinome, ko iš jo tikisi vidiniai žmonės, klientai, rašoma pranešime spaudai.
Jei atsakymo neturite, galite bandyti patys pasidaryti namų darbus ar ieškoti IT kompanijos, kuri teikia ir konsultavimo paslaugas bei gali sustyguoti jūsų produkto viziją, sėkmės metrikas ir tik tuomet nerti į funkcionalumo įgyvendinimą.
„Produktyvius pirminius susitikimus su IT įmone metu nulemia keletas faktorių. Svarbu, kad susitikimas ar susitikimai vyktų gyvai arba nuotoliu, bet ne elektroniniu paštu. IT įmonės atstovai turėtų būti atlikę savo namų darbus ir įsigilinę į medžiagą, kurią jūs jau buvote pateikę. Susitikimo formatas ir dienotvarkė turi būti aiškūs, turintys struktūrą bei konkretų siekiamą rezultatą.
Darbas prasideda nuo diskusijų apie bendresnę informaciją, tokią kaip problemos identifikavimas, siekiamo tikslo apsibrėžimas, konkurentų analizė, sėkmės metrikų išgryninimas. Skirtingos įmonės gali turėti savo darbo principus ir metodikas, tačiau egzistuoja ir tam tikros blogosios praktikos. Keletas pavyzdžių, kai reiktų sunerimti susitikimo metu – IT atstovai primeta savo siūlomus sprendimus, neįsigilindami į jūsų situaciją arba neatsakydami į jūsų klausimus, o galbūt naudodami daug trumpinių, kurie jums nieko nesako, jus tik supainioja. Jei pokalbis yra labai abstraktus ir susitikimo pabaigoje nėra pasiekta aiškių rezultatų, tuomet sunku tikėtis konstruktyvaus bendradarbiavimo. O kartais tenka pakalbinti ir susitikti su keliomis IT kompanijomis, kad pavyktų suprasti tiek darbo principų skirtumus, tiek sau atsakyti į klausimą, su kuriais toliau norėtumėte bendradarbiauti“, – dalijasi L. Bisikirskienė.
Antras žingsnis, pasak jos, yra nėrimas į daugiau detalių. Jei IT kompanija jums patiko ir norėtumėte diskusijas pratęsti, bet nežinote, nuo ko pradėti arba gąsdina įsipareigojimai ilgam laikui, o galbūt neaiški darbo apimtis ar neaiškus rezultatas, tai nėra jūsų bėda.
„Mes taikome susitarimo metodą, kai pirmiausiai IT komanda susėda su klientu ir sutaria, kokie yra suinteresuotų šalių lūkesčiai (ar pateikimo į rinka greitis, ar platus funkcionalumo pasirinkimas ir t.t.) ir kas bus, jei lūkesčiai nebus patenkinami (ar komanda investuoja į pilnai išdirbtą galutinį rezultatą, ar mes koreguojame lūkesčius ir atitinkamai juos išdėliojame laike). Tuomet komanda pasilieka lankstumo, kokius darbo principus pritaikys projekte, kad galėtų išpildyti keliamus lūkesčius. Tai tampa pastoviu procesu ir susitarimas yra pritaikytas prie konkrečių verslo poreikių“, – pabrėžia pašnekovė.
IT produktai, anot ekspertės, yra labai skirtingi, bet bendri jų vystymo principai egzistuoja ir tai gali jums padėt. Čia puikiai tinka mintis „Skaldyk ir valdyk“ gerąja prasme, nes jei turite sudėtingą metų ar dviejų projektą (o gal ir ilgesnį), skaidykite jį į smulkesnes dalis.
„Tiek jums, tiek IT kompanijai bus lengviau įsisavinti dalykinės srities informaciją, išskaidyti darbus ir susiderinti su jumis kokio rezultato tikimasi. Būtent šiame žingsnyje pasimato bendradarbiavimo ypatumai. Jei IT įmonė įsigilina į jūsų sprendžiamą problemą, pasiūlo detalų taktinį darbų planą artimiausiam laikotarpiui (pavyzdžiui, 3 ar 6 mėnesiams) bei strateginį darbų planą visam projekto laikotarpiui, tai pirmi svarbūs žingsniai sėkmingo bendradarbiavimo link. Jūsų įsitraukimas derinimo procese yra kritinis, jei neturite laiko, resursų konsultavimui ar aiškiai suformuluotos problemos, gal IT darbus reiktų atidėti vėlesniam laikotarpiui. Norint pastebėti ar darbai vyksta ne pagal planą, keletas pagrindinių įžvalgų būtų: darbų planas nepritaikytas jums, t.y. taikomas šabloninis; neišgryninamas siekiamas rezultatas bei sėkmės metrikos; IT įmonė deklaruoja, kad jų ekspertai išmano visas industrines sritis bei jų procesus; planuojami darbai abstraktūs, teigiama, kad eigoje bus matyt, kurią kryptį reiks pasirinkti. Neatsakytų klausimų bei prielaidų turėjimas projekto pradžioje nėra blogai, bet juos reikia išsigryninti iki jo pradžios. Tai gali būti ir iki sutarties pasirašymo, jei klausimai nesunkiasvoriai. Vis dėlto, kartais rekomenduojame trumpos apimties sutarties pasirašymą analizės (angl. discovery) etapui, kurio metu atsakomi tiek verslo klausimai, tiek technologinės galimybės ar apribojimai, išgvildenamos prielaidos. Tai ypač svarbu, kai norime atnaujinti esamas sistemas, t.y. modernizuoti jas“, – kalba pašnekovė.
O IT įmonės lankstumas parodo tiek jos gebėjimą prisitaikyti prie kliento poreikių, tiek ir gebėjimą pagrįsti savo siūlomos sprendimus nepasislepiant po ilgalaikiais kontraktais.
Kas nulemia projekto sėkmę
Ji pabrėžia, jog galvoti apie prielaidas ir rizikas yra svarbu ne tik projekto pradžioje, bet ir viso projekto metu. Dažnai atrodo, kad jos gali būti susijusios su resursais, įgyvendinimo datomis, bet kartais pamirštame riziką, ar tiksliai žinome kokio produkto reikia mūsų vidiniams vartotojams ar mūsų klientams.
Nepriklausomai nuo rizikų, jomis būtina pasidalinti ir su vykdytoju IT kompanija). Jie iš savo patirties didžiąją dalį klausimų padės detalizuoti, pasiruošt galimiems scenarijams (rizikų atveju) ar patikrinti duotas prielaidas. Dalintis būtina net ir tuo atveju, jei viena iš rizikų yra IT kompanijos nepatikimumas. Išskaidžius prielaidas į konkrečius klausimus, daugelį atsakymų galima gauti dar prieš sutarties pasirašymą.
„Mūsų klientai dažnai turi jau egzistuojančias sistemas ir siekia jų atnaujinimo. Tai sudėtingi kompleksiniai projektai, kurie užtrunka metus ar du, įtraukia daug suinteresuotų šalių. Dažnai tokiais atvejais pirkti tinkamų esamų sprendimų nėra, tuomet jie kviečiasi IT kompaniją, kad padėtume įgyvendinti pokyčius. Vienas iš pavyzdžių galėtų būti Jungtinių Valstijų bankas, kuris siekė atnaujinti vartotojų investicinių portfelių valdymą bei jį modernizuoti. Intensyvaus bendradarbiavimo pagalba pavyko išsiaiškinti esamą situaciją, identifikuoti skaudamas vietas, kurias reikia optimizuoti ir tik tuomet buvo parinktas ir įgyvendintas technologinis sprendimas. „Agile“ darbo principus yra sunku įgyvendinti sunkiasvorėse organizacijose, nes daug apribojimų, daug suinteresuotų šalių, daug judančių dalių. Manau, kad šioje situacijoje sėkmę lėmė betarpiškas bendradarbiavimas, maksimalus įsigilinimas į kliento situaciją, darbų vykdymas žingsnis po žingsnio pateikiant rezultatus bei reguliarus projekto pulso sekimas“, – išskiria „Cognizant“ verslo analitikų praktikos vadovė.
Projekto sėkmė, anot jos, yra labai unikalus projekto aspektas ir jų vienodų niekada nebūna. Įprasta galvoti apie laiką, biudžetą ir resursus. Vis dėlto, dauguma esame buvę situacijose, kai vienas ar du iš šių parametrų nukrypsta, tačiau projekto tikslai vis tiek būna pasiekti. Tai nereiškia, kad galime švaistyti pinigus ar laiką, tai reiškia, kad pokyčių visada būna. Jei juos tinkamai įsivertiname ir išlaikome aukštą skaidrumo lygmenį, tuomet tai nesukelia nepasitenkinimo. Priešingai, tai dar labiau motyvuoja siekti galutinio rezultato. Svarbiausia, kad visos suinteresuotos šalys sėkmę suprastų vienodai, o atsiradus iššūkiams, norėtų ir kartu ieškotų sprendimų.
„Organizacijos viduje esame nutarę, kad komandos susitaria su klientais, kokios metrikos yra svarbios iš verslo pusės ir tai užrašome verslo kalba (pavyzdžiui, pagaminta verslo funkcija tampa prieinama vartotojui per 5 dienas). Kontrolinio sąrašo (angl. checklist) turėjimas nepasiteisina, dėl to ėmėme ieškoti būdų, kokias kitas geriausias praktikas galime pasitelkti. Kas nutikdavo su kontroliniais sąrašais – komandos lanksčiau interpretuodavo, pritempdavo geresnius rezultatus. Visi yra žmonės, bet to laiku nepastebėjus, tai gali tapti ir savęs apgaudinėjimu, tad kol tai nepadarė žalos, ėmėme savęs klausti, kokius kitus būdus galima atrasti? Visos praktikos taikomos dėl esminės priežasties – kad produkto pakeitimai nesugadintų vartotojo patirties“, – pabrėžia ekspertė.
Kaip apčiuopti komandos efektyvumą
Apčiuopti komandos efektyvumą yra labai sunku. Jei komanda yra tvirta, ji darydama darbų apimties vertinimą bei planavimą pradės pati jausti pulsą ir darbų kiekis įvykdomas per dvi savaites nusistovės (Scrum metodikos rekomendacija yra turėti dviejų savaičių darbo intervalus).
„Jei komandai neaišku, ką daryti arba ji netiki tuo, ką daro, gali atsirasti darbai, kurie vis nesibaigia, jie vis keliauja iš vienos savaitės į kitą. Scrum metodika, kurią taikome savo projektuose, padeda darbus smulkinti, tada sunku pasislėpti po darbu, kuris trunka mėnesį ar tris. Kartais net ir tokiu atveju, komanda gali gražiai sudėlioti darbus dviem savaitėms ir projekto parametrai atrodys tinkami. Čia reikia neapsigauti, jei komanda reguliariai negali parodyti kokie darbai buvo nuveikti per dvi savaites, tai yra didelė rizika“, – kalba ji.
Dar vienas svarbus stiprios komandos aspektas, ekspertės teigimu, apie esamas problemas praneša užsakovui pirma ir tuo pačiu pasiūlys galimus sprendimo variantus. Jei rizikos ar bėdos pasimato tik paklausus ar netikėtai patikrinus, tai taip pat didelė rizika, nes nei pasitikėjimo, nei bendradarbiavimo šioje situacijoje nėra. Ne komandos darbo rodikliai rodo jos sėkmę, bet sukurti rezultatai.
Jos nuomone, kad dauguma esame girdėję situacijų, kai mokama už sukurto kodo eilutes ar sugeneruotų puslapių kiekį ataskaitoje. Tiek užsakovų žinios, tiek ir IT įmonių branda yra stipriai pasikeitusi, todėl ir sukurti rezultatai turi kurti vertę, bet neimituoti darbą.
„O įvertinti ir apskaičiuoti bet kurio projekto atsiperkamumą yra kompleksinis uždavinys, nes į formulę atkeliauja ilgas sąrašas kintamųjų. Vis dėlto, net ir čia galima turėti sąrašą klausimų, į kuriuos atsakius pasirinkimas patampa lengvesniu. Pagrindinis yra – dėl kokių priežasčių ieškome naujų sprendimų, naujos sistemos? Jei atsakymas yra tik dėl to, kad esama paseno arba visi konkurentai turi jau tokią, tai neteisingas kelias. Jei atsakymą performuluojame ir norime pasakyti, kad esama sistema veikia ne optimaliai ir norime kurdami naują optimizuoti procesus, tai jau būtų kelias į sėkmę. Visų pirma, turime suprasti, ką norime pagerinti, o tik tada ieškoti technologinių sprendimų. Analogiškai ir su sistemomis, kurias jau turi konkurentai. Tai ypač pasijautė pandemijos metu, kai visi skubėjo persikelti į elektroninę erdvę. Analizuoti konkurentus labai svarbu, tačiau renkantis ar kuriant IT sistemas, taip pat itin svarbu suprasti kaip jos atitiks jūsų procesus, jūsų klientų norus. Kartais kas tinka visiems, netinka niekam. Tad skaičiuojant projekto atsiperkamumą, reikia būti budriems, tam, kad resursus (laiką, pinigus) išleistume norimam rezultatui pasiekti“, – atkreipia dėmesį L. Bisikirskienė.