Антон Водолазький уже два роки обіймає посаду СТО в OBRIO — компанії з групи Genesis. Починав із позиції iOS-розробника у внутрішньому продукті Nebula, а сьогодні відповідає за технічну стратегію та розвиток всієї команди.
В інтерв’ю DOU Антон розповів, чому складно наймати QA, як набирають початківців і за які досягнення співробітники можуть виграти iPhone. А також — чому DDoS-атаки стали новою реальністю для українських компаній і скільки грошей може заощадити ШІ.
🙆♂️ Як наймають початківців
— Скільки людей зараз в OBRIO і як зросла команда останнім часом?
У 2025 році команда суттєво зросла більш ніж на 140 людей, з яких близько 50 — технічні спеціалісти. Зараз в Україні в нас працює 300 фахівців.
Наймати складно всіх — ринок дуже конкурентний. Особливо важко знайти фахівців, які ідеально підходять і за софт-скілами, і за цінностями. Найбільше труднощів із пошуком iOS Lead, iOS Developer і QA-інженерів. Окремо варто згадати нативних автоматизаторів, які пишуть під iOS або Android — це рідкісна, але дуже потрібна спеціалізація. Загалом після переходу з manual QA до general ми самі ускладнили собі процес найму. Причина — тестувальники мають мати досвід мануальника і певний стек в автоматизації. На ринку general та automation QA набагато менше, ніж manual.
— Чи наймаєте джунів?
У співвідношенні з іншими фахівцями джунів — близько 20%. Приблизно
Перед тим як запросити джуна, у команді має бути людина з досвідом менеджменту та менторства, яка готова з ним працювати. Якщо лід або менеджер щойно перейшов на керівну роль, то найм джуна в таку команду недоцільний. Якщо в команді шість сеньйорів і немає завдань, що підходять для навчання, брати джуна немає сенсу.
Водночас є команди з технічним боргом або нескладними завданнями, що не критично впливають на систему. Саме туди ми й запрошуємо джунів — у безпечне середовище, де вони можуть навчатися і водночас приносити користь команді.
Ми також наймаємо інтернів, які щойно закінчили університет, але вже мають сильну базу та бажання розвиватися. Інтернів залучаємо переважно через школи Genesis Academy (як-от Genesis IT school, Software Engineering school, Front-end school). Якщо фахівці викладають у школі як ментори, то після завершення навчання вони можуть запропонувати офер найкращим студентам. Це логічно, адже команда вже встигла з ними попрацювати, бачила їхній рівень і потенціал.
За потреби ми проводимо додаткові співбесіди — і після цього пропонуємо роботу в компанії. Цього року, наприклад, до команди приєдналися четверо таких інтернів.
Процес відбору в нас майже однаковий для джунів і сеньйорів. Спершу кандидат проходить скринінг із рекрутером. Далі, залежно від команди, отримує тестове завдання або має технічну співбесіду з лідом, під час якої оцінюють софт-скіли.
Після цього — Bar Raising (фінальне узгодження чи затвердження кандидата). Іноді команди міняють місцями тестове завдання та технічну співбесіду — це залежить від специфіки вакансії.
Команда OBRIO. Фото надали у компанії
— Хто зазвичай не приживається в команді?
Ми в команді поділяємо думку, що звільнення — це не завжди погано. Це як у будь-яких стосунках — дружніх чи особистих: іноді просто не збігаються очікування або цінності. Скорочень у нас немає — навпаки, останні роки ми масштабуємося.
І завжди відкрито обговорюємо всі деталі. Якщо метчу не сталося — чесно визнаємо це й розходимося. Для нас це абсолютно нормальна історія. На етапі найму я завжди питаю: «Як виглядає твій ідеальний робочий день?». Це допомагає зрозуміти, які завдання людині цікаві й у якому середовищі їй комфортно. Якщо бачу, що наші реалії зовсім інші, краще відразу розійтися.
Або інший приклад: кандидат каже, що любить швидкий темп. У таких випадках, ми завжди уточнюємо, що він має на увазі, бо кожен сприймає «швидкість» по-своєму.
Швидкий темп у нас зумовлений насамперед великою кількістю A/B-тестів. Ми не можемо дозволити собі втрачати частину аудиторії, тому під кожен новий реліз команда готує тести заздалегідь.
Перенести фічу «на потім» — не варіант, усе має бути завершено до наступного релізу
Якщо говорити про цифри, то релізи на iOS, Android і scalable-платформах відбуваються щотижня. Вебверсії оновлюємо з тією ж частотою, а бекенд — кілька разів на день. Тести запускаються щодня і так само щодня зупиняються. Команда постійно має встигати все оновлювати, чистити й адаптувати — саме це і формує наш темп.
Іноді нові колеги зізнаються, що темп у нас швидший, ніж вони очікували. Це досить типова ситуація, і не всім це підходить. Дехто розуміє, що бракує фокусу чи концентрації, щоб тримати такий ритм. Тоді або людина сама про це говорить, або ми бачимо це за прогресом і результатами.
🥷 Чому DDoS-атаки — нова реальність українських компаній
— Нещодавно на вас здійснили DDoS-атаку. Як ви дієте в таких випадках?
Цьогоріч у нас уже було три хвилі атак. Перша — навесні, друга — у серпні (якраз під час моєї відпустки), а третя почалася 20 вересня і тривала весь день
Проблема була в тому, що атака мала системний характер: близько 40 000 унікальних IP-адрес надсилали велику кількість запитів у короткий проміжок часу — і це вивело систему з ладу навіть попри невелику кількість запитів від кожного IP.
Раніше атаки були локальними, тож їх вдавалося блокувати відносно легко. Спочатку думали, що достатньо «підкрутити» конфігурації та швидко відбити атаку, але згодом усвідомили масштаби проблеми й скоординували дії.
І, мабуть, найважче було прийняти те, що це не про короткочасний збій, а про потребу у системних змінах, які дозволять команді працювати без виснаження, якщо таке траплятиметься надалі.
Коли атака триває день, другий, третій — команда фактично не спить, працює без зупинок.
У якийсь момент ми почали помилятися і самі погіршили ситуацію
Наприклад, хтось виснажений, працював усю ніч, увімкнув правило для блокування атаки, а після її завершення забув його вимкнути. У результаті система могла випадково заблокувати щось важливе — і це впливало на роботу сервісу для звичайних користувачів, які не були ботами.
У такі моменти доводиться казати: «Стоп. Зупиняємось». Ми вимкнули все на кілька годин, щоб спокійно перебудувати інфраструктуру, перерозподілити навантаження і переписати процеси.
Точну суму збитків оцінити складно, адже атаки відрізняються за масштабом і тривалістю. Іноді зловмисники б’ють по ресурсах, де вже налаштований захист, — тоді витрати мінімальні. Буває, що перед атакою вони проводять підготовку, шукають вразливості й б’ють саме по них. У таких випадках збитки варто оцінювати за наслідками: наскільки сильно атака вплинула — чи вивела систему з ладу повністю, чи лише сповільнила роботу.
Якщо ми стикаємося з унікальною атакою, яка обходить наші захисні правила через високу розподіленість, доводиться масштабувати інфраструктуру, щоб витримати навантаження. Усе залежить від конкретної ситуації, але максимальні втрати на підтримання системи під час таких навантажень сягали
Щодо команди: зазвичай один спеціаліст повністю зосереджений на реагуванні — моніторить і контролює ситуацію. Якщо атака відбувається поза робочим часом і потрібен додатковий контроль, приєднується ще один фахівець техпідтримки. Коли атака зачіпає бекенд або фронтенд-сервіси, кличемо відповідного розробника. Під час активної атаки працює вся необхідна команда.
— У чому причина таких атак? Чи вдалося визначити їхнє джерело?
Ми серед великих гравців на ринку, де обертаються значні кошти. Тому, думаю, є два варіанти. Перший — конкуренти. Коли компанія стає помітною, не всі учасники ринку поводяться етично: дехто діє поза правилами. Другий — країни, які традиційно агресивні в кіберпросторі, зокрема росія.
Я більше зосереджуюся не на пошуку винних чи суперників, а на захисті продукту та його стабільності. Ми регулярно проводимо навчання з безпеки та співпрацюємо з профільною компанією, яка допомагає нам з пентестами та скануванням системи, щоб вчасно знаходити вразливості й не допустити стороннього доступу.
Я вважаю, що подібні атаки — нова реальність для українських компаній, які виходять на глобальний рівень
Ми вже бачили схожі інциденти — атаки на «Укрзалізницю» та інші великі компанії. Думаю, їх буде тільки більше, тож не варто чекати — треба готуватися заздалегідь.
🫰 Скільки вдається заощадити завдяки ШІ
— Поговорімо про Nebula, яка фактично перетворилася на маркетплейс. Що тут найскладніше підтримувати з погляду розробки?
У нас немає «суперскладних» алгоритмів чи власних технологій, де окрема команда дослідників пише математичні моделі.
Наші головні технічні виклики — це масштабування та робота з великою кількістю мікросервісів. Ми постійно запускаємо десятки A/B-тестів одночасно, перевіряємо різні гіпотези, і кожен із них може стосуватися різних аудиторій, платформ чи функцій. Найскладніше — синхронізувати все. Команда QA витрачає багато часу, щоб врахувати контекст: які тести активні, які зміни можуть вплинути на результати.
Нині у команді QA понад 20 інженерів, із них
Ми часто запускаємо MVP або fake door, щоби перевірити гіпотезу. Якщо ітерація невдала, доопрацьовуємо й тестуємо ще раз. Через це із часом накопичуються дрібні ітерації, які не завжди технічно чисті. Потім доводиться переписувати окремі частини системи, щоби повернути стабільність. Найскладніше — зберегти швидкість змін без втрати якості. Більшість багів у продакшені пов’язані саме із цими швидкими тестами та оновленнями.
Окремий виклик — чати з довгими онлайн-сесіями. Є користувачі, які проводять у них до 90 годин на тиждень. Іноді достатньо просто зайти в метро, і з’єднання обривається, через що повідомлення доходить із запізненням.
Ми приділяємо багато часу стабільності чатів, адже в системі паралельно працює багато функцій. Іноді це створює неочікувані ситуації — не критичні, але помітні для користувачів. Тому зараз перебудовуємо систему, щоб зробити її більш передбачуваною та плавною у використанні.
Команда OBRIO. Фото надали у компанії
— Як ви інтегруєте ШІ в ці процеси?
Ми почали інвестувати в ШІ взимку минулого року, коли формували нову стратегію. Найняли двох інженерів із ШІ, які створюють внутрішні інструменти для автоматизації — тулзи, промпти та рішення для оптимізації процесів.
За цей рік частково перейшли на ШІ-підтримку в застосунку: агент отримує тікет, класифікує його, визначає категорію й, якщо запит стандартний, відповідає автоматично.
— Скільки вдається заощадити завдяки ШІ?
Ми заощаджуємо десятки тисяч доларів. Орієнтуємося на кількість використаних токенів. Підраховуємо, скільки токенів йде на кожну задачу чи проблему, і переводимо це в грошовий еквівалент. Точну суму назвати не можу.
Загалом йдеться про тисячі доларів на місяць
Крім того, багато рішень команда створює самостійно — наприклад, MVP, зроблені за допомогою ШІ. Раніше на один MVP могли витратити до двох тижнів, а тепер його можна зібрати за один вечір.
Так само великі баги, які раніше вимагали глибокого аналізу чи тривалого дебагінгу, тепер часто вирішуються з першої спроби завдяки ШІ.
Також ми запустили ШІ-аналіз чатів — анонімізований процес, який показує, чи все гаразд у користувачів, які проблеми виникають і як змінюється їхній досвід.
Ми автоматизували процес локалізації контенту. Раніше експерт писав матеріал, а окрема команда адаптовувала його під стиль Nebula. Тепер це робить ШІ: редагує текст, структурує його, адаптує під tone of voice і персоналізує для користувача.
— Як вимірюєте ефективність ШІ-команди?
Ми відстежуємо, наскільки активно команда користується Cursor — за кількістю запитів і створених чатів. Водночас ця метрика не є самоціллю: ми не стимулюємо використання інструменту лише задля статистики, а використовуємо показники, щоб зрозуміти загальні тенденції. Для різних команд підхід до метрик відрізняється. Команда сапорту орієнтується на кількість опрацьованих тікетів, а контент-команда — на зекономлений завдяки ШІ час.
Також використовуємо ШІ під час Code Review. Розробник завантажує свій код, і система автоматично перевіряє його на відповідність code style, виявляє помилки, дублювання та логічні збої. У технічній команді зараз двоє людей, ще двох шукаємо. Один ШІ-спеціаліст працює в бренд-команді, ще один — у маркетингу (MRT). У креативній команді є двоє ШІ-креативників. Загалом п’ятеро людей, ми плануємо розширити команду до шести.
Ми використовуємо Cursor для генерування коду — це суттєво пришвидшило розробку. ШІ створює рішення або тести, розробник перевіряє результат, за потреби вносить правки та приймає код. Таким чином ми закриваємо багато рутинних задач.
Втім, є речі, які ми не довіряємо ШІ та, ймовірно, ще довго не будемо. Це насамперед рішення, які можуть створити ризики для бренду: будь-які дії, здатні видалити дані, зупинити сервіси чи іншим чином вплинути на стабільність продукту.
Тому ШІ має обмежені права — він може діяти лише в межах, де ми впевнені, що його втручання не призведе до негативних наслідків.
💫 Як видають «зірки» за досягнення
— Як ви мотивуєте команду генерувати ідеї?
Це непросто, адже більшість фокусується на своїй зоні відповідальності. Технічна команда переважно думає про фреймворки, оновлення бібліотек і те, як позбутися легасі.
Я завжди прошу команду ділитися своїми досягненнями — навіть невеликими. Багато хто спершу соромиться, бо думає, що це виглядатиме як самореклама. Але я пояснюю: це не про «вихваляння», а про обмін досвідом, який може надихнути інших. Коли чую, що хтось зробив щось круте або запропонував ідею, яка спрацювала, завжди прошу про це написати й поділитися. Такі історії формують здорову культуру відкритості і взаємної мотивації.
Друга річ, яка добре працює в нас, — це планування. Ми маємо трирічну стратегію, що описує, які кроки потрібно зробити для зростання. Плануємо і зверху вниз, і знизу вгору.
Наші
Наприклад, команда пропонує ідею локалізації — і вона зростає до рівня стратегічної ініціативи «вихід на нові ринки». Інший приклад — впровадження автотестів, що переросло в масштабну ініціативу переходу від manual-тестування до автоматизації.
Крім того, у нас є щомісячний апдейт від С-level — він так і називається. Раз на місяць ми проводимо івент, де збираємо всю команду офлайн у Києві або Варшаві, а ті, хто не може бути присутнім особисто, приєднуються онлайн.
Під час зустрічі кожен
У нас є окремий і дуже популярний канал у Slack — #recognition. Там кожен може відзначити колегу: у кожного є певна кількість «зірок» на місяць, якими можна подякувати чи похвалити інших. «Зірки» можна накопичувати й обмінювати на мерч або гаджети. Ми ще не дійшли до повноцінного каталогу.
Головна «фішка», над якою всі жартують, — можливість обміняти «зірки» на новий iPhone
Щоб його отримати, потрібно накопичити 70 тисяч зірочок. Їх також можна заробити ще й за різні активності — наприклад, за зовнішні виступи, публікації чи рекомендації знайомих у команду.
Нещодавно ми провели AI Challenge — й авторів трьох найкращих інновацій із найбільшим впливом нагородили найновішими iPhone.
— Які у вас плани зростання? Плануєте посилювати команду або запускати нові проєкти?
Нові проєкти поки не запускаємо. Наша стратегічна ініціатива — розвивати ШІ-експертизу, тому продовжуємо наймати інженерів із ШІ. Паралельно зростають frontend-, backend- і QA-команди.
Щодо продукту — плануємо вихід на нові ринки. Ми бачимо, що ще є напрями, які потребують доопрацювання, і зараз головна мета — встигнути реалізувати все заплановане.
