Įvadas
AK: Konnichiwa. Sveiki atvykę į AI Automation Dojo. Laidoje, kurioje žvelgiame į šiuolaikinį projektų valdymą ir svarstome, ar ginklų diagramą nereikėtų pakeisti Ouija lenta. Šiandien sparnuotai neriame į klastingus dirbtinio intelekto projektų įgyvendinimo vandenis. Žinote, kai projekto planas yra daugiau stiprus pasiūlymas, o rezultatai kartais įgyja savo pačių protą.
Į pagalbą pasikvietėme ypatingą svečią – tikrą pristatymo vadybininką, kuris žvelgė į dirbtinio intelekto bedugnę ir liko gyvas. Kalbėsime apie projektus, kurių reikalavimai yra judantis taikinys. Pagrindinis komponentas – dirbtinio intelekto modelis – iš esmės yra juoda dėžė su užrašu „čia būk drakonas”, o sėkmė dažnai apibrėžiama kaip „gerai, kad šį kartą jis neuždegė serverio”.
Esu jūsų laidos vedėjas Andrzejus Kinastowskis, vienas iš ” Office Samurai ” įkūrėjų, kuris tiki, kad svarbiausia projekto plano dalis yra aiškiai pažymėtas avarinis išėjimas. Jei kada nors bandėte paaiškinti pasitikėjimo balą kambariui, pilnam vadovų, kurie tiesiog nori paprasto atsakymo „taip” arba „ne”, šis epizodas gali būti jūsų terapijos seansas. O dabar griebkite savo mėgstamą kataną arba labai išsamų rizikos registrą ir imkimės darbo.
Šiandien prie mūsų prisijungė „Office Samurai” pristatymo vadybininkė Dagmara Sysuła. Ji prisijungė prie mūsų prieš ketverius metus ir tapo žmogumi, kuris iš esmės rūpinasi visu mūsų pristatymu, o man lieka laiko užsiimti tokiais dalykais kaip podcast’ai. Dagmara, sveiki atvykę į podkastą.
DS: Sveiki, Andžej. Ačiū, kad mane čia pakvietėte.
AK: Kalbėsime apie dirbtinio intelekto projektus. Sakykite, kodėl būtent su jumis kalbamės apie dirbtinio intelekto projektus?
DS: Kadangi bandome įgyvendinti dirbtinio intelekto projektus, manau, kad dabar labai svarbu žinoti, kaip tai daryti arba tiesiog bandyti tai daryti tam tikru būdu, ir žinoti, kodėl tai gali būti sudėtinga arba kodėl tai gali baigtis sėkmingai arba ne, ir koks būdas yra geriausias dirbtinio intelekto projektams įgyvendinti. Manau, kad dirbtinis intelektas, iš tikrųjų podkastas yra to įrodymas. Šiuo metu tai labai aktuali tema ir visi nori prisiliesti prie šios technologijos.
Projektų metodika: mišraus požiūrio būtinybė
DS: Kažkaip, bet kartais dar nežinome, kaip tai tinkamai padaryti. Bandome tai daryti taip, kaip jau žinome, su mums žinomais metodais, su mums žinoma metodika. Tačiau tai nėra taip paprasta, kaip manėme anksčiau.
AK: Kuo tai skiriasi, nes man taip pat atrodo, kad šie projektai bent jau šiuo metu gerokai skiriasi nuo to, ką mes jau darome? Kuo arba kodėl jie labai skiriasi nuo, tarkime, klasikinio RPA projekto?
DS: Sakykime, kad apskritai IT srityje dažniausiai turime du projektų teikimo ir valdymo būdus. Tai yra krioklio būdas, kai viskas yra susisteminta, kai yra numatyti etapai, kai galima numatyti, koks bus kitas žingsnis, o RPA neabejotinai yra viena iš krioklio dalių. Kodėl? Todėl, kad tai paprastai yra trumpas projektas, ne ilgesnis kaip 300 valandų, o kartais daug kartų jis būna trumpesnis. Ir jūs turite labai griežtus etapus: analizė, kūrimas, testavimas, diegimas ir priežiūra.
Agile sistemoje viskas kitaip, nes dirbate sprintuose, kažką atrandate, tikrinate, tobulinate ir einate tokiais ciklais. Tačiau tai taip pat yra kažkiek nuspėjama, nes jūs teikiate tam tikrą projektą. Dirbtinio intelekto srityje jums reikia šiek tiek daugiau dėmesio skirti eksperimentams, todėl „agile” tikrai yra geriausias būdas.
Tačiau vis tiek turite kažkaip tvarkytis su biudžetu, pavyzdžiui, su suinteresuotosiomis šalimis, rėmėjais. Todėl taip pat turite atsižvelgti į krioklį. Todėl reikia šiek tiek maišyti ir tiesiog rasti naują metodiką. Tikriausiai kol kas ją vadiname hibridine, nes, pavyzdžiui, eksperimentuojame. Eksperimentus naudojame vikriai, ir iš tikrųjų čia visiškai puikiai tinka vikraus Kanban dalis, nes Kanban dažniausiai naudojamas techninės priežiūros projektuose. Vertinimas atliekamas prieš diegimą, o dirbtiniam intelektui, manau, tai labai svarbus momentas, kad įsitikintume, jog tai, ką parengėme, yra paruošta įgyvendinti.
Žinoma, jūs taip pat žinote, kad tai yra didžiulis krioklio projektas, tik mažais gabalėliais. Iš „Office Samurai” perspektyvos norėčiau pasakyti, kad prieš kelerius metus visuose savo projektuose, kuriuos teikiame klientams, įdiegėme retrospektyvą.
Lemiamas retrospektyvos vaidmuo dirbtinio intelekto projektuose
DS: Jūsų projektas bus baigtas retrospektyva, o retrospektyvoje labai, labai svarbu, ir man labai patinka ši judrios metodologijos dalis – mes sėdime kartu, pristatymo komanda (nes turime analizės analitikus, kūrėjus, vadovus, architektus, visus, kurie prisilietė prie šio projekto). Turime erdvę, kurioje galime labai sąžiningai pasikalbėti apie viską, kas nutiko, apie gerus dalykus, blogus dalykus, ką jau išmokome, ką padarėme ne taip šio projekto metu ir ką, ir labai, labai svarbu, ką aš labai mėgstu, yra veiksmai. Ką galime padaryti geriau ar kitaip kito projekto metu arba ko jau išmokome ir ką galime įgyvendinti ateityje. Manau, kad dirbtinio intelekto projektuose labai svarbu, kad pasibaigus projektui būtų atlikta tam tikra retrospektyva ir tiesiog sužinota, ko išmokome, nes dažniausiai visi dirbtinio intelekto projektai gali būti eksperimentiniai arba tiesiog atrandantys kažką naujo.
AK: Manau, kad retrospektyva – tai dalykas, kurį įvedus į mūsų organizaciją, kai kuriems žmonėms iš pradžių buvo šiek tiek sunku. Projektuose, kuriuose viskas vyko gal kiek karštligiškiau, kai kas nors nepavyko, labai svarbu tai daryti, nes kitaip nepasimokysime iš tų klaidų ar galbūt kilusių problemų. Kalbant apie dirbtinio intelekto projektus, kadangi jie yra kur kas labiau nauji ir mažiau nuspėjami, dėl to tos santraukos, apibendrinimai yra labai svarbūs.
DS: Taip pat svarbu padalyti projektą į mažesnes dalis ir po šio nedidelio pirmojo ar antrojo rato padaryti šį retro. Tai kartais sunku padaryti dirbtinio intelekto projektuose, nes tie, kaip minėjote, nėra nuspėjami. Kartais galvojame, kad turime tam tikrą planą, bet jis neveikia arba jis keičiasi, arba keičiasi technologijos, ir mums reikia keisti projekto teikimo būdą. Štai kodėl taip pat svarbu turėti šią „pit stop” stotelę ir suteikti rėmėjui tam tikrą grįžtamąjį ryšį. Kontrolinis taškas, retrospektyva, puikiai tinka dirbtinio intelekto projektams.
AK: Ypač tada, kai viskas vyksta ne taip, kaip tikėjomės. Turime keletą nesenų projektų, kuriuos pradėjome gana seniai, pavyzdžių. Kad ir kaip būtų skaudu, kartais turime sustoti ir paklausti savęs: gerai, gal tuo metu, kai pradėjome, buvo teisingas pasirinkimas naudoti šią technologiją. Bet kol kas turime kitą. Galbūt mums iš tiesų reikia šiek tiek persitvarkyti. Galbūt mums reikia žengti žingsnį atgal. Nes dirbtinio intelekto technologijos, ir ne tik „Gen AI”, tos dirbtinio intelekto technologijos, kurias taip dažnai naudojame, pavyzdžiui, „UiPath” dokumentų supratimas arba komunikacijos gavyba, taip pat vystosi labai sparčiai. Manau, kad visiškai teisinga, jog reikia ne tik pabaigoje atlikti retrospektyvą, bet ir projekto metu daryti tuos sustojimus ir pagalvoti, gerai, ar teisingai elgiamės.
DS: Manau, kad tai labai svarbu. Poreikis turėti retro pirmiausia kyla iš mūsų kūrėjų. Man tai yra tarsi kultūros dalis, kuriai stengiausi vadovauti, tai yra visiškai fantastiška, nes jie tiesiog supranta, ko reikia projektui, ir jie supranta projekto eigą. Tikrai nuostabu, kad tai ateina iš komandos.
Metodikų derinimas: krioklio būtinybė rėmėjams
AK: Minėjote Kanban, kuris yra labai paprastas įrankis. Paminėjote retrospektyvas. Ką dar? Ar yra kitų įrankių ar metodikos dalių, kurios, jūsų nuomone, labai padeda dirbtinio intelekto projektams?
DS: Anksčiau minėjau apie krioklį ir manau, kad jį būtinai turime įtraukti, nes turime kažkaip bendrauti su rėmėjais. Žmonėmis, kurie nesupranta dirbtinio intelekto projekto arba tiesiog technologijos, nes ji sudėtinga. Reikia turėti labai didelį techninį supratimą, kad žinotumėte, kodėl tai vyksta.
Tačiau rėmėjas turi poreikį organizacijoje vykdyti dirbtinio intelekto projektus. Tai tikrai yra tiksluose. Beveik visur jie turi biudžetą ir tam tikrus orientyrus. Jie taip pat turi pranešti apie tai kokiam nors valdymo komitetui savo vadovams, direktoriams, kaip vyksta projektas. Štai kodėl mums čia taip pat reikia krioklio, kad būtume tikri, jog nepanaudojome viso biudžeto.
AK: Gali būti manoma, kad tai trukdo, bet paprastai klientai neturi neriboto biudžeto ir neriboto laiko. Mums reikia šio krioklio kelio, kad galėtume bendrauti su suinteresuotosiomis šalimis ir atlikti savidiagnostiką. Kur mes esame? Ar einame tokiu greičiu, kokiu norėjome? Ar norime pakeisti kryptį? Ar norime pakeisti technologiją? Ar esame pakeliui, kad ką nors pasiektume?
dirbtinio intelekto projektai yra ilgalaikė priežiūra, o ne trumpalaikiai produktai
DS: Kalbant apie biudžeto sudarymą, taip pat svarbu, kad tai galbūt labai svarbu rėmėjams. Iš to, ką mes matome, dirbtinio intelekto projektai nėra kažkas, kas yra tiesioginis produktas, kurį turėsite. Tai ilgas priežiūros procesas. Nusprendę vykdyti dirbtinio intelekto projektą arba tiesiog dirbtinio intelekto priemonę ar sprendimą, turite žinoti, kad galbūt po pusmečio technologijos taip pasikeis, kad reikės ką nors keisti šiame projekte.
Modeliai nuolat mokosi. Reikia kažkaip tai palaikyti. Tai nėra kažkas tokio, kad padedate pinigus ant stalo ir po trijų, šešių, septynių mėnesių turite produktą. Šiuo metu pripažįstame tris ar keturis pagrindinius dirbtinio intelekto projektus, kuriuos turime rinkoje. Pirmasis paprastai yra POC arba tiesiog eksperimentiniai projektai. Norime ką nors išbandyti.
Vėliau turėsime didžiausius projektus, tai yra diegimo projektas. Trečiasis, kurį šiandien matau, yra jau įsigytas dirbtinio intelekto įrankis, pavyzdžiui, „Copilot”, ir įdiegtas mūsų komandose. Tačiau visada yra kaip ir su bet kuria kita priemone ar programa – jūs ją perkate, bet turite žinoti, kaip ja naudotis. Kai galvojame apie „Copilot” arba tiesiog apie rinkoje esančius įrankius, turime žinoti, kad reikia įsigyti ir žinių arba tiesiog mokymų, kurie žmonėms parodytų, kaip tais įrankiais naudotis.
AK: Įdiegimas – tai ne tik licencijų pirkimas ir įdiegimas į žmonių kompiuterius, tiesa? Jie turi žinoti, kaip ja naudotis.
Ketvirtasis projekto tipas: dirbtinio intelekto strategija
AK: Kalbėjote apie trijų rūšių projektus. Koks yra ketvirtasis?
DS: Galvoju apie strategiją. Daug įmonių dabar galvoja apie dirbtinio intelekto strategiją. Sakyčiau, tai ketvirtoji, kurią šiuo metu matau. Labai svarbu žinoti, ką norime įgyvendinti, kokias priemones ir su kokiais ištekliais ketiname dirbti. Nepaprastai svarbu nevykdyti projekto neturint visos strategijos ir nekeičiant kultūros, nekeičiant mąstymo ir organizacijos.
AK: Bet tai yra kažkas, ko mes vėlgi mokomės iš klaidų, kurias daug įmonių padarė su RPA. Visus šiuos dalykus reikia daryti lygiagrečiai. Turėtų veikti lygiagrečiai, nes sukūrus strategiją reikia turėti ir tam tikrų žinių, kas įmanoma mūsų organizacijoje. Be galo svarbu turėti strategiją, bet ne pirmiausia pradėti kurti strategiją.
DS: Taip. Būtent.
AK: Arba turėsite sumokėti daug pinigų kokiai nors konsultacinei įmonei, kad ji jums ją parengtų. Ir, beje, pusę jos jie tikriausiai sukurs naudodami dirbtinį intelektą. Dagmara, žinau, kad esate sugalvojusi projekto valdymo tiesų ar taisyklių rinkinį. Papasakokite, labai noriu išgirsti, kokios, jūsų manymu, jos galėtų būti.
10 auksinių dirbtinio intelekto projektų valdymo taisyklių
DS: Pirmiausia reikia valdyti talentus. Reikia žinoti, kokius gebėjimus ir išteklius turite. Pirmiausia reikia suburti komandą. Antra, taip pat apmokyti tuos žmones.
AK: Bet tai taip pat susiję su šiomis technologijomis. Tai itin sudėtingos technologijos, tačiau priemonės, leidžiančios jomis naudotis, nėra tokios sudėtingos, tiesa?
DS: Teisingai. Daug kartų reikia labai gero analitiko. Įėjimo į rinką barjeras nebėra toks, kad reikia būti labai geru matematiku, statistiku ir pan. Jūs galite būti tikrai geru galios naudotoju ir be tokių žinių. Štai kodėl verslo analitikai puikiai tinka pradėti dirbti su dirbtiniu intelektu.
DS: Jei norėčiau pereiti prie antrosios taisyklės, tai bandyti surasti kokių nors dirbtinio intelekto čempionų ir parodyti juos mūsų aplinkoje.
Kita taisyklė, manau, ypač svarbi vadovams, – valdyti rėmėjų lūkesčius. Parodyti jiems, kad tai nėra labai tiesus, paprastas kelias. Jei norime turėti dirbtinio intelekto sprendimą, turime rizikuoti.
AK: Šie projektai yra savotiški moksliniai tyrimai ir taikomoji veikla, dėl kurių nesate tikri, ar jie bus vykdomi, nes šios technologijos yra labai šviežios. Mes tikrai nežinome. Galime manyti, kad kažkas veiks, bet gali būti netikėtumų.
DS: Ketvirtoji – mokymasis. Turime dėti daug pastangų, kad mokytumėmės patys ir mokytume savo komandas. Manau, kad tai labai svarbi dalis, kurios šiuo metu mūsų organizacijoje tikrai reikia – tiesiog mokytis.
AK: Mokytis, dalytis žiniomis ir stebėti, kas vyksta. Dabar, kai technologijos taip sparčiai keičiasi, tai, ką žinai šiandien, rytoj gali būti pasenę.
DS: Turime būti sąmoningi ir turėti šių žinių.
AK: Turime priimti pagrįstą sprendimą.
DS: Dar vienas dalykas – prieš pradėdami vykdyti dirbtinio intelekto projektą, turime turėti aiškius duomenis. Jei jūsų duomenyse yra netvarkos, nestruktūrizuotų duomenų, daug sunkiau tinkamai apmokyti modelį ir vėliau gauti tinkamus atsakymus.
AK: Gen AI geriau tvarkosi su nešvariais duomenimis nei, tarkime, mašininis mokymasis, tačiau tai vis tiek yra didelė problema ir turime sugebėti ją valdyti. Niekada neturėsime 100 proc. švarių duomenų, bet turime to siekti.
DS: Labai svarbu tinkamai prižiūrėti modelius. Tai kitas punktas – priežiūra. Galiausiai dirbtinio intelekto projektas nebaigiamas kaip vienas paprastas produktas. Jis visada bus palaikomas.
AK: Ypač su Gen AI technologijomis atlikti bandymus yra gana sunku, nes gaunami nedeterministiniai rezultatai. Reikia turėti būdą, kaip ją nuodugniai išbandyti, kad įsitikintumėte, jog laikui bėgant ji nepablogėja.
DS: Tikrai testavimas yra tai, kas skiria dirbtinio intelekto projektus nuo kitų rinkoje esančių projektų, pavyzdžiui, IT projektų, RPA projektų ar kitų. Manau, kad visuose šiuose dirbtinio intelekto projektuose turime būti tikri, kad tai yra etiška, kad mūsų organizacijoje komunikacija yra skaidri. Turime būti tikri, kad informuojame, ką įrankis mums duos, kaip turėtume su juo dirbti, ir turime labai aiškiai apie tai pranešti organizacijai, kad žmonės jaustųsi saugūs.
DS: Grįžtant prie šių klausimų, galvojau apie tam tikrus matavimus ir KPI. Visada turime būti tikri, kaip įrodyti, kad kažkas vyksta gerai ar blogai, taip pat turime žinoti, kaip išmatuoti dirbtinio intelekto poveikį mūsų aplinkai.
AK: Turite galvoti apie rodiklius, kurie leistų tai padaryti.
DS: Manau, kad bendravimas ir mąstymas apie kultūros keitimą bei atvirumą mūsų organizacijoje taip pat yra labai svarbūs. Taip pat lūkesčių valdymas, nes kartais jie būna labai dideli.
AK: Lūkesčiai gali būti labai dideli. Žmonės eina į konferencijas ir klausosi konsultantų, kurie iš esmės jiems parduoda nerealius reikalavimus. Reikia laikytis saiko, nežadėti to, ko negalėsite įvykdyti, nes tai gali reikšti jūsų dirbtinio intelekto programos ir dirbtinio intelekto strategijos pabaigą.
DS: Būtent. Paskutinis punktas – būti atviram pokyčiams. Technologijos keičiasi labai, labai, labai greitai. Po pusmečio jie gali išmesti ją į šiukšlių dėžę, nes technologiją jau atrado kokia nors kita bendrovė ir ją galima nusipirkti tiesiog rinkoje, nereikia jos kurti patiems.
Išvada
AK: Tai buvo Dagmaros 10 auksinių dirbtinio intelekto projektų valdymo taisyklių. Manau, kad tai būtų puikus straipsnis mūsų tinklalapio žinių skilčiai.
DS: Galime jį sekti.
AK: Dagmara Sysuła, labai ačiū, kad prisijungėte prie šio podkasto epizodo ir pasidalijote mintimis bei patirtimi apie dirbtinio intelekto projektus.
DS: Man neramu, kad po kelių mėnesių visas šias taisykles taip pat galėsime išmesti į šiukšlių dėžę, nes kažkas pasikeis. Bet mes esame tam atviri ir laukiame geros ateities.
AK: Tai yra šio epizodo pristatymas. Tikėkimės, kad jis atvyko laiku, neviršijo biudžeto ir pakeliui nesukėlė jokių keistų naujų haliucinacijų. Dėkojame, kad šį kibirą informacijos atsisiuntėte į savo smegenis. Didelis ačiū mūsų svečiui Dagmarai Sysulai, kovų užgrūdintai pristatymo vadybininkei, kuri mus vedė per chaosą, nepametusi nė vieno „Jira” bilieto. Ir, žinoma, Annai Cubal, mūsų pačių pristatymo meistrei, kuri rengia šią laidą iš legendinės „Wodzu Beats Studio”, mūsų pačių kūrimo aplinkos. Iki kito karto, tegul jūsų duomenys būna švarūs, o suinteresuotosios šalys – protingos. Matau, kad ne.
