Kiekviena kompanija, norinti rimtai naudoti DI, kada nors atsiduria toje pačioje kryžkelėje: kurti savo DI/ML komandą, ar pasitelkti išorės ekspertus. Abu keliai gali pasiteisinti. Abu gali ir tyliai išsemti biudžetą, jei sprendimas priimamas remiantis nuojauta, o ne tikrais skaičiais.
Štai ką iš tikrųjų rodo skaičiai ir praktiškiausias būdas apsvarstyti šį sprendimą.
Tikroji savo komandos kūrimo kaina
Samdyti į DI/ML pareigas yra brangu, ir ne tik dėl atlyginimo. JAV vidutinis metinis DI inžinieriaus atlyginimas siekia apie 145 080 USD, o patyrę specialistai reikalauja 180 000 USD ar daugiau, dažnai su akcijų opcionais ir premijomis. Be to, techniniai atrankos specialistai paprastai ima 15-30% mokestį, o tai net neįskaičiuoja vidinio laiko, praleisto pokalbiams, nepavykusio samdymo kainos ir įsibėgėjimo laikotarpio, kol naujas komandos narys tampa iš tiesų produktyvus.
Infrastruktūra prideda dar vieną sluoksnį. Vietinės (on-premise) DI infrastruktūros išlaidos visame pasaulyje tik 2024 m. pirmąjį pusmetį pasiekė 47,4 mlrd. JAV dolerių, o apie 72% DI serverių išlaidų šiuo metu patiriama debesijoje, o ne nuosavoje įrangoje. Šis pokytis svarbus planavimui: debesijos mokėjimo pagal naudojimą modelis leidžia išvengti didelių pradinių kapitalo investicijų, ir tai verta įvertinti, kai kyla noras iškart visą įrangą pirkti ir turėti nuosavybėje.
Greitis taip pat yra sąnaudos, net jei jis nepasirodo sąskaitoje faktūroje
Nuo nulio sukurti pajėgią savo DI komandą paprastai užima 6-12 mėnesių: darbo skelbimai, pokalbiai, įvedimas į darbą, ir laikas, per kurį nauja komanda iš tiesų supranta jūsų duomenis ir darbo eigas. Per šį laikotarpį konkurentai, veikiantys greičiau, jau pristato produktus. Tikroji lėto kūrimo kaina retai matoma biudžeto eilutėje. Ji vėliau išryškėja kaip prarasta rinkos dalis ir sunkiai atgaunamas pagreitis.
Todėl daugelis kompanijų projekto pirmajam etapui pasitelkia išorės specialistus, konkrečiai tam, kad sutrumpintų šį laikotarpį, ir savo vidinius pajėgumus kuria tik tada, kai požiūris jau patikrintas. Tai panašus principas, kaip įprastai dirba „AAI Labs” su klientais: greitai ateiname patikrinti idėjos arba sukurti pirmąją veikiančią versiją, tada perduodame dokumentaciją ir, kur tai prasminga, padedame kliento komandai perimti darbą.
Talentų rinka rodo, kad „tiesiog pasamdykite ką nors” nėra taip paprasta, kaip skamba
Net kompanijos, turinčios biudžetą samdymui, konkuruoja itin ribotoje rinkoje. Vien JAV yra apie 750 000 laisvų su DI susijusių darbo vietų - dėl to atlyginimų reikalavimai išlieka aukšti, o kandidatų trūksta. Ir samdymas yra tik pusė problemos: mašininio mokymosi sritis turi antrą didžiausią darbuotojų kaitos rodiklį tarp pramonės šakų, 12,9%, o vidutinė mašininio mokymosi specialisto darbo trukmė yra vos 1,2 metų. Komandos sukūrimas nereiškia, kad ją išlaikysite.
Dauguma DI projektų žlunga dėl priežasčių, nesusijusių su tuo, kas rašė kodą
Šią problemą verta apsvarstyti prieš priimant bet kokį sprendimą: daugiau nei 80% DI projektų nesėkmių priežastis yra valdymo trūkumai ir duomenų kokybės problemos, o ne talento trūkumas. Apie 80% projekto galutinės sėkmės priklauso nuo tvirto duomenų inžinerijos darbo, neblizgaus darbo, kai duomenys tvarkomi, struktūrizuojami ir patikrinami, prieš jiems pasiekiant bet kokį DI modelį. Nei puikus vidinis darbuotojas, nei išorinis paslaugų teikėjas negali išgelbėti projekto, kuris nuo pradžių nebuvo sukurtas taip, kad pasisektų.
Praktiškas būdas nuspręsti
Savo komandos kūrimas dažniausiai prasmingas, kai komandos įgūdžiai yra pagrindinis jūsų produkto įgyvendinimo reikalavimas, kai turite pakankamai nuolatinio darbo, kad komanda būtų užimta ilgą laiką, ir kai intelektinės nuosavybės ir organizacijos žinių valdymas atsveria lėtesnį įsibėgėjimą.
Išorės ekspertų pasitelkimas (konkrečiam projektui, koncepcijos patvirtinimui, ar kad greitai paleistumėte pirmąją versiją) dažniausiai prasmingas, kai reikia patvirtinti idėją prieš įsipareigojant nuolatiniam personalui, kai reikalingi įgūdžiai yra siauri ar laikini, arba kai greitis pasiekti veikiantį rezultatą šiuo metu svarbesnis nei viso proceso nuosavybė.
Šie du keliai nėra tarpusavyje nesuderinami. Dažnas modelis yra pradėti nuo išorės pagalbos, siekiant patvirtinti koncepciją ir paleisti veikiančią sistemą, o tada, kai grąža tampa aiški, aplink ją auginti vidinę komandą. Nesvarbu, kuris kelias tinka, klausimai, kuriuos verta užduoti prieš įsipareigojant, yra tie patys: kaip atrodo sėkmė, kaip duomenys bus prižiūrimi po pradinio kūrimo etapo, ir kas bus atsakingas už rezultatą po šešių mėnesių?
Jei šį sprendimą svarstote konkrečiam projektui ir norėtumėte nepriklausomos nuomonės sprendžiant DI komandos būrimo klausimą, susisiekite su mumis.