Агенція розвивалася, база клієнтів збільшувалася, спочатку це були полтавські компанії, згодом ми вийшли на національний рівень. Yoda Consult надавала піар-послуги на умовах аутсорсу. Нашими клієнтами, наприклад, були лідери аграрного ринку, газового ринку, паливо-мастильного ринку.
Згодом я зрозумів, що настав час рухатися далі, а саме, на зовнішні ринки. До того ж хотілося попрацювати в продукті, відчути овнерство та мати можливість сказати, що ось це твоя робота і ти це зробив. Я обрав IT саме за те, що працювати можна з будь-якої точки світу, не треба, наприклад, відправляти команду кудись, як у випадку з продакшеном.
Окрім того, я фанат Насіма Талеба, зокрема його книги «Антикрихкість». І для мене важлива ця антикрихкість – розуміння того, що за будь-яких непередбачуваних подій ти все одно залишишся у безпеці, у плані роботи у тому числі.
До того ж я розумів, що за 7 років я надто сильно приріс до агенції, приріс до соціальних мереж, до тих умінь, які в мене були. І потрібно з цим щось робити. Перехід в ІТ, рух до чогось нового, туди, де немає жодного досвіду, де немає якихось навичок, знайомств – це і був мій особистий челендж.
Мені був вже майже 31 рік, коли я вирішив змінити професію. І для початку я проконсультувався зі знайомою – Тетяною Бойченко, яка працює Chief People Officer у Beetroot. Вона порадила не думати про вік, але тримати в голові три складові успіху: фінансову подушку, англійську мову та pet-проєкти.
І це справді геніальна порада, яку я тепер і сам всім раджу. Це речі, які максимально важливі для того, щоб рухатися в ІТ.
В мене була стратегія: я звільнявся з роботи в травні 2021 року, і до кінця року в мене залишалося 7 місяців. Я порахував, що в середньому зможу в день виділяти 6-7 годин активного розумового часу на навчання, тож до кінця року в мене є 1000 годин.
Я вирішив, що витрачу ці 1000 годин на навчання, нічого при цьому не заробляючи. Але якщо за 7 місяців не отримаю роботи аналітиком, то, мабуть, це не моє, і я повернуся до комунікацій.
Розглядаючи різні професії у сфері IT, я звернув увагу саме на дата-аналітику. Чому? Тому що я, як кажуть, data geek – мені подобається працювати з даними, я себе хочу максимально оцифрувати. Наприклад, за допомогою гаджетів, я оцінюю свій сон – чи добре я сплю, біг – наскільки покращується моя швидкість, кількість споживання кисню тощо.
В мене не було великого бекграунду в аналітиці, але було зацікавлення. Коли працювали з соцмережами замовників, зрозуміло, що доводилося аналізувати якісь цифри: охоплення, вартість кліку, переходу. Але все це було на такому собі дитячому рівні у порівнянні з дата-сетами, які важать сотні гігабайт.
Враховуючи, що я живу в Полтаві, то само собою зрозуміло, чому я обрав Beetroot Academy. Я бачив, коли компанія відкривалася, як вона далі розвивалася, до того ж знав одного з засновників – Андреаса Флодстрома. На той час, за масштабами Beetroot Academy була найпершою школою для айтівців, де ти приходиш і бачиш величезні офіси, і там працює та навчається купа людей. Взагалі в мене сфера IT довгий час асоціювалася саме з Beetroot Academy.
У 2016 році я навіть встиг тут закінчити курс з фронтенду. На той час заняття проходили офлайн, тобто ти жив зі своїми одногрупниками в одному місті, особисто зустрічався на лекціях. Це дуже цікавий досвід. Для того, щоб пройти курс, потрібно було виділяти максимум часу та максимум зусиль. Але тоді я працював і, на жаль, не віддавався навчанню на 100 %.
Згодом під час пандемії коронавірусу я спробував знову піти навчатися, обрав курс Python та знову на заваді стала зайнятість на роботі, тож я покинув навчання на середині. Та через рік я знову задумався про дата-аналітику та Python – мову, яка використовується для роботи з великими дата-сетами. Для мене це був, певною мірою, незакритий гештальт. Я прагнув зрозуміти: я не закінчив курс, тому що в мене немає хисту до цього, чи тому, що роботи було багато, і важко було поєднувати її з навчанням?
Навчання тривало з травня до вересня 2021 року. Викладав у нас Олександр Солявкун. Найбільше мені сподобалася і запам’яталася атмосфера підтримки. Нас було 13-14 людей в групі, кожен намагався підтримати одне одного. Хтось навчався в університеті і хотів рухатися в ІТ, хтось уже мав якусь роботу, але хотів її змінювати. Відчуття комьюніті та того, що ми рухаємося однією дорогою, мені сподобалося.
Була частина людей, які старалися прийти на лекцію за 5 хвилин до початку. В цей час у нас тривали такі собі small talk – можна було поділитися новинами, розпочати дискусію. Навіть бувало, що коли викладач вже приєднувався, то він ще кілька хвилин не переривав наше обговорення.
Олександр викладався на 100 %, але мені на курсах завжди подобається ще й peer-to-peer комунікація, коли студенти можуть самі між собою спілкуватися. В мене було багато часу, тож я з радістю допомагав з якимись питаннями чи кодом одногрупникам, які до мене зверталися. Здзвонитися та поспілкуватися 20 хвилин – для мене це не проблема.
Ключовим для мене був курс Академії, але додатково я накидав собі план по дисциплінам, які згадувалися у вакансіях дата-аналітика. Наприклад, BI системи, які допомагають робити дашборди, мова SQL і навіть статистика. Виявилося, в університеті, де я вчився на інженера-будівельника, у нас викладали вищу математику, але статистики як такої в мене не було. Тому доводилося окремо читати книги, шукати курси, я навіть проходив підготовку до ЗНО, де була шкільна статистика. І це допомогло.
В міру навчання, список додаткових дисциплін ріс, але оскільки у мене був вільний час, мені було доволі легко проходити програму курсу, робити домашки, а решту часу витрачати на ці дисципліни.
Дивитися вакансії та подаватися на них я почав вже через місяць навчання. Річ у тім, що я 7 років не шукав роботу, та й раніше робота сама знаходила мене, оскільки я був доволі активний в медіа, і саме так мені запропонували посаду в агентстві. Тож я розумів, що, можливо, моє резюме не відповідає сучасним вимогам. Про супровідний лист я тоді взагалі вперше почув.
Я став шукати роботу, зокрема, і щоб протестувати себе. Наскільки в мене гарний профіль в LinkedIn, чи зацікавить роботодавців моє CV, яке враження справляє мій супровідний лист? Майданчики Dou.ua, Djinni.co та LinkedIn – це те нове, що я відкрив тоді для себе.
Я інколи люблю деяким людям показувати мій найперший супровідний лист і той, який допоміг мені отримати роботу. В першому було щось на кшталт: в мене немає ніякого досвіду в цій сфері, але я дуже системний, швидко вчуся, візьміть мене, будь ласка. В останньому я вже чітко розписую, хто я, що я витрачаю ці 1000 годин на навчання, і що я вже вивчив. А далі розписую по кожній вимозі у вакансії: що я знаю і наскільки я відповідаю цій вимозі, які маю докази своїх знань (сертифікати, проєкти тощо).
Пошук роботи тривав два місяці, але я розумію, що потрібно було пройти цей шлях. І це були два місяці відмов, інтерв’ю, тестових, відсутності відповіді або відразу відмов. Тодішній час, літо 2021 року, зараз називають ледь не золотим періодом українського IT. Дійсно, на ринку праці було багато пропозицій для айтівців, але це були вакансії для досвідчених фахівців. Початківцям і тоді було важко, і зараз не легше.
Найнеприємніше під час пошуку роботи – це отримувати відмови. Ти стараєшся, намагаєшся на повну викластися на співбесіді, але ти отримуєш реджект. І це демотивує. Та я придумав собі черговий челендж, певною мірою, гейміфікацію: чи зможу я за 7 місяців, які я собі виділив на перехід до нової сфери, отримати 100 відмов?
При цьому я продовжував старанно готуватися до кожної співбесіди, викладатися на повну на тестовому, тому що справді хотів отримати цю роботу. Але приходила відмова. І я такий собі думав: «Окей, +1». Насправді це здається легко – отримати відмову, насправді 100 відмов не так просто дістати. Наприклад, якщо рекрутер перестає спілкуватися, не відмовляючи, це не рахується за відмову.
Також з неприємних моментів для мене був стрес, який відчуваєш під час співбесіди. І я теж знайшов для цього рішення. Я ввів інтерв’ю з рекрутерами у свою рутину, тобто в мене майже щодня була співбесіда. Так з часом я звик. Це як починати бігати: спочатку в тебе калатає серце, тобі важко, а потім ти тренуєшся та адаптуєшся, і бігти стає все легше.
До слова, більшість моїх одногрупників чекали закінчення курсу, щоб почати пошуки роботи. А я знайшов її за місяць до закінчення навчання. Тобто вони стикнулися зі всіма «підводними каміннями» пізніше за мене і втратили якийсь час.
Тому моя порада: старатися одразу рухатися. Або ж, якщо ви все ж таки боїтеся, що ще не вистачає знань, починайте шліфувати свій супровідний лист. Шукайте знайомих, хто працює HR, Talent Acquisition, або рухайтеся на безкоштовні менторські майданчики, наприклад ADPList, там багато рекрутерів, Talent Acquisition-менеджерів. Вони безкоштовні, але треба знати англійську. А якщо у вас проблеми з англійською, то кидайте резюме та супровідний лист і починайте шліфувати англійську, бо без неї дуже складно буде.
З приємних вражень з того періоду згадую, коли отримав перший офер. Це відбулося десь через 1,5 місяці з початку пошуку роботи. І це було відчуття, що ти це можеш, що отримати роботу за новим фахом – реально.
Перші дві компанії, які запропонували мені офер, були пов’язані з фінтехом, але ця сфера мені була не дуже цікава, тож я відмовився. Третій офер я отримав від геймдев-компанії Bini Games, і я його прийняв. Я взагалі фанат Duolingo, і мені здалося, що цей український розробник розвивальних мобільних додатків для дітей чимось схожий з Duolingo. У Bini Games я спочатку працював маркетинговим аналітиком, а зараз я продуктовий аналітик.
Після того, як я сам навчався та шукав роботу, я зрозумів, що було б добре, щоб студентам ще під час курсу радили шукати менторів. Я знаю, що в Beetroot Academy є менторська програма, але вона розрахована вже на випускників. А, на мій погляд, менторство – це чудовий інструмент, яким краще почати користатися раніше, ніж пізніше.
Ментори – це люди, які вже мають досвід і які можуть тебе трошки швидше привести до цілі. Так, вони не замінять тобі сотні годин, які ти маєш витратити на навчання, але вони все одно можуть десь допомогти, десь підказати, десь навіть порадити вас якимось знайомим роботодавцям, які, наприклад, шукають фахівця-початківця.
Я свого часу прийшов з питанням про менторство до одного Data Scientist відомої української компанії. Він послався на те, що в нього немає часу, але принаймні він подивився мій навчальний план і сказав, що він виглядає доволі добре. Але під час пошуку роботи я не використовував менторство, можливо це б пришвидшило мій шлях.
1. Визначте, ким хочете бути. Можливо, ви прочитали, що фронтендер чи UX-дизайнер – це гаряча професія. Але коли ти 8 годин на день сидиш над цією роботою, вона може здатися не такою вже захопливою. Гроші – це добре, але ви маєте усвідомити, що ви цим будете займатися 40 годин на тиждень, мінімум кілька років. І робота має приносити задоволення.
2. Визначте, скільки часу готові присвячувати навчанню, і трекайте цей час. Не просто скажіть собі: «Я буду цьому приділяти цьому 2 години на день», а вимірюйте та занотовуйте час. Може статися, що тиждень пройшов, а ви собі так нічого не затрекали.
3. Робіть пет-проєкти як тільки вивчили якусь технологію, бібліотеку, мову. Це дуже важливо, адже людині без комерційного досвіду складно довести, що вона має якісь знання, навички без пет-проєктів.
4. Починайте подаватися на вакансії, щоб перевірити свої проблемні місця. Є певний процес найму співробітника, і на якомусь етапі ви будете «відпадати». Наприклад, рекрутер не буде хотіти з вами одразу говорити або поговорить, а на технічну співбесіду не запросить. Або вас запросили на технічну співбесіду, а ви погано відповідали, або добре відповіли, але тестове погано зробили. На якомусь етапі ви будете постійно провалюватися, і вам потрібно подумати, яким чином підсилити себе. Але якщо ви не почнете подаватися, ви навіть не зрозумієте, де ваше слабке місце.
5. Знайдіть ментора для швидшого руху. Зараз є купа менторських програм, платформ, зокрема ADPList (англійська, безкоштовно), TheWays (українська, плата залежно від ментора), також Women in Engineering періодично проводить менторські програми. Можна просто написати людині, за якою слідкуєте у соцмережах, щоб хоча б на півгодини-годину зустрітися з нею онлайн і проговорити свої питання.
6. Знайдіть або створіть свою маленьку спільноту колег-початківців. Це можуть бути спільноти людей однієї професії, наприклад, фронтендери, або ж кросфункціональні команди. Наприклад, з'являються проєкти на зразок #трейніроблятьстартап, де початківці різних спеціальностей разом роблять пет-проєкт для своїх портфоліо. І це буде готовий продукт, в якому кожен з них зробив свій внесок. Це відчуття належності – воно дуже допомагає, як на мене.
7. Святкуйте маленькі перемоги. Протягом цього багатомісячного шляху з пошуку роботи будуть відмови, розчарування, колись навіть захочеться все кинути. Тому важливо винагороджувати себе навіть за маленькі досягнення. Пройшов курс – окей, зробив проєкт – окей, потрапив на співбесіду (можливо вона навіть закінчилася відмовою, але ти все одно туди потрапив) – це теж окей. І ці маленькі перемоги треба святкувати, купити тортика чи випити комбучу, чи що вам до вподоби.
Якщо ви починаєте розбиратися в розробці дронів, чотири назви трапляються постійно: 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. Спокійно, без романтизації й пафосу, з фокусом на те, як тут реально працюють.
.png)
