PM у miltech — не координатор зустрічей, а людина, яка рухає продукт
З боку може здатися, що в miltech панує майже стартапний хаос: фронт постійно генерує нові запити, продукти змінюються буквально на ходу, а часу на багатогодинні обговорення немає. Але реальність виявилася складнішою.
Читайте также: 4A Games показала перший геймплей Metro 2039: новий диктатор у москві та реліз у 2027 році
Усі компанії, з якими поспілкувався 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-мітингів перетворюються на розкіш. Замість цього працюють короткі синки, прямі комунікації та швидкі рішення.
Саме тому більшість опитаних компаній використовують 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.
Особливо це помітно в 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-інженером і користувачем одночасно. А це означає, що між рішенням, ухваленим сьогодні в офісі чи лабораторії, та його перевіркою в реальному світі іноді проходять не місяці й навіть не тижні, а лише кілька днів.
Читайте также: Оксана Жданова Колишній Чоловік: подробности личной жизни и карьеры