Військові технології України: як працюють команди, що створюють майбутнє на фронті
У сфері цивільного IT давно гуляє жарт: будь-який проєкт рано чи пізно стає битвою з legacy-кодом, нескінченними погодженнями та календарем, напханим сінками і статусними зустрічами. Великі компанії роками вибудовують процеси, які мають зробити розробку передбачуваною, але часто такі процеси настільки гальмують роботу, що від ідеї до реалізації минають місяці.
В українському miltech усе інакше. Тут продукти тестуються не на фокус-групі, а в справжніх бойових умовах. Запит може надійти ввечері з вимогою надати рішення вже наступного дня. У такій ситуації звичні корпоративні правила трансформуються: оборонні технологічні компанії формують унікальну культуру розробки — швидшу, більш жорстку і менш терплячу до бюрократії заради самих процесів.
У розмові з представниками SKIFTECH, Himera, BlueBird, DevDroid, WIY LLC, The Fourth Law і Odd Systems команда dev.ua дізналася, як сучасні defense tech-команди організовують роботу, чи потрібен їм Scrum та PM, як використовують AI, а також чому поєднання hardware і software залишаєтся одним із найбільших викликів.
PM у військових технологіях: не просто координатор, а рушійна сила продукту
З першого погляду може здатися, що в miltech панує хаос із натхненням стартапу: запити сиплються безперервно, продукти змінюються на ходу, часу на довгі обговорення немає. Та реальність набагато глибша.
Усі опитані компанії мають продуктову або проєктну команду, а роль PM тут часто значно виходить за межі класичних IT-позицій. Розглянемо кілька думок учасників:
- SKIFTECH: без PM тут неможливо, адже товар — це не просто софт, а військові рішення з високою відповідальністю. Затримка або помилка може мати важчі наслідки, ніж у цивільних продуктах.
- BlueBird: менеджери глибоко занурені у технічні процеси, координують hardware- та software-команди, пріоритизують завдання і швидко ухвалюють рішення.
- The Fourth Law і Odd Systems: класичні функції PM розподілені між Product Owners (пошук ідей, формування гіпотез) і Engineering Managers (технічна реалізація).
- DevDroid: наголошують на дефіциті кваліфікованих менеджерів. Олег Федоришин, R&D-директор, каже: «Ми не так активно шукаємо програмістів, як людей, здатних керувати процесами, бо управлінський bottleneck — головна перешкода.»
Scrum і фронт: чому класичні методології часто не працюють
В IT давно склалося негласне правило: чим більша компанія, тим більше процесів. Планування спринтів, ретроспективи, статусні зустрічі, узгодження – все це збирає бюрократичний багаж. Але miltech — інша історія.
У SKIFTECH зауважують, що в умовах постійної зміни вимог годинні синхронізації – розкіш, яка кабально витрачає час та ресурси. Замість цього — короткі обміни інформацією, прямі комунікації і прийняття оперативних рішень.
«У defense tech цикл „отримали фідбек — внесли правки — перевірили“ може тривати кілька годин або днів», – пояснюють у компанії.
У більшості компаній застосовують Agile, але відмовляються від суворого дотримання Scrum за книжкою. Наприклад, BlueBird зберігають гнучкість, відмовляючись від «корпоративного Scrum у вакуумі». Процеси підлаштовують під справжні потреби та швидкість команди.
DevDroid пішли ще далі: традиційний Scrum у них не прижився через непередбачуваність завдань. Олег Федоришин зазначає, що Kanban краще підходить для ситуацій, коли завдання виникають блискавично:
- Завтра потрібно терміново оновити сценарій використання обладнання.
- Додати автономні функції під конкретну місію.
- Відкласти до кінця спринту – неможливо, потрібне рішення уже сьогодні.
Досвідчені фахівці переконані: процеси потрібні, але вони мають служити для прийняття швидких, якісних рішень, а не стати самим собою.
Роль MVP у defense tech: швидкість і надійність мають баланс
Можна подумати, що miltech живе за правилами стартап-культури: швидко зробив, швидко перевірив, швидко виправив. Частково так, адже постійні ітерації та перевірка гіпотез – у тренді.
Проте принцип «ship now, fix later» тут мало де спрацьовує. У SKIFTECH наголошують, що помилка в оборонних рішеннях дорого коштує, тому важливий баланс між швидкістю й надійністю.
Himera описує свій підхід так: «Для нас це радше test now, fix now». Рішення проходять безперервну перевірку у польових умовах, а зміни впроваджуються негайно на підставі практичного досвіду користувачів.
Тому MVP – не сирий продукт, а мінімально життєздатне, безпечне для тестування в реальних обставинах рішення.
Особливість українського defense tech – надзвичайно короткий цикл взаємодії між інженером і кінцевим користувачем. Кращим QA тут виступає військовий, що тестує обладнання уже завтра.
The Fourth Law називає це однією з головних переваг галузі: прототип сьогодні – тестування завтра. Реальний фідбек набагато цінніший за лабораторні чи usability-тести. Фактично фронт став для miltech команди користувачем, QA і аналітиком одночасно.
AI в оборонних технологіях: максимально корисний, але не замінить досвід
Одна з тем обговорення – впровадження штучного інтелекту. Усі учасники одностайні: AI стає невід’ємною частиною роботи інженерів.
У SKIFTECH пророкують, що компанії, які не інтегрують AI найближчими роками, ризикують втратити конкуренцію. BlueBird активно користується:
- Copilot, Cursor для кодування;
- agentic coding для автоматизації;
- synthetic data та симуляції;
- нейромережі для комп’ютерного зору й автономних систем у The Fourth Law.
В DevDroid дивляться реалістично: AI – це радше найсильніший junior-інженер, який допомагає розібратися в задачах і прискорити роботу, але поки не досяг рівня middle чи senior.
«AI ще може галюцинувати, особливо у embedded-розробці та роботі з hardware, де навіть впевнені пропозиції бувають помилковими», — зазначає Олег Федоришин.
Виклики «залізо + софт»: синхронізація двох світів
Тут закінчуються звичні правила класичного IT: якщо програмний код можна оновлювати щодня, то hardware – це складний ланцюжок виробництва, тестування, логістики і польових випробувань.
У Himera підкреслюють головну проблему – необхідність одночасно розвивати два світи зі сильно різною швидкістю змін. SKIFTECH додають, що будь-які коригування в софті можуть вплинути на харчування, сенсори чи комунікацію.
Інженери The Fourth Law називають найскладнішим завданням створення повноцінних апаратно-програмних систем, де все взаємопов’язане. В DevDroid підкреслюють: у кризових ситуаціях на полігоні, під дощем і під тиском часу вирішальне значення має людський досвід і інтуїція, а не інструменти.
Без зайвих процесів — лише ефективність
Якщо підвести підсумок сотням відповідей, то звучить це приблизно так: miltech не обходиться без процесів, але без зайвих. Jira, GitLab, Agile, PM, ретроспективи й планування тут є, але кожен інструмент проходить фільтр практичної цінності.
Все, що допомагає швидко, якісно і безпомилково створювати продукти – залишається. Те, що існує заради самого існування процесу – відкидається. Але головна різниця з класичним IT полягає в іншому.
У цивільних продуктах помилка – це просто незадоволений клієнт, знижений прибуток чи втрата контракту. У військових рішеннях вартість помилки значно вища. Звідси випливає те, що українські miltech-команди навчені йти швидше, але при цьому надзвичайно відповідально ставитись до якості.
Фактично фронт став найвимогливішим продакт-менеджером, QA-інженером і користувачем водночас. А це означає, що між рішенням, ухваленим в лабораторії чи офісі, і його тестуванням у реальному світі може пройти не місяць і навіть не тиждень, а кілька днів.
