Марія Бровінська Робота 8 червня 2026, 09:00

«У нас немає двох тижнів на спринт». Як український miltech навчився працювати без legacy, нескінченних мітингів і корпоративної бюрократії

У цивільному IT давно є жарт, що будь-який проєкт рано чи пізно перетворюється на боротьбу з legacy-кодом, нескінченними погодженнями та календарем, забитим синками й статусними зустрічами. Великі компанії роками будують процеси, які мають робити розробку передбачуваною, але часто сповільнюють її настільки, що від появи ідеї до її реалізації минають місяці.

Український miltech сьогодні живе в іншій реальності.Коли продукт тестується не на фокус-групі, а в реальних бойових умовах, а запит від військових може надійти ввечері з вимогою отримати рішення вже наступного дня, звичні корпоративні правила починають працювати інакше. Саме тому оборонні технологічні компанії поступово формують власну культуру розробки — швидшу, жорсткішу і значно менш терпиму до процесів заради процесів.

dev.ua поспілкувався з представниками SKIFTECH, Himera, BlueBird, DevDroid, WIY LLC, The Fourth Law та Odd Systems, щоб зрозуміти, як насправді працюють сучасні defense tech-команди, чи потрібні їм Scrum і PM, як вони використовують AI та чому поєднання hardware і software залишається одним із найскладніших інженерних викликів галузі.

Залишити коментар

«У нас немає двох тижнів на спринт». Як український miltech навчився працювати без legacy, нескінченних мітингів і корпоративної бюрократії

У цивільному IT давно є жарт, що будь-який проєкт рано чи пізно перетворюється на боротьбу з legacy-кодом, нескінченними погодженнями та календарем, забитим синками й статусними зустрічами. Великі компанії роками будують процеси, які мають робити розробку передбачуваною, але часто сповільнюють її настільки, що від появи ідеї до її реалізації минають місяці.

Український miltech сьогодні живе в іншій реальності.Коли продукт тестується не на фокус-групі, а в реальних бойових умовах, а запит від військових може надійти ввечері з вимогою отримати рішення вже наступного дня, звичні корпоративні правила починають працювати інакше. Саме тому оборонні технологічні компанії поступово формують власну культуру розробки — швидшу, жорсткішу і значно менш терпиму до процесів заради процесів.

dev.ua поспілкувався з представниками SKIFTECH, Himera, BlueBird, DevDroid, WIY LLC, The Fourth Law та Odd Systems, щоб зрозуміти, як насправді працюють сучасні defense tech-команди, чи потрібні їм Scrum і PM, як вони використовують AI та чому поєднання hardware і software залишається одним із найскладніших інженерних викликів галузі.

PM у miltech — не координатор зустрічей, а людина, яка рухає продукт

З боку може здатися, що в miltech панує майже стартапний хаос: фронт постійно генерує нові запити, продукти змінюються буквально на ходу, а часу на багатогодинні обговорення немає. Але реальність виявилася складнішою.

Усі компанії, з якими поспілкувався dev.ua, мають продуктові або проєктні команди, а роль PM тут часто навіть ширша, ніж у класичному IT.

У SKIFTECH зазначають, що без PM неможливо обійтися навіть у військових технологіях, однак рівень відповідальності тут значно вищий. Менеджери не просто ведуть проєкти, а працюють із продуктами, які використовуватимуть військові, тому затримка чи помилка можуть мати значно серйозніші наслідки, ніж у цивільному софті.

У BlueBird також говорять, що PM у miltech значно глибше занурений у розробку та технічні процеси, ніж його колеги в багатьох IT-компаніях. Значна частина роботи пов’язана з координацією hardware- та software-команд, пріоритизацією задач і швидким ухваленням рішень.

Своєю чергою у The Fourth Law та Odd Systems визнають, що частину класичних функцій PM взагалі розподілили між Product Owners та Engineering Managers. Перші займаються пошуком ідей, формуванням гіпотез і пріоритизацією, другі — реалізацією та технічними рішеннями.

А у DevDroid кажуть, що сьогодні їм бракує саме менеджерських кадрів. «Ми навіть не так активно набираємо програмістів чи технічних спеціалістів в R&D, бо розуміємо: без достатньої кількості людей, які можуть керувати процесами й проєктами, ми просто впремося в управлінський bottleneck», — пояснює R&D-директор DevDroid Олег Федоришин.

Чому Scrum на фронті часто програє реальності

У цивільному IT давно існує негласне правило: що більша компанія, то більше процесів. Планування спринтів, ретроспективи, статусні зустрічі, узгодження між командами, погодження між менеджерами. З часом усе це часто обростає додатковими рівнями бюрократії.

У miltech ситуація інша. Зокрема, у Skiftech кажуть, що коли продукт працює в умовах постійних змін вимог, десятки годин sync-мітингів перетворюються на розкіш. Замість цього працюють короткі синки, прямі комунікації та швидкі рішення.

«У defense tech цикл „отримали фідбек — внесли зміни — перевірили“ може тривати дні або навіть години», — пояснюють у компанії.

Саме тому більшість опитаних компаній використовують Agile-підходи, але майже ніхто не працює за книжкою. У BlueBird кажуть, що команди залишаються Agile, але без «корпоративного Scrum у вакуумі». Процеси підлаштовуються під інженерів та реальну швидкість розробки, а не навпаки.

У DevDroid пішли ще далі. «Класичний Scrum у наших умовах працює погано. Ближче нам зараз Kanban, тому що задачі можуть з’являтися буквально на вчора», — розповідає R&D-директор компанії Олег Федоришин.

Він наводить показовий приклад. Якщо військовим завтра потрібно реалізувати новий сценарій використання обладнання або додати елемент автономності для конкретної місії, команда не може відповісти: «У нас зараз спринт, повернемося до цього через два тижні». «Їм потрібно рішення сьогодні або максимум завтра, тому реальність фронту диктує зовсім іншу швидкість роботи. У нас немає двох тижнів на спринт», — каже він.

Втім, це не означає відсутності процесів. Навпаки, майже всі співрозмовники dev.ua підкреслюють: без процесів створювати складні технологічні продукти неможливо. Але процеси мають допомагати ухвалювати рішення, а не заважати їм.

MVP працює. Але «ship now, fix later» — ні

На перший погляд, може здатися, що miltech живе за канонами класичної стартап-культури: швидко зробив, швидко перевірив, швидко виправив. Частково це справді так. Усі компанії говорять про швидкі ітерації, постійне тестування та перевірку гіпотез. Але майже всі одночасно наголошують: принцип «ship now, fix later» у військових технологіях працює дуже обмежено.

Зокрема, у SKIFTECH пояснюють, що помилка в defense tech може коштувати набагато дорожче, ніж у типовому програмному продукті, тому швидкість завжди доводиться балансувати з надійністю.

Натомість у Himera описують підхід інакше: «Для нас це радше test now, fix now. Рішення мають проходити постійну перевірку в реальних умовах, а зміни впроваджуються максимально швидко на основі практичного досвіду користувачів».

Саме тому MVP у miltech зазвичай означає не «сирий продукт», а мінімально достатнє рішення, яке вже можна безпечно перевіряти в польових умовах.

Одна з найцікавіших особливостей українського defense tech — короткий шлях між інженером і кінцевим користувачем. Найкращий QA у галузі — це військовий, який тестує продукт завтра. У The Fourth Law називають це однією з головних переваг галузі. Прототип, створений сьогодні, може опинитися на тестуванні вже наступного дня. А фідбек від людей, які використовують продукт безпосередньо в реальних умовах, часто виявляється значно ціннішим за будь-які лабораторні чи usability-тести.

Фактично фронт став для українських defense-tech команд одночасно користувачем, QA-відділом і продуктовою аналітикою.

AI уже всюди. Але він ще не senior-інженер

Ще одна тема, щодо якої компанії виявилися напрочуд одностайними, — AI поступово стає невіддільною частиною інженерної роботи.

У SKIFTECH прямо говорять, що компанії, які не інтегруватимуть AI у найближчі роки, ризикують втратити конкурентоспроможність.

Фахівці BlueBird активно використовують Copilot, Cursor, agentic coding, synthetic data та simulation-середовища. Своєю чергою інженери The Fourth Law працюють як із загальними моделями на кшталт GPT і Gemini, так і з власними нейромережами для задач комп’ютерного зору та автономних систем.

Утім, найбільш прагматичний погляд на AI озвучили в DevDroid.

«Сьогодні AI для нас — це радше дуже сильний junior-спеціаліст, який може допомогти розібратися, пришвидшити роботу чи взяти на себе частину задач. Але це ще не впевнений middle і точно не senior», — каже Федоришин.

Особливо це помітно в embedded-розробці та роботі з низькорівневим hardware, де моделі все ще можуть галюцинувати або впевнено пропонувати рішення, які не існують у реальності.

Найважче починається там, де зустрічаються hardware і software

Саме тут, за словами практично всіх співрозмовників, закінчуються звичні правила класичного IT. Якщо програмний продукт можна оновлювати кілька разів на день, то hardware підпорядковується зовсім іншим законам. Виробництво, компоненти, логістика, тестування, полігони та польові випробування неможливо прискорити так само як деплой нової версії застосунку.

У Himera кажуть, що головна складність полягає в необхідності синхронно розвивати два світи з абсолютно різною швидкістю змін. А у SKIFTECH наголошують, що будь-яка зміна в програмному забезпеченні може вплинути на поведінку сенсорів, електроніки, енергоспоживання чи зв’язку.

Найцікавішою інженерною задачею сучасного miltech у The Fourth Law називають створення повноцінних апаратно-програмних систем, де кожен компонент впливає на інші. А у DevDroid додають, що саме в таких моментах особливо помітною стає роль людського досвіду. Адже коли система поводиться непередбачувано, а проблему потрібно шукати на полігоні під дощем, в умовах стресу та обмеженого часу, вирішальними стають не інструменти, а інженерна інтуїція та досвід команди.

Без зайвих процесів

Якщо спробувати звести десятки відповідей від різних українських defense-tech компаній до однієї думки, вона звучатиме доволі просто: miltech не працює без процесів. Він працює без зайвих процесів. Усі звичні для IT інструменти тут залишаються на місці. Є PM-и, Jira, GitLab, Agile-практики, ретроспективи та планування. Але кожен із цих елементів проходить перевірку на практичну цінність. Якщо процес допомагає швидше створювати якісний продукт — він залишається. Якщо починає існувати заради самого себе — його прибирають.

Втім, головна відмінність defense tech від класичного IT лежить ще глибше. У цивільних продуктах помилка часто означає незадоволеного клієнта, втрачений контракт або падіння конверсії. У військових технологіях ціна помилки значно вища. Саме тому українські miltech-команди одночасно змушені рухатися швидше за більшість IT-компаній і бути значно обережнішими з якістю рішень.

Фактично фронт став для українського miltech найбільш вимогливим продакт-менеджером, QA-інженером і користувачем одночасно. А це означає, що між рішенням, ухваленим сьогодні в офісі чи лабораторії, та його перевіркою в реальному світі іноді проходять не місяці й навіть не тижні, а лише кілька днів.