Чаму на змену крос-камандам прыходзяць крос-людзі? Што рабіць джунам? Як вопыт працы ў Акадэміі навук дапамагае кіраваць ШІ-трансфармацыяй у сучаснай кампаніі? Шукаем адказы на гэтыя ды іншыя пытанні з Head of AI Platform у Flo Яўгенам Сяргеевым.
Чаму на змену крос-камандам прыходзяць крос-людзі? Што рабіць джунам? Як вопыт працы ў Акадэміі навук дапамагае кіраваць ШІ-трансфармацыяй у сучаснай кампаніі? Шукаем адказы на гэтыя ды іншыя пытанні з Head of AI Platform у Flo Яўгенам Сяргеевым.
— Як увогуле ўкараненне ШІ-інструментаў змяняе хайрынг? Наколькі ўважліва вы глядзіце на тое, ці ўмее чалавек з імі працаваць?
— Мы выбіраем інжынера з добрым меркаваннем. У Flo заўсёды быў высокі бар найму, ён апісаны ў нашай кар’ернай матрыцы. Гістарычна мы наймалі пераважна сеньёраў. AI гэты бар не знізіў, а зрушыў: змянілася тое, як мы яго правяраем.
AI fluency стала звычайнай часткай навыкаў, якія мы правяраем на інтэрв’ю. Гэта не асобны этап і не бонус, а такі ж навык, як System Design або веданне Computer Science. Галоўная змена ў тым, што нам цяпер важней не тое, ці вырашыў кандыдат задачу на інтэрв’ю, а тое, як яны яе вырашалі.
Вырашыць задачу з агентам можа амаль кожны. Розніца бачная ў працэсе: як кандыдат ставіць задачу, які кантэкст дае агенту, як правярае вынік, калі спыняе агента і бярэ кіраванне на сябе.
Кандыдат можа расшарыць экран і паказаць свой харнес: як ён стасуецца з агентам, якія ў яго (яе) правілы і skills, як ён (яна) разбівае задачу. Па гэтым адразу бачна і ўзровень інжынера, і ўзровень ягонай працы з ШІ.
На тое, як уладкаваны наш найм, можна паглядзець на прыкладзе engineering-менеджараў. Там добра відаць, што мы глядзім на меркаванні і кампрамісы, а не на завучаныя фрэймворкі.
— Джунаў вы не наймаеце?
— Не. Але пару словаў пра іх скажу. Базавы код цяпер сапраўды пішацца ў адзін промпт, але праца інжынера ніколі не зводзілася да напісання кода. Важнейшыя этапы да генерацыі і пасля яе: разабрацца ў праблеме, прыняць рашэнне, запусціць, падтрымліваць сістэму і не даць ёй разваліцца, калі змяняюцца патрабаванні.
Менавіта гэтаму джунам цяпер трэба вучыцца з самага пачатку, таму што простых задач, на якіх раней набіраліся вопыту, становіцца менш. Складанасць пры напісанні кода знікла, так? Але ўсё роўна засталіся фундаментальныя рэчы, на якія трэба набіваць руку: пастаноўка задач, праверка якасці.
— Атрымліваецца, што ІТ-ВНУ цяпер выпускаюць сотні спецыялістаў, якія наогул не патрэбны прадуктовым кампаніям, пакуль не набяруцца вопыту, а набрацца амаль няма дзе. Як вырашаць гэту праблему? Памяншаць выпуск айцішнікаў?
— Ведаеш, я выпускаўся з ВНУ радыёінжынерам, калісь гэтая прафесія была папулярнай. І я прапрацаваў радыёінжынерам нуль дзён у сваёй кар’еры. Попыту на рынку на радыёінжынераў ужо не было.
Праблема ў індустрыі, пра якую ты кажаш, ёсць. Ёсць навіны ад умоўнай «Меты», якая скарачае чарговыя X тысяч чалавек. Ёсць схаваныя скарачэнні, калі пазіцыя сышоўшага спецыяліста не запаўняецца. Як гэта робіцца? Часта кажуць: «Ці сапраўды вам трэба чалавек на замену? А давядзіце, што вы не зможаце рабіць усё тое ж самае, што і з ім, але без яго, з меншай камандай».
Гэта рынак, дзе попыт нараджае прапанову. Раней быў попыт, вялікія кампаніі былі зацікаўленыя ў вялікай колькасці джунаў ды інвеставалі ў навучанне. Спецыяльнасці з’яўляліся ва ўніверсітэтах, адкрываліся лабараторыі, дзе супрацоўнікі кампаній навучалі будучых спецыялістаў. Адкрываліся інтэрнатуры, у каманды на некалькі месяцаў бралі яшчэ студэнтаў, працавалі з імі, навучалі практыкам.
Цяпер як быццам для кампаній гэта становіцца менш цікавым. Людзей на рынку шмат, ім прасцей узяць нейкага вопытнага інжынера, якога скарацілі ў той жа «Мете», таму што ён ужо ўмее працаваць, чым узяць нейкага выпускніка з моцнага ўніверсітэта.
Тут вельмі складана рабіць нейкія прагнозы. Таму што сітуацыя з мадэлямі ўжо такая, што складана сачыць нават за іх назвамі, «перыяд паўраспаду» паскараецца з кожным разам. Магчыма, праз год з’явяцца нейкія зусім новыя прафесіі, а ўніверсітэты і хайрынг пад гэта перабудуюцца.
Але калі мы гаворым канкрэтна пра сёння, я б пры найме чалавека ў першую чаргу глядзеў, наколькі яму камфортна працаваць з новымі інструментамі, як ён умее фармуляваць задачы. Калі чалавеку яшчэ не хапае вопыту, але ёсць цікавасць, гараць вочы, то мне з гэтым чалавекам цікавей будзе працаваць. Таму што нават калі ён нечага не ведае, яго можна гэтаму даволі хутка навучыць.
— Людзей, для якіх праграмаванне — гэта прафесія, будзе станавіцца ўсё менш?
— У прафесіі інжынер-праграміст ёсць розныя развілкі. Ёсць людзі, якія займаюцца нейкімі платформеннымі рашэннямі, робяць інструменты ўнутры кампаніі альбо для іншых інжынераў. Задача ў многіх — не код напісаць, а зрабіць інструмент, які дазволіць выканаць нейкую бізнес-задачу. Ёсць людзі, якія робяць інструменты ў лабараторыях, якія навучаюць мадэлі (на іх, дарэчы, попыт вырас, і заробкі выраслі). І гэта таксама інжынеры, толькі спецыялізацыя ў іх крыху іншая.
Гэта ўжо не кодэры, якія калісь проста пісалі код. Вось для тых будучыня — сапраўды вельмі туманная.
— Давай паглядзім на гэту праблему з прадуктовага пункту гледжання. Нядаўна мой знаёмы гісторык, які наогул нічога не разумее ў праграмаванні, зрабіў сабе амаль адным промптам стратэгію накшталт Panzer General. Гульня прымітыўная — але сэнс у тым, што ён зрабіў роўна такую гульню, якую хацеў. Тэхніка ў яго з патрэбнымі параметрамі, паводзіць сябе ў баі, паводле ягонага меркавання, гістарычна. І ён шчаслівы. Хмары над геймдэвам згушчаюцца?
— Памятаеш, ты казаў, што попыт на софтвер можа аказацца канечным? Дык вось, пакуль адказу на гэтае пытанне ніхто не ведае. Мы бачым, што з’яўляюцца новыя нішы, як у гэтым тваім прыкладзе. Калі трэба нейкае персаналізаванае прыкладанне, як гульня гэтага гісторыка, у цябе цяпер узнікае пытанне: трэба схадзіць у маркет пашукаць, ці я магу сесці і для сябе яго напісаць? З патрэбным функцыяналам, а не нейкі камбайн, ад якога мне будзе патрэбны 1% яго функцыянальнасці.
І ты можаш альбо купіць нешта падобнае на тое, што табе трэба, альбо купіць падпіску на ШІ-агента на месяц і зрабіць роўна тое, чаго хочаш. Мне здаецца, што тут таксама ўсё рынак скалібруе.
— Давай пра рост кагнітыўнай нагрузкі на сеньёраў, якія ў вас займаюцца рэв’ю. Яна ж расце? Калі на цябе звальваецца цунамі згенераванага кода, калі табе трэба пастаянна перавучвацца — хіба гэта не вядзе да хуткага выгарання высокаўзроўневых спецыялістаў? Як у такіх умовах захаваць гэтых вельмі-вельмі каштоўных людзей, «канечны рэсурс»?
— Так, ты маеш рацыю, колькасць пул-рэквестаў відавочна вырасла. Мы гэта бачым па нашых метрыках. Наша задача — утрымаць метрыку PR Cycle Time, адну з галоўных, пра якую я расказваў мінулы раз, у дыяпазоне двух дзён. У інжынірынг-менеджара, які будзе працаваць з камандай, гэта будзе адна з метрык, якую ён будзе імкнуцца з камандай аптымізаваць.
Калі ўсе мае інжынеры заняты тым, што робяць рэв’ю, не паспяваюць рэв’юіць, то ўсё гэта назапашваецца і да прадакшна нічога не даязджае. Ну і як гэтую штуку можна аптымізаваць?
Мы глядзім, як усё гэта можна зрушыць улева. Чаму мы рэв’юілі гэты код? Якія мы папрасілі ўнесці праўкі? Ці можна гэта вынесці ў нейкія скілы, якія будуць запускацца ад лакальнага інжынера пасля таго, як ён альбо яна напісалі нейкія змены перад тым, як адправіць PR. І гэты цыкл паляпшэнняў ідзе пастаянна. Адпаведна, нагрузка на інжынера, які займаецца рэв’ю, перастае расці з той жа хуткасцю, як расце колькасць пул-рэквестаў. І становіцца больш-менш лінейнай.
І яшчэ знікае неабходнасць кожны рэквест накіроўваць на інжынера. Тое, што можа быць смерджана аўтаматычна, павінна быць смерджана аўтаматычна. Цяпер усімі гэтымі дэталямі не абавязкова займацца чалавеку. Чалавеку трэба папросту рэв’юіць.
Яшчэ адзін кірунак, у якім мы цяпер працуем — а што, калі мы будзем рэв’юіць не сам рэквест, а план? Гэта значыць, задачу, якую мы даём агенту?
Цяпер мы якраз пераходзім з Jira на Linear. І ў Linear гэта класна можна рэалізаваць. У нас ужо ёсць невялікі пілот, дзе мы гэта правяраем. Першапачаткова фармулюем нейкія прадуктовыя патрабаванні, ставім задачы. Далей з агентам дапаўняем план, які ідзе яму на execution. І там падключаецца чалавек, каб гэты план парэв’юіць. QA можа сказаць, якая валідацыя тут патрэбна, інжынер — якія ёсць абмежаванні ў сістэмы, Product можа задаць свае патрабаванні. Цяпер гэта тры ролі, тры розных чалавекі, але з часам для гэтага спатрэбіцца менш людзей.
Што, напэўна, інжынерам даецца складана? Раней яны прывыклі працаваць у нейкім сфакусаваным патоку. Ты бярэш задачу, думаеш над ёй. Гэта з майго вопыту — я думаў больш, чым пісаў код, і напісанне кода мне здавалася нейкай руцінай. Цікавей было прыдумаць рашэнне, а запраграмаваць яго — гэта справа тэхнікі.
А цяпер атрымліваецца, што я бяру адну задачу і, пакуль агент яе робіць, павінен пераключыцца на наступную. Для мяне няма сэнсу глядзець у манітор і сачыць, што ён там робіць. Мая задача — прыйсці, праверыць вынік працы, дадаць нейкія ўводныя, нешта падрэгуляваць.
Гэтае пераключэнне кантэксту, як мне здаецца, можа прыводзіць да выгарання. Таму што табе пастаянна трэба пагружацца ў новы кантэкст, ставіць задачу агенту, пераключацца на наступную задачу і гэтак далей. Дарэчы, у менеджараў у гэтым плане ёсць перавага, таму што ў іх заўсёды быў скіл пераключэння з аднаго кантэксту на іншы.
Інжынерам даводзіцца вучыцца працаваць з пастаянным пераключэннем кантэксту, тады як раней яны працавалі ў патоку.
— Ты кажаш, што любіў у рабоце праграміста падумаць над рашэннем, а не кодзіць. Але ж рэв’ю — гэта, напэўна, нават менш творчая задача, чым напісанне кода. Калі праца сеньёраў будзе зводзіцца да рэв’ю, яны ж будуць выгараць яшчэ хутчэй?
— Я думаю, што ад рэв’ю мы хутка адмовімся. Гэта сапраўды руціна. На месца ручнога рэв’ю кода прыходзяць аўтаматычныя праверкі, а чалавек застаецца на крытычных зменах. Магчыма, рэв’юіць будзем план, а не напісаны код. Код — гэта ўжо вынік. І каб ён быў добрым, напэўна, спачатку трэба падрыхтаваць добры кантэкст.
Ведаеш гэту фразу пра смецце на ўваходзе і смецце на выхадзе? І калі мы не хочам смецця на выхадзе, напэўна, трэба, каб і на ўваходзе не было смецця. Будзем эксперыментаваць. Думаю, рэв’ю — гэта тое, ад чаго індустрыя з часам будзе адмаўляцца на карысць аўтаматызацыі. Той жа Anthropic Code Review — няблагі інструмент. Папросту пакуль звышдарагі.
Будзе гэты інструмент танней — будзем яго мадыфікаваць, дадаючы правілы, падказваючы рэв’ю-агенту, як палепшыцца. І калі мы ўбачым, што яго якасць прыблізна адпавядае таму, якое выдаюць людзі, ужо не будзе сэнсу ў тым, каб гэтым займаўся чалавек. Аўтаматызавалі напісанне кода — аўтаматызуем і рэв’ю.
— Ты ўжо досыць даўно працуеш на менеджарскіх пазіцыях, але прыйшоў на іх з інжынернага кірунку. Вопыт працы на інжынерных пазіцыях у Аб’яднаным інстытуце праблем інфарматыкі НАН Беларусі як-небудзь дапамагае табе кіраваць ШІ-трансфармацыяй у Flo?
— Увесь папярэдні вопыт для мяне карысны. Напрыклад, у АІПІ мы былі буйным інтэгратарам медычных сістэм. Там я працаваў у медычным дамене і быў крыху пагружаны ў яго. Інтэграцыя нейкай медычнай сістэмы ў сістэму аховы здароўя — гэта зносіны з замоўцамі, з вендарамі. Вядома, гэтыя рэчы былі вельмі карыснымі.
Яшчэ я быў тэхнічным дырэктарам і фаўндарам у кампаніі BIS-Soft. Не вельмі вялікі стартап, які рабіў платформу абмену медычнымі дадзенымі. Установы аховы здароўя — яны фрагментаваныя. У тым сэнсе, што перасылаць нейкія дадзеныя з адной клінікі ў іншую часам проста немагчыма, таму што сістэмы для іх рабілі розныя вендары. І мы рабілі платформу, якая дапамагала абменьвацца дадзенымі.
Я вельмі ганаруся, што мы запусцілі сістэму электронных рэцэптаў у Беларусі. Якая дазволіла, напрыклад, людзям з хранічнымі захворваннямі накшталт астмы аўтаматычна падаўжаць рэцэпты праз асабісты кабінет, а не з дапамогай паходаў па паліклініках.
Гэты вопыт таксама быў суперкарысным. Таму што праз яго я, як оўнер, прыйшоў да такой мантры: ідэі трэба правяраць вельмі хутка. Я гэта называю Fail Fast or Learn Fast. Калі нешта не працуе, не трэба за гэтую ідэю трымацца. Ты праверыў гіпотэзу, яна не працуе? Падумай, як яе можна адаптаваць.
Што яшчэ было карысным у стартапе? Мы не маглі сабе дазволіць наймаць шмат інжынераў і доўга ўводзіць іх у працу. Таму прыдумалі такі падыход: людзям, якія хацелі ў нас працаваць, проста аплачвалі адзін рабочы дзень, каб яны прыйшлі, паглядзелі, як мы працуем знутры. У гэты ж дзень мы ім давалі канкрэтную задачу і глядзелі, як яны з ёй справяцца.
Такі падыход абярнуўся для нас дадатковай нагрузкай, бо ўся наша інфраструктура павінна была быць гатовай да імгненнага онбардынгу, да таго, што чалавек з першага дня прыйдзе і будзе рабіць код. Але яно таго вартае.
Гэтыя падыходы я выкарыстоўваў ужо як менеджар у нейкіх онбардынг-праграмах. Таму што калі я прыходзіў у кампаніі, я хутка разумеў, праз якую бюракратыю трэба прайсці чалавеку, каб проста пачаць пісаць код. Першыя дні ён толькі доступы атрымліваць будзе.
— Працуючы на менеджарскай пазіцыі, ты сумуеш па кодынгу?
— Не тое каб я сумаваў па самым кодынгу. Самая цікавая рэч у інжынерыі — гэта падумаць, нешта прыдумаць. І рабіць гэта з ШІ-інструментамі вельмі класна. З Claude можна пабрэйнстарміць, прапанаваць нейкую ідэю, задаць нейкія абмежаванні, а код ён ужо напіша сам.
Я лічу, што менеджары ў бягучых рэаліях павінны спрабаваць гэтыя інструменты, пісаць з іх дапамогай код. Інакш ты проста адрываешся ад каманд ды інжынераў і ператвараешся ў чалавека-роўтара, які пераказвае патрабаванні з аднаго мітынгу ў іншы.
— Цікава. Тут, напэўна, таксама будзе нейкі натуральны адбор, і такіх людзей-роўтараў LLM заменяць хутчэй за астатніх менеджараў?
— Так. Гэта, дарэчы, адна з маіх матывацый быць Head of AI Platform. Гэта крыху бліжэй да тэхналогій. Я заўсёды імкнуся будаваць траекторыю кар’ернага развіцця. Мы неяк абмяркоўвалі гэта з Сашам Паламодавым. Ён нейкі час працаваў у Т-банку як CTO аднаго з кірункаў, а потым пераключыўся ў Fellow-інжынера. Разумееш, ты павінен часам задавацца пытаннем «што ты можаш даць кампаніі?» Але павінна быць і пытанне «што кампанія можа даць табе?» Таму што ты з часам павінен развівацца, твае навыкі для рынку павінны заставацца рэлевантнымі.
Цяпер у індустрыі мы бачым, што колькасць вакансій для інжынераў скарачаецца. Менеджараў і так было менш, адзін прыходзіўся на каманду з пяці-дзесяці інжынераў. Але лік вакансій для іх памяншаецца яшчэ хутчэй. Самі каманды становяцца меншымі, і наяўнасць у менеджара адразу двух-трох-чатырох каманд становіцца нормай. Заставацца бліжэй да hands-on — гэта, як мне здаецца, стратэгічная стаўка для менеджараў.
— Давай пагуляем у футуралогію. Дапусцім, у тваёй камандзе працуюць 100 інжынераў. Як ты лічыш, колькі інжынераў са 100 застанецца ў камандзе пасля таго, як яна пройдзе праз цяперашні этап ШІ-трансфармацыі? Напрыклад, праз тры гады?
— Тры гады — вялікі гарызонт. Як яно ўсё зменіцца, вельмі складана сказаць. Але які я бачу трэнд цяпер? Ён называецца Tiny Teams, «маленькія каманды». Калі каманда з двух-трох чалавек пачынае выконваць больш задач. За кошт чаго яна гэта робіць? За кошт таго, што ў камандзе ў чалавека з’яўляецца больш роляў. Раней мы рабілі кросфункцыянальную каманду, куды дадавалі ролі па прынцыпе «плюс роля — плюс чалавек». Мабільны інжынер, бэк-энд, JS і гэтак далей. А цяпер чалавек плюс ШІ-інструмент можа сумяшчаць у сабе розныя ролі. І рабіць адразу рашэнне пад ключ, калі табе не трэба чакаць бэк-энда і можна адразу зрабіць сваю частку.
Мне здаецца, што гэты трэнд працягнецца. І кросфункцыянальнымі будуць станавіцца ўжо не каманды, а людзі. І мы, напэўна, зможам убачыць трэнд сола-прадпрымальнікаў, калі адзін чалавек будзе ствараць мільярдную кампанію.
Як усё гэта адаб’ецца на вялікіх кампаніях? Магчыма, штат не будзе павялічвацца, затое будзе ісці запыт рабіць больш інкрэменту і карысных рэчаў на адзінку часу. Але тут узнікае пытанне: а ці трэба карыстальнікам столькі змяненняў? Таму што карыстальнік не заўсёды любіць шмат апдэйтаў. Бо калі з’явілася новая функцыянальнасць, у ёй трэба разабрацца, патраціць на гэта час.
У заключнай частцы інтэрв’ю мы пагаворым з Яўгенам Сяргеевым пра тое, як фарміраваўся і з чаго складаецца ШІ-стэк у Flo, а таксама пра ўдалыя эксперыменты і пра фэйлы ШІ-трансфармацыі ў маштабах адной кампаніі. Не пераключайцеся!
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.