«В окремих deftech-напрямах платять більше, ніж в IT». Розробник софту для НРК про ШІ, проблеми ринку і брак керівників
Tech Unity — українська deftech-компанія, яка робить бортові комп’ютери, системи зв’язку та софт для наземних роботизованих комплексів. Вона виросла з волонтерських ініціатив, допомагала робити перші НРК Третій штурмовій бригаді, а сьогодні розвиває власні R&D-продукти.
У розмові з DOU співзасновник і директор R&D Віктор Брайченко розповів, чим відрізняється класичне ІТ і дефтек, якого спеціаліста шукали рік і так і не знайшли, які «аварійні» ситуації з військовими продуктами треба враховувати. А також чому стримано ставляться до ШІ і що зі стандартами НАТО у виробників.
«В якийсь момент у нас в роботі було 17 продуктів». Про вироби
Часто у мене питають, чого ми робимо компоненти, а не одразу НРК. Зробити наземний роботизований комплекс — це значно складніше, ніж розробити електроніку чи написати софт. Йдеться про повноцінний виробничий ланцюг: приміщення, металообробку, зварювальні та механічні роботи, логістику, сервісне обслуговування, складські процеси й контроль якості на кожному етапі.
Це інша індустрія, інша структура, інший масштаб. Ми не команда, яка варить корпуси і гусениці. Ми команда, яка закриває те, виробники часто не можуть або не хочуть будувати всередині.
На сьогодні у нас два основних продукти:
- Бортовий комп’ютер для НРК Jarvis — це інтегрована система керування, що забезпечує автономну роботу наземного роботизованого комплексу (НРК) та інших безпілотних платформ. Jarvis відповідає за обробку даних з датчиків, планування руху, взаємодію з операторами та іншими системами, а також за підтримку автономних режимів функціонування в польових умовах.
- RoboLink — це модуль супутникового звʼязку на базі Starlink, що дозволяє керувати наземними роботами та безпілотними системами на великих відстанях. Такий звʼязок критично важливий для роботи в умовах обмеженої або відсутньої наземної мережної інфраструктури.
Також у нас є власна база даних з роботів і бібліотека, як зібрати робота з нуля. Якщо звертається військовий або партнер-виробник — ми даємо доступ. Це безплатно. Там є практичні речі, прошивки, дрібні покращення. Також ми допомагаємо військовим із софтом. Можемо зробити кастомні рішення там, де є тільки ідея і потреба.
В якийсь момент у нас одночасно в роботі було 17 продуктів, але через фінанси довелося зосередитися на двох. Решта поки що заморожені, адже для їхньої реалізації потрібні інвестиції і масштабування.
«Весь софт закриваємо своїми силами». Про компанію і команду
TechUnity виросла з неформальної спільноти однодумців в лютому 2024 року. На старті ми радше були групою людей, які хотіли допомогти армії, ніж компанією в класичному сенсі. Частина команди тоді долучилася до експериментального проєкту — ми допомагали Третій штурмовій бригаді робити перші НРК, а також доєднувалися до інших розробників роботів. Волонтерський дух у нас залишився і сьогодні, навіть коли з’явилась комерційна структура, частина людей досі допомагає паралельно з основною роботою або службою.
У певний момент стало очевидно, що R&D — це дорога історія. Будь-яка розробка може «вистрілити», а може й ні. Ти вкладаєш час і гроші, а потім з’ясовується, що рішення не має попиту. На одному ентузіазмі й власних коштах далеко не заїдеш. Тому торік ми вирішили оформити комерційну організацію, тож формально ми досить молоді.
Фактично всі інвестиції — це внески самої інженерної команди і друзів. Зараз ми намагаємося отримати грант від Brave1 як «критична компонента», але окремих зовнішніх інвесторів у нас немає.
Фото надане Tech Unity
У нас 30 фахівців: 15 офіційно працевлаштованих і 15 волонтерів. З них половина — ІТ-спеціалісти. Усе програмування ми закриваємо своїми силами. Техпідтримка теж внутрішня, бо її неможливо нормально тримати на аутсорсі.
Команда R&D в нас дуже різнопрофільна. Є класичні embedded-інженери, а ще дизайнери, тестувальники, розробники з вебу та десктопу. Іноді людей дивує наявність дизайнерів. Але якщо твій користувач — звичайний солдат, для якого важливий досвід використання, інтерфейси й логіка роботи — це критично.
«Жоден з НРК в Україні сьогодні не пройде кодифікацію за стандартами НАТО». Про проблеми робототехніки
Проблеми в сфері НРК часто починаються не там, де всі звикли їх шукати. Люди люблять говорити про РЕБ, зв’язок, «штучний інтелект», автономність, але на практиці ми постійно впираємось у базовий рівень — ходову, герметичність, якість збірки.
На ринку багато НРК, але чимало з них мають вади на базовому рівні. Постійно щось ламається, клинить, розвалюється або поводиться непередбачувано. Я вже мовчу про ситуації, коли корпус не герметичний. Пішов дощ — вода потрапила в електроніку, і все, машина зупинилась. Для мене досі загадка, як у 2026 році можна продавати «військовий» виріб, який не переживе поганої погоди.
Інша велика проблема — мотивація у деяких виробників «зробити дешево». Це загалом не погано. Але коли головна мета — швидко продати, а не зробити ефективний продукт, починається інженерна лотерея. А в робототехніці лотерея означає ризики, інколи — для життя людей.
У мене є простий внутрішній тест. Наприклад, якщо це евакуаційна платформа, треба запитати себе, чи готовий ти розмістити там пораненого і бути впевненим, що машина не стане посеред дороги? На жаль, по багатьох виробах відповідь — ні. Максимум — «підвезти воду», але не людину.
Фото надане Tech Unity
Нині ми у процесі отримання натівської кодифікації для Jarvis. І це дуже протвережує. Коли ти читаєш вимоги до електромагнітної сумісності, тестових процедур, документації — стає зрозуміло, чому «в них» все довше і дорожче. І чому виріб, який умовно «працює в нас», може не пройти сертифікацію в ЄС чи США. Я не кажу, що закордонні вимоги ідеальні або що нам треба копіювати все «як у НАТО». Але я бачу, що жоден з НРК в Україні сьогодні не пройде кодифікацію за стандартами НАТО.
У підрозділів є склади з технікою, але часто там лежить те, що вони не хочуть брати навіть безкоштовно.
«Мене як інженера це б сильно ображало»
Але якщо робот підводить на місії — він стає не допомогою, а тягарем. І тоді військові починають або переробляти все самі, або збирати з різних компонентів.
«Якщо рішення не працює на ЛБЗ, то воно не працює взагалі». Про тестування і виправлення
Важливою частиною будь-якого дрона є зв’язок. Раніше були ситуації, коли НРК виконував задачу, а оператор мав супроводжувати машину на відстані близько 100 метрів на небезпечній ділянці, бо інакше вона не доїжджала або не тримала керування.
Тоді ми і інші виробники почали працювати над системами зв’язку зі Starlink і LTE. В результаті ми створили Robolink, який дозволив керування на відстані принаймні в частині задач, без прямого ризику для оператора. Тоді багато хто не вірив, що це працюватиме стабільно — мовляв, «Starlink повернеться, пропаде, і все стане». Але технічно ми зробили так, щоб система працювала в реальних умовах.
Ми для себе тримаємо простий принцип: якщо рішення не працює на ЛБЗ, то воно не працює взагалі. Можна протестувати продукт у Києві, у нормальних умовах, але це лише перший фільтр. Тому ми намагаємося будувати процес так, щоб тестування було спільною відповідальністю: ми як команда продукту, виробник як інтегратор у свою платформу, і військові як ті, хто дає чесний фідбек із реальних місій.
Іноді бувають ситуації, коли потрібно реагувати дуже швидко. У нас були кейси, коли після фідбеку з місця доводилося дебажити й випускати правку в максимально стислий час — буквально за декілька годин, бо від цього залежала конкретна задача. Але в нормальному процесі ми намагаємося не жити «пожежами», а закривати максимальну кількість сценаріїв тестуванням і контрольними перевірками, щоб потім у полі не «ловити сюрпризи».
Пригадую випадок із програмним забезпеченням для оптимізації відео. На НРК був не Jarvis, але використовували наше ПЗ для передачі відео. У команди воно не запускалося на конкретному ноутбуці. Ми підняли команду, розібралися, де саме «ламається» запуск, і викотили точковий фікс буквально за кілька годин. Такі ситуації — радше виняток, але це до теми, чому у нас техсапорт і розробка не на аутсорсі.
Фото надане Tech Unity
У нас є QA/QC-логіка, і ми намагаємося тестувати так, щоб покрити максимум можливих сценаріїв. На фронті ніхто не буде поводитися з системою як інженер-розробник. Людина може натиснути не туди, перезавантажити «не так», переплутати послідовність дій, працювати в холоді, в темряві, під стресом тощо. Тому ми проганяємо кейси так, ніби продукт уже в руках у звичайного оператора, який хоче, щоб воно просто їхало і показувало картинку.
Крім «аварійних» історій, є більш рутинні речі: логістичні місії, випробування нових конфігурацій, перевірка оновлень, тестування зв’язку або відео на конкретних платформах. Ми постійно тримаємо контакт із тими, хто використовує наші продукти.
Але нам пощастило з партнерами-виробниками. У нас нормальна робоча синергія. Абсолютно типова ситуація — подзвонити партнеру, попросити підняти конкретну машину і разом протестувати. Ми дивимось відео, телеметрію, поведінку під навантаженням, відловлюємо баги, перевіряємо сценарії. Це економить тижні і зменшує ризик «польових сюрпризів».
«Люди звикають працювати в моделі «є наказ зверху — виконуй». Про проблеми управління і пошук спеціалістів
На сьогодні у нас закриті тільки базові керівні ролі — CEO, CTO і R&D-директор. Повноцінного операційного директора, наприклад, немає. Є людина, яка частково виконує ці функції. Загалом проблема з управлінцями в оборонних компаніях системна.
Моя особиста думка — багато в чому це наслідок того, як в Україні десятиліттями формувалась управлінська культура. Часто я бачу ситуацію, коли людина має
Нам такі управлінці не підходять, бо в нас інженер має працювати усвідомлено. Ми не будуємо «піратську республіку» з криком і тиском, але й не будуємо систему, де хтось один думає, а решта просто виконує. Нормально, що дизайнер приходить і каже: «Давайте додамо цю фічу, бо солдату так буде простіше». Ми це обговорюємо командою і, якщо рішення логічне, робимо.
Фото надане Tech Unity
Я не кажу, що я ідеальний управлінець. Я теж багато чого вчу в процесі. У мене є своя «роадмапа» розвитку в менеджменті, і я точно не вважаю, що все знаю. Просто в цій сфері банально мало середовища, де можна набиратись сильного управлінського досвіду, і ще менше людей, у яких цей досвід справді «живий», а не формальний.
Із спеціалістами на ринку теж непросто. Особливо в ролях, які для військового R&D важливі, але в цивільному IT або майже не були масовими, або були «вузькою нішою».
Наприклад, у мене була мрія знайти в команду людину з penetration testing — умовно «білого хакера». Перевірка систем на злам, кібератаки, стійкість... Для військових систем це важливо. Якщо ти робиш рішення для фронту, ти маєш бути готовим до того, що його будуть ламати, глушити, обманювати, підміняти, шукати слабкі місця. Я шукав таку людину майже рік — і не знайшов навіть для розмови. Можливо, ці спеціалісти є, але вони або в дуже закритих середовищах, або зайняті, або їх банально мало.
В окремих deftech-напрямах зараз платять більше, ніж у комерційному IT. Я знаю Computer Vision інженера, який робив SLAM для агрокомпанії в Україні. Він заробляв близько $3000 у цивільному IT, а після переходу в оборонний сектор отримав офер на рівні $5500.
Такі випадки не рідкість. Але це не означає, що так усюди. Часто це пов’язано з дефіцитними компетенціями, конкретними напрямами або з моделлю фінансування компанії.
У нас в компанії зарплати не вищі за ринкові. Я також заробляю менше, ніж міг би, якби залишився в класичному IT.
«На війні „непередбачуване“ — це не виняток, а норма». Про штучний інтелект
Для нас «штучний інтелект» існує у двох вимірах: як робочий інструмент для розробки всередині команди і як бойова функція в продуктах. Я дещо стримано ставлюся до ШІ у військових виробах.
Можна скільки завгодно сперечатись, але те, що я бачив як справді ефективне «на фронті», коштує відчутні гроші. А щоб здешевити — потрібне масштабування. Щоб масштабувати — воно має стабільно працювати. А для цього потрібен дорогий і довгий R&D. Це замкнене коло, яке неможливо перескочити однією «геніальною ідеєю».
«Робочий ШІ у військових задачах майже ніколи не буває дешевим»
Саме тому я скептично дивлюся на гучні тренди, які регулярно з’являються і так само швидко зникають з порядку денного. Наприклад, нещодавно всі говорили про донаведення, про «рої», «матки», а потім тема різко затихла. Це не тому, що ідея погана в теорії. Це тому, що, коли доходить до реальних сценаріїв, з’являються проблеми. Якщо я везу пораненого, то буду прагнути контролювати процес максимально руками, бо розумію, як об’їхати, як реагувати на непередбачуване, як «вийти з ситуації». На війні «непередбачуване» — це не виняток, а норма.
При цьому я не кажу, що ШІ не потрібен. Навпаки, коли він стане масовим, достатньо дешевим і стабільним хоча б у 90% сценаріїв — я буду одним із перших, хто підтримає його вбудовування. Просто ми ще не там.
«Скоро маємо отримати можливість бронювати спеціалістів». Про плани
Головний фокус цього року — розвиток і масштабування продуктів. Ми хочемо розширювати лінійку рішень під НРК.
Скоро зможемо бронювати спеціалістів. На сьогодні такої можливості немає, і вже декілька наших інженерів мобілізували. Безумовно, вони роблять надважливу справу, але думаю, що у нас їхній внесок міг би бути більш ефективним.
Також є проблема щодо економіки виробництва та залежності від імпорту. Наприклад, прототип може виглядати «на $100», але далі додаються мито, ПДВ, логістика, дистриб’ютори, юристи, бухгалтерія, збірка, тестування — і на виході продукт стає кратно дорожчим. А у deftech для державних контрактів діє обмеження прибутку до 25%, і ми цю планку тримаємо не лише в роботі з державою, а й у комерційних продажах партнерам. Для нас це питання довіри і довгострокової стратегії.
Фото надане Tech Unity
Тому плануємо навчитись працювати на спецефічному обладнанні — PCB-лінії. А також створити виробничий цикл плат і компонентів наших систем. Я хочу робити їх тут не «з принципу», а заради стійкості, швидкості й масштабу. Але це реально лише тоді, коли є гроші, обладнання і стабільний попит. Зараз різниця в собівартості між Китаєм, Європою і Україною дуже відчутна.
