Povzetek vsebine
Po dovolj implementacijah opažam, da največje ovire skoraj nikoli ne prihajajo iz same tehnologije. Model, API-ji, integracije, infrastruktura — to so inženirski problemi, in inženirski problemi se rešijo, ker jih nekdo prevzame in sistematično reši. Kar dejansko odloča o usodi…
- Nekdo mora dejansko prevzeti odgovornost
- Primer uporabe mora biti resničen, ne udoben
- Dvom se pojavi, preden se pojavi navdušenje
- Prvi MVP, ki dejansko deluje
- Odkritja, ki jih noben demo posnetek ne pokaže
- Lastništvo se začne premikati
- Go-live redko poteka dramatično
- Petminutni sestanek
- Trenutek, ko se zahteve spremenijo
Po dovolj implementacijah opažam, da največje ovire skoraj nikoli ne prihajajo iz same tehnologije. Model, API-ji, integracije, infrastruktura — to so inženirski problemi, in inženirski problemi se rešijo, ker jih nekdo prevzame in sistematično reši. Kar dejansko odloča o usodi projekta, je kratko zaporedje organizacijskih trenutkov, ki nimajo nobene zveze s prompti ali arhitekturo. Večina AI projektov ne propade zato, ker bi bil model napačen. Propadejo, ker nikoli ne prečkajo enega od teh trenutkov.
Nekdo mora dejansko prevzeti odgovornost
Vsak projekt, pri katerem sem sodeloval, je imel točko, kjer je moral direktor ali vodja oddelka na glas reči: “Temu bomo namenili čas, ljudi in budget.” Ne “poglejmo, kako bo šlo” in ne petkov popoldanski eksperiment, ki nekaj ljudi zanima iz radovednosti. Prava zaveza. Brez nje je vse, kar sledi, krhko — v trenutku, ko se prioritete premaknejo, projekt tiho izgubi pozornost, in nikomur ni treba pojasnjevati zakaj, ker ga uradno ni nikoli nihče prevzel. Videl sem tehnično odlične prototipe, ki so umrli prav tukaj — ne zato, ker ne bi delovali, ampak zato, ker nihče s pooblastilom za budget ni nikoli izgovoril stavka, ki jih naredi resnične.
Primer uporabe mora biti resničen, ne udoben
Obstaja razlika med procesom, ki je res boleč, in procesom, ki samo dobro zveni na slajdu. Projekti, ki uspejo, so tisti, kjer je bolečina dovolj konkretna, da jo ljudje znajo opisati v enem stavku, in kjer je donos dovolj velik, da nikogar ni treba dvakrat prepričevati. “Uporabimo AI za X” ni primer uporabe — to je ambicija. Pravi primer uporabe je običajno nekaj, kar je nekdo že poskušal rešiti s preglednico, pravilom za skupni predal ali pripravnikom, in še vedno boli.
Dvom se pojavi, preden se pojavi navdušenje
Skoraj nihče novega AI orodja ne pozdravi z navdušenjem prvi dan. Prve reakcije so bližje skrbi: naredilo bo napake, prineslo bo dodatno delo pri preverjanju, nadomestilo bo mojo vlogo. To ni odpor do sprememb v abstraktnem smislu — je razumen odziv ljudi, ki še nimajo dokaza, da stvar deluje, in imajo vse razloge, da branijo svojo vlogo, dokler ga ne dobijo. Ekipe, ki prebrodijo to fazo, niso tiste z najboljšo predstavitvijo o upravljanju sprememb. So tiste, kjer je nekdo ostal dovolj blizu vsakodnevnim pripombam, da je nanje odgovarjal s konkretnimi primeri, ne z zagotovili.
Prvi MVP, ki dejansko deluje
Obstaja specifičen trenutek, običajno tih, ko nekdo v ekipi zažene orodje na resničnem primeru, pogleda navzgor in reče nekaj v smislu “počakaj, to dejansko deluje.” Vse pred tem trenutkom je teoretično. Vse po njem je drugače, ker zdaj obstaja referenčna točka, na katero se lahko ljudje sklicujejo, ko projekt razlagajo komu drugemu. To je običajno prvi trenutek, ko se dvom začne pretvarjati v radovednost, in vredno je opaziti, kdo je to izrekel in kaj je pravzaprav testiral, ker je tam običajno vir naslednjega kroga povratnih informacij.
Odkritja, ki jih noben demo posnetek ne pokaže
To je faza, ki je nihče ne kaže na LinkedInu, ker ni bleščeča — je nehvaležno delo poganjanja sistema na resničnih podatkih in odkrivanja vsega, kar je bilo narobe pri izvirnih predpostavkah. Robni primeri, na katere nihče ni pomislil. Polja, ki so včasih prazna in včasih napačno oblikovana. API-ji, ki se ne obnašajo tako, kot je pisalo v dokumentaciji. Procesi, ki obstajajo samo v glavi ene osebe in jih ni nikoli nihče zapisal. To je tudi po mojih izkušnjah faza, kjer nastane največ dejanske vrednosti, ker je to točka, kjer razumevanje ekipe o resničnem procesu končno ujame proces, kakršen dejansko je, ne kakršen je bil opisan na uvodnem sestanku.
Lastništvo se začne premikati
Obstaja trenutek, ki ga imam za najlepšega v celotnem projektu, in ga je lahko spregledati, če nanj nisi pozoren. To je trenutek, ko interna ekipa preneha spraševati, kaj orodje zna, in začne govoriti, kaj želijo, da naredi naslednje — “dodali smo še to,” “lahko bi avtomatizirali še tisti korak.” Takrat nisi več izvajalec projekta. Stvar postane njihova, in ta premik, bolj kot katerikoli kazalnik uspešnosti, pove, ali bo implementacija obstala.
Go-live redko poteka dramatično
Kljub temu, kar izraz namiguje, je dober zagon skoraj dolgočasen za gledati. Ne zgodi se kot en sam preklop — zgodi se kot postopno širjenje kroga: deset odstotkov procesa, potem trideset, potem šestdeset, potem vse. Pomanjkanje drame je bistvo. Zagon, ki potrebuje krizni štab, je običajno znak, da je v prejšnji fazi ostalo preveč neodkritega.
Petminutni sestanek
Takoj po zagonu je tedenski pregledni sestanek dolg — pogosto uro, včasih več, ker je veliko za pregledati: proizvodne težave, opažanja, prioritizacija popravkov, primerjava novega procesa s starim. Sčasoma ti sestanki postanejo krajši. Ne zato, ker bi se razvoj ustavil, ampak ker se je organizacija spremenila okoli orodja. Interna ekipa postane samoorganizirana. Vodje se prenehajo bati sponzorirati nove ideje. Ljudje prenehajo trošiti energijo za obrambo ponavljajočega se dela in jo začnejo usmerjati v iskanje naslednjega procesa, vrednega izboljšave. IT ima v lasti tehnologijo, posel ima v lasti rezultat, in nekje v tem premiku sestanek, ki je nekoč trajal uro, začne trajati pet minut — ne zato, ker ni ničesar za poročati, ampak ker organizacija tebe ne potrebuje več, da jih skozi to vodiš.
Trenutek, ko se zahteve spremenijo
Dodal bi še en trenutek, in to je tisti, ki ga dejansko iščem kot dokaz, da je implementacija uspela: točka, ko naročnik preneha spraševati po popravkih in začne spraševati po novih idejah. To je trenutek, ko AI preneha biti “projekt” in postane del načina, kako podjetje deluje. Nihče ga več ne vzdržuje iz obveznosti — ljudje si preprosto ne znajo več predstavljati procesa brez njega. To je, bolj kot katerakoli nadzorna plošča ali KPI, pravi cilj, čeprav pravzaprav sploh ni cilj, ker je trenutek, ko lastništvo v celoti preide, običajno tudi trenutek, ko nekdo vpraša, kaj sledi.
