Олександр Піхтовніков – проєктний менеджер з п’ятирічним досвідом і міжнародними клієнтами. Він вміє запевнити кого завгодно, в чому завгодно. А тепер ще й склав курс з проєктного менеджменту для Beetroot Academy. Ми вирішили поставити Сашкові як очевидні, так і вузькопрофільні питання. Запитали – що краще, Agile, чи Waterfall. Дізналися, як спрацюватися продакту й проджекту. Поговорили про перспективи зростання, співбесіди та заробітні плати.
Проєктом може бути що завгодно – будівництво мосту, дороги, будинку. Це не обов’язково пов’язано з ІТ. Проєкт має критерії: дата старту, відповідальний, спонсор й дата очікуваної здачі.
Я так не вважаю. В Agile – це людина, яка спрямовує розробників в потрібному напрямку. Він радить, але не вказує, що робити. Хтось може зі мною не погодитися, але для мене проєктний менеджер – не начальник.
Є старі формати в дусі: “Лише я володію інформацією. Лише я знаю, що ми маємо зробити”. Всі сидять і чекають, доки менеджер щось скаже. Він може маніпулювати даними, знає потреби замовника, всі вважають його за боса.
Насправді на проєкті має бути цілковита прозорість. Ти ділишся інформацією з командою та залучаєш усіх. Ти не можеш самостійно відповідати за весь проєкт. Якісь зони відповідальності делегуєш, отримуєш зворотний зв’язок від команди. В реаліях Agile ти не можеш звільняти людей, але можеш вплинути. Якщо хтось недопрацьовує, треба поговорити зі стейкхолдерами й з командою. Якщо після цього ситуація не змінилася, потрібно робити заміну.
В класичному проєктному менеджменті начальником є спонсор. Він каже, що його не влаштовує, диктує формат роботи, каже, чи потрібно когось замінити. Він не відповідає за фінанси, але має важелі впливу. При цьому замовник і спонсор – це можуть бути дві різні людини.
Все залежить від проєкту, від його рівня складності, від кількості людей, від специфіки. В зрілій команді до 4-5 людей, можливо, проєктний менеджер і не потрібний. Завдання програміста – написати класний код, щоб все добре працювало. Програмісти не завжди цікавляться – чого хоче бізнес. Але, якщо розробнику це подобається, він виконує роль проксі-проджект-менеджера.
Коли з’являються міні-проєкти, завдання ускладнюється. Налагоджування процесів і комунікація з клієнтом займають багато часу. Програміст припиняє кодити, виявляється, весь час пішов на спілкування. В такому випадку краще найняти людину, яка розбирається в бізнес-аспектах, фільтрує інформацію та тримає баланс між програмістами й бізнесом.
Продакт-менеджер – це дуже “бізнесова” людина. Він добре знається на продукті та на потребах клієнта. Розбирається в цифрах, любить аналітику. Наприклад, змінили колір кнопки й посунули на 7 пікселей вліво – він перевірить, чи стало краще, або гірше, чи вплинуло це на форми реєстрації або на систему оплати.
Продакти багато спілкуються з кінцевим користувачем, з клієнтом, з програмістами. Продакт-менеджер може працювати над покращеннями системи, він знається на дизайні. Проєктний менеджер, як правило, не впливає на кінцевий дизайн. Він не заглиблюється так, як продакт. Якщо проєкт складний та є багато даних, проєктний менеджер налагоджує зв’язок зі стейкхолдерами та координує сам проєкт. Продакт каже, які потрібні фічі, виходячи з аналітики. У великих проєктах це тандем, але вони можуть працювати й окремо.
За наявності готового продукту наймайте продакт-менеджера. Він дивитиметься на цифри, спілкуватиметься з користувачами. Якщо проєкт лише розпочався – потрібен проджект. Він розбереться в процесах, налагодить комунікацію зі стейкхолдерами й командою.
Я не вважаю, що хтось крутіший, а хтось гірший. Кожний по-своєму крутий. Можна перейти з однієї посади на іншу, якщо тобі це подобається. Продакт любить дизайн і естетику. Проджект налагоджуватиме комунікацію.
Олександр з командою
Я працював віддалено з командою з 16 осіб. Ти маєш повністю довіряти людям. Потрібно частіше зідзвонюватись, аби бути в курсі. Якщо команда зріла – все вийде.
Я навчався в Німеччині й в Молдові – вивчав економіку та менеджмент, а потім – інформаційні технології. Гарною базою буде економічна освіта, але все залежить від школи. Мені зустрічалися люди, які переходили з інших галузей. Не думаю, що потрібна профільна вища освіта – те, чого навчають в інститутах, не завжди можна застосувати.
Є програм-менеджмент – коли в тебе з’являється більш ніж 2-3 проєкти, ти відповідаєш за постановку, є декілька проджектів в підпорядкуванні. Або ж можна зростати в делівері менеджменті. Вище – програмний директор і СЕО компанії.
Це непогано, але не обов’язково. Потрібно розуміти, що таке баг, як проходить цикл розробки. Навчитися розмовляти із розробниками однією мовою. Я знаюся на архітектурі застосунку, циклі розробки, практиках на проєкті. Це приходить із досвідом. Не потрібно мати диплом або вміти кодити – в реальності це не знадобиться. Робота проєктного менеджера на 40% – комунікація.
Waterfall добре пасує до великих індустріальних проєктів. Agile на 90% використовується в ІТ – ринок динамічний, потрібно якось адаптуватися. Agile – це той самий Waterfall, але менший. В Waterfall ми за три місяці після початку розробки дізнаємося, що щось не так, а вже маємо готову архітектуру. Тут менше гнучкості. В Agile команда підписується на певний проміжок часу, наприклад – 10 робочих днів. По завершенню – отримує відгуки клієнтів, користувачів, аналізує ринок та розуміє, чи у вірному напрямку рухається.
Які проєкти він чи вона вели? Складності, розмір команди, чи випадала нагода вирішувати проблемні кейси. Адже, зазвичай, всі проблеми на PM валяться. Якщо щось іде не так – це провина проєктного менеджера. Якщо все добре – це заслуга команди. Проєктний менеджер тримається в тіні.
Можуть запитати, чи спілкувалися зі стейкхолдерами безпосередньо, за яким фреймворком працювали.
Цікаві запитання – ситуаційні. Часто питають: “Як би ти поводився в цій ситуації?” Відповідь допомагає зрозуміти, чи підходите ви під структуру компанії, команди, самого проєкту.
Мені на співбесіді цікаво дізнатися, що керує людиною, які її принципи. Дивлюся на поведінку – важливо зрозуміти динаміку співбесіди. Одне з улюблених питань: “Уявіть, що команда виконує все вчасно без проєктного менеджера. Що керує людьми?” У відповідь проєктний менеджер скаже про власну приховану мотивацію.
Зрозуміти й пробачити. Потрібно бути готовим до того, що не стане коштів. Або ж тебе не влаштує культура компанії, хоча проєкт подобається. Або ж ти просто не розвиваєшся.
Я намагався доводити до завершення всі проєкти, але одного разу пішов через токсичне середовище в команді й в компанії. Було складно спілкуватися, але мені все одно вдалося налагодити процеси.
Налагоджуйте гарні стосунки із клієнтом. Якщо ви довго працюєте й розумієте один одного, можна пояснити, чому саме ці технології важливі. В нашому випадку проєктний менеджер виступає від імені компанії, але він має враховувати інтереси клієнта. Потрібно розуміти, який зиск з цих технологій, обговорювати нюанси з технічними фахівцями. Коли клієнт тобі довіряє та бачить результати, він готовий слухати.
Якщо команда залучена до бізнесу, можна обговорити ризики, але, як правило, клієнт краще знає свій бізнес. Потрібно дослуховуватися до клієнта так само, як і він дослуховується до програмістів, коли мова йде про технічні нюанси.
Agile потрібний, аби розуміти, чи рухаємося ми у вірному напрямку. На восьмий день ми показуємо, над чим працюємо. Отримуємо фідбек й можемо адаптуватися під вимоги клієнта.
Потрібно зрозуміти, чому взагалі виникла така ситуація. На моєму проєкті люди розуміють, чому кожен з них отримує ту чи іншу суму. Різниця в зарплатах може бути до 20% при однакових функціях. Або ж хтось когось дурить.
Я люблю систему оцінки “360” – кожен робить крос-фідбек. Ми розуміємо, що покращити, в кого які слабкі сторони. Тоді не виникає питання, що хтось отримує більше. Створюється культура довіри.
Я даю співробітнику ту суму, яку він просить, навіть якщо вона нижча за ринкову. Якщо за якийсь час він зрозуміє, що не оцінив об’єм та складність робіт та попросить про підвищення – я підвищу. В ІТ поширений синдром самозванця, тому люди можуть занижувати заробітну плату. Мені й самому іноді не зрозуміла, як так цінується моя робота. Але гірше, коли людина без досвіду має завищені вимоги. Страшно уявити, що буде, коли вона набуде більшого досвіду.
Буває, зарплату підвищують тільки тоді, коли ти маєш офер від іншої компанії. Раптом з’ясовується, що роботодавець має гроші на все. Це проблема культури компанії. Я вважаю, що 10-15% за рік – нормальне зростання.
Проєктний менеджмент підійде не всім. Не зможуть працювати інтроверти, ті, хто не любить спілкуватися. Підійде тим, хто хоче більше дізнатися про бізнес, зрозуміти, що “під капотом” у розробників та бути містком між бізнесом й технічними фахівцями. Це тонка навичка, не в кожного виходить. Але з часом ти вибудовуєш власний підхід, вчишся читати емоції, працювати з людьми та давати їм можливості зростання й розвитку
Якщо ви починаєте розбиратися в розробці дронів, чотири назви трапляються постійно: Betaflight, INAV, PX4 і ArduPilot. Усі чотири – прошивки для польотних контролерів, і всі керують апаратом у польоті. Але архітектура в них різна, бо створювали їх під різні задачі й різне залізо.
Польотний контролер — це плата з мікроконтролером і сенсорами (гіроскоп, акселерометр, барометр, іноді GPS і компас), яка керує дроном у польоті. Прошивка - це програма на цій платі: вона зчитує дані сенсорів і команди пілота, стабілізує апарат і керує моторами. Від прошивки залежить, що вміє дрон: різко маневрувати у FPV, утримувати позицію за GPS чи самостійно виконувати місію за точками.
Звідки ця різниця? Найпростіше пояснити через історію, бо ці прошивки походять із двох окремих гілок розробки.
Перші аматорські польотні контролери працювали на Arduino з 8-бітними мікроконтролерами ATmega. На такому залізі почалися обидві гілки.
Перша гілка – ArduPilot (в українському сегменті його часто пишуть як «ардупілот»). Він з'явився наприкінці 2000-х на платах APM на базі Arduino і від початку задумувався як автопілот із місіями за точками й автономною навігацією. Коли ETH Zurich разом із 3D Robotics випустили 32-бітну плату Pixhawk, ArduPilot перейшов на неї. Навколо Pixhawk згодом виріс і PX4.
Друга гілка почалася з MultiWii, і задача там була скромніша. Прошивка працювала на Arduino з гіроскопом, який діставали з контролера Nintendo Wii (звідси назва), і мала просто стабілізувати мультиротор на дешевому слабкому процесорі. Тому ця лінія з самого початку трималася простої математики і спрощеного PID-контролера.
8-бітного Arduino швидко стало замало: не вистачало ні швидкодії, ні пам'яті. MultiWii переписали під 32-бітні мікроконтролери STM32F1, і так з'явився Baseflight разом із першими STM32-контролерами на кшталт Naze32.
CleanFlight відгалузився від Baseflight. Зробив це розробник Домінік Кліфтон, відомий як Hydra, і причини в нього були цілком практичні. Код Baseflight було важко підтримувати, прошивка працювала лише на кількох платах, а нові функції додавалися повільно. У CleanFlight код переписали чистіше, додали підтримку інших контролерів, нові PID-контролери і blackbox-логування польотів.
Спільнота навколо CleanFlight росла, і з часом розробники захотіли різного. Одним потрібна була максимальна продуктивність 5-дюймових мультироторів, іншим – GPS і навігація. Так з'явилися два окремі проєкти, Betaflight та INAV, а сам CleanFlight поступово втратив користувачів і перестав розвиватися як окрема прошивка.
Тож CleanFlight є предком Betaflight та INAV, а ArduPilot і PX4 до нього стосунку не мають.
Betaflight виріс із запиту на продуктивність мультироторів. Розробники вкладаються у швидкий цикл стабілізації, фільтри й тонке налаштування PID, і серед FPV-пілотів ця прошивка стала фактичним стандартом.
Список підтримуваних апаратів у Betaflight довший, ніж можна подумати. Крім квадрокоптерів у X- і +-конфігурації, там є трикоптери, гекса- й октокоптери, літаюче крило і літак із сервоприводами. Проте розвивається прошивка передусім навколо мультироторів, і найсильніша вона саме там.
Налаштовують Betaflight через Betaflight Configurator. Там прошивають плату, налаштовують PID, фільтри, режими польоту та OSD.
INAV – друга гілка CleanFlight. Її розробники зробили ставку на GPS і навігацію, тому основні режими тут – утримання позиції й висоти, повернення додому і польоти за маршрутом.
INAV добре працює з літаками й крилами, але на ній можна зібрати і мультиротор, ровер чи човен, бо мікшер налаштовується гнучко. Апарат програмують через графічний інтерфейс за допомогою логічних умов і глобальних змінних. Так, наприклад, налаштовують перемикання відеопередавача (VTX) за певних умов.
PID-контролер і фільтри в INAV влаштовані інакше, ніж у Betaflight, хоча загальний принцип той самий.
ArduPilot – найстаріша з чотирьох платформ і класична база для автопілотів. Під кожен тип апарата в цьому сімействі є своя прошивка:
ArduPilot цінують за перевірену стабілізацію, розвинену навігацію, велику документацію і спільноту. Його ставлять там, де апарат має виконувати місію передбачувано. Для зв'язку з апаратом ArduPilot використовує протокол MAVLink, а місії планують у наземних станціях Mission Planner або QGroundControl.
PX4 – автопілот того ж класу, що й ArduPilot. Він розвивається разом з екосистемою Pixhawk, тож під нього є найсучасніше залізо.
Архітектура PX4 модульна: компоненти обмінюються даними через внутрішню систему повідомлень, і з прошивки можна прибрати все, що не потрібно у вашому проєкті. Є інтеграція з ROS 2 і розвинені інструменти симуляції. Основні типи апаратів – мультиротори, літаки, VTOL і ровери. Гелікоптери, дирижаблі, човни й підводні апарати теж підтримуються, але на базовому рівні.
Універсальної найкращої прошивки немає. Вибір залежить від того, що саме ви будуєте.
Для FPV-збірки логічно почати з Betaflight, а для маршрутних місій на крилі з легким контролером підійде INAV. Якщо потрібен повноцінний автопілот, вибирати доведеться між ArduPilot і PX4. Перший дає перевірену базу, другий дає модульну архітектуру та інтеграцію із сучасним робототехнічним стеком.
Коли з прошивкою визначилися, починається практика: прошити політник, налаштувати PID, зібрати апарат, який справді літає. Цьому присвячена освітня програма Drones Firmware в Beetroot Academy, де стек дронів розбирають на реальному залізі.
Матеріал підготовлено спільно з інженером із багаторічним досвідом розробки БпЛА, якого ми не можемо назвати через безпекові причини. Також радимо прочитати, чому інженери у Defence Tech “стирають” себе з інтернету.
У другому кварталі 2026 року оборонні компанії опублікували на DOU 3518 вакансій, на 17,1% більше, ніж кварталом раніше. Deftech зайняв 17% усього ринку вакансій в українському IT і став одним з найбільших сегментів ринку праці серед технічних напрямів.
За перше півріччя 2026 року в оборонному секторі опублікували 6523 нові вакансії — більше, ніж за весь 2025 рік, коли їх було 5915. Найпродуктивнішим місяцем став червень: 1285 нових позицій за 30 днів.
Дані по кварталах показують стабільне зростання протягом усього року, без різких провалів.
Разом із кількістю вакансій зросла і кількість відгуків: у травні 2026 їх було 9303, тоді як роком раніше — лише 3534. Ринок і росте, і одночасно привертає більше уваги кандидатів.
Найбільше зростання у II кварталі показав напрям Hardware — 646 вакансій, майже стільки ж, скільки за все друге півріччя 2025 року. Поруч тримаються QA, Embedded і Project Manager: ці чотири категорії стабільно очолюють список найпопулярніших спеціалізацій.
Серед розробницьких стеків найбільш затребувані C++ та Python — саме ці мови зазвичай вимагають у вакансіях embedded-інженерів і фахівців з firmware для БПЛА.
Конкуренція за вакансії Hardware та Embedded найнижча серед усіх технічних категорій у deftech, і саме тут роботодавці найчастіше скаржаться на брак кандидатів. Кількість відгуків на embedded-вакансію практично не змінилася за квартал (−0,2), тоді як у Project Manager чи QA вона зростає.
Для порівняння: в категорії QA в deftech у середньому 25 відгуків на вакансію, а в IT загалом — 77. Різниця в три рази пояснюється просто: код фронтенду вміють писати тисячі людей, а працювати з UART, I2C, SPI, читати документацію на STM32 чи налаштовувати PID-регулятор у Betaflight чи ArduPilot — набагато менше.
Найбільшу кількість відгуків традиційно отримують вакансії Project Manager — у середньому 31,6 відгуків. QA на другому місці з 24,9, а DevOps показав найбільший приріст конкуренції за квартал (+10,5).
Водночас середня кількість відгуків на deftech-вакансію загалом — 10,2. Це помітно менше, ніж на аналогічні позиції у звичайному IT, де конкуренція за той самий досвід і той самий стек часто вища в кілька разів.
Серед нетехнічних вакансій найбільша конкуренція у II кварталі була на позиції Copywriter (18,8 відгуків на вакансію) і Sales (16,4), а найменша — на Support: кандидатів на ці вакансії відгукується мало навіть на тлі загального зростання інтересу до сектору. З-поміж усіх нетехнічних напрямів найчастіше шукають людей у категоріях HR, Support, Sales і Marketing — саме тут відкривається найбільше позицій для тих, хто йде в defence не через інженерію, а через свою наявну експертизу.
Роботодавці дедалі частіше шукають фахівців із досвідом, а не новачків. У II кварталі найбільше вакансій відкрили для кандидатів з 1–3 роками досвіду — 1210 позицій. Попит на спеціалістів із 3–5 роками зріс на 138 вакансій за квартал, а на фахівців з 5+ роками — на 67.
Водночас кількість вакансій для junior-рівня скоротилася з 287 до 227. Вхід у сектор лишається відкритим: вакансій без вимог до досвіду стало навіть більше, 54 проти 26 кварталом раніше. Просто шлях частіше лежить через базову технічну підготовку, ніж через співбесіду з чистого аркуша.
Київ традиційно лідирує і продовжує зростати — 2922 вакансії у II кварталі, майже на 500 більше, ніж у попередньому. Але цікавіша динаміка в інших містах: в Одесі кількість вакансій зросла з 24 до 83 за пів року, у Дніпрі — з майже нуля наприкінці 2024 року до 46 у II кварталі 2026-го. Віддалених вакансій — 273, і цей показник тримається стабільно після різкого стрибка на початку року.
Медіанна зарплата фахівців у deftech у червні 2026 року становить $2500, в IT загалом $2700. Розробникам платять більше: їхня медіана в deftech зросла за пів року на $350 і дійшла до $3200. dou
Цифри залежать від ролі. Ось медіани з зарплатного опитування DOU:
Найвищі медіани в deftech мають DevOps, Hardware-інженери та продакт-менеджери, а зарплати інженерів БпЛА одні з найнижчих. Тому для embedded-інженера цікаво дивитися не лише на власну роль, а й на суміжний hardware-напрям, де медіана вища. dou
Найбільша різниця з IT видна на краях шкали:
Початківцям deftech платить більше, ніж ринок IT загалом, а на сеньйорських рівнях виплати поки нижчі. Розрив із IT на рівні Senior скорочується: пів року тому сеньйори в deftech заробляли $3800. Це добре поєднується з даними про вакансії: порогом входу є базова hardware-підготовка, а не стаж. dou
Це медіани з опитування, а не вилки з вакансій. Вибірка в DOU невелика: 542 відповіді з deftech, з них 127 від розробників. DOU попереджає, що за окремими спеціалізаціями анкет небагато, тому результати можуть відчутно коливатися. Для Hardware-інженерів вибірка найменша, тож $4000 варто сприймати як орієнтир. dou
Джерело: DOU, «Зарплати фахівців у DefTech — літо 2026», опитування червня 2026.
Цифри показують закономірність: ринку потрібні фахівці з конкретною hardware-базою (embedded, firmware, hardware-дизайн), а не універсальні джуніори. Тому попит на курси з оборонних технологій і освітні програми з embedded зростає швидше, ніж встигає з'являтися пропозиція готових кадрів.
Освітня програма Embedded Development на Beetroot Academy розрахована саме на цей перехід: 5 місяців, тричі на тиждень, від основ електроніки та мікроконтролерів STM32 і ESP32 до протоколів UART, I2C, SPI, PCB-дизайну в KiCad і багатозадачних систем на FreeRTOS. Практика — на реальному залізі зі стартовим набором з 45 компонентів.
Для тих, хто вже має embedded-базу і хоче спеціалізуватися вужче, є курс Drones Firmware — 2 місяці, робота з Betaflight, ArduPilot, PX4 та MAVLink, фінальний проєкт у SITL-симуляторі.
Ринок deftech у 2026 році росте швидше, ніж встигає готувати кадри, і саме тому технічна база в embedded і hardware зараз цінується більше, ніж диплом чи вхідний рівень англійської.
Дані галузевих оглядів, липень 2026 (DOU, аналітика ринку праці в оборонці).
Project management у defence tech виглядає як звичайний PM в ІТ, поки не доходить до першого hardware-релізу. Тоді з'ясовується: спринт не рятує, коли партія плат застрягла на кордоні, а Jira-борд нічого не каже про те, що зміна ревізії плати зсуває весь дедлайн на два місяці.
За останні два роки кількість PM-вакансій у секторі зросла у 20 разів. Медіанна зарплата — $2 500 на місяць, вище, ніж у класичному ІТ. А PM, який розуміє embedded, FPGA чи hardware-цикли, отримує на $500–1 000 більше за колегу без цього досвіду. Ринок росте швидше, ніж встигає готувати людей. Розберімось, у чому саме різниця.
Класичний ІТ PM веде продукт від беклогу до релізу, і релізів у нього десятки на рік. У defence tech проєкт рухається по іншому маршруту: вимоги → R&D → testing → production → deployment. Кожен з цих етапів має свою логіку, свої gate'и і свою команду.
Софт можна відкотити патчем. Партію друкованих плат — ні. Якщо помилку в вимогах знайшли після того, як пішла серія, це не баг-репорт, це — втрачені гроші, час і часто компоненти, яких більше нема на складі. PM, який веде такий проєкт, відповідає не за спринт, а за весь ланцюжок: від першого начерку ТЗ до техпідтримки в полі.
Розрив між ІТ-логікою і defence-реальністю виглядає не абстрактно, а дуже предметно:
Після переходу картина інша: PM веде повний цикл – від вимог і R&D до testing, production readiness і deployment, планує R&D через WBS, milestones, dependency map і critical path, і бачить integration між hardware, firmware, software і production, а не лише свою частину процесу.
В ІТ-проєкті якість — це code review і QA-цикл. У defence tech додається ще один шар: ISO, AQAP, MIL-STD, ДСТУ. PM не мусить бути інженером-стандартизатором, але має розуміти, які readiness gates існують і хто ухвалює рішення «go» чи «no-go» на кожному з них.
Це governance іншого рівня. Пропущений gate — це ризик, що продукт не пройде приймання чи не отримає потрібний сертифікат уже після того, як у нього вкладені місяці роботи.
«FPGA не встигне до SOP» — фраза, яку класичний PM просто не розшифрує. У defence tech PM має розуміти архітектуру продукту на рівні hardware, embedded, firmware і software настільки, щоб читати технічну документацію, розбиратись у BOM і бачити, де саме виникає integration risk.
Йдеться про здатність розмовляти з інженерами їхньою мовою і самостійно оцінювати стан проєкту без «перекладача», який пояснює технічний фідбек звичайними словами.
Agile-мислення класичного PM ламається на перших же R&D-ітераціях. У hardware-проєкті частину задач неможливо оцінити наперед і чистий Scrum тут не працює.
Замість спринтів — WBS, milestones, dependency map і critical path. Замість point estimation — three-point estimation, яка враховує невизначеність. Замість фіксованого плану на квартал — rolling-wave planning, що уточнюється в міру надходження даних. Це ближче до Waterfall і Stage-Gate, ніж до звичного Agile, і саме тому підхід комерційного ІТ тут не масштабується напряму.
Компонент, який завтра має прийти зі складу, може виявитись під санкціями або з lead time у пів року. Project manager у miltech працює з long-lead items, будує dual-sourcing стратегії і тримає в голові логістику як постійний фактор ризику, а не форс-мажор.
Класичний ІТ PM рідко стикається з ситуацією, коли рішення про постачальника ухвалюється на місяці наперед і впливає на весь виробничий план. Тут це щоденна робота.
Jira і MS Project нікуди не діваються, але додається RAID-лог, decision log та ескалація до рівня, якого класичний ІТ-проєкт зазвичай не потребує. RACI прописується детальніше, бо команда multidisciplinary: інженери, виробництво, testing, логістика.
Переговори теж інші за складом учасників. Defence project manager веде діалог не тільки з розробниками і продактом, а й з leadership та military чи government-стейкхолдерами. Це люди, які ухвалюють рішення за іншою логікою і з іншими пріоритетами, ніж продуктова команда. Рішення тут часто доводиться приймати за неповних даних, зважуючи trade-offs і ризик-апетит, а не чекаючи, поки з'явиться повна картина.
Failed test у полі, зміна вимоги в останній момент, incident після deployment — усе це нормальний хід проєкту, а не аварійна ситуація. PM у defence веде діагностику, ескалацію, rebaseline і кризову комунікацію так само системно, як звичайний PM веде ретро після спринту.
Різниця в тому, що ціна помилки тут вища. І в тому, що after-action review не формальність для галочки, а джерело даних для наступного циклу.
Найчастіше PM або технічний менеджер з класичного ІТ, який хоче вести проєкт повністю, а не тільки координувати спринти. Інколи інженер, що виріс в управлінську роль, уже розуміє hardware, але потребує системи для вимог, ризиків і звітності.
В обох випадках бракує одного й того самого: структурованого мосту між менеджерськими навичками і технічною глибиною. ІТ-бекграунд дає процеси. Інженерний — розуміння заліза. Але без обох одразу PM губиться саме там, де класичний ІТ-досвід закінчується — на межі hardware, firmware і production.
Ми проаналізували 61 реальну вакансію Project / Technical / R&D-менеджменту в українському Defence Tech і побудували на цьому програму Project Management у Defence Tech: 22 заняття, 11 тижнів, наскрізний фінальний проєкт — Defence Project Execution Pack, який захищається під живою кризовою ввідною.
Якщо хочеш зрозуміти, чи підійде тобі формат — залиш заявку на сторінці програми, і ми розкажемо деталі.
Одна з перших речей, яка дивує людину при переході в український Defence Tech, – це не складність технологій і не темп роботи. Це вимога зникнути з інтернету. У цій сфері таку практику називають OPSEC (операційна безпека) і для багатьох ролей це базове правило роботи, а не забаганка інтроверта чи корпоративна параноя.
Спеціаліст, який ще у 2023 році давав інтерв'ю Forbes і мав відкритий профіль у соцмережах, після переходу в закритий оборонний проєкт повністю зник з інфопростору. Нуль фотографій, нуль статей, почищений кеш у пошукових системах. По його імені сьогодні не знайти навіть уривка старого тексту.
Розберемо, навіщо це роблять, як це виглядає на практиці і чому не всім у defence взагалі потрібно ховатися.
OPSEC (operational security, операційна безпека) – це набір практик, які зменшують кількість інформації про людину й компанію, доступної ворогові. У класичному IT про це майже не думають: розробник відкрито вказує стек у LinkedIn, ділиться пет-проєктами, дає інтерв'ю профільним медіа.
У Defence Tech логіка інша. Тут цифровий слід спеціаліста – це вразливість не лише для нього, а й для всього виробництва. Тому процесом очищення часто керує служба безпеки компанії, а не сам працівник.
Для людини з цивільного сектору це різкий контраст. Ще вчора публічність працювала на кар'єру. Тепер вона стає ризиком і це одна з головних культурних відмінностей defence tech в Україні від звичайного IT.
Люди, які розробляють дрони, системи РЕБ (радіоелектронної боротьби) або пишуть софт для військових, – пріоритетні цілі для ворожих спецслужб. Розкриття особи може обернутися фізичною загрозою і для самого інженера, і для виробництва, на якому він працює.
Ворог діє підступно. Якщо дістати самого розробника складно, мішенню для шантажу, погроз або ІПСО (інформаційно-психологічних операцій) стають його родичі. Коли в мережі немає даних про сімейні зв'язки, цей важіль тиску зникає.
Щоб зламати систему компанії, найпростіше зламати її співробітника. Старі пости, список друзів, інформація про хобі чи улюблені заклади – готовий матеріал для точкового фішингу (spear-phishing). Немає цифрового сліду – немає за що зачепитися.
Якщо ворожа розвідка знає, хто відповідає за закупівлі у стартапі з виробництва дронів, вона може відстежити, у яких іноземних компаній ця людина замовляє мікросхеми чи двигуни – і спробувати заблокувати поставки на міжнародному рівні. Анонімність менеджера захищає весь supply chain.
Очищення цифрового сліду зазвичай проходить у кілька рівнів.
Тут є важливий нюанс, який знімає частину тривоги. Рівень секретності залежить від ролі.
Якщо ви інженер-конструктор або керівник R&D на закритому заводі – вас справді не повинно існувати в публічному просторі. Саме такі технічні ролі — наприклад, у embedded-розробці для оборонних систем — найчастіше підпадають під найсуворіший OPSEC. Але якщо ваша робота – залучати донати у благодійний фонд на кшталт «Повернись живим» чи презентувати українські технології іноземним інвесторам на виставках, то публічність стає вашим головним робочим інструментом. Це один із нетехнічних напрямів у Defence Tech, де відкритість — навпаки, перевага.
Тобто питання не в тому, «ховатися чи ні». Питання в тому, яку роль ви займаєте і які правила діють саме для неї.
Культура безпеки – лише одна з відмінностей Defence Tech від звичайного IT. Поряд із нею йдуть висока ціна помилки, ненормований темп і робота під NDA в оборонних компаніях, коли неможливо відкрито ділитися успіхами навіть з друзями. Саме ці умови роботи в оборонній компанії варто розуміти ще до того, як ви шукаєте, як потрапити в miltech.
Це не привід відмовлятися від переходу. Це привід заходити в сферу з реалістичними очікуваннями. Люди, які розуміють ці правила заздалегідь, адаптуються швидше й спокійніше – бо для них закритість не стає несподіванкою.
Саме розуміння того, як влаштована індустрія зсередини – її ролі, культура, вимоги, – ми даємо в освітніх програмах Defence Tech напряму Beetroot Academy. Спокійно, без романтизації й пафосу, з фокусом на те, як тут реально працюють.
